What Is GDPR's Effect On Medical Devices?

By John Kenneth Barchie, Arrakis Consulting

The EU’s General Data Protection Regulation (GDPR) will go into full effect on May 25, 2018 — as will penalties for non-compliance. While most of the GDPR affects the back end of medical device data handling, the Cloud, Databases, and transportation of data, some of the GDPR affects software on medical devices themselves:

Consent is the first concern for somebody developing a medical device that will access sensitive patient data.  If the patient is interacting with the medical device, a consent form must be provided to patients, allowing them to acknowledge their rights and consent to processing of their information (either on the device itself, or on the device’s back end).

          

Basically, there is a long list of what cannot be processed without explicit consent.  The processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade-union membership, as well as the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health, or data concerning a natural person's sex life or sexual orientation, is prohibited without explicit consent.

Consent forms cannot be pre-selected, and they need to take into consideration the age of the patient, as well as patient nationality and special handling for children (i.e., parental consent).   

If your development team uses an Agile development system, you may hear some groans, as this is a non-trivial, multi-disciplinary task that requires the entire organization to know what data they need in order to provide the appropriate service to a consumer. 

The basic concept with GDPR is that your patient’s data is no longer yours to process at will. Instead, the device now needs to be configured to protect patients’ data, as is THEIR right.  Violation of this concept can be grounds for penalties.

If the device is used by practitioners, each practitioner will need a way to signify that the patient understands and gives consent to the processing  of their data that will take place on the medical device (or on the back end). Essentially, whomever controls the data on behalf of the patient is considered the Controller;  if the Controller subcontracts processing to another service provider, that provider is considered the Processer. In any case, processing that takes place on medical devices is covered under GDPR in any case where the data subject is a member of an EU country, or is visiting the EU.

Encrypting the data on devices at rest and in transit is paramount. Pseudonymization generally is a more difficult proposition for medical devices used directly by patients, but for back-end processing, where lots of devices aggregate their data, it should be regularly considered.

Phones that draw data from and/or are updated by medical devices should be considered medical devices for purposes of compliance with GDPR Article 32.   Write your software with the patient’s rights, not just security, in mind.

Other things to keep in mind include: if actual processing takes place on the medical device, it will need to be captured as a place of processing on reports that may go back to the patient. If processing on the device is considered high-risk, it will need a formal and documented risk assessment. Patients also can request that processing be suspended while particulars in their data or account are being reviewed. Implementing that command into a medical device is problematic, at best.  Indeed, GDPR gives patients many Rights and privileges that may not be familiar to those outside the EU that are processing medical device data.

Rights provided to data subjects reinforced via GDPR are:

• The right to be informed of the type of processing of their data that will be taking place
• The right to access and review the data that is being used to make decisions on the data subject
• The right to be forgotten once the service provided is completed
• The right to data portability, where the service provider must provide the data subject their data in electronic format

These rights have many specific processing requirements built around them and the relevant Supervisory Authorities, those organizations that enforce GDPR, will have opinions on how these rights should be applied.

That said, GDPR is not much different, functionally, from HIPAA. If a medical device was created with a strong HIPAA understanding, making the device GDPR compliant may not be as burdensome as it initially seems. Still, GDPR imposes a software development burden on medical devices, from communications and storage to processing and data collection, as well as consent, and devices that have yet to be updated likely need revision in order to become GDPR compliant.

About The Author

John Barchie is a Senior Fellow with Arrakis Consulting, and has twenty years of experience in computer networking -- particularly Information Technology and Cyber Security. The majority of his career has been spent developing security protocols for Silicon Valley corporations including Symantec, Paypal, PG&E, KPMG and OpenSky. He has completed security projects for Sony PlayStation and NASA. John is ISACA, (ISC)2 and ISACA certified.