MDCG 2023-4 provides a key regulatory framework for medical device software (MDSW) that require hardware or hardware components (which often are not medical devices) for their intended use. However, how about MDSW that require non-device general-purpose software (operating system, browsers, etc.)? This blog post takes a new angle on MDCG 2023-4 and extends its key principles for the combination of MDSW with non-device general-purpose software.
In 2021, a software update to Android operating system caused a manufacturer’s insulin pump to malfunction, potentially putting patients at serious risk. The update changed the way the pump’s companion medical device software (MDSW, or software-as-a-medical device, SaMD) mobile phone app communicates with the pump, preventing the pump from timely delivering insulin to patients. The issue was discovered by patients who noticed that their blood sugar levels were rising rapidly and was quickly brought to the attention of the manufacturer. Fortunately, the manufacturer was able to issue a patch rapidly to fix the issue before any severe harm occurred, but the incident highlighted the potential risks stemming from third-party non-device software for MDSW.
Early in October, the EU published the guidance document MDCG 2023-4 on MDSW intended to work in combination with hardware or hardware components, including smartphones and wearables. The guidance document outlined 3 regulatory options for the MDSW-hardware combination, namely:
- Hardware is placed on the market as an accessory to the MDSW
- Hardware is placed on the market as a medical device either as part of a system (MDR Art. 22), as a combination with another medical device (MDR Art. 2(1)), or as an integral part of a medical device
- Hardware is an integral part of a consumer product and is not a medical device nor accessory and has no intended medical purpose.
For options 1 and 2, the hardware is classified as a medical device accessory or a medical device, and therefore needs to demonstrate full compliance with MDR. For option 3, the hardware remains a general-purpose consumer product, but the MDSW manufacturer is responsible for the safety, performance, and reproducibility of the hardware in supporting the MDSW’s intended medical purpose, and the combination, as a system, is subject to MDR conformity assessment.
While the guidance focuses on MDSW-hardware combinations, it is reasonable to conclude the same principles can also be transferred to situations where the combination is with another software -- a non-device general-purpose software. For example, operating systems or web browsers. However, on the practical level, it might not be feasible for an MDSW manufacturer to seek full MDR compliance for general-purpose non-device software. This leaves option 3 as the most viable option for MDSW-non-device software combinations in real-world practice.
Relevant Concepts from the Guidance and their Extensions to Non-device Software (based on Section 5, Option 3)
- The manufacturer of the MDSW is responsible for the safety, performance, and reproducibility of any non-device hardware supporting MDSW’s intended medical purpose. The same also can be applied to non-device, general-purpose software. This means ensuring proper risk management, performance testing, cybersecurity, and post-market surveillance in the context of the MDSW system for any non-device software the MDSW relies upon. MDSW manufacturers cannot absolve themselves of the regulatory responsibilities for general-purpose software because of its non-device nature.
- MDSW’s risk management processes should cover risks arising from the non-device hardware and its interaction with the MDSW. The same would apply to non-device software. Software anomalies, usability issues, cybersecurity vulnerabilities, and version changes in non-device software can all introduce hazards to the MDSW. The manufacturer needs proactive risk management for the entire system.
- MDSW manufacturer must demonstrate clinical evidence for all intended configurations (e.g., all platforms the MDSW is running on). The same would also be true for software configurations or platforms.
- Post-market surveillance must monitor the safety and performance of the non-device hardware. The same also would apply to non-device software combined with MDSW. Adverse events need to be analyzed in the context of the entire system
- Changes to the non-device hardware could impact the safety and effectiveness of the MDSW. The same is also true for non-device software. Updates of non-device software can happen frequently, and each may introduce safety and/or performance issues to the MDSW. The MDSW manufacturer needs mechanisms to stay abreast of changes and timely assess their impact through regression testing.
Implications for Manufacters
- Understanding the regulatory status of all software, both device and non-device, in the MDSW system that may have an impact on the safety, performance, reproducibility, interoperability and/or compatibility of the MDSW. Inventory all dependencies and list them clearly in the technical documentation.
- Ensuring traceability of non-device software the MDSW relies on. Record version information at a minimum.
- Implementing comprehensive risk management pre- and post-market for both MDSW and non-device software. Take a systems approach covering risks across components.Maintaining non-device software under configuration control as part of the MDSW. The control strategy shall scale with the risk of the non-device software in the MDSW system in determining whether the manufacturer should exert full control over the non-device software.
- For non-device software that may lead to risks that are unacceptable according to the device’s risk management plan, consider implementing total control of the non-device software. For example, shipping together with the MDSW a dedicated hardware platform that does not allow any change of the non-device software without MDSW manufacturer’s permission.
- For non-device software that may lead to risks that are acceptable, the manufacturer may allow MDSW to run freely on general purpose hardware platforms in which the users can change the non-device software. In this case however, the MDSW manufacturer shall establish a change management and notification processes with non-device software vendors. Many of such vendors do offer preview/beta builds to developers prior to an update’s public release. The manufacturer should closely monitor any upcoming updates and perform regression analysis/testing with the beta version prior to the update’s public release.
Of course, there can also be other solutions for configuration control involving non-device software. For example, implement a version checking mechanism in the MDSW for the non-device software and take appropriate actions if an unverified version is encountered. The ultimate choice of the control strategy boils down to risk and design properties of the MDSW and the non-device software concerned. Potentially, the choice can also be influenced by compliance with other applicable regulations or business reasons.
- Collecting and assessing clinical data that spans the intended combinations of MDSW and non-device software.
- In post-market surveillance, actively and systematically monitoring and assessing information on non-device software concerning its combination use with the MDSW.
The principles from the hardware oriented MDCG guidance also provide a good regulatory framework for MDSW combined with non-device general-purpose software. Practical guidance for implementation can be found in standards such as IEC 82304-1, IEC 82304-2, and IEC 81001-5-1. As software permeates healthcare, a holistic view of the entire digital ecosystem supporting the intended purpose of an MDSW will be increasingly important. As they say in Spain “Hacen falta dos para bailar un tango”. Do you know your non-device partner well in your MDSW dance?
Do you have questions or need assistance with the control of non-device software in combination with your MDSW? Reach out to us! Our software and regulatory experts would be happy to work together with you to analyze your use case and develop a practical strategy to ensure the safety, performance, and compliance of non-device software in the ecosystem of your MDSW.