A shild with an eye on it, symbolizing GDPR principles

GDPR Principles and Medical Software: Privacy by Design is King

Modern medical care is increasingly dependent on medical software. Both device software and standalone software is a medical device if it serves a medical purpose. Such software processes patient-related data on a relevant scale. This data is “special” data, which plays an important role in the medical care of patients. Thus it requires special protection. In Europe, the General Data Protection Regulation (GDPR) is the legal basis for protecting individual’s data. It has only recently come into force (2018) and includes numerous changes. In the following, we explain how GDPR principles affect medical devices in general and medical software in particular and what manufacturers and operators must pay particular attention to.

Basic GDPR Principles

The GDPR is valid since 25 May 2018 in all European member states and applies to the processing of personal data. Exceptions apply e.g. to certain authorities and private persons. An important part of the GDPR principles concerns the territorial scope. Accordingly, the GDPR applies to companies which have customers in the EU, track customers by means of data profiling or offer goods or services in the EU in general. The fact whether such a company has its own branch in the EU is not relevant. The GDPR is valid in every case. A further aspect of GDPR principles affects the way how data are processed in general. These principles are:
  • transparency
  • purpose limitation
  • data minimization
  • accuracy
  • storage limitation
  • integrity
  • confidentiality
Thus, if you are a manufacturer of medical software you should observe these principles at an early stage. It should be your goal to implement privacy by design into your product and your (business) processes.


What data are we talking about in detail? GDPR only applies for personal data. Personal data means any information relating to an identified or identifiable natural person which is called a “data subject”. Processing of personal data is generally prohibited and is only allowed if a legitimation exists (in the GDPR). However, there are special categories of personal data whose processing has to meet stronger requirements. This applies for data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership. Also genetic data, biometric data, data concerning health or data concerning sexual orientation are considered to be special categories. When we talk about medical devices and medical software, of course “data concerning health” is of particular interest. Unfortunately, as shown above, the GDPR apparently prohibits their processing. However, there are some exceptions whose precise understanding is important for a manufacturer or operator of medical software. There are four relevant situations in which manufacturers or operators of medical devices (or software) can lawfully process health data:
  • the data subject has explicitly consented,
  • the processing is necessary for the purpose of medical treatment, or
  • for reasons of public interest in the area of public health, or
  • for assuring high quality standards of the product.
However, the GDPR restricts the processing of health data as part of the medical treatment because only specialized personnel are permitted to do that. In addition, the GDPR explicitly allows the EU member states to introduce additional regulations at this point. It is therefore reasonable to deal in detail with this section of the law and to examine the individual situation.

Roles and Responsibilities

The GDPR principles include certain roles with the processing of personal data, in particular the controller, the joint controller, the processor, or the third party. The controller is the responsible body and determines the purposes and means of the processing of personal data. Two or more controllers are joint controllers when they determine the purposes and means of data processing together. The processor is an external party and processes the controller’s data on behalf of him. A processor is thus a kind of an external “employee” of the controller which must process the data to the requirements of the controller. Hence, it is very important to evaluate who plays which role in order to find out what obligations who has in each individual case. If you are a processor, you are responsible for meeting the legal requirements of the GDPR. You must then also take the necessary technical and organizational measures as part of the risk management. Unfortunately, it is often difficult for medical device manufacturers to judge whether they are actually “responsible” for the data processing of their product. As shown above, the individual case is decisive. Not only the contractual aspects but also the technical and organizational conditions are important. The medical device design and the way how it transfers and processes data also play an important role. If, for example, a manufacturer gets access to patient data in the case of remote maintenance, he is likely to be the processor. The controller must then conclude a special contract with the processor. If the processor processes the data independently (for other purposes on his own behalf), he becomes the controller.

Access, Rectification and Erasure

The public debate on the risks of social media in recent years has made some of us more sensitive in the way we handle our personal data. More and more, people expect that it should always be possible to receive information about one’s data, to change or correct one’s data and, of course, to delete one’s data if e.g. one revokes one’s consent to data processing. By now the GDPR grants these rights explicitly. The data subject therefore has the right to obtain confirmation from the controller as to whether the controller has processed data relating to him or her. In this case, he or she has the right to access these personal data, i.e. also to a copy of all data stored by the controller. In addition, the data subject may also request information on a range of supplementary information, such as the purpose of the processing, the duration of the storage or any recipients of the data. Moreover, the data subject has the right to request that the controller rectify inaccurate personal data without delay. The same applies to the deletion of personal data, e.g. if the data subject withdraws its consent, if data has been unlawfully processed or if the data is no longer required for the respective purpose. It follows that the more networked medical technology is and the more players are involved in the application of medical software, the more costly it should be to implement the above-mentioned legal requirements consistently. However, it becomes even more complex if personal data is published in any way in the use of a medical product or medical software. In this case, the controller must take reasonable steps, including technical measures, to cause deletion of the respective data. This also includes search engines or public directories. Fortunately, this case shouldn’t be the rule.


Another issue of the GDPR principles regarding the rights of the individual are his rights in the case of profiling. Profiling is any form of automated processing of personal data in order to evaluate personal aspects relating to a natural person, including health. Therefore, profiling is a relevant component of many medical devices including medical software. Examples are a patient monitoring system or a device to continuously measure a metabolic component. It is therefore important to know that the data subject has the right not to be subject to a decision based solely on automated processing, including profiling. Such an automated decision could produce legal effects concerning him or her or similarly significantly affects him or her. However, there are restrictions to this rule, especially if the data subject has explicitly consented or if a contract has to be fulfilled. Nevertheless, the GDPR principles mentioned above, in particular transparency, access, rectification and erasure apply as well in the case of profiling. For example, the data subject has the right to know whether and how profiling is carried out. The controller must provide meaningful information about the logic involved as well as the scope and desired effects of such processing. And of course the data subject has the possibility to revoke his consent at any time.

Data Portability

What happens to my data when I change a provider? Also here the GDPR strengthens the rights of the data subjects. For the first time there is a right on data portability. Accordingly, the data subject can receive the personal data concerning him or her, which he or she has provided to a controller. Then, the controller must provide the data in a structured, commonly used and machine-readable format. The GDPR principles also demands that the transfer of data from one controller to another controller must not be slowed down by any (technical) hurdles. It will become clear in the future how the controller can technically implement this demand together with the medical devices or software manufacturers. The more players are involved in a medical device, system or method, the more difficult it will be to provide consistent interfaces and processes for smooth data transfer. Here, too, privacy by design will quickly pay off.

Risk Management

Interestingly, the GDPR principles include a kind of new risk management, even if it does not call it so. The GDPR recognizes that many data processing procedures represent high risks for the rights and freedoms of persons. Therefore, necessary actions measure themselves at the risk of the data processing to be expected. The measures for the protection of the data must consequently always be appropriate. For this reason, the GDPR requires a special impact assessment for data processing that involves a particularly high risk. This could be e.g. the case when profiling is carried out. The controller is responsible for this special form of risk management. In particular, he or she evaluates the cause, type, specificity and severity of the risk and takes necessary measures from this. By doing so, the controller must prove that the processing of personal data is in compliance with the GDPR. If the controller cannot limit the risk by suitable technical measures, he or she should consult the supervisory authority before processing. The data protection impact assessment is therefore a kind of preliminary check.

Privacy by Design

It is part of the GDPR principles to think about data protection from the outset, to view it holistically and to implement it in all processes. Consequently, the GDPR demands that the controller establishes privacy by design in his organization and therefore in his processes. This requirement applies to all data processing systems (software and hardware) that collect and process personal data from data subjects. This is why it applies equally to old systems and, of course, to new systems to be purchased. The controller is obligated to privacy by design. Software manufacturers are not obliged to develop or offer data protection-friendly technology for GDPR reasons unless they are controllers themselves. However, controllers may expect to receive products with which they can implement privacy by design in their processes. This will create a corresponding market pressure. If a (medical) software manufacturer studies the GDPR in detail, he knows exactly what his customers need in order to be “compliant”. If the manufacturer advertises “GDPR compliant” or “compliant to the current laws” and the software does not meet these requirements, a civil law problem can arise. Therefore, the manufacturer should inform a customer if the software design is not GDPR compliant, e.g. due to a modular structure.

Privacy by Default

According to GDPR, a controller can only use software and hardware which has data protection-friendly pre-settings. Hence, data protection and data security must be implemented routinely in devices, software and systems. Consequently, privacy by default should also become standard in medical devices and medical software. In the standard settings, software may only process as little personal data as possible and transmit as little data as possible to “outsiders”. Of course, this also applies to medical software. However, this must function perfectly as part of medical diagnosis or therapy. Here, both the software manufacturers and the controllers must carefully weigh the optimal compromise between medical performance on the one hand and data protection on the other in view of the GDPR principles. Overall, the manufacturer should transparently explain to the customer or the processor, respectively, how the software is structured and to what extent the manufacturer can influence privacy by design and privacy by default. As an appropriate measure he should create a corresponding documentation that describes in detail how the software realizes GDPR requirements.


So manufacturers, operators and controllers in medical technology have a lot of work to do. Even if many GDPR principles do not appear completely new, detail questions concerning practical implementation might cause the biggest expenditure in the long run. In addition, substantial fines threaten. Up to EUR 20 million or 4% of an annual turnover are possible, depending on the type and severity of the infringement. In addition, companies may be confronted with warnings under competition law.