Impact of the Regulatory Framework on Medical Device Software Manufacturers: Are the Guidance Documents Supporting the Practical Implementation?; Comment on “Clinical Decision Support and New Regulatory Frameworks for Medical Devices: Are We Ready for It? – A Viewpoint Paper”

Introduction

Just as other sectors, the healthcare sector has recently experienced an increased digitalisation. This tendency caused the widespread use of software, for example to streamline administrative processes within hospitals and care centres (information technology equipment), but also to support clinical decision making by healthcare professionals (HCPs). Van Laere et al¹ explain the different regulatory frameworks that apply to clinical decision support (CDS) software in the United States (Food and Drug Administration, FDA, 21st Century Cures Act)² and in Europe (European Union Medical Device Regulation [MDR]).³

We will mainly comment and ask critical questions on the practical implementation of the regulatory framework for medical device software (especially CDS software), with a reference to the available international guidance documents and their limitations. As mentioned by Van Laere et al,¹ manufacturers of medical device software need to consider those regulatory frameworks carefully as they might impact their time and costs to market significantly.

Importance of Keeping Guidelines Up to Date With the “State of the Art” Software

There is a general trend of digitalization in healthcare with a broad spectrum of different medical and non-medical device software functions used. This is confirmed by policy-makers through providing illustrative examples in guidance documents for the qualification of software used in the healthcare environment.^4-10 It is understood that the examples in the guidelines have been drafted in the light of today’s state of the art. However, we hope that those guidance documents will be treated by policy-makers as living documents that will be updated with innovative examples (eg, software algorithms that operate via machine learning or other artificial intelligence [AI] techniques) following the pace of evolving technologies. It is correctly noted in the viewpoint article that there is an assumption that EU MDR will hamper software development as the FDA Guidances^4-9 present more innovative software examples than the EU Medical Device Coordination Group (MDCG) Guidance Documents.¹⁰

Qualifying Software as a Medical Device – Is the Definition Clear?

To be qualified as a medical device, a product must first fulfil the definition of a medical device according to the applicable legislation. The international harmonization body (former Global Harmonization Task Force or International Medical Device Regulators Forum [IMDRF]) has created non-binding guidance documents (eg, definition of the term “Medical Device”) to encourage regulatory systems’ convergence at the global level by eliminating differences between jurisdictions. Harmonized guidance would ideally result in decreasing the cost of gaining regulatory compliance and in allowing patients earlier access to innovative technologies and treatments.¹¹ The EU MDR definition and its specification of the medical purpose of a device is more leaning towards the Global Harmonization Task Force definition compared to the device definition in section 201 (h) of the Food, Drug & Cosmetic Act.² In addition, the term “monitoring” in the EU MDR³ is focused on products intended to monitor physiological processes, while “monitoring” is not present in the FDA device definition.² Unfortunately, there is no clear definition of the term “to monitor” which complicates the qualification of a software product. We would suggest defining monitoring as “following the evolution of a disease, injury/disability or physiological or pathological process or state at different stages or at different moments in time.” Many software products are intended to follow up chronic patients at home by visualising parameters measured with different hardware medical devices and notifying deviations to enable HCPsto take treatment decisions. For such software products, we would welcome a clear definition of medical device monitoring in updated guidance documents to facilitate their qualification.

As confirmed by the FDASIA report,¹² the development of software products used to take decisions with diagnosis or therapeutic purposes has increased in the last decades (called “decision support software in EU”¹⁰ or “CDS software in US”⁵). Unfortunately, no harmonized definition is available for CDS software. The authors of the viewpoint article came up with their own definition on CDS software: ‘any software system that integrates personal patient data with external sources of medical knowledge to assist the HCPs in their decision-making process.’¹ Following MDCG guidance,¹⁰ decision support software is intended to provide HCPs and/or users with recommendations for diagnosis, prognosis, monitoring and treatment of individual patients. Following FDA guidance,⁵ CDS software would provide ‘HCPs and patients with knowledge and person-specific information, intelligently filtered, or presented at appropriate times, to enhance health and healthcare.’ Generally, the meaning of those definitions seems identical, however limitations exist in the practical qualification of CDS software as a medical device (SaMD). Van Laere et al¹ are correctly requesting further guidance on how FDA will assess the availability of plain language description of the logic or rationale used by an algorithm and the availability of the elements forming the basis of the recommendations to the intended user. The understanding of the basis of a certain CDS might trigger that CDS software being exempted from the 21st Century Cures Act.² This approach of a software recommendation being or not being understandable has not been considered in the EU MDCG guidance document as a criterion to qualify CDS SaMD. Additional clarification in guidance documents (US and EU) on the basis of the software recommendation and/or the action of the software on the data (eg, data analysis) would improve the qualification assessment of software products.

Is the Classification of Clinical Decision Support Software Different Between Jurisdictions?

The EU and FDA medical device legislations have leveraged the IMDRF risk-based framework for categorizing SaMD, based on the risk to patients if the software malfunctions.¹³ IMDRF’s categorization criteria and framework (Table 1)¹³ are not a regulatory classification, nor imply a convergence of classifications rules. Each jurisdiction has aligned her SaMD or medical device software (EU term) classification rules with this IMDRF framework in a unique way. As indicated by Van Laere et al, the EU MDR classification is much more stringent, especially due to the new classification Rule 11. Software intended to provide information in the clinical management is always classified as a Class IIa medical device in Europe, requiring the regulatory approval by a notified body (Table 2).^3,10

The FDA approach is more pragmatic. FDA has drafted guidance on CDS software functions with a specific focus on CDS software used for informing clinical management.⁵ The categorization method for regulatory oversight is based on the user (a HCP, patient, or caregiver) on the one hand and on the fact that the user can review the basis of the information on the other hand (Table 3). With this approach, FDA strikes the right balance between ensuring patient safety and promoting innovation by clarifying which products would be the focus of FDA’s oversight and which would not. As noted by Van Laere et al,¹ two medical devices with the same intended use may obtain different classifications in those two jurisdictions. Unfortunately, EU MDR does not consider the lower significance of informing clinical management of the IMDRF framework nor the stage of healthcare condition of the patient, to allow a lower classification and thus regulatory burden for such CDS software (leading to a class IIa classification for low impact SaMD in non-serious situation or patient condition in Table 2).

Are There Other Limitations in the Practical Implementation of Medical Device Legislations?

Advanced technologies such as AI are becoming more frequently used in healthcare for diagnostic or therapeutic purposes. The US FDA clearly has taken the path forward for embracing this technology by drafting an AI/machine learning SaMD action plan.¹⁴ In Europe, guidance on interpretation of significant changes to AI are not yet available. Due to the promotion of those innovative products to the market, there is a growing need for software experts in Europe, especially within the conformity assessment bodies for reviewing the CE certification applications. As suggested by the FDA,¹⁴ there is a great need for more harmonization in the AI domain, more specifically in the development of good machine learning practice through the creation of consensus standards and other guidelines.

Conclusion

The topic of CDS software is relevant as it became more widespread in different healthcare fields. With the evolution of software technologies such as AI, CDS software is expected to consolidate its position in healthcare. To keep up with the technological evolutions, it is desirable that the different regulators consult with industry and users and publish and continuously update more practical guidance documents. US FDA already takes a proactive approach in providing multiple guidance documents^4-9 on software, but also on CDS software and an action plan for AI/machine learning based SaMD.¹⁴ Although the European Commission had good intentions when considering the IMDRF risk categorization framework, it did not classify CDS software which informs HCPs for non-serious patient conditions in a low medical device class. This results to the fact that manufacturers will most likely need a notified body to place this type of products on the market in Europe. This will certainly increase the costs and timelines to go to the market, probably making Europe a less attractive market to deploy digital health innovations in a first stage. Currently, some manufacturers are reducing their product portfolio in Europe to limit regulatory cost related to EU MDR. As expected by Van Laere et al,¹ the real clinical impact on patient’s health will only be measurable in the next few years.

Ethical issues

Not applicable.

Competing interests

Authors declare that they have no competing interests.

References

1. Van Laere S, Muylle KM, Cornu P. Clinical decision support and new regulatory frameworks for medical devices: are we ready for it? - A viewpoint paper. Int J Health Policy Manag 2021; 11(12):3159-3163. doi: 10.34172/ijhpm.2021.144 [Crossref] [ Google Scholar]
2. U.S. Government Publishing Office. Public Law 114-255 - 114th Congress (In Short: 21st Century Cures Act). https://www.govinfo.gov/app/details/PLAW-114publ255. Published 2016.
3. European Parliament and Council. Regulation (EU) 2017/745 (In Short: Medical Device Regulation (MDR)). https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02017R0745-201705052017. Published 2017.
4. US Food and Drug Administration. Policy for Device Software Functions and Mobile Medical Application. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/policy-device-software-functions-and-mobile-medical-applications. Published 2019.
5. US Food and Drug Administration. Draft Guidance on Clinical Decision Support (CDS) Software. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software. Published 2019.
6. US Food and Drug Administration. Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act: Guidance for Industry and Food and Drug Administration Staff. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/changes-existing-medical-software-policies-resulting-section-3060-21st-century-cures-act. Published 2019.
7. US Food and Drug Administration. General Wellness: Policy for Low Risk Devices. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-wellness-policy-low-risk-devices. Published 2019.
8. US Food and Drug Administration. Off-The Shelf Software Use in Medical Devices. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/shelf-software-use-medical-devices. Published 2019.
9. US Food and Drug Administration. Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/medical-device-data-systems-medical-image-storage-devices-and-medical-image-communications-devices. Published 2019.
10. Medical Device Coordination Group Document MDCG 2019-11. Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR. https://ec.europa.eu/docsroom/documents/37581. Published October 2019.
11. Global Harmonization Task Force. GHTF/SG1/N071:2012. Definition of the Terms ‘Medical Device’ and ‘In Vitro Diagnostic (IVD) Medical Device.’ https://www.imdrf.org/documents/ghtf-final-documents/ghtf-study-group-1-pre-market-evaluation. Published 2012.
12. US Food and Drug Administration. FDASIA Health IT Report. April 2014. https://www.fda.gov/about-fda/cdrh-reports/fdasia-health-it-report.
13. IMDRF SaMD Working Group. “Software as a Medical Device”: Possible Framework for Risk Categorization and Corresponding Considerations. http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-140918-samd-framework-risk-categorization-141013.pdf. Published 2014.
14. US Food and Drug Administration. Artificial Intelligence/Machine Learning (AI/ML) Based Software as a Medical Device (SaMD) Action Plan. https://www.fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-and-machine-learning-software-medical-device. Published January 2021.