Medical care has become digital. We now routinely use smartphone apps, image analysis software or data-based patient models. These are just a few examples. The decisive component here is software. But what does it mean for risk assessment when a computer program becomes a medical device? And what is the consequence in terms of product liability? Manufacturers of medical devices or software have to answer this question carefully. Medical software must meet considerably stricter legal requirements than software without a medical scope. The approval or certification of medical software costs a lot of time and money. What is even more important, however, is risk compensation in view of product liability. Since manufacturers of medical software are exposed to considerable risks here, corresponding measures such as concluding product liability insurance are mandatory.
Contents
Regulation of Medical Software
The legal basis for medical devices and thus also for medical software in Europe is the EU medical device regulation 2017/745 (EU MDR), which came into force on 25 May 2017. Even though the “old” directives on medical devices and active implants will continue to apply in a transitional period until 26 May 2021, you should always deal intensively with the new regulation. First of all, there is the question whether your software is a medical device at all. A bold look at the definition of medical devices will help here. The EU MDR defines medical devices primarily on the basis of their areas of application. These are:- 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 and
- providing information by means of in vitro examination of specimens derived from the human body, including organ, blood and tissue donations.
Stand-Alone or Integrated Software
In addition to devices, instruments, apparatus etc., the EU MDR explicitly mentions software. Thus software can be a medical device in principle if it has a medical purpose. However, to make things more demanding, the law distinguishes between independent medical software and device-related medical software. Independent medical software, so-called “stand-alone software”, performs its functions independently and does not require an associated medical device. Device-related medical software, on the other hand, is required for the operation of a medical product and must be regarded as a component thereof. Such software is an integral part of an apparatus, device, instrument or system. Read our article about “Stand-alone Software as Medical Device” for a deeper insight into this subtopic. All in all, the legal wording makes clear that medical software obviously has to be able to do more than just search for, store, archive or transmit data. In particular, medical software interprets data. It directly helps to make diagnoses and initiate therapies. This also means that patient data management systems, hospital information systems or medical learning and teaching programs are not medical software.Purpose of Use
But who ultimately determines whether software is a medical device or not? The answer: It is the manufacturer of the software. Software becomes a medical device if the manufacturer itself assigns it a medical purpose. For this, the manufacturer determines who may use the software for what purpose. These specifications appear in the labelling, the instructions for use or in the advertising material. It is therefore a “subjective” purpose. But what happens if users use software medically that the manufacturer has not designated as such? This would at least have no significance for the question of whether it is a medical device or not. The decisive factor is the manufacturer’s assessment. The purpose of the software, which the manufacturer has determined, is of decisive importance for the later risk consideration. And this, of course, also applies to the question to what extent product liability comes into effect. However, manufacturers cannot resolve product liability issues solely by considering the medical device regulation. There are other areas of law that are also important. They also require analysis if you want to assess the risk of product liability for your medical software.Copyright
For example, think of the copyright. It protects the intellectual property and serves to secure and exploit the author’s rights. Software is subject to copyright. For cost and time reasons, software developers usually fall back on already existing third-party components. They often use open source components, which is particularly tempting because they are freely available. But be careful at this point. Open source software or freeware does not necessarily mean that you can integrate these components into your commercial software without further ado. The same applies to third-party services or content of any kind like text parts or images. Therefore, check and document each external component and content carefully to see whether, to what extent, or under what conditions the authors allow you to use it.Data Protection
Data protection also plays an important role. A person has the right to decide which of the personal data he wants to make available to a responsible body. The person also decides for what purpose a responsible body may process his or her data. If, for example, a software manufacturer brings the user data into a cloud, he can become a responsible body in this way. The consequence of this is that he must comply with all legal requirements for such a responsible body. He must also examine in detail which data protection rules are relevant in the individual case. Therefore, it is important for software manufacturers to understand that data protection follows certain principles:- There must be a clear and legitimate purpose to the data processing.
- The level of data processing must be reasonable and proportionate to the purpose of the processing.
- Data processing must be transparent so that users can keep themselves informed at all times.
- Measures related to data protection law must always be proportionate.