5 quick questions on IEC 82304

Christian Kaestner at Qadvis, is an expert company offering quality and regulatory services for medtech companies, and co-author of the upcoming standard "IEC 82304-1: Health Software - General Requirements for product safety." We were fortunate to get a few minutes of his time to answer five quick questions about the standard and its implications.

What is IEC 82304 all about?

"The purpose of the standard is to establish product requirements for standalone software, i.e. software products not running on a dedicated hardware. IEC 82304-1 could be seen as an equivalent to IEC 60601-1 with the difference that the later includes a dedicated hardware for the software to run on. (And of course have a lot of hardware requirements!)"

But isn't this already covered by IEC 62304?

"No, IEC 62304 is a process standard and as such “only” defines expectations on activities and their corresponding outputs. The key scope of IEC62304 is the lower part of the traditional V-model while IEC 82304-1 takes the complete product lifecycle into account. This means that IEC 82304-1 establish product requirements which isn’t addressed by IEC 62304, examples:

  • Product requirement, like intended use and accompanying documents.
  • Product validation
  • Decommissioning of software (and its data!)

IEC 62304 is of course referenced by IEC 82304-1 for the development of the actual software."

Which companies are affected by IEC 82304? How can I find out if my company is affected?

"The scope of the standard is health software which is a broader term than medical device software. So, I would suggest any company working with medical device software (standalone) or software in the surrounding of medical device products to have a look at the standard. As a rule of thumb; you could say if your company develops software which might have an impact on the health/wellbeing of a human, I would say you are affected.

Below some examples which I believe should be included in the scope of health software:

  • Prescription management systems - If the data is mixed up in anyway it may result wrong doses or even wrong medication to a patient.
  • App keeping track of your medication (as one example) - If you use the app to avoid forgetting you medication or by mistake take it twice. This would of course not be good follow the instructions and the instructions are wrong.
  • Software tracking “safe periods” to avoid pregnancy - Assuming the software counts wrong and gives green light when it shouldn’t… I can imagine the surprise in a month or so isn’t very popular!"

What is your advice to companies that needs to implement IEC 82304?

"To be fair; all standards are voluntary so there is no requirement or need to comply with IEC 82304-1. But as for all other standards it is a good praxis and gives your company a quality mark otherwise hard to claim.

My advice to companies with regards to IEC 82304-1 is to take advantage of it; it will support you in what is required to make standalone software to a product."

When will the standard be released and where can I get a copy?

"So far, the standard isn’t published, it is currently out for review (DIS, draft international standard). Depending on the result of the voting, a FDIS may be ready Q2 2016. Usually the difference between a FDIS and the final version should be marginal. The final version can probably be expected late Q3 2016. (But, it all depends on the results from the voting process.)

Should you be interested already today, you can purchase a copy of the draft standard at"

If you want to know more about how to prepare for IEC 82304-1, contact Christian Kaestner at This email address is being protected from spambots. You need JavaScript enabled to view it..

IEC 82304

Learn more about how Aligned Elements can help you support IEC 62304

Request a live demo and let us show you how Aligned Elements can help you to comply to IEC 62304


How Software Safety Classifications changed in IEC 62304:2015 Amendment 1

The first amendment to the IEC 62304 was released in June 2015 and contains some welcome contributions, including:

  • Clarification on the scope of the standard
  • Information on how to approach Legacy Software
  • Increased number of clauses applicable to Class A

There was also some interesting changes made to Software Safety Classifications in section 4.3.

For those familiar with the original IEC 62304 text, the following section describes to assign a Software Safety Classification:

"The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B, or C) according to the possible effects on the patient, operator, or other people resulting from a HAZARD (being a potential source of Harm) to which the SOFTWARE SYSTEM can contribute.

The software safety classes shall initially be assigned based on severity as follows: 

Class A: No injury or damage to health is possible

Class B: Non-SERIOUS INJURY is possible

Class C: Death or SERIOUS INJURY is possible

If the HAZARD (i.e. the potential source of harm) could arise from a failure of the SOFTWARE SYSTEM to behave as specified, the probability of such failure shall be assumed to be 100 percent."

This is essentially saying that severity alone decides the classification of your software system/item/unit. Since there is no consensus on how to determine the probability of software failure, the probability of a failure to occur is assumed to be 100%, effectively eliminating the probability factor from having any kind of influence on the software safety classification. 

Now, software in itself has never killed anyone. When harm occurs due to a software failure, there is always some other executing agent involved, e.g. some piece of hardware or a human actor. Consequentially, for harm to occur, there must exist a causal chain of events, tying the software to the harm via that external agent. A causal chain of events occurs with some probability, sometimes called probability of harm.

Probability of harm did not play any prominent part in the original release of IEC 62304 and focusing by effectually removing the probability of failure from the equation due to the difficulties of establishing it in quantitative terms sometimes lead to more or less absurd results. 

In examples where failure have severe consequences but are extremely unlikely to result in any kind of harm, the software safety class is C according to IEC 62304:2006 (if no hardware mitigations exist), regardless of how unlikely the risk of harm is.

And here is where the authors of the IEC 62304:2015 Amendment 1 have done a great job reformulating the Software Safety Classification section.

The IEC 62304:2015 Amd 1 section 4.3 point a) now reads:

"a) The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B, or C) according to the RISK of HARM to the patient, operator, or other people resulting from a HAZARDOUS SITUATION to which the SOFTWARE SYSTEM can contribute in a worst-case scenario as indicated in Figure 3.

IEC 62304 2015 1

The SOFTWARE SYSTEM is software safety class A if:
the SOFTWARE SYSTEM cannot contribute to a HAZARDOUS SITUATION; or
the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which does not result in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM.

The SOFTWARE SYSTEM is software safety class B if:
the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM and the resulting possible HARM is non-SERIOUS INJURY.

The SOFTWARE SYSTEM is software safety class C if:
– the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM and the resulting possible HARM is death or SERIOUS INJURY.”

The pivotal point lies in the use of the terms "RISK of HARM" and "unacceptable risk". RISK, in this case, being a combination of severity AND probability.

Now, the probability of harm, (the probability that someone gets hurt) is different from the probability of failure (the probability that the software malfunctions).

The combination of these two probabilities becomes the probability of occurrence of harm. IEC 62304:2015 Amd 1, explains this further in section B4.3 and also includes a Figure (B.2) from ISO 14971.

IEC 62304 2015 2

This means that it makes sense to incorporate both the probability of failure and the probability of harm in our risk assessments. We will still stay true to IEC 62304:2006 by setting probability of failure to 1 (100%) (and avoid the problematic discussion of the probability of a software failure) and concentrate our efforts on correctly estimate the probability of harm.

The amendment of the standard also claims clinical knowledge might be necessary to correctly estimate that the probability of harm following a hazardous situation, in order to “distinguish between hazardous situations where clinical practice would be likely to prevent HARM, and hazardous situations that would be more likely to cause HARM.” This certainly makes sense since the casual chain of events leading from a hazardous situation to a harm typcially takes place in a clinical context. 

There are also further complications. Where it previously was sufficient to map severity to the  “no injury”, “non-serious injury” and “serious injury” categories, which is fairly straight forward, we now have the additional possibility of bringing in the risk's accetability into the picture.

Establishing severity and probability is one thing that can be done fairly objectively, but in a rational manner argue why a particular combination of these factors is “unacceptable” or “acceptable” is subjective at best, opening the software safety classification establishing to an amount of arbitrariness. On the other hand, "unacceptable" and "acceptable" risks are terms defined in ISO 14971 and should therefore not be new territory to the average medical device manufacturer.

The software safety classification method in IEC 62304:2015 Amendment 1 has certainly become more intuitive. The price for this change lies in the extra effort of:

  1. Establishing the probability of harm following a hazardous situation, with the involvement of clinical expertise if and where applicable.
  2. Establish and rationalize what makes a particular risk limit acceptable or unacceptable, if not already defined in the general risk management process. 

To finalize this discussion on Software Safety Classification in IEC 62304:2015 Amd. 1, I would like to point out sections in the standard that have received some welcomed clarifications.


The new version of the standard amends that segregation of software items does not necessarily have to be physical. In the 2006 version, the only segregation exemplified was hardware related, which has lead to the false belief that segregation between items has to by physical. This is not the case. The 2015 Amendment makes it clear that the main concern is to assure that one item does not negatively affect another. Furthermore, the segregation applied shall make sense in the context it is used as well as clearly documented and rationalized.

Software Items implementing risk controls

A software item implementing a software risk control (i.e. not external risk controls which can have a positive effect on the classification) shall be assigned the same software safety classification as the software item containing the risk it is controlling. This idea is applicable not only on System level (as described in the 2006 version) but also Item/Unit level.

Learn more about how Aligned Elements can help you support IEC 62304

Request a live demo and let us show you how Aligned Elements can help you to comply to IEC 62304

IEC 62304: Unit tests are not Unit tests

Sometimes when I ask development teams about their Software Unit verification, they fire up Nunit (or MSUnit or some other unit test tool) and say “Look here, we have more than 1800 unit tests with a test coverage way over 70%! Regarding Software Unit tests, we are certainly well covered!”

It is obvious to readers that the guys who wrote IEC 62304 explicitly tried to stay away from established software notions. You don’t see any “components”, “classes”, “modules”, “diagrams”, “dlls” or “objects” in the text (at least not in the english version). The authors did this on purpose in order to stay out of the nitty-gritty details of software development, to not make any technical prescriptions and avoid a minefield of interpretations of concepts existing since decades. 


That’s why the norm speaks of software development in tech- and methodology-neutral terms. We have “architecture”, “items”, “interfaces” and “versions”. And, unfortunately, “units”.

This is just about the only notion where there seems to be confusion. Maybe not about units per se, but certainly about “Software Units verification”, which in some companies is translated to “Unit Testing”.

What is a “Unit”?

Unit testing was popularized by the practice of Test Driven Design and extreme programming in the late 90’s. JUnit was the first xUnit testing framework getting widely used and the concept was reused for other development stacks. The xUnit testing frameworks have since then evolved and is today widely used for automated testing in many industries, including the medical device industry. Over time, the frameworks have become increasingly versatile and are today used far beyond the original scope of classical unit testing. 

IEC 62304 defines the Software Unit as an Software item “not subdivided into other items”. According to the standard, it is up to the manufacturer to decide the granularity of items and therefore also the criterion for divisibility, making the definition somewhat arbitrary. Members of the medical device commuicty has through lengthy discussions tried to agree on practical interpretation of what a "Software Unit" is. Suggestions include:

  • Class
  • File
  • Package
  • Namespace
  • Module

Unfortunately, there seems not to be a commonly accepted definition. This leaves us, the implementers of the standard, with much freedom and little support. 

Regardless of the manufacturers definition of the “Software Unit”, the standard do require the unit to be “Verified”. Again, the IEC 62304 leaves it up to the manufacturer to define according to which acceptance criteria and through which means the verification shall be conducted.

Note that the verification of a Software Unit does not necessarily has to be a test (depending on the software safety classification). The verification strategy can be a walkthrough, inspection, review, results from static testing tools or anything else that is valid and appropriate for the Software safety classification of the unit. Furthermore, the verification strategy, methods and acceptance criteria are permitted to vary from Unit to Unit as long as this is appropriately documented.

Let’s now move the focus from the definition of a “Software Unit” in IEC 62304 to the definition of a “Unit” in classical "Unit Testing". Wikipedia suggests several definitions (which are all variants of the word “small”) but conclude that at the business end of unit testing, we find a piece of code that can be tested in isolation. This is in general a much finer level of granularity than "Software Units" in IEC 62304. Whereas a “Software Unit” in IEC 62304 is an architectural building block, a “Unit” in Unit Testing is simply something that can be tested in isolation with no explicit relation to the software architecture.    

Thus, summary so far:

  1. A “Unit” as in Unit Testing is not the same thing as a “Software Unit” in IEC 62304.
  2. A Test being executed in a xUnit Testing Framework does not automatically make it: 
    1. a classical Unit Test
    2. a Software Unit Verification.
  3. A Software Unit can be verified by other means than tests (depending on the software safety classification).

 “But I really want to use my xUnit Tests for Software Unit Verification! What do I need to do?”

It is of course entirely possible to use unit tests run by an xUnit Testing Framework (or manually if preferred) as a verification method for Software Unit. However, the tests themselves are only a part of the required deliverables. Be careful to:

  • Document the test strategies, the test methods and the procedures used.
  • Evaluate the procedures for adequacy and document the results.
  • Establish and document acceptance criteria (more rigid for class C than A and B, see IEC 62304)
  • Perform the tests and document the result.
  • Explicitly evaluate if (and document that) the results fulfill the acceptance criteria.

Learn more about how Aligned Elements can help you support IEC 62304

Request a live demo and let us show you how Aligned Elements can help you to comply to IEC 62304

Medical Device Documentation: but what (exactly) shall I write?

Documenting the design controls for a medical device is a mandatory exercise in our industry. Regulations descibe what the documentation must show. Standards describe harmonized ways in which regulations can be fullfilled. Your quality management system should, in best case, describe which process you need to follow in order to satisfy the standards and regulations and finally your company templates are what you use to finally pen it down.

However, regardless of the multitude of support systems, at the end of the day some of us given the task to provide a document, will sit down in front of the computer and think: 

But what exactly should I write?

Here is where we can help. The Aligned Elements Extension section contains more than 50 importable plug-and-play content packages that can help you accelerate the documentation process by leaning on collected experiences and best practices. Our extensions examplifies how Aligned Elements can be used to solve ubiquitus medical device documentation problems.


These extensions contain things like:

  • Example Design Controls such as 21 CFR Part 11 Requirements, ISO 14971 Harms etc.
  • Ready-made configuration packages for e.g. IEC 62304 and IEC 62366
  • Regulatory Wizards, such as finding out if your software is a medical device
  • Queries
  • XSLT - transformations to transform Aligned Elements into a desired output format

To make this even better: all extensions on our website are free to our customers.

Today, we added a new package of 120 Infusion Pump requirements examplifying the Design Input for an Infusion Pump device. Let us help you. If you have questions about our extensions, please This email address is being protected from spambots. You need JavaScript enabled to view it. for more information.

The Aligned Elements IEC 62304 configuration

The "IEC 62304 – medical device software – software life cycle processes" is a standard specifying life cycle requirements for the development of medical software and software within medical devices. 

This international standard is harmonized by the EU and USA and therefore can be used as a benchmark to comply with regulatory requirements from both these markets.

Software development according to IEC 62304 is a risk-driven approach, requiring the developer to perform reliability- and safety enhancing actions and tasks proportional to the risk the software poses to the patients and users.

Getting compliant with IEC 62304 may seem daunting at first. The Aligned Elements IEC 62304 configuration has been set up to guide you through this process and has been tuned to automatically take care of most of the involved quality checks, making sure that the required tasks and actions are sufficiently covered.

The Aligned Elements IEC 62304 configurations contains:

  • Pre-configured templates using IEC 62304 standard naming conventions
  • Software Safety Classification automatically based on risk analysis results
  • Numerous quality checks for consistency verification
  • Pre-configured Reviews and checkpoints according to IEC 62304 stipulations
  • Pre-configured Trace Tables based on the IEC 62304 requirements
  • Included Process-checklists for documented verification of process compliance

The Aligned Elements IEC 62304 supports documentation management of:

  • System and Software Requirements
  • Software Architecture building blocks(Software Items, Units SOUPs and segregations)
  • Risk Management using a Preliminary Hazard Analysis technique (listed in ISO 14971)
  • Verification and Validation (Unit, Integration and System testing)
  • Change and configuration management (Problem Reports and Change Management)

On top of all that, the Aligned Elements IEC 62304 includes all the standard features of Aligned Elements, including:

  • Completed change control of all Design Control Items
  • Complete audit trail for all changes
  • Keep your company specific look and feel of all report outputs
  • End-to-end tracability with real-time impact analysis
  • Easy and fast Word reporting using drag and drop
  • FDA QSR 21 CFR Part 11 compliant User Management
  • Efficient decision-making process using workflows and E-signatures

By applying selected parts of the Aligned Elements IEC 62304 configuration to your Aligned Elements setup, you can efficiently leverage Aligned Elements in your IEC 62304 compliance effort.

The Aligned Elements IEC 62304 configuration is available for download in our extension library.

For a live demonstration of the Aligned Elements IEC 62304 configuration, please This email address is being protected from spambots. You need JavaScript enabled to view it. to set up an appointment.

The IEC 62304 Matrix Model in Aligned Elements

I say "IEC 62304 Software Safety Classification", you say "A, B, C".

If you have worked with IEC 62304, you have (probably) also faced the challenge of assigning Software Safety Classifications to the Software Items. It has to do with associating a risk level to your software items in order to assess how careful you need to be when you document, develop and test them.

Now, if you work with medical device development, it has probably dawned to you that you are already doing risk management. Lots of risk management. All sorts of risk management. Is it possible to use the existing risk assessments when doing our IEC 62304 work? Yes, I think so.

When a software designer/architect constructs the software architecture needed for IEC 62304, there are lots of approaches to choose from. The norm is explicitly ambiguous on this point. In short, it is up to you to pick an approach. It is however not uncommon for the software designer to use established modelling techniques such as UML, Object-oriented design, multi-layered design, SAAS etc. which in most cases results in number of boxes (the software items) with names like:

  • User Interface
  • Logging
  • User Management
  • Reporting
  • Data Access Layer
  • Persistence
  • Serial Communication etc.

So are we supposed to perform a risk assessment of these boxes now?

What strikes you immediately is the insight that these boxes in themselves do not "have" risk. Why? Because we have not defined the context in which they are used. Software risk emanates from how we use the software i.e. in which functional aspect we use the software items.

The guys of Certified Compliance Solution have solved this in a really neat way using what they call "The Matrix Model for Software Safety Classification". It is well summarized in the picture below.



The CCE people have correctly identified that functional flows cut accross the software architecture.

In their model, Software Items are listed on the horizontal axis and User stories (or Epics, Use Cases, Work Flows, Specification or whatever you want to call them) are listed on the vertical axis. Now, risk assessments for User Stories is something we do every day so that part should be pretty straight-forward. Once that is completed, we can deduct a classification for each User Story based on this risk assessment (more about that later).

The Software Designer can now point out the Software Items that implements our User Story in the software. After we have done this for all User Stories, the software Safety Classification for a Software Item is simply the highest risk of its aggregated use, which is summarized in the bottom line "Overall SW Item Safety Class".

Isn't it beautiful?

Let me show you how this is implemented in Aligned Elements.

First, I introduce the Document Object type "Use Case" which will represent the user stories. Then I set up Document Object types for Software System, Software Item, Software Unit and SOUP which all have a Software Safety Class attribute being A, B or C, with the default value C.

I can then proceed to document the Use Cases and structure the Software Architecture separately.

Now, time for risk assessment. I will use the integrated Preliminary Hazard Analysis (PHA) to assess my Use Cases. When working out the risks using the PHA method, I am requested to define the possible Cause(s) for each risk. The Cause has a severity attribute and I will use this severity to calculate the Software Safety classification. If the Cause is emanating from the software, I further tag the Cause originator as "Software".


I go back to the Software Item definition and map the values A, B and C to a Severity range in the Cause i.e. a Severity from 1-3 maps to Class A, Severity 3-5 maps to Class B etc.

To tie it all together, I trace the Use Cases to the PHA risks and (here comes the trick) Software Items to the software originated Causes.




I run an Inconsistency analysis on the Software Items and get a report on how well the Software Item Safety classifications match the risk assessment, including suggestions on what the Software Safety Classification ought to be based on the associated risks.




Simple, transparent and consistent.

So we have a range benefits from this approach:

  • We perform risk assessment where it makes sense i.e. to Use Cases.
  • When we map use cases to software items via the risks, automatic checks that ensure that the maximum severity of the risks match to the software item safety class.
  • We have reused the use case risk assessment in our IEC 62304 implementation.
  • We have used traces to establish the relationships between use case, risk and software items and automatically get the required traceability for free.

Once again we have showed the benefit of integrating all Design Control Items in a single system.

The sum is truly greater than its parts.