I’ve often warned medical devices companies that they need to start looking at privacy by design obligations under the General Data Protection Regulation, the GDPR. Engineers at a company where I gave an in-company presentation earlier this year were seriously unhappy that privacy by design obligations can affect both hard and software and that the deadline for transition expires on 25 May 2018. They were surprised, annoyed and then in panic (in that order) because of the time it takes to redesign capital equipment and clouds that these devices feed into. That’s right, by end of May 2018 all the hardware and software that processes personal data and personal data concerning health of EU data subjects must comply with these rules. If it doesn’t, it cannot be used to process that data because it’s non-compliant.

Did you know already that the maximum fine under the GDPR is 4% of the total worldwide annual turnover of the preceding financial year of a company? Happy times if you have to break the news to your boss that your department singlehandedly evaporated last year’s profit for the entire company everywhere.

Pacemaker and other device data

One example of data portability in practice is the ongoing discussion between patients and companies about if the patient can receive the data in their medical device, e.g. pacemaker or continuous blood glucose monitoring system. Manufacturers would routinely say no, but cannot maintain that position anymore when the GDPR is fully applicable in 2018. That means that by then their devices and systems must have been redesigned to accommodate requests for data portability.

Hateful eight

This is why I have dubbed data portability as one of the ‘hateful eight’ of the GDPR innovations with regards to connected health (see slide 10) because it is a nasty one to implement, and will require quite some adaptation to devices and software to make this happen in practice:

[slideshare id=62339621&doc=pchahatefuleightgdprpresentation-160524113253]

I was recently speaking again about implementation of the GDPR in relation to data subjects’ access rights in relation to clinical data for medical devices. Companies present were seeing quite a lot of problems in implementing data portability rights for data subject with respect to clinical data that related to them.

Article 29 WP guidance

The Article 29 Working Party has now issued guidance on how this should work in practice:

“As a good practice, data controllers should start developing the means that will contribute to answer data portability requests, such as download tools and Application Programming Interfaces. They should guarantee that personal data are transmitted in a structured, commonly used and machine-readable format, and they should be encouraged to ensure the interoperability of the data format provided in the exercise of a data portability request.”

Yes, you are reading that correctly:

• download tools and APIs;
• personal data that are transmitted in a structured, commonly used and machine-readable format; and
• interoperable data formats.

Because:

“Article 20 of the General Data Protection Regulation (GDPR) introduces the new right of data portability. This right allows for data subjects to receive the personal data, which they have provided to a data controller, in a structured, commonly used and machine-readable format, and to transmit those data to another data controller without hindrance. This right, which applies subject to certain conditions, supports user choice, user control and consumer empowerment. […] The new right to data portability aims at empowering data subjects regarding their own personal data as it facilitates their ability to move, copy or transmit personal data easily from one IT environment to another.“

This is not – ahem – where industry in medical devices and connected health is orginally coming from although a lot has been improved over the last years.

Main elements of data portability

What rights will data subjects have and must your systems be able to facilitate? Even if you are not the controller, the GDPR obliges processors (which you will be then) to be able to assist the controller in implementing these rights. There are, according to the 29 WP guidance:

• Right to receive (as complement to the right of access);
• Right to transmit personal data from one data controller to another data controller;
• Data portability tools that allow not only for direct downloads, but also for direct transmission to another controller.

The data concerned (the data that must be provided) is all data that the data subject provided, e.g. by virtue of the use of the device. Data that results from operations on that data (inferred and derived data) do not have to be provided, like for example a algorithmic model of the patient concerned created based on the data provided. Privacy by design would require implementing technical means to separate these data from personal data, because if this is not possible, everything must be provided.

IP rights do not as such constitute a ground for refusal, although a potential business risk might. In the words of the Article 29 WP:

“The right to data portability is not a right for an individual to misuse the information in a way that could be qualified as an unfair practice or that would constitute a violation of intellectual property rights. A potential business risk cannot, however, in and of itself serve as the basis for a refusal to answer the portability request and data controllers can transfer the personal data provided by data subjects in a form that does not release information covered by trade secrets or intellectual property rights.”

Formalities

Data controllers must inform the data subjects regarding the availability of the new right to portability.

It’s the controller’s problem if the data set is large. It has to be provided within one month and in any event with undue delay.

The request can only be made subject to a fee in case of requests that are manifestly unfounded or excessive. That means that the controller is not allowed to use fees as a means to pay for the technical means it must develop to meet its obligations.

Personal data are expected to be provided in formats, which have a high level of abstraction. As such, data portability implies an additional layer of data processing by data controllers, in order to extract data from the platform and filter out personal data outside the scope of portability (such as user passwords, payment data, biometric patterns, etc.). This additional data processing will be considered as an accessory to the main data processing, since it is not performed to achieve a new purpose defined by the data controller.

Happy redesigning!

Did I already say that all of this must be ready by 25 May 2018 at the latest? Better start if you have not started yet. And remember, whatever you implement by means of privacy by design may impact your new design obligations under the MDR (the new chapter 14 on software that applies to any software (both standalone and embedded), which addresses e.g. security requirements that may be impacted by a convenient API that allows a user to export their own data). Security requirements for data protection compliance purposes and for the new MDR software securities design requirements are another happy overlap in this respect (see the Hateful Eight presentation framed above).