Medical Software Development 101 | Cambridge Network
Categories to know
Most medical software is designed to run on custom hardware and is designed with the intent of being a medical device. In this case, the software is part of the medical device or system. This is called software in a medical device (SiMD).
Example: Software that is part of a diagnostic platform, which runs on bespoke hardware (designed for medical use).
Conversely, Software as a Medical Device (SaMD) relies solely on generic hardware (e.g., built-in camera of a smartphone, PC cloud system). The hardware was not designed to be a medical device and therefore only the software itself is the medical device.
Example: If PC software interprets test data from a database to derive a new diagnosis and is completely independent of the medical device itself but produces a medical result, this would be considered a SaMD.
Healthcare software is any software involved in healthcare for specific health-related purposes. Medical software (SaMD and SiMD) is considered a subsection of healthcare software. This type can stand alone or be integrated into a device.
Example: If the software pulls results data from a database for medical purposes but does not perform any additional processing or produce results, it would be considered standalone health software. It would also be considered as such if it was designed to visualize diagnostic results.
Software standards and relevant regulatory compliance
The distinction between SaMD, SiMD and healthcare software is recognized in two relevant IEC standards:
IEC 62304 applies to all medical device software, whether the device is SaMD or SiMD. It provides the lifecycle activities that should be defined, the planning requirements, and the types of documentation expected to be produced when developing medical software. The standard relies on risk management practices during development to ensure that medical software is generated safely.
IEC 82304 applies to all healthcare software that runs on generic hardware (smartphone, PC, etc.). In the IEC 82304 definitions, it is pointed out that healthcare software encompasses medical device software, but mentions that the definition is significantly broader. IEC 82304 takes a system-level approach to ensure safe and secure systems as it lists the validation requirements for healthcare software.
These two standards refer directly to each other. IEC 62304 has a single reference line to IEC 82304 to indicate that SaMD system level validation activities are covered by IEC 82304. IEC 82304 indicates that various clauses of IEC 62304 should be followed to produce a appropriate health software, in addition to its own conditions.
IEC 82304 provides a useful matrix to highlight the limits of the scope. In the context of medical devices, it indicates which standards apply under which conditions (NB – other standards also apply to medical devices!).
This diagram is adapted from the IEC 82304 standard. There are four categories of health software distributed on two axes: type of hardware and category. For medical devices, IEC 62304 applies. For standalone healthcare 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 defines the processes to ensure that the risks are controlled. Software is included in this framework, as outlined in IEC 62304 and 82304, and key sections are dedicated to risk management planning and implementing risk control measures.
The types of risks that may 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 safely detect and manage these failures. For example, data transferred via wireless protocols may be corrupted. If this data is used to form the basis of a diagnosis and corruption causes this to change, it could result in entirely different treatment being applied. This risk can be safely managed by designing your software to account for these risks.
Numerous aspects of risk management come from the experience of your development teamadvice derived from international standards and best practices within the industry.
The medical software development process
One of the key elements of this process is that it defines a development cycle. The lifecycle begins long before the first line of code – it involves a large amount of planning: how are you going to manage your requirements? How will you handle the front-end design work? What testing methods will you apply?
Each organization defines its specific development lifecycle based on IEC 62304 guidelines, industry best practices, and organizational requirements. Typically, these will be adaptations of a waterfall process (in which each activity flows from one to another) or an agile process (in which development occurs in incremental steps), or a hybrid of these approaches.
Lifecycle activities are there to ensure that before you implement your software, you have formed a solid design, understood the risks associated with it, and planned how you will develop your software.
Medical devices have many functional parts and each is checked to determine if it works properly according to the set specifications.
In the case of SiMD, we release verified software for use throughout the medical device where it can be integrated and validated. In this case, you don’t validate it directly because the validation is done on the device as a whole.
With SaMD, the software itself is the medical device and therefore performance validation is part of the scope of the software. In practice, whether the validation applies to software or a physical device is irrelevant. For example, for a diagnostic device and a diagnostic SaMD, we can test performance using known benchmark 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 may differ between SiMD and SaMD are 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.
Setup and maintenance
If you plan to release a medical device, you should collect information on device failures and post-market surveillance issues in the field. These include issues commonly referred to as “bugs”. Before releasing health and SiMD software, you need to plan how you will maintain your software once it is in the field.
How can I collect failure information?
How to assess the risks posed by these failures?
How do we implement fixes?
How to release patches or fixes for users when needed?
These questions are part of your maintenance process and are things you should do, even if your application is not part of a medical device. You should consider these issues 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 should follow a risk-based approach. Each time a bug is fixed, it is possible that a new bug will be introduced with unknown consequences. Your maintenance and development processes will need to focus on properly testing your product and risk evaluating all changes before implementing them. By doing so, you reduce the chances of release failures and ensure that your products are well received by users.
Likewise, your software will rarely exist in complete isolation, even SaMD. For example, it can 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 happens 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 elements that can impact your software (called configuration elements). You will need to save versions of items and understand what makes them so important. This way, when these configuration items are updated, you can assess what changes have occurred and determine which (if any) are needed.
these configuration items may include software libraries of unknown provenance (SOUP), which you use to reduce your development time. If the owner releases an important security update, you should be aware that the change has occurred, respond to the change, and release your updated software within a reasonable time.
As all applications are very specific to their tasks, it is very difficult to say exactly what should be done for all development projects. This article provides an overview of the activities involved in developing 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 past 30 yearsincluding medical software applications such as a powerful diagnostic platform and one portable liver perfusion system. Our software engineers understand the specific needs of medical software and can help you with your next program. If you want to talk about the categories of healthcare software concerned, or if you have questionsplease contact us at email@example.com.