Medical Device Software 

Medical devices are subject to rigorous regulations worldwide, and the same holds true for medical device software. Whether the software is part of a Hardware instrument (SiMD), stand-alone software (SaMD) or an Assessory to a medical device, compliance is paramount. This applies as well to In Vitro Diagnostic (IVD) medical devices.

The topics below summarize the main areas that need special attention and where I believe my expertise can be of value for your medical device development project.

SDLC (&TPLC)

Establish a robust Software Development Life Cycle (SDLC) that imposes a scrutiny proportional to the risk classification of medical device under development. Implement this SDLC by maximally leveraging the efficiency of modern software development methodologies and tooling but yet ensure that regulatory requirements are fulfilled. Although not a hard regulatory requirement, the harmonized IEC62304 standard can not be neglected when drafting a software development plan that addresses all expected IEC62304 processes, activities, tasks and design controls as per ISO13485 or 21CFR820.30. Because the scope of IEC62304 is limited to development - be it for initial or a maintenance release - additional activities must be considered in such plan like usability engineering (IEC62366) and SW validation activities. For a SaMD product one can use IEC82304-1 for organizing this. For a SiMD system these activities are typically covered by the device development processes (ref to the IEC60601 series).

With MDR/IVDR and FDA increased emphasis on post market surveillance and cybersecurity, focus is shifting from SDLC to a broader scoped Total Product Life Cycle (TPLC) approach. These evolutions need attention when starting a new product development project.

Risk Management

MDSW risk management is a complex subject. While the ISO14971 harmonized standard provides essential principles for device safety risk management, additional activities are crucial to address all hazards that are inherent to software and connected devices.

Activities to be considered in the risk management plan relate to the following: consider security risks as design input, configuration management and continuous vulnerability testing (SBOM), SOUP validation, usability engineering, risk based testing, threat modelling, Software validation, and more.

These risks management activities must be integrating in the SDLC process and in the TPLC process to address post market surveillance requirements.

Security

For decades, medical device risk management primarily centered around patient safety. However, privacy legislation (such as GDPR and HIPAA) and a surge in security exploits have prompted regulatory agencies to heighten their focus on security risks. FDA issued new guidance, following an amendment to the US law (section 524B(a) of the FD&C Act) on 'Ensuring Cybersecurity of Medical Devices'. This amendment urged the immediate implementation of the following security measures for all medical device pre-market submissions:

• a dedicated cybersecurity risk management plan which covers not only development but the total life cycle of the device
• Dynamically maintained Software Bill Of Materials (SBOM) is listed as a mandatory deliverable
• Processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure. This translate in the implementation of threat modelling activities during the life cycle of the device.

These explicit security requirement obviously merge with the other risk mitigating measures. European guidance on the subject is less explicit but suggest similar measures.

Agile methodology and tooling

Agile practices and the V-model methodology, as suggested by IEC62304, are often seen as incompatible. When comparing the Agile Manifesto against common medical device regulatory requirements, it becomes apparent that they represent opposing approaches. However, this doesn’t mean that both worlds cannot be merged and that the proven benefits that Agile development and tooling delivers cannot be valorised during development of medical device software. Most if not all development activities can be executed in an iterative manner using modern ALM tools, all controlled by a compliant software development plan.

Below some example ALM tools and add-ons that facilitate Agile development and that can be tailored to fulfill medical device regulatory requirements.

AI / ML regulation

Artificial Intelligence (AI) and Machine Learning (ML) have emerged as the most disruptive technologies of the past decade. Their rapid evolution outpaces regulatory frameworks, leaving agencies grappling with how to address them effectively. The European AI act (approved by the European parliament on 13 Mar 2024) is only a first step to gain control over the technology, but provides little guidance for medical device manufacturers; it only states that medical devices using AI/ML are categorized as high risk in this domain.

As with cybersecurity, it is worth looking to the other side of the Atlantic to learn how FDA handles the subject. After many public discussions with the medical device industry and white papers, FDA has issued a guidance (still draft in Feb 2024) on the subject that gives valuable insights for manufacturers what documented evidence FDA expects in the process of getting a AI/ML device cleared. It shows that also here FDA expects a total product life cycle approach with a lot of attention on the management of training data and future changes to the AI/ML model.

Active learning systems have not yet been cleared by FDA (beginning 2024) and are a real regulation challenge.

For EU it is probably safe to follow the US suggested approach until more practical guidance is provided by MDCG.

Compliance

Showing compliance with market legislation is inevitable when bringing medical device products on market.

This involves correct classification and a tailored regulatory strategy. Both the EU and the US offer comprehensive guidance on the documentation expected in a pre-submission file. Despite the clear guidance and templates, it is valuable to bring some experience in this process of submission; once the registration process has been kicked off, the agencies impose strict timelines and review constraints which can turn against the manufacturer if not properly prepared.

Internal audits against ISO applicable harmonized standards or MDR/IVDR can be facilitated.