The term “medical device PC” is not clearly defined. However, most people understand a medical device PC to be
- either a PC placed on the market as a medical device together with the software
- or a PC for safe use in the operating theater due to its electrical safety and electromagnetic compatibility. However, the PC itself is not a medical device, as the person placing the device on the market or the operator provides the medical functionality, e.g., by installing a medical device software.
Depending on the constellation, manufacturers must fulfill different regulatory requirements. These are presented in this article.
1. Case distinctions for medical device PCs
Case A: Standalone software is delivered
If you as a manufacturer only supply standalone software, the question of medical device PCs does not yet arise. We do not need to examine this case further in this article.
Case B: Software is delivered with PC
But what happens if you deliver your software together with the PC hardware?
Reasons for this include, for example:
- To protect your code from threats
- To ensure that your software runs on the specified or sufficiently performant hardware
- To minimize risks from the hardware you are not familiar with
- To make some extra money with the hardware 🙂
Examples of these cases are
- Software for therapy planning (radiation planning, medication planning)
- Software for in-vitro diagnostics (e.g., for trisomy 21)
- For viewing and analyzing radiological images
Case C: Medical device consisting of software and hardware (“without patient contact”)
It may also be that the software cannot be delivered without the hardware at all, especially if it is a special hardware, e.g.,:
- Special external connections
- Hardware components or FPGA developed in-house
- Special mechanical, electromechanical, pneumatic, or hydraulic components
Joint delivery is required even if a special or self-developed operating system is used. Examples of this case include
- IVD that are not just software
- Systems with particular requirements in terms of computing power, e.g., for simulation, image processing, or therapy planning
The difference between cases B and C is that in case B, the manufacturer can decide whether to supply the medical device software with or without hardware, and in case C, both are designed as a unique system, as one medical device.
Case D: PC is not a medical device
Some hardware manufacturers market so-called “medical-grade PCs,” which are not medical devices themselves but are used in the “patient environment,” such as the operating theater or as components for medical device manufacturers (see case B).
Case E: Medical device consisting of software and hardware (“with patient contact”)
The boundaries between medical technology and IT are becoming increasingly blurred. Ultrasound devices, for example, are essentially PCs that have a so-called applied part, in this case, an ultrasound probe. ECGs are also increasingly falling into this device class.
2. Regulatory requirements for medical device PCs
a) Overview of regulations
The regulations to be considered are:
- The EU Medical Device Regulation MDR and national laws such as the MPDG
- General standards for medical devices, such as ISO 14971, IEC 62366-1, and IEC 62304
- Regulations that set requirements for basic safety and essential performance, such as IEC 60601-1
- General requirements for devices (not just medical devices), such as (electrical) safety
b) Mapping of the regulations to the cases described above
Case A: Standalone software
For medical devices that only consist of standalone software, regulations 1 and 2 must be complied with, particularly ISO 14971, IEC 62366, and IEC 62304.
Cases B and C: Software is delivered with hardware, no patient contact
In these cases, the same requirements apply as in case A); however, the manufacturer would purchase (or develop) hardware that meets the general requirements for devices (4.).
This hardware does not have to meet the requirements according to 3. (i.e., in particular, not IEC 60601-1). You can read more about why below.
Case D): PC is not a medical device
As the PC is not a medical device, it does not have to fulfill any specific regulatory requirements (1, 2, 3) but only the general product requirements (4). After all, the manufacturer of this medical device PC is not a person placing a medical device on the market.
However, manufacturers will comply with the regulations in accordance with (3) because that is precisely the benefit they provide to their customers.
Case E: PC is a medical device with “patient contact”
In this case, the PC must comply with the requirements 1, 2, and 3. The manufacturers must definitely consider the IEC 60601-1 with aspects such as leakage currents, air clearance, and creepage distances.
The more specific requirements of IEC 60601-1 “overwrite” the electrical safety requirements for general requirements of non-medical PC’s.
Summary
| Case | 1. MDR | 2. General standards such as ISO 14971 | 3. Safety, IEC 60601-1, and others | 4. Safety requirements for non-medical devices |
| Case A: standalone software (SW) | x | x | — | (x) |
| Case B: software (medical device) incl. PC hardware (HW) | x | x | — | x |
| Case C: medical device consisting of software and (PC) hardware (outside patient environment) | x | x | — | x |
| Case D: medical-grade PC, not a medical device (inside the patient environment) | — | — | X | (x) |
| Case E: medical device with patient contact | x | x | x | — |
3. When to apply IEC 60601-1
a) Definitions
IEC 60601-1 states that it applies (only) to the basic safety and essential performance features of medical electrical equipment (ME Equipment) and medical electrical systems (ME Systems). IEC 60601 defines the terms as follows:
electrical equipment having an applied part or transferring energy to or from the patient or detecting such energy transfer to or from the patient and which is:
- provided with not more than one connection to a particular supply mains; and
- intended by its manufacturer to be used in:
- the diagnosis, treatment, or monitoring of a patient; or
- for compensation or alleviation of disease, injury, or disability
part of ME Equipment that in normal use necessarily comes into physical contact with the patient for ME Equipment or an ME System to perform its function
combination, as specified by its manufacturer, of items of equipment, at least one of which is ME Equipment to be inter-connected by Functional Connection or by use of a Multiple Socket-Outlet
b) Conclusions
The IEC 60601-1 is only applicable to ME Equipment or ME Systems.
- This is not the case in cases A, B, and C; IEC 60601-1 is therefore not applicable.
- In case D (medical-grade PC), the question cannot be answered clearly because it is not yet clear what the medical device manufacturer or operator intends to do with it. If the PC is used in the patient environment and direct or indirect contact with the patient is likely, then conformity with IEC 60601-1 is recommended.
- In case E, IEC 60601-1 must be complied with.
The publications on IEC 60601-1 listed here provide a sound insight into the topic.
4. Placing software on the market with or without a PC?
The following comparison can serve as a decision-making support in answering whether manufacturers should place their software with or without hardware (i.e., PC) on the market as a medical device.
| pros software including hardware as a medical device | cons software including hardware as a medical device |
| You can sell the hardware at a high price. After all, it is a medical device. 🙂 | With every hardware change – and this is likely to be frequent in today’s product cycles – a new conformity assessment is required. |
| You have a better grip on the overall system, can assess risks more accurately, and manage them better. This makes Apple computers, for example, somewhat more stable than Windows systems. At least that’s what Apple supporters say 😉 | This conformity assessment also includes the PC. For example, electromagnetic compatibility, and electrical safety must be tested, costing five-figure sums. |
| You limit the number of buyers who want to work with their own hardware. |
Manufacturers who place software and hardware on the market as one medical device must undergo a (!) conformity assessment procedure for the entire device. The decision for or against “combining” with hardware can influence the class of the medical device and, thus, on the possible conformity assessment procedures.
If you opt for the “standalone software” variant, you must specify in its intended purpose in which run time environment it must or may run (i.e., on which hardware, which operating system, which other resources).
Which is the better option can only be decided on a case-by-case basis. In my opinion, the more elegant solution is to only place the software on the market as a software medical device – if risk management allows you to do so.
5. Conclusion and summary
There is a lack of common understanding of what is meant by a medical-grade PC. This article has presented five use cases, each with different regulatory requirements.
Which variant manufacturers should choose depends on the intended purpose, the business case, risk management, and other factors.
Get in touch if you want to ensure that you have chosen the right variant and identified and met all regulatory requirements.
Change history
- 2023-06-04: Article updated, section 4 completely revised, section 5 added
- 2015-06-12: First version of the article created
