Triteq is making medicine safer

Developing Safety Critical Medical Apps

Ken Hall, Technical Director at product design consultancy Triteq, talks about designing iOS and Android Apps for safety critical medical devices.

IEC62304 compliance and regulatory approval in the EU for class 2b and 3 devices requires high grade software to be developed, this conflicts with the fast pace of development required for the mobile device App market.

Standards for Medical Device Design

IEC62304:2006 has emerged as the global standard for management of the software development lifecycle for medical devices. Since the App software itself can be classed as a medical device under the Medical Devices Directive (93/42/EEC) this is the standard that would be applied. This standard details the process requirements for all phases of development depending on the software classification. The software classification is divided into three classes A, B and C. A simplistic view of the software classification required gives a classification mapping directly to the device classification 1, 2 and 3. In most cases this is the starting point for software classification.

A fundamental part of the IEC62304 standard is the requirement to follow a risk based design process and the normalised standard referred to for this is ISO14971. The latest version of this is ISO14971:2012.

The fundamental problem

Using the ISO14971 standard for developing an initial risk assessment for your software will inevitably produce a conflict. App developers wish to use non-medical grade software, such as iOS or Android operating systems and their associated development tools. Furthermore they wish to run the software produced on non-medical grade and undefined hardware, such as mobile phones, tablet computers etc.

The requirements to produce a safety critical, medical grade App capable of diagnosing illnesses, defining treatment plans, or controlling life critical equipment would appear at first sight to conflict with the development environment required and the hardware platform running the software. This is because there is usually no control by the developer over the physical hardware or the software environment running the code.

Software Safety Classification

Initially the ISO62304 standard expects the manufacturer to assign a safety class to the software system as a whole.  This classification is based on the potential to create a hazard which could result in an injury to the user, the patient or other people.

The classification is divided into three simple classes 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

The definition of ‘serious injury’, ‘non-serious injury’, ‘injury’ and ‘damage to health’ is important to undertake this classification effectively. It may at first appear to be obvious what constitutes an injury, however this can be a far more complex question when the context of the device is taken into account. Unfortunately the only definition in the standard is for ‘serious injury’ and this is as follows:

Serious Injury

Injury or illness that directly or indirectly:

a) is life threatening,
b) results in permanent impairment of a body function or permanent damage to a body structure, or
c) necessitates medical or surgical intervention to prevent permanent impairment of a body function or permanent damage to a body structure

NOTE: Permanent impairment means an irreversible impairment or damage to a body structure or function excluding trivial impairment or damage.’

It is relatively simple to apply a negative to the above to derive a non-serious injury definition. However the definition of injury for use with the Class A software safety classification may be debatable. This is complex because of the lack of definition of injury or damage to health.  For example, there may be a grey area between normal side effects of treatment or a condition, rather than the device itself causing injury.

Triteq has developed procedures for carrying out this initial analysis and defining the class to be applied. In some cases, the notified body being used can affect this decision. Some will recommend that Class B is the minimum standard to be applied for any medical product as Class A safety classification does not insist on a rigorous enough software development process.  It is possible to segregate software code functions and have multiple grades of software within a software device.

Effect of the software classification on the documentation

It is important to grade the software into its correct class since the resulting documentation and process associated with development will increase with the class. This will directly reflect in the time and cost of development.

Software Documentation Class A Class B Class C
Software Development Plan Must contain contents to sections 5.1 ISO62304:2006 Must contain contents to sections 5.1 ISO62304:2006 Must contain contents to sections 5.1 ISO62304:2006
Software Requirements Specifications A software requirements specification conforming to 5.2 ISO62304:2006 A software requirements specification conforming to 5.2 ISO62304:2006 A software requirements specification conforming to 5.2 ISO62304:2006

Software Architecture

Not Required Software Architecture to 5.3 ISO62304:2006. Refined to software unit level Software Architecture to 5.3 ISO62304:2006. Refined to software unit level

Software Detailed Design

Not Required Not Required Document detailed design for software units. (5.4)
Software unit implementation All units are implemented and documented & source controlled (5.5.1) All units are implemented and documented & source controlled (5.5.1) All units are implemented and documented & source controlled (5.5.1)
Software unit verification Not required

Define process & tests & acceptance criteria (5.5.2, 5.5.3) Carry out verification (5.5.5)

Define process & tests & acceptance criteria (5.5.2, 5.5.3) Carry out verification (5.5.5)

Software integration and integration testing

Not required Integration testing to 5.6 ISO62304:2006 Integration testing to 5.6 ISO62304:2006

Software system testing

Not required System testing to 5.7 ISO62304:2006. System testing to 5.7 ISO62304:2006.

Software release

Document the version of the software product that is being released

Check and release according to 5.8 ISO62304:2006.

List of remaining software anomalies, annotated with an explanation of the impact on safety or effectiveness, including operator usage and human factors

Check and release according to 5.8 ISO62304:2006.

List of remaining software anomalies, annotated with an explanation of the impact on safety or effectiveness, including operator usage and human factors

In practice any company developing medical device software will carry out verification, integration and system testing on all software classes. However the difference is that formal detailed documentation does not need to be generated for Class A code. Cross-referencing and verification of requirements also does not need to be formally proven. This can save a great deal of time and money in software development. 

SOUP

SOUP (Software of unknown provenance) is any code (tools, or source code) that does not have any formal documentation or that was developed by a third party and has no evidence as to the controls on the development process. This code, by definition, is deemed to be capable of producing faults. The most common operating systems for mobile phones and tablets (iOS and Android) fall into the category of SOUP as do the development tools required to produce code to operate on them.

In 2006, when the standard was first adopted it was interpreted by some Notified Bodies to mean that SOUP could not be used for Class 3 devices at all. In recent years it has become commonplace to use SOUP such as this for Class 3 devices provided certain constraints are met to reduce the risk of failure.

It is important to carry out a software risk analysis on any SOUP code being proposed for the software being developed and to produce a rationale as to why this code should be used. Triteq has developed processes to identify and justify the use of SOUP in medical device software, even for the most stringent applications. Its own experience with this has proven that such processes can drastically reduce development timescales and costs

Methods of justification

In most cases, to produce software for an iOS or Android based platform that meets the requirements for Class C software, there are a number of technical issues that have to be overcome. The exact issues will depend on the functionality of the device and software being developed and these will be apparent as a result of the Risk Analysis.

The most common issues are these:

  1. The App must not be stopped, or demoted in priority for hardware resources, or have its operation suspended relative to any other applications or services running on the device. This is usually the case for software running a real-time monitoring function, which is used to alert for a critical condition, or for software having a real time response for controlling a medical device.
  2. The environment running the App must be defined, i.e. the upgrade path for the software and the operating system must be linked. In practice any automatic update of the operating system will be disabled so that the OS can only be updated with the App software.
  3. Power management functions should be controlled by the App for applications that require continuous monitoring. It should not be possible for the operating system to put the device to sleep or power off. This may mean that power management functions will need to be duplicated from within the App and relevant warnings provided to alert the user in the event of power running low.
  4. The software may be required to be deterministic. i.e. critical code functions may be required to be completed within a specific time deadline. Normally this means minimising or removing background tasks such as ‘garbage collection’. This is normally done by the same techniques as used to improve the performance of the code. i.e. Avoiding creating unnecessary objects, use static not virtual etc. etc.
  5. The application must be secure from interruption or corruption from other applications. i.e. the user should not be allowed to install or run other applications on the device while the App is running.
  6. The App should be proof against unintended use by the user. i.e. The user should be prevented from exiting the App and running anything else. Usually this means that the device will power up with the App running and not have any means of exiting the App once started.

Conclusion

ISO62304 is a well considered, logical standard for developing safety critical and high reliability Apps as medical devices. Now that this standard has been adopted it would be very difficult for a medical device software developer to justify any equivalent approach that meets the requirements of the Medical Devices Directive, without effectively complying with this standard. 

This is good news for the safety of patients, but also for the manufacturers themselves as it provides a more level playing field. There is no longer much opportunity for rudimentary software development processes and this raises quality across the board. In addition, as the ISO62304 is a harmonised standard, it means that there are more equal quality expectations between Europe and the US.

For medical device manufacturers, it is important that they select software designers who have well-established quality and risk management systems, and who have experience in developing software to ISO62304. Additionally, Triteq’s own experience has proved how valuable processes can be to analyse medical product software architecture and usage.  Such processes can greatly reduce timescales and costs for the development of medical device Apps.

Ken Hall is Technical Director at Triteq (email: ken.hall@triteq.com,
Tel: +44 (0)1488 684554, www.triteq.com).

Design

Develop

Manufacture

Let's Discuss product Design...



if you would like one of the team to contact you, please complete the form below.




Send

Copyright Triteq