April 11 2016

The Mobile Health Application market is glowing hot at the moment. New players are entering the market from left and right. Traditional blue chip players are moving in and new start-up's are popping up by the day. However, the medical device market is regulated market and finding out to which laws that apply for your mobile health app might be obvious. Start-up companies may not even realize that their apps are subjected by FDA regulations.



For those unsure about the legal status of their mobile health apps, the US Free Trade Comission has provided an excellent interactive online tool.

Take it for a spin right here! 

Learn more about how Aligned Elements can help with achieving regulatory compliance for your app

Request a live demo and let us show you how Aligned Elements can manage your documentation for your app

March 11 2016

On March 3rd, the 2016 revision of ISO 13485 was finally released. The new revision is essentially an evolution of the 2003 revision and includes a number of changes and clarifications.

For Aligned Elements users, a change in section 4.1.6 might have some important implications. Whereas ISO 13485:2003 did not explicitly require computer systems used in the quality management system to be validated, the 2016 edition certainly does. ISO 13485 is now finally on par with FDA 21 CFR 820 on this matter.


Computer Software Validation is used to ensure that each computer systems fulfills their intended purpose. It prevents problems with the software to reach the production environment. CSV is today used in many regulated industries and is today regarded as a good manufacturing practice.
Aligned Elements certainly fall into the category of Computer systems that must be validated according to ISO 13485:2016 and FDA 21 CFR 820. If you do not have CSV process in place, we do have some things that may help you.

Why is Aligned Elements not validated by Aligned AG?

Aligned Elements falls into the GAMP 5 Software category 4 - "Configurable Software". AE is a highly configurable software with the purpose of mapping the customers QMS, as opposed to force the customer to change his processes and templates to match Aligned Elements.
When validating a software of Category 4, it is of course the particular configuration of the software that is validated. Since each Aligned Elements customer is using a different configuration (each customer has its individual QMS), we cannot forsees which configuration our customers will use.
As mentioned, we do supply a number of useful tools to make the validation process faster.

What do I need in order to validate Aligned Elements?

Even though ISO 13485:2016 and FDA 21 CFR 820 require Computer Systems used in the Quality Management System to be validated, they do not explicitly described how to do it. This is up to each organisation to decide.
With no intention to be a complete listing, you need at least the following things:

  1. A Standard Operating Proceedure (SOP) that describes how Computer Software is validated in your organisation
  2. A validation plan, that describes:
    • INTENDED USE of the computer system in question
    • WHAT are you validating, i.e. which name, version and configuration of the software including manuals and supplier information and target environment
    • WHY are you validating this software to this particular extent (hint: the GMP Software Categories are a good starting place. A risk-based approach is also viable starting point.)
    • WHO is responsible for the software, for the maintenance of the software and who is responsible for the validation
    • HOW do you intend to validated the software, what the acceptance criteria is and in particular how do you intend to handle software errors detected during the validation
    • DELIVERABLES i.e. the documentation you intend to provide
  3. Requirements and/or use cases describing how you intend to use the Computer Software.
  4. Tests verifying that the use cases and documenting any deviations found.
  5. A Validation Summary or Report stating the result of the validation, preferably with some kind of traceability and weather the Computer Software should be cleared for use in the production environment

To make this process a bit simpler, we provide our customers with a pre-filled example validation kit of Aligned Elements that can be adapted to the individual needs of each organization.

Can Aligned Elements be used to document the validation of other systems?

Absolutely. Aligned Elements is very well equipped for documenting the validation of other systems (provided AE has been validated, of course). AE supports all steps of the CSV process, from evaluating the validation extent via checklists or using a risk based approach, documenting requirements, use cases and test cases, executing test cases, analysing the test results and finally supplying the necessary traceability reports.

Learn more about how Aligned Elements can help with achieving regulatory compliance

Request a live demo and let us show you how Aligned Elements can manage your documentation

January 29 2016

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

November 16 2015

"Defect rejected - not reproducible” - we have all experienced the gnawing feeling of closing an unreproducible defect. We suspect that the error is still in there somewhere, but without being able to reproduce it, we are fumbling in the dark. In a Medical Device context, where a considerable risk is potentially lurking in this evasive defect, we end up in a very uncomfortable spot.

To minimize these kinds of risks, it is therefore of outmost importance that defect reports contain the information necessary for timely reproduction. 


"We are all interested in getting defects fixed as soon as possible. However, more often than not, the defect reproduction takes more time than the actual fixing. The tester has a major role in providing the information necessary to reproduce a defect. However, he can only excel in this role if the underlying concepts of providing accurate diagnostic information are in place to begin with.", claims Mr.  Michael Stegmann, Chief Executive Director in the Stegmann Innovation Team. 

Mr Stegmann, having an extensive background in Medical Device Verification and Validation, singles out five critical software aspects that have a decisive effect on effective defect reporting.

Versioning of the software under test

"If the software I test is not unambiguously identifiable, the chance that the development team will be able to reproduce the defect decreases significantly. "V1.0.0.0" or "found in current trunk" will not help anyone. Sending patched dll:s back and forth is a risky practice that eventually will make your environment completely opaque. Therefore, a clear version schema of the software tested needs to be in place from day one." 

Nightly builds with versioned Installers

"Half-baked deployments from various developers will invariably deteriorate your test environment. In the end, you will simply not know what you are testing. Better to go with a centralized build system that automatically creates versioned Installers. 

In that way, all testers have a common source of versioned, predictable deployments that also correctly cleans out all files and dependencies during an uninstall. Setting up a build server does not have to be complicated or expensive. There exists many examples of free and low-priced options in the market."

 Logs, logs, logs

"Logs are one of the main diagnostic tools for finding and fixing defects. When the software developer wants to reproduce the defect, he will certainly ask for the logs. This, of course, presupposes that there exists logs in the first place.

Characteristics of a good logging concept includes:

  • Logging shall be easy to apply in the code
  • Log messages shall have timestamps
  • The Log files shall be humanly readable on any computer
  • Message severity categories to enable quick visual identification of abnormal entries
  • In multi-threaded applications, the logging shall be tread-safe
  • The logs shall be stored in an unambiguous and accessible location 
  • The log files shall be of a manageable size for viewing and sending, 500kB is a good approximation
  • Log message meta data that enables a Log Viewing Application to efficiently filter large amounts of data"

 An Error Handling Concept

"Error handling includes the anticipation, detection, resolution and communication of errors. When it comes to effective defect tracking the last word, communication, is the most important. If the developer deals with an error situation, seeming ever so improbable, a clear message of what, why and where the problem occurred, communicated both in logs and on screen, will go a long way.

Details on the error context, stack traces and probable causes shall be communicated in a way that is detectable and collectable for the tester. Only then can the information serve as accurate feedback to the developer."

Automatic Collection of Diagnostic information

"Collecting test evidence often includes the finding and bundling of log files, screenshots, PC Information, event log files, configuration file, crash  dumps etc. This is often a tedious and time consuming activity. Automating this process can greatly speed of the verification process and also make sure that the evidence collected is uniform and according to expectations. 

Integrating such a capability in the software will have the additional benefit of making it easier for users and field service engineers to collect and send diagnostic information back to the company in case a defect has slipped through the verification net."

"These aspects shall be designed and implemented in due time before verification starts. In a medical device development environment where risk management is a central factor, a solid foundation for collecting valid and accurate diagnostic information is a requirement, not an option.”

Request a live demo and let us show you how Aligned Elements can help you with your reporting


September 13 2015

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 www.iso.org."

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


googleplus facebook