I wrote earlier some analysis on how MDR affects remote patient monitoring (RPM) systems. At the time the MEDDEV 2.1/6 guidance (which governs software) had not yet been updated, so the analysis was by necessity partly speculative. However, the updated guidance MDCG 2019-11 is now available, so it is time to update my analysis.
For remote patient monitoring systems, the MEDDEV 2.1/6 guidance was especially important related to qualification of the RPM system, i.e. whether the RPM system was a medical device, an in-vitro diagnostic medical device, or neither.
MEDDEV 2.1/6
In MEDDEV 2.1/6, this worked roughly as follows: Basic functionality commonly found in non-medical software did not make software into a medical device even if the functionality was now included for medical purposes, as long as data was not altered for medical purposes. This was described by the following rule:
if the software does not perform an action on data, or performs an action limited to storage, archival, communication, ‘simple search’ or lossless compression (i.e. using a compression procedure that allows the exact reconstruction of the original data) it is not a medical device.
Altering the representation of data for embellishment purposes does not make the software a medical device. In other cases, including where the software alters the representation of data for a medical purpose, it could be a medical device.
MEDDEV 2.1/6, July 2016, page 11
This rule essentially created a whitelist of allowed functionality. Two later notes extended that whitelist:
Note 3: Software intended to modify the representation of available IVD results is not considered as an IVD medical device as per decision step 5 of Figure 1, e.g. basic operations of arithmetic (e.g. mean, conversion of units) and/or plotting of results in function of time, and/or a comparison of the result to the limits of acceptance set by the user.
MEDDEV 2.1/6, July 2016, page 15
Stand alone software intended for archiving patient results or for transferring results from the home environment to the healthcare provider is not an IVD device. The results are available, readable and understandable by the user without the intervention of the software.
MEDDEV 2.1/6, July 2016, page 26
So, an RPM system was not a medical device if it only contained the whitelisted functionality:
- Storage
- Archival
- Lossless compression
- Communication
- Simple search (search that only does “dumb” matching against given search criteria and does not include intrepretative search results)
- Simple display (implicit given the previous ones)
- Note that e.g. display of images using image alteration techiques for the purpose of facilitating the medical use of the images, such as improving contrast, may make the software into a medical device
- Altering the representation for embellishment purposes (as opposed to medical purposes), e.g.
- Basic operations of arithmetic (e.g. mean, conversion of units)
- Plotting of results in function of time
- Comparison of the result to the limits of acceptance set by the user
The interpretation of “The results are available, readable and understandable by the user without the intervention of the software” in the last cited part must take into consideration that retrieval from storage, simple search and display of results have already been whitelisted, so it cannot refer to simple functionality. Rather, it should be understood in the context of the previous example:
In the case where software is necessary to render raw data, obtained from an IVD by means of in vitro examination of body samples, readable for the user, this software is to be considered as an accessory to an IVD when it is specifically intended to be used together with this IVD to enable it to be used in accordance with its intended purpose.
MEDDEV 2.1/6, July 2016, page 26
In other words, the software is an accessory to an IVD if the software is required for using the IVD as intended. This would apply e.g. to a mobile app used to interact with an IVD that does not have a user interface of its own. Thus, “The results are available, readable and understandable by the user without the intervention of the software” simply means that the measurement device can be used for its intended purpose without the RPM system.
This whitelist is actually extensive enough that basic RPM systems do not need to be considered medical devices. However, as soon as you want to add decision support functionality, including any priorization of patients which requires more complex analysis, the system becomes a medical device. I have written earlier on how decision support and AI are essential to realize the potential of RPM systems.
In-Vitro Medical Devices
If an RPM system is a medical device, it may be a “regular” medical device (MD) or an in-vitro diagnostic medical device (IVD). This was decided based on whether the RPM system contained an “expert system” that used any data from IVDs. If there was any IVD data, then the RPM system was an IVD, otherwise it was a MD:
If the information provided by the software is based on data obtained from IVD medical devices only, the software is an IVD medical device or an accessory of an IVD medical device.
If data are obtained from both IVD medical devices and from medical devices are analysed together for the purpose of providing information according to the definition of an IVD medical device, this software is an IVD medical device (e.g. evaluation of the risk of Trisomy 21)
[…]
If the information provided by the software is based on data obtained from medical devices only, the software would be a medical device.
MEDDEV 2.1/6, July 2016, page 14
The term expert system means software which is able to analyse existing information to generate new specific information according to the intended use of the software. A basic RPM system would therefore not include an expert system. On the other hand, such a basic RPM system is also likely not a medical device at all. For the edge case of an RPM system that qualifies as a medical device without having an expert system, MEDDEV 2.1/6 does not provide any specific guidance.
Classification
Under MDD and MEDDEV 2.1/6, if RPM systems are medical devices, they are typically classified as class IIa if they are used for direct diagnosis or to monitor vital physiological parameters, and class I otherwise:
Active devices intended for diagnosis are in Class IIa:
[…]
— if they are intended to allow direct diagnosis or monitoring of vital physiological processes, unless they are specifically intended for monitoring of vital physiological parameters, where the nature of variations is such that it could result in immediate danger to the patient, for instance variations in cardiac performance, respiration, activity of CNS in which case they are in Class IIb.
MDD, classification rule 9, page 55
All other active devices are in Class I.
MDD, classification rule 12, page 55
Since RPM systems are partly operated by the patients themselves, and the networks used to transmit data could fail for a prolonged time, a certain amount of unreliability is intrinsic to the concept. Thus RPM systems are typically not used in situations where failure of the system would put the patient in immediate danger, and therefore class IIb typically does not apply.
MDCG 2019-11
In my earlier analysis I assumed that since the definition of a medical device did not change between MDD and MDR in any way that would justify changing the qualification guidance, the above whitelist would remain relatively unchanged. For that to be true, the same whitelist text should be found within the new MDCG 2019-11 guidance. Searching for similar text, we can find:
If the software does perform an action on data, or performs an action beyond storage, archival, communication, simple search, lossless compression (i.e. using a compression procedure that allows the exact reconstruction of the original data) then it may be a medical device software
MDCG 2019-11, October 2019, page 8
For example, the software which alters the representation of data for a medical purpose would qualify as a medical device software (e.g. “searching image for findings that support a clinical hypothesis as to the diagnosis or evolution of therapy” or “software which locally amplifies the contrast of the finding on an image display so that it serves as a decision support or suggests an action to be taken by the user”). However, altering the representation of data for embellishment/cosmetic or compatibility purposes does not readily qualify the software as medical device software.
MDCG 2019-11, October 2019, page 6
Note: software intended to modify the representation of available in vitro diagnostic medical device results is not considered an in vitro diagnostic medical device, e.g. basic operations of arithmetic (e.g. mean, conversion of units) and/or plotting of results in function of time, and/or a comparison of the result to the limits of acceptance set by the user.
[…]
Software intended for archiving patient results or for transferring results obtained from in vitro diagnostic medical devices from the home environment to the healthcare provider is not an in vitro diagnostic medical device. The results are available, readable and understandable by the user without the intervention of the software.
MDCG 2019-11, October 2019, page 22
As you can see, all the items in the MEDDEV 2.1/6 whitelist can also be found in MDCG 2019-11. The same whitelist is therefore still valid. However, it is worth noting that there is a new qualification decision step in MDCG 2019-11:
If the product is an MDR Annex XVI device, or is an accessory for a medical device, or is software driving or influencing the use of a medical device, then it must be considered as part of that device in its regulatory process or independently if it is an accessory.
MDCG 2019-11, October 2019, page 8
This begs the question, is an RPM system driving or influencing the use of a medical device?
An RPM system may have three types of functionality that need to be considered here:
- Transferring measurement results from the measurement device to the RPM system,
- Scheduling of measurements, and
- Calibration of measurement devices.
Not only does data transfer not drive or influence the use of the measurement device, but data transfer is also explicitly whitelisted, so we can safely exclude that. Scheduling of measurements, on the other hand, is a little trickier. However, “driving or influencing” clearly indicates a degree of control of how the device is being used. For measurement scheduling, which is essentially just a calendar reminder, it does not seem applicable, but for calibration it could very well apply, especially if the calibration uses patient-specific values or is otherwise such that the measurement would not work correctly without it.
In-Vitro Medical Devices
The decision whether an RPM system is a MD or an IVD is a little different in MDCG 2019-11:
Is the intended purpose substantially driven by data sources coming from in vitro diagnostic medical devices? If yes, then the applicable legislation is Regulation (EU) 2017/746. If the intended purpose is substantially driven by data sources coming from medical devices, then the applicable legislation is Regulation (EU) 2017/745.
In the condition where the intended purpose of the MDSW output data fulfils both the medical device and in vitro diagnostic medical device definitions set out in the MDR and IVDR (refer to Decision Step 2), a weighting of the data sources based on the significance of the information21 in relation to fulfilling the intended purpose should be conducted to aid the manufacturer in determining which regulation to apply.
MDCG 2019-11, page 11
Note the lack of the term “expert system” – the guidance is now always applicable to RPM systems. The manufacturer now also has more leeway in deciding whether the RPM system should be a MD or an IVD, assuming that both MD and IVD measurement devices are being used. It is recommended to qualify an RPM system as a MD if possible because the MDR gives much better consideration for stand-alone software compared to IVDR.
Classification
Under MDR and MDCG 2019-11 the classification of RPM systems is governed by the MDR classification rule 11, which states:
Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause:
death or an irreversible deterioration of a person’s state of health, in which case it is in class III; or
a serious deterioration of a person’s state of health or a surgical intervention, in which case it is classified as class IIb.Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb.
All other software is classified as class I.
MDR, classification rule 11, page 144
Most RPM systems are used to make decisions for therapeutic purposes, so the first paragraph almost always applies. The second paragraph is really just a fallback to cover edge cases.
Now, assuming the RPM system is used to make decisions for therapeutic purposes, the classification therefore typically depends on whether a malfunction of the system could lead to physicians making wrong decisions. However, as previously noted, RPM systems are typically not used in situations where failure of the system would put the patient in immediate danger. Thus, when considering RPM system failure modes, the ones that produce incorrect data (as opposed to lack of data) are usually the most dangerous.
| Effect of making wrong decision due to incorrect RPM data | Classification |
| Non-serious deterioration of health, or no effect | IIa |
| Serious deterioration of health or a surgical intervention | IIb |
| Irreversible deterioration of health or death | III |
The MDR classification rule 22 is also worth noting:
Active therapeutic devices with an integrated or incorporated diagnostic function which significantly determines the patient management by the device, such as closed loop systems or automated external defibrillators, are classified as class III.
MDR, classification rule 22, page 145
An RPM system that automatically determines patient management based on the RPM data is classified as class III. This would include e.g. systems that automatically adjust medication based on measurement results. Note that this does not include decision support systems, since those always leave the final decision to the physician.
Summary
The updated guidance did not really change things much with regard to qualification of RPM systems, and the changes that did happen (qualification as IVD) were benign and made the rules more general. The new guidance did make it explicit that RPM systems that drive or influence the use of (medical) measurement devices become medical devices themselves, but that should really always have been the case even if MEDDEV 2.1/6 was a little opaque on the subject.
The change in classification guidance was to be expected based on MDR rule 11, and the updated guidance did not really add any new information. The classification of RPM systems mainly depends on the impact of the therapeutic decisions done based on RPM data.
So, my earlier predictions are still valid:
- If your RPM system is not a medical device under MDD, it is not one under MDR either.
- If your RPM system was a class I medical device under MDD, it is likely a class IIa or IIb medical device under MDR.
- If your RPM system has an expert system that uses data from IVD devices, which makes it an IVD device under the current MEDDEV 2.1/6 guidance, it might be qualified as a medical device under MDCG 2019-11 if the intended purpose is substantially driven by data sources coming from MD rather than IVD devices.
Comment on this article on Linkedin
Disclaimer: All information in this blog post is for educational use only and should not be construed as legal advice. Your Mileage May Vary.