Medical software development 101

Categories to be aware of

Before we start the development process, it’s important that we understand the different categories of software.

Most medical software is designed to operate on bespoke hardware and are designed with the intent of being a medical device. In this instance, the software is part of the medical device or system. This is called Software in a Medical Device (SiMD).

Example: Software that forms part of a diagnostics platform, which is run on bespoke hardware (designed for medical use).

Conversely, Software as a Medical Device (SaMD) relies only on generic hardware (e.g. a smartphone’s built-in camera, PC cloud system). The hardware has not been designed to be a medical device and, therefore, only the software itself is the medical device.

Example: If the PC software interprets testing data from a database to derive a new diagnosis and is completely independent of the medical device itself but does produce a medical result, this would be considered an SaMD.

Health software is more broadly defined as any software involved in healthcare with specific health-related purposes. Medical software (both SaMD and SiMD) is considered a sub-section of health software. This type can be standalone or be integrated within a device.

Example: If the software takes results data from a database for medical purposes but does not perform additional processing or produce results, it would be considered standalone health software. It would also be considered in this way if it was designed to view diagnostics results.

Software standards and relevant regulatory compliance

The distinction between SaMD, SiMD, and health software is recognised within two relevant IEC standards:

• IEC 62304: Medical device software – Software life-cycle processes
• IEC 82304: Health software

IEC 62304 applies to all software within medical devices, whether the device is SaMD or SiMD. It provides the lifecycle activities that must be defined, as well as the planning requirements and expected documentation types to produce while developing medical software. The standard leverages the practices of risk management during development to ensure that medical software is generated safely.

IEC 82304 applies to all health software that operates on generic hardware (smartphone, PC, etc.). Within the definitions of IEC 82304, it is highlighted that health software encompasses medical device software but mentions that the definition is significantly wider. IEC 82304 takes a system-level approach to ensure safe and secure systems as it lists the validation requirements of health software.

Both these standards refer to eachother directly. IEC 62304 has a single line reference to IEC 82304 to indicate that the system-level validation activities of SaMD are covered by IEC 82304. IEC 82304 instructs that various clauses of IEC 62304 must be followed to produce appropriate health software, in addition to its own requirements.

IEC 82304 provides a useful matrix to highlight the scope boundaries. Within the scope of medical devices, it indicates which standards apply in several conditions (NB – other standards apply to medical devices as well!).

The diagram below is adapted from IEC 82304. We can see four categories of health software split across two axes: hardware type and category. For medical devices, IEC 62304 applies. For standalone health software, IEC 82304 applies. For SaMD, both standards apply.

Software risk management

All medical devices must follow the risk management principles set out in ISO 14971: Medical devices: Application of risk management to medical devices. This sets out the processes that must be followed to ensure that risks are controlled. Software is included as part of this, as highlighted in both IEC 62304 and 82304, and key sections are dedicated to risk management planning and ensuring that risk control measures are implemented.

The types of risks that can arise due to software failure are distinct and unpredictable. One of the key messages is to assume that the risk will occur and focus on how to detect and handle these failures safely. For example, data that is transferred through wireless protocols has a risk of being corrupted. If that data is used to form the basis of a diagnosis and corruption causes this to change, it could result in an entirely different treatment being applied. This risk can be managed safely by designing your software to account for these risks.

Many aspects of risk management come from the experience of your development team, advice from international standards, and best practice within the industry.

The medical software development process

One of the key components of this process is that it defines a development lifecycle. The lifecycle begins a long time before the first line of code – it involves a large amount of planning: how will you manage your requirements? How will you manage front end design work? What test methods will you apply?

Each organisation defines their specific development lifecycle based on guidance from IEC 62304, industry best practices and organisational requirements. Typically, these will be adaptations of a waterfall process (whereby each activity cascades from one to another) or an agile process (whereby development occurs in incremental steps), or some hybrid of these approaches.

The lifecycle activities are there to ensure that before implementing your software, you have formed a strong design, understand the risks associated with it and have planned how you will develop your software.

Software validation

Medical devices have many functional parts and each one is verified to determine whether it performs correctly to the defined specification. Validation is then performed to ensure that the device executes its intended function with the intended user group.

In the case of SiMD, we release verified software to be used within the overall medical device where it can be integrated and validated. In this case, you do not validate it directly as validation is performed against the device as a whole.

With SaMD, the software itself is the medical device and, therefore, validating the performance is in the scope of the software. In practice, whether validation applies to the software or a physical device doesn’t matter. For example, for both a diagnostic device and diagnostic SaMD, we might test the performance using known reference data or samples. If the results reported by the device match the expected results in the reference data set (within an acceptable tolerance), then this validation test will pass.

What might differ between SiMD and SaMD is the types of validation, where for SiMD a physical device may require laboratory testing as part of validation but may not be appropriate for SaMD.

Configuration and maintenance

If you are planning to release a medical device, you are required to collect information about device failures and issues in the field post-market surveillance. These include issues commonly known as ‘bugs’. Before releasing health software and SiMD, you must plan how you will maintain your software once it is in the field.

• How do I collect information about failures?
• How do I assess the risks posed by these failures?
• How do we implement fixes?
• How do I release fixes or patches to users when needed?

These questions form part of your maintenance process and are things that you should be doing, even if your application is not part of a medical device. You should be considering these questions early in your development cycle to ensure that the software has been designed with these maintenance requirements in mind.

As with all medical software development activities, you need to follow a risk-based approach. Each time a bug is fixed, there is the possibility that a new bug is introduced with unknown consequences. Your maintenance and development processes will need to focus on testing your product adequately and risk assessing all changes before implementing them. By doing this, you reduce the risk of failures on release and ensure that your products are well received by users.

Similarly, your software will rarely exist in complete isolation, even SaMD. For example, it may integrate with an independent cloud system that provides input data. What happens if the format of this input dataset changes? How will your product adapt to this? Can it adapt without being updated? What if a new partner wants to integrate your software into their system? Will you be able to update your product to support their interface definition?

For this reason, you must understand all the items that can impact your software (known as configuration items). You will need to record the versions of items and understand what makes them so important. That way, when these configuration items are updated, you can risk assess changes that have occurred and determine which ones (if any) are needed.

These configuration items can include Software of Unknown Provenance (SOUP) libraries, which you use to reduce your development timelines. If the owner releases an important security update, you will need to be aware that the change has happened, respond to the change and release your updated software in a reasonable time frame.

Wrapping up

As all applications are highly specific to their tasks, it is very difficult to say exactly what must be done for all development projects. This article provides an overview of the activities involved in the development of your medical software. We have mentioned the themes that need to be considered during development, one of which is key – risk management.

At Team Consulting, we have developed many innovative technologies over the last 30 years, including medical software applications such as a powerful diagnostics platform and a portable liver perfusion system. Our software engineers understand the specific needs for medical software and can help you with your next programme. If you would like to talk about which categories of health software are involved, or if you have any questions, please contact us at info@team-consulting.com.