With software as medical device, it differentiates between standalone software and software that is part of a medical device. Classifying the standalone (also called SaMD - Software as Medical Device) software is often difficult, especially whether it is classified as a medical device.
Depending on this classification, manufacturers must pay attention to the different regulations. This article helps you to classify your own software.
Manufacturers and authorities are often experiencing uncertainty regarding if a software is classified as a medical product or not. This is also the reason why many decision-making aids are published, present below.
The decision on whether a software should be classified as a medical device is up to the manufacturer themselves. Notified Bodies can provide advice. But the advice that the manufacturer attained does not give any legally binding information. Inquiries for the BfArM will not usually be answered promptly. Ultimately, and this may sound cynical, a judge will only answer this question in the case of a lawsuit for the classification of software as a final medical device.
For this, the judge will appoint an appraiser. They will, by examining the writing of the report, test if the software corresponds to the definition of medical device; in other words if it serves (to formulate it briefly) its diagnosis, treatment or monitoring of diseases and injuries.
If you have software of which you are unsure of, then please contact:
The issue of "classification of software as a medical device" preoccupies not only the manufacturers of medical devices, but also the authorities, bodies and associations. They have published a number of documents about this, which should serve as decision aids.
The "European Coordination Committee of the Radiological, Electro-medical and Healthcare IT Industry" has published a "Decision Diagram for Qualification of Software as Medical Device".
I'm still a little hesitant, as to what I should make of it. On the one hand there is nothing really new in it (and ultimately only the legal definition counts), on the other hand people have done the work here to support us manufacturers and developers.
From the EU comes a "Manual", that tries using examples to distinguish medical from non-medical devices and to give help in classification. The examples relate partly to Software:
Next, the British "Medicines and Healthcare Products Regulatory Agency" issued a document entitled "Borderlines with Medical DDevices". In Chapter 9 of the document you can read the sentence on the "Telecare Alarm System".
Now there's a document from the International Medical Device Regulator Forum IMDRF. It defines the terms
The document is pleasantly short with just 10 pages and definitely worth a look.
An interesting feature of this article is the fact that on the one hand it largely limits itself to definitions of terms, but on the other hand it makes use of already existing concepts or just repeats them. A distinction between a "SAMD Manufacturer" and "Manufacturer" does not result from this. What could be the value of this? Perhaps the realization that software is not to be treated differently.
Particularly interesting for me were the references and among other things the sources:
The IMDRF explains the definition of a medical device again and lists cases in which a stand-alone software does not count as part of a medical device, and when it does, such as:
Whether these are really groundbreaking insights into the classification of software as a medical device is debatable. Finally, the support is not critical beyond the classification of the definition of medical devices.
The MEDDEV 2.1/6 has released the document Guidance on the Qualification and Classificastion of Stand Alone Software used in Healthcare within the Regulatory Framework of Medical Devices. But it has never progressed beyond the draft stage. One divides software into the following categories:
From the Swedish authorities comes the „Medical Information Systems – guidance for qualification and classification of standalone software with a medical purpose“.
The Asian Harmonisation Working Group Document repeats the definitions in the context of "Software as a medical product" as a "stand alone software", "Mobile Medical Application" and "Health Programs" and distinguishes three types:
Furthermore, the document introduces already existing considerations, for the classification of software as a medical device and essentially discusses the above mentioned sources:
In the summary, the document summarises the similarities and differences, among other things, in a table. Herby, software is discussed, which serves data communication. This software is not classified in Europe as a medical product, but it is already in most other areas of law.
a) Food, Drug, and Cosmetic Act (FD&C)
In the summer of 2017, the US Food, Drug, and Cosmetic Act (FD&C for short) revised the term “medical device” specifically with regard to software. However, this description was so cryptic that the FDA felt compelled to publish a guidance document in December 2017 setting out its interpretation of the law. Although this guidance document only refers to the decision support systems, it can easily be transferred to other standalone software.
In September 2019, the FDA published a guidance document on “Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act”. In this guidance document, the FDA again set out its interpretation, provided examples and referred to other guidance documents, some of which are mentioned below.
b) General Wellness: Policy for Low Risk Devices
The Food, Drug & Cosmetic Act was revised at the end of November 2016. It no longer(!) defines software used “for maintaining or encouraging a healthy lifestyle and [that] is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition” as a medical device.
The FDA confirms in Guidance document “General Wellness: Policy for Low Risk Devices” that it does not intend to examine “low risk general wellness products” to determine whether they are medical devices nor does it intend to examine, if they are classified as medical devices, whether they comply with the regulatory requirements.
But the prerequisites for this are:
Manufacturers must not make any reference to diseases to be diagnosed or treated with the devices. Instead, the device must relate to, for example:
However, the FDA also allows devices related to certain diseases in this category if they could help:
The guidance document gives examples and provides a small decision tree.
Conclusion: Through this document, the FDA has provided clarity as to when devices - including software - are exempted from FDA inspection. This is what people in Europe want. The FDA also exempts a lot more devices from inspection than European authorities and regulators do.
c) Policy for Device Software Functions and Mobile Medical Applications
The guidance on mobile medical apps published in 2016 defined apps that:
With its 2019 update, the FDA has extended the scope to other software and now often talks about “software functions”. Mobile apps are only one type of software that has such functions.
This means that you should consult the document even when you have to decide whether software that is not a mobile medical app is a medical device or not.
d) FDASIA Report
The FDA is co-editor of the FDASIA Report. FDASIA stands for Food and Drug Administration Safety and Innovation Act, an act that required the FDA to prepare a report
“that contains a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to health information technology, including mobile medical applications, that promotes innovation, protects patient safety, and avoids regulatory duplication.”
In this report, the FDA again distinguishes (as in the guidance document on mobile medical apps) between:
This division into three is surprising. It means laws don't always have to be obeyed?! The FDA justifies this differentiation with a “risk-based approach”:
“In applying a risk-based approach, FDA does not intend to focus its regulatory oversight on these products/functionalities, even if they meet the statutory definition of a medical device.”
It also gives concrete examples in which it considers these exceptions to be justified:
It is not quite clear what statistical analysis the assumptions that the above device classes present fewer risks are based on. Such clinical decision support systems are often particularly treacherous because the risks are not as obvious as they are with classical medical devices such as ventilators.
A new guidance document gives concrete examples of when software no longer has to be classified as a medical device:
The FDA will have to revise the aforementioned guidance documents accordingly.
You can read more about this in this draft FDA guidance on “Existing Medical Software Policies”.
Health Canada has published a Draft Guidance Document - Software as a Medical Device (SaMD). It is essentially based on the aforementioned IMDRF framework and adopts its definitions. It adds to these ideas with examples.
a) Medical purpose
Health Canada gives examples of medical purposes:
However, Health Canada does not classify all systems designed to help decision-making as a medical device.
b) Examples of software that is not a medical device
Health Canada also helps by giving some examples of software that it does not consider to be medical devices:
c) Risk classification
Health Canada also takes the IMDRF document as the basis for risk classification, but permits a lower classification in some places.
The MCDG 2019-11 document governs the classification of medical device software according to the MDR. It replaces the aforementioned MEDDEV 2.1/6. The classification scheme is key for a lot of manufacturers:
The last question, “Is the Software a Medical Device Software according to the definition of this Guidance?” is particularly relevant. As a reminder:
Medical device software is software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a “medical device” in the MDR or IVDR, regardless of whether the software is independent or driving or influencing the use of a device.
The MDCG emphasizes that the following are irrelevant for classification as MDSW:
The MDCG gives examples of such medical device software (MDSW):
Read our article on when software as an IVDD This classification also applies to the MDCG document.
Exception: Software used only to control hardware
If a piece of software is used exclusively to control a medical device’s hardware and does not have its own medical purpose, then it should be considered only as part of this medical device. In this case, an additional classification according to Rule 11 does not come into consideration.
Criticism of the MDCG document
There has been criticism already, just a few days after publication. Antonio Bartolozzi published a presentation on LinkedIn:
Criticism from Professor Bartolozzi
The Johner Institute assesses this criticism as follows:
Conclusion: The criticism cannot be completely dismissed, even though in some places it is slightly over the top with several exclamation marks. Rule 11 is unsuitable in its current form and the MDCG document does not completely rectify this. That's partly because it:
At the Johner Institute, we don’t think that the classification proposed by Mr. Bartolozzi is the solution either. It would mean that even more devices would fall into class III than is being proposed by the MDCG.
He himself argues that classification should be risk-based, but then takes Rule 11, which only considers the severity of the potential damage, as the basis for his classification.
Australia has also published a document on the classification of software as a medical device. It is entitled “Consultation: Regulation of software, including Software as a Medical Device (SaMD)” and takes the MDR and the IMDRF into account.
As the title of the document makes clear, it does not establish any definitive rules, but asks for feedback on planned regulation.
Heise Online reports of a start-up whose business idea is to diagnose skin diseases on the Internet and charge for this. The company (Goderma)’s website (goderma.com/) takes you through a questionnaire and allows to upload photos of your own skin. Within 48 hours you will get an answer. For just 29 EUR.
Without wanting to go into a discussion about which advantages and disadvantages such an offer has, the question arises whether a / this website is a medical device. Web pages can generally be medical devices - examples of which I have already mentioned in this blog. And what about the specific website? Does it also fall under the definition of a medical device?
To give you a shortened version, the 2007/47 has clarified that stand-alone software also falls under the definition of a medical device, when it can serve the diagnosis, treatment and monitoring of diseases and injuries. It seems likely that the website serves the diagnosis of the disease because Goderma offers the supply of the diagnosis of skin diseases.
Thinking carefully you will come to the conclusion that the intended purpose of the manufacturer of the website is to collect information and to support the workflow of the company. This would mean that the website is not a medical device. It would be different if the software would be designed to pre-analyse the images and to calculate sizes of the skin lesions to determine scores or to support the doctors in a different way, directly in the diagnosis.
As to the classification (not just for the web pages) as a medical device, the question whether something can happen is not crucial.
A loyal reader of my blog alerted me to a Web service attentive, that provides an API for medical diagnoses: www.programmableweb.com/api/promedas
On the manufacturer's website it states:
Promedas provides a clinical expertise system to medical professionals. The Promedas API can be integrated into existing medical systems that contain a patient file database. Using this data, Promedus can provide a differential diagnosis based on the data contained in a patient’s file. The API is currently in a developer beta. To access the API, contact Promedas.
This immediately results in the first few questions I am asked:
The Johner Institute's thoughts on this:
The next question is whether document management systems DMS are medical devices. One might argue that patients could be harmed by errors in a DMS. On the other hand, doctors would always make the final decision.
Both considerations are important, but not relevant to the classification as a medical device: Software never damages directly. It's always people or hardware that ultimately hurt or harm patients. What is relevant, however, is what the manufacturer says, as to how customers can and should use the product. If the manufacturer says that the system is used only for documentation, then this system is not a medical device. However, If the manufacturer says that these, for example, X-ray images will be saved for follow ups, the system serves as therapy, making it a medical device as defined by MPG.
Depending on the wording of the purpose, the manufacturer can make a product a medical device or not. Thus the purpose is not just a document. Rather, the manufacturer will document it in many different ways: In the instructions for use, on its website or in marketing materials, at trade fairs and even in conversations.
Therefore, we recommend DMS vendors to articulate clearly. This can also include explicit exclusions of functionality or application scenarios.
The task of the clinical information systems (HIS) is obviously to assist users in diagnosing, monitoring and treating patients. These systems occasionally endangering patients (indirectly), is also not unknown. For example, if you
Crucial to the question, whether this program should be classified as a medical device, is not only the risk, but being in accordance with the definition:
Consequences for operators
Because no HIS manufactures will survive in the long run whose systems can't do anything but display entered data, all HIS will - I predict - in the medium-term, become a medical device. But no one wants to hear that, especially not the operators, particularly the hospitals. The reason is obvious: Once a HIS is classified as a medical device, it is subject to the Medical Devices Operator Ordinance. And this requires, for example, that
But how can hospitals achieve this? How can they fully check that the HIS with diagnostic functionality still works after a software update? That it still flawlessly cooperates with the RIS, which hangs in the same network segment? That there are no repercussions on the ultrasound machines, which are also connected to the network? The only way to tackle these almost infinite combinations of possible causes of errors, is to operate a risk management system that can be prioritized with the test steps.
Some companies classify their systems as a medical device such as GE whose information system Centricity has the CE mark (in accordance with MDD 93/42 / EC). Here is the corresponding press release from GE.