MDCG 2023-4 on combinations of MDSW and hardware

MDCG published guideline MDCG 2023-4 in October 2023 entitled “Medical Device Software (MDSW) – Hardware combinations – Guidance on MDSW intended to work in combination with hardware or hardware components.”

Criticism 1: Unclear scope of MDCG 2023-4

The title gives the impression that (all) types of combinations of hardware and Medical Device Software (MDSW) are addressed. This would concern

• hardware that is part of the same medical device as the software,
• as well as hardware that is part of another medical device, and
• commercially available hardware that is not a medical device, such as PCs, tablets, and smartphones.

The first sentence of the introduction reinforces this assumption. But the second sentence talks about “smartphones and wearable digital products.”

Then, in the “scope” chapter, the authors write that it would be about hardware that collects the data (“incorporating the data collection element“). At the same time, they exclude desktop PCs and cloud computing platforms. This is surprising because it would exclude, for example, ultrasound devices, which often sit on top of desktop PCs and use sensors, from the scope. Why?

Presumably, the authors are focusing on portable hardware that contains sensor technology that provides data for MDSW.

The guideline excludes clinical evaluation from its scope. Yet it addresses this aspect and requires “demonstrate clinical evidence for all intended configurations.”

Criticism 2: Unclear objective definition and achievement

What the actual objective of the guideline is remains unclear. It claims to provide guidance on which “specific regulatory considerations apply.” But it does not really provide any (new) answers. It should be well known that a manufacturer has to prove conformity with the MDR. For the most part, the guideline does not even refer to the relevant sections of the MDR. References to standards, e.g., on interoperability, are missing altogether.

The guideline does not give a list of specific questions it intends to answer. Therefore, it is not easy to assess which objectives it aims to achieve and whether it has achieved them.

Criticism 3: Statements worthy of discussion

Example 1

The “option 2” discussed by the guideline includes the case where a hardware component is placed on the market “as an integral part of a medical device” (see point c) on page 6).

With reference to this option 2, it states on page 7:

„the MDSW manufacturer may rely on the compliance of that hardware or hardware component with the MDR, in particular compliance with the GSPRs, when used in line with its intended purpose, under the intended normal conditions of use.“

This is not true in this generality. On the one hand, a hardware component, according to option 2 point c), has no intended purpose at all in the sense of the MDR.

Secondly, the manufacturer cannot rely on the fact that the component is also compliant in another context. For example, the electromagnetic compatibility of a component cannot be assessed at all without the surrounding hardware of a device.

Example 2

“Option 3” describes the case where the MDSW manufacturer uses hardware that is not a medical device or accessory. According to this guideline, the manufacturer becomes responsible for the “safety, performance, and reproducibility of the hardware or hardware component in its combined use with the MDSW in all intended configurations.”

Does this make the manufacturer of an app responsible for the electrical safety of the smartphone? The text gives that impression.

Elsewhere, the authors refer to the fourth section of Article 22 of the MDR. However, the requirements of this article are not identical to the requirements stated in option 3 of the guideline.

Example 3

The examples distinguish whether the manufacturers of the hardware and the manufacturers of the MDSW app are the same entity. However, this is largely irrelevant from a regulatory perspective. The MDR does not distinguish this either. Rather, the key questions are whether

• the hardware and the software are marketed as one or two devices, and
• the hardware or software are placed on the market as a medical device, as an accessory, or as a non-medical device.

Interestingly, the regulatory assessments in chapter 5) also recapitulate the two cases (same or different entity). But then, why were they differentiated so explicitly and in such detail?

Example 4

Under option 3, the guideline requires manufacturers to conduct post-market surveillance that includes non-medical device hardware (components). This requirement is valid. However, it is equally applicable to hardware (components) that are parts of the medical device. This is because, in many cases, medical device manufacturers purchase the hardware (components). Thus, this section could lead to incorrect conclusions.

Criticism 4: Unclear benefit

A guideline should answer the questions that lead to discussions in audits and tech file reviews, such as:

• How does a manufacturer derive how many configurations of “platforms” need to be tested? Regarding which aspects may the hardware be considered a black box? It is impossible to test all types of smartphones in all hardware configurations with all versions of operating systems and all possible combinations of software installed in parallel.
• What are typical hazards of mobile hardware with sensor technology that should be considered in risk management?
• What are the operating system requirements, and what related verification activities are expected? In the case of mobile devices, which are the focus of the guideline, manufacturers usually do not access the sensors directly but use the corresponding APIs of the operating system.
• In which cases does an MDSW manufacturer have to verify the biocompatibility, electrical, mechanical, and thermal safety of commercially available mobile devices? Discussions about the applicability of the IEC 60601 family to mobile apps are not uncommon in audits and tech file reviews.
• How can a legally compliant monitoring of hardware (e.g., smartphones) be set up? What information is particularly relevant? At what frequency should this be collected?
• What influence does an existing CE marking of the hardware (e.g., according to the Radio Equipment Directive RED) have on the verification measures of this hardware?
• When is performance data not(!) sufficient in clinical evaluation? Since the guideline explicitly requires “clinical evidence” for all(!) combinations, an answer would be helpful.
• What difference does it make if the manufacturers of the hardware and software are not the same entity?

Criticism 5: Insufficient abstraction and internal logic

Guidelines are not scientific papers. But they should adopt some basic concepts:

• Clear (research) question
• Description of methodology
• Precise and correct results
• Comprehensible explanation of how the authors arrived at these results

The MDCG 2023-4 guideline does not meet these requirements sufficiently. It makes it very difficult for readers to follow. For example, it gives four examples very broadly. As a reader, one tries to figure out the differences and similarities of these examples.

	A. External hardware component (e.g., sensor embedded in a dermal patch) providing input data to a MDSW app		B. Hardware component incorporated within a smartphone or wearable connected to a MDSW app on smartphone or wearable
#	1) Manufacturer of hardware component and MDSW app are the same entity	2) Manufacturer of hardware component and MDSW app are different entities	1) Manufacturer of hardware component incorporated within a wearable and MDSW app are the same entity	2) Manufacturer of wearable and MDSW app are different entities
1	Example: Manufacturer X places on the market a dermal patch that incorporates a sensor intended to collect and relay data correlated to the user’s physiological parameters such as body temperature, oxygen saturation (SpO2) and heart rate.	Example: Manufacturer X places on the market a dermal patch that incorporates a sensor intended to collect and relay data correlated to the user’s physiological parameters such as body temperature, oxygen saturation (SpO2) and heart rate.	Example: Manufacturer Z places on the market a wearable (e.g., watch) that incorporates a sensor that is intended to collect and relay data correlated to the user’s physiological parameters such as body temperature, oxygen saturation (SpO2) and heart rate.	Example: Manufacturer Z places on the market a wearable (e.g., watch) that incorporates a sensor intended or capable of collecting and relaying data correlated to the user’s physiological parameters such as body temperature, oxygen saturation (SpO2) and heart rate.
2	Upon purchase of the dermal patch, users download the MDSW app also placed on the market by Manufacturer X on a smartphone and connect the two (patch and smartphone app).	Manufacturer Y places on the market a MDSW app claimed to be compatible with the dermal patch of manufacturer X (or claimed to use input data provided by patches or sensors similar to the patch of Manufacturer X).	Upon purchase of the wearable, users are prompted to download (or activate) MDSW app also placed on the market by Manufacturer Z on their smartphone and/or wearable.	Users can download a variety of MDSW apps placed on the market by different MDSW app manufacturers. Manufacturer D claims that their MDSW app achieves its intended medical purpose through receiving data from the sensor integrated in the wearable placed on the market by Manufacturer Z.
3	Based on the sensor’s input data, the MDSW app calculates, further processes and analyses physiological parameters and other medical information about the user.	Collected data by the sensor are transmitted to the smartphone MDSW app for further analysis and calculations.	Based on the sensor’s input data, the MDSW app calculates, further processes and analyses physiological parameters and other medical information about the user.	Based on the sensor’s input data, the MDSW app calculates, further processes and analyses physiological parameters and other medical information about the user.
4	The MDSW app may also provide the possibility to have the user’s collected data directly transmitted to a healthcare professional.	The MDSW app may also provide the possibility to have the user’s collected data directly transmitted to a healthcare professional.	The MDSW app may also provide the possibility to have the user’s collected data directly transmitted to a healthcare professional.	The MDSW app may also provide the possibility to have the user’s collected data directly transmitted to a healthcare professional.
5	The app displays the monitored medical information and conducted analysis to the user and/or may transmit this information directly to the healthcare professional.	The MDSW app displays the calculated and monitored physiological parameters and conducted analysis to the user and/or transmits this information directly to the healthcare professional.	The app displays the monitored medical information and conducted analysis to the user and/or may transmit this information directly to the healthcare professional.	The MDSW app displays the monitored medical information and conducted analysis to the user and/or may transmit this information directly to the healthcare professional.

It would have been helpful to give one(!) example and then discuss the differences between when the hardware is marketed as a medical device or accessory and as a non-medical device. This would have contributed not only to less text but also to more comprehensibility. Readers of MDCG guidelines are capable of such abstraction.

The distinction between whether the manufacturers of the HW and the MDSW are the same entities takes up a lot of space, is confusing, and is not addressed in the discussion of regulatory consequences.

The distinction between whether the HW and MDSW are marketed as one device, or two devices need not be discussed. This is because the first case corresponds to a “normal medical device” and is covered by the MDR.

Criticism 6: Formality

Notified bodies most probably would not accept a document that only gives the month and year as the date. But if this information is correct, and if it is changed, we should be able to clearly identify the document.

The document is probably based on the same format template as other MDCG documents. While this creates consistency, it replicates the unattractive layout with unfortunate indentations at the headings or in the table of contents and results in formatting that makes it difficult to see the hierarchy of the headings.

On a positive note, the document appears to have gone through a proofreading process. Grammar and spelling are correct except for minor issues.

Conclusion

The MDCG has done neither itself nor the manufacturers and notified bodies any favors with the MDCG 2023-4 guideline.

The guideline hardly creates any additional clarity, rather causes even confusion, and does not serve as proof of precise argumentation. “State of the art” is not this line of reasoning.

Notified bodies are well-advised not(!) to demand conformity with this guideline in audits and during inspections of technical documentation. This would mean that they would adopt the lack of intellectual acuity as their own.