Who is the stricter regulatory parent?

Medical technology is rapidly evolving, challenging regulators to maintain oversight while also encouraging innovation. The EU and the US don’t always take the same path to achieve this balance – like parents who may have different views on how to best nurture their children.

The US Food and Drug Administration (FDA) recently published a new set of guidance documents regarding Software as a Medical Device (SaMD) and its classification. In this article, I take an imaginary example of a software product and run it through the applicable regulatory governance in these new guidelines.

By comparing FDA’s approach to the EU’s, I highlight some significant differences, aiming to open a debate around which framework is stricter and will better safeguard medical applications.

Understanding the terms

My focus is solely on the guidelines regarding Clinical Decision Support Software (CDS), Medical Device Data Systems (MDDS) and Device Software Functions and Mobile Medical Applications. Some examples of products that fit these terms are:

CDS: Software that analyses patient-specific measurements to identify patients potentially experiencing a time-critical disease.

MDDS: Software that collects output from a medical device and transmits the information to a central patient data repository.

Device Software Functions and Mobile Medical Applications: Software that is able to control a connected medical device.

As a disclaimer, I will not touch upon Computer-Assisted Software systems such as CADe, CADx or CADt devices, for which separate guidances and definitions apply.

Imaginary Report

Let’s consider a fictive medical data reporting tool, with the following intended use:

“ImaginaryReport” functions as a report for physicians to fill in and store medical information about patients. ImaginaryReport also incorporates information transferred from connected software medical devices into this report.

Based on this information and on clinical guidelines, ImaginaryReport calculates a certain metric (routinely used in clinical practice) for diagnosis. Based on this metric, the medical information, and another clinical guideline, ImaginaryReport provides the physician with a recommendation for a diagnostic procedure for the patient. ImaginaryReport is not intended to replace the clinical judgement of the physician.

The ImaginaryReport, thus, has three functions:

1. Transfer, storage and display of medical information from physicians and connected medical devices.
2. Calculating a metric routinely used in clinical practice for diagnosis, based on clinical guidelines.
3. Providing a recommendation for a diagnostic procedure, based on existing clinical guidelines.

I will analyse each of these functions against the existing legislation and guidance, to determine whether these functions qualify as a medical device within the US and the EU, and, if so, what their respective classification would be.

Function 1: Transfer and storage of information from physicians and connected medical devices

The EU approach

Article 2 of the EU Medical Devices Regulation 2017/745 (MDR) contains this definition:

Medical device means any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the following specific medical purposes:

– Diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease,
– Diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability,
– Investigation, replacement or modification of the anatomy or of a physiological or pathological process or state,
– Providing information by means of in vitro examination of specimens derived from the human body, including organ, blood and tissue donations.

None of the aspects in Function 1 of ImaginaryReport fit in the description of a medical device. Therefore, Function 1 would not be considered a medical device in the EU.

The US approach

The first guidance recently updated by the FDA is the Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices. Devices intended to function as a ‘Data System’ are classified into two categories:

Device-MDDS: Hardware functions that are solely intended to transfer, store, convert formats, or display medical device data and results;

Non-Device-MDDS: Software functions that are solely intended to transfer, store, convert formats, or display medical device data and results.

Our focus is on software, thus, Non-Device-MDDS. FDA clarifies that Non-Device-MDDS is not considered a medical device and not subject to FDA’s regulations.

Function 1 of ImaginaryReport is solely intended to transfer, store, and display medical device data. So, applying the FDA MDDS Guidance, Function 1 would also not be considered a medical device in the US.

Comparing the EU and the US

Regarding the first function of our imaginary medical device, the EU and the US take a similar regulatory approach.

Function 2: Calculating a metric routinely used in practice for diagnosis, based on clinical guidelines

The EU approach

Rule 11 of Annex VIII of the MDR clarifies that:

Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa.

Additionally, Section 3 of the MDCG 2019-11 does not restrict this function from being regarded as a medical device. Annex 1 of the MDCG 2019-11 explicitly mentions that:

Decision Support Software are qualified as medical devices. These are computer-based tools which combine general medical information databases and algorithms with patient-specific data. They are intended to provide healthcare professionals and/or users with recommendations for diagnosis, prognosis, monitoring and treatment of individual patients.

Since Function 2 aims to provide the physician with additional diagnostic information, calculated by the device itself, it fits the definition of a medical device under the MDR.

The US approach

The second guidance updated by the FDA is the Policy for Device Software Functions and Mobile Medical Applications, explaining its oversight over:

1. Software functions that are an extension of one or more medical devices by connecting to such device(s) for purposes of controlling the device(s) or analysing medical device data;

2. Software functions (typically, mobile apps) that transform the mobile platform into a regulated medical device by using attachments, display screens, or sensors or by including functionalities similar to those of currently regulated medical devices;

3. Software functions that become a regulated medical device by:
a. performing patient-specific analysis and providing specific output(s) or directive(s) to health care professionals for use in the diagnosis, treatment, mitigation, cure, or prevention of a disease or condition, or;
b. performing patient-specific analysis and providing patient-specific diagnosis or treatment recommendations to patients, caregivers, or other users who are not health care professionals.

It further sets out criteria for software functions that are not subject to regulatory oversight. These may meet the definition of a medical device. However, FDA intends to exercise enforcement discretion, i.e. not enforce the regulations for them, because they pose a low risk.

These functions either:

• Provide or facilitate supplemental clinical care, by helping patients manage their health in their daily environment;
• Are specifically marketed to help patients communicate with healthcare professionals by capturing an image for patients to convey to their doctors about potential medical conditions;
• Perform simple calculations routinely used in clinical practice. (Note: the FDA does not clarify the thresholds for “simple calculations” and “routine use in clinical practice”, leaving this point open to a certain level of interpretation.)

Function 2 of ImaginaryReport meets the third point of performing simple calculations. Subsequently, Function 2 may be considered a medical device for which the FDA does not intend to enforce regulations.

Comparing the EU and the US

Here, there is a clear distinction between the governance of the software in the US and the EU. The EU is taking a more cautious approach compared to the US. With the MDR and Rule 11 in place, many of these software devices will be classified at least as class IIa medical devices.

Function 3: Providing a recommendation for a diagnostic procedure, based on clinical guidelines

The EU approach

The same interpretation as for Function 2 applies to Function 3. Function 3 would also render the product a medical device, of at least class IIa.

The US approach

The third guidance recently released by the FDA is the guidance on Clinical Decision Support Software. CDS is a broad concept which encompasses various types of products and functions, such as:

• Computerised alerts and reminders for providers and patients;
• Clinical guideline automation;
• focused patient data reports and summaries;
• diagnostic support; and
• contextually relevant reference information.

This type of software can either be a regulated medical device or can be considered a (non-medical) device which is not regulated by the FDA. CDS not considered to be medical devices are those which meet the four criteria set out in the guidance, as derived from Section 520(o)(1) of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 360j):

1. Not intended to acquire, process, or analyse a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system;

2. Intended for the purpose of displaying, analysing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines);

3. Intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition;

4. Intended for the purpose of enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.

ImaginaryReport’s function 3 would meet all four criteria:

• It is not intended to acquire, process, or analyse a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system;
• It displays medical information, namely the outcome of a clinical practice guideline;
• It provides a recommendation to a healthcare professional about the diagnosis;
• It is based on a clinical guideline, and the physician can always consult the clinical guideline to verify or determine the recommendation. This is also communicated to the physician within ImaginaryReport.

As a result, Function 3 would not be considered a medical device.

Comparing the EU and the US

As in the previous section, the FDA is less concerned with these devices than the EU, making them easier and faster to bring onto the US market than the EU.

Different turns

Where does this analysis leave our imaginary product? ImaginaryReport would not be considered a medical device in the US. However, In the EU, it would be at least a class IIa medical device.

Which benefits patients more? Does the lack of regulatory control in the US also mean that there is an inherent safety risk for patients?

As a medical device manufacturer, we argue it is important to be subjected to appropriate documentation of requirements, verification and validation testing, and risk management assessments, irrespective of regulatory needs. Even though these types of devices apply known algorithms and medical protocols, there can always be risks, e.g. incorrect interpretations of clinical classification scores, interface usability aspects, or risks associated with implementing the protocols into the software.

The new FDA documents provide a clear framework for lower-risk classes of medical device software, which was not always straightforward to understand. Yet, as noted, the FDA insufficiently defines what “simple” calculations are or when a guideline is “routinely used” in clinical practice. In the EU, the MDCG guidance also leaves room for interpretation since the specific example of implementing a clinical guideline or known risk scores is not addressed.

The two regulatory authorities have taken different turns regulating a product such as ImaginaryReport. FDA’s leniency could stimulate innovation in the field of CDS. But, the EU’s stricter approach could set CDS to higher standards. It remains to be seen which parenting style fits the development of CDS over the coming years.