Ringholm-Logo Ringholm Ringholm page header

Impact of the GDPR on the use of interoperability standards

Publication date: Jun 27, 2017

Recently I was made aware that the EU GDPR (General Data Protection Regulation) will have a significant impact on the use of interoperability standards.

I've heard the GDPR mentioned during the past few years, but I thought it would once again be one of those high level pieces of legislation which focuses on consent and security. Something one perhaps would worry about if one happens to be a security officer, but other than that something which could be safely ignored.

As it turns out, I was wrong: this will have a direct impact on the use of interoperability standards, and as such it is something that those that implement or create healthcare data interoperability standards need to be aware of.

GDPR, wider impact

The GDPR aims to give EU citizens and residents back control of their personal data; this is a new obligation compared to the old EU Data Protection Directive. A few highlights:
  • Valid consent must be explicit (opt-in based) for data collected and the purposes data is used (it does however list a series of grounds when one doesn't need to seek consent, e.g. for the provision of health or social care or treatment)
  • The data subject has the right to request erasure of personal data related to them
  • A person shall be able to transfer their personal data from one electronic processing system to and into another, without being prevented from doing so by the data controller. In addition, the data must be provided by the controller in a structured and commonly used Open Standard electronic format. 
  • Privacy by Design and by Default (Article 25): this requires that privacy settings must be set at a high level by default. (see also this US publication on Privacy by Design)
  • Has force of law, effective May 2018. This is a EU Regulation (which has force of law), rather than a EU Directive (which means member states have to create/change their own legislation to reflect the contents of the directive).
  • The law is extraterritorial, i.e. it applies to any organization which stores, transfers or otherwise processes data from EU citizens, regardless of whether that organization is based in the EU or not.

What is the GDPR?

For a high level overview of the GDPR and its components, see Wikipedia, this legal assessment or analysis by the European Patient Federation. It rehashes a lot of privacy principles defined by other parties, e.g. by the OECD. The GDPR covers a range of issues, most of these are focused on how to run the organisation procedurally, how to take privacy seriously and protect the sensitive personal data of customers and employees. This post mainly focuses on the new Data Portability requirement, as well as on its Data Access requirement.

Data Access right

The right of access (GDPR Article 15) defines that a patient has the right
  • to obtain from a data controller confirmation as to whether or not personal data concerning him or her are being processed, and, where that is the case, access to the personal data and the following information (amonst other things):
    • the purposes of the processing;
    • the categories of personal data concerned;
    • the recipients or categories of recipient to whom the personal data have been or will be disclosed,
    • where possible, the envisaged period for which the personal data will be stored, or, if not possible, the criteria used to determine that period;
    • where the personal data are not collected from the data subject, any available information as to their source.
  • The controller shall provide a copy of the personal data undergoing processing. Where the data subject makes the request by electronic means, and unless otherwise requested by the data subject, the information SHALL be provided in a commonly used electronic form.
    • Note that (unlike the Data Portability right) this doesn't require that a machine-readable format be used, e.g. the use of PDF documents would satisfy the GDPR requirements. A machine-readable format MAY be used, but there is no requirement to do so. Given the ever increasing use of patient portals one may, or may not, get away with just providing the data as PDF files.

Data Portability right

One of the new things introduced by the GDPR is the right to data portability (PDF). This allows individuals to obtain and reuse their personal data for their own purposes across different services (e.g. second opinion, switching healthcare providers, use of a PHR). It allows them to move, copy or transfer personal data easily from one IT environment to another in a safe and secure way, without hindrance to usability.

Data portability applies to personal data concerning the data subject:

  1. Which is processed automatically (so not paper records)
    • The patient has a (separate) right to access all of their records (see previous section), data portability however is limited to any electronic data.
  2. Which is provided by the individual,
    • This includes any information provided verbally/in writing such as their medical history, but also any observations on the patient or samples taken from the patient, such as findings from physical examinations, medical images, lab values, observations in general. (In other words: the Subjective and Objective parts of a SOAP Note). It also includes any metadata necessary to interpret the data, such as the time of the observation.
    • This does NOT include any derived data (added by the healthcare provider) such as: conclusions, diagnoses, treatment plans, goals.
  3. which is processed based the individual’s consent or for the performance of a contract.
    • the data portability right ONLY applies when the processing of health data happens on the basis of an explicit patient consent (or their explicit agreement to the terms of a contract with a healthcare provider, i.e. when the patient signs a contract with a private care provider).
    • The data portability right doesn’t apply when "processing is necessary for the purposes of preventive or occupational medicine, for the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment or the management of health or social care systems and services on the basis of Union or Member State law" (GDPR, Art. 9, para.2, point(h))
    • That's a rather wide ranging definition which greatly diminishes the value of the Data Portability right in healthcare. However, any processing or exchange of data which requires patient consent (e.g. most regional/national data exchanges, XDS/XCA implementations, clinical trial data) will be subject to the GDPR data portability right.

In order to satisfy the Data portability requirement one has to know what information is subject to which explicit patient consent (or contract), and the information has to be either provided by the patient (e.g. quantified self, medical history) or has to be (in most general terms) an observation on the patient - this will require those specific data items to be labelled as such. If one isn't able to distinguish between this category of data and other data one will have no choice but to disclose all of it, and to do so in a machine-reable (i.e. using healthcare interoperability standards) format.


GDPR requirements when Transferring Data

To quote the EU Guidance for the implementation of data portability document:

  • Data controllers 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.
  • it strongly encourages cooperation between industry stakeholders and trade associations to work together on a common set of interoperable standards and formats to deliver the requirements of the right to data portability.
  • On a technical level, data controllers should explore and assess two different and complimentary paths for making portable data available to the data subjects or to other data controllers (1) a direct transmission of the overall dataset of portable data (or several extracts of parts of the global dataset); (2) an automated tool that allows extraction of relevant data. This may be preferred by data controllers in cases involving of complex and large data sets.
  • The overall system implementation costs should neither be charged to the data subjects, nor be used to justify a refusal to answer portability requests.

Erik Vollebrecht's blog describes the impact of GDPR on medical devices like pacemakers and continuous blood glucose monitoring systems. "Engineers at a company [..] 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."

The GDPR allows one to respond "within 30 days". These requests are likely to occur frequently, and as such one will have to create a scalable solution to deal with the issue - "a practical way by which a data controller can answer requests for data portability may be by offering an appropriately secured and documented API".

Within the EU there are a fair number of countries that currently don't provide any access to electronic patient data. For patients in those countries the Data Portability right (even when limited to certain use cases which require explicit patient consent) is potentially a "big stick". Other countries already provide some form of limited access to electronic patient data - in these countries the Data Portability right may end up being a right of the last resort in case patients aren't satisfied with whatever is provided via current methods.

Impact on data exchanges

The GDPR mainly has an impact on organisational processes and the internal architectures of software applications and devices which store, use or process patient data. How does it impact the use of interoperability standards ?
  1. The new right to Data Portability requires that applications use a common set of interoperable standards (which could be any generally accepted healthcare interoperability standard, e.g. DICOM, HL7v2, CDA, FHIR, etc.). This new right has a direct impact on the interoperability requirements of any application which creates/uses/processes healthcare data, if and when that application is involved in any data processing scenario which requires explicit patient consent under the GDPR.
  2. Whenever data needs to be exchanged (be it within one single organisation, or between organisations), it will have to be enriched with metadata (such as consent, provenance and security labels) if the originator of the data can reasonably assume that such metadata may have consequences on the processing/use of the data by the receiver. Examples:
    • If the patient consented to sharing the data with the research community in general, then that consent would allow the receiver to redisclose the data to other research organizations.
    • A label on an item of data that states "data subject to the Data Portability rights" would be useful for any 'downstream' processors of that data (i.e. processors which recieve or query for the data at some later point in time), for that specific data item would also be subject to the Data Portability right within a receiving application.
    • Receivers should be informed about the Data Retention policy as applicable to this data item. If the originator of the data has its reasons to declare an item to be "valuable for treatment during the next year" a receiver would have to have a good reason for using a different data retention period.

GDPR and its impact on the use of interoperability standards

Whether FHIR is used as the 'data Portability API' or as part of any healthcare data exchange:

  • GDPR in general will require a detailed Consent management system, as well as the use of Security Labels (as the basis for an access control mechanism). FHIR Consent Directives tell data processors/holders what security labels to use on types/instances of data and related data.
  • The new right to Data Portability effectively adds a requirement to use Security Labels (to label which data items fall under the data portability act) as well as the Provenance resource (to identify any information provided by the patient, when this was done, to whom).
  • If one manages a pool of data, some of which is related to EU citizens, one will have to add a label in order to identify the data which falls under the GDPR regulation, which includes a 72 hour notification requirement in case of any data breaches.
  • GDPR also requires auditing (and for any data disclosures: why/to whom/what context/based on which consent/legal ground); patients have the right to view their entries from the audit log of any data controller or data processor. These can be served as AuditEvent resources.

Two centralized registries could be used to lessen the overall interoperability burden of the GDPR:

  • One of the main legal grounds listed in the GDPR for the exchange of data is related to the joint provision of health or social care or treatment. This means that (using FHIR terms) the existence of an EpisodeOfCare or Encounter resource and the parties involved therein (who may work for different legal entities, e.g. a hospital clinician and a GP) should play an essential role in the access control mechanism. This may require the creation of a Care-Relationship registry at the regional/national level (e.g. as already implemented in Finland).
  • In order for data interoperability to work under the GDPR there should be a harmonized set of security labels as well as a nationally defined set of consent policies. Ideally there would be a nationwide registry which holds the patient consents: the patient has to consent just once, and all healthcare providers will be able to locate and use that consent. (e.g. this is planned for the Netherlands).

Opportunity for FHIR

The EU Guidance strongly encourages cooperation between industry stakeholders and trade associations to work together on a common set of interoperable standards and formats to deliver the requirements of the right to data portability. It also suggests that vendors offer an appropriately secured and documented API.

FHIR could be that standard.

-Rene

Thanks to Kathleen Connor for reminding me about the GDPR, and thanks to John Moehrke and Kathleen Connor for reviewing draft versions of this post. Rob Madge provided useful feedback after publication of this post.

Questions/comments

Some interesting questions were raised during discussions after this blog had been published:
  1. Question: As a vendor, can I get away with creating a CSV-formatted database dump to satisfy the Data Portability Right ?
    • No. Whilst it is true that the GDPR does not require (it just "strongly recommends") the use of an API nor the use of "commonly used industry standards" the overall aim of the Data portability right is to enable the patient to easily upload the downloaded data somewhere else (another healthcare provider, another software application). The GDPR requires the use of a "machine-readable" format.
    • GDPR Recital 68 provides a clarification that this format should be interoperable, a term that is defined in the EU as: "the ability of disparate and diverse organisations to interact towards mutually beneficial and agreed common goals, involving the sharing of information and knowledge between the organisations, through the business processes they support, by means of the exchange of data between their respective ICT systems. The terms “structured”, “commonly used” and “machine-readable” are a set of minimal requirements that should facilitate the interoperability of the data format provided by the data controller. In that way, “structured, commonly used and machine readable” are specifications for the means, whereas interoperability is the desired outcome.
    • Recital 21 of the Directive 2013/37/EU17 defines “machine readable” as: "a file format structured so that software applications can easily identify, recognize and extract specific data, including individual statements of fact, and their internal structure. Data encoded in files that are structured in a machine-readable format are machine-readable data. Machine-readable formats can be open or proprietary; they can be formal standards or not. Documents encoded in a file format that limits automatic processing, because the data cannot, or cannot easily, be extracted from them, should not be considered to be in a machine-readable format. Member States should where appropriate encourage the use of open, machine-readable formats."
    • To qoute the official EU guidance on data portability: "Data controllers should provide as many metadata with the data as possible at the best possible level of granularity, which preserves the precise meaning of exchanged information. As an example, providing an individual with .pdf versions of an email inbox would not be sufficiently structured. E-mail data must be provided in a format which preserves all the meta-data, to allow the effective re-use of the data. As such, when selecting a data format in which to provide the personal data, the data controller should consider how this format would impact or hinder the individual’s right to re-use the data."
    • If one uses an industry-standard interface (such as HL7, IHE, DICOM, IEEE 11073) for other purposes, it would be difficult to defend ones decision to use CSV as the format for the Data Portability right. This could well be interpreted as a conscious attemp to limit the individual’s right to re-use the data, given that commonly agreed upon industry standards exist.
  2. Question: As a healthcare provider, can one avoid ever being subject to a patient exercising their Data Portability right?
    • Not likely. Given the use of IT systems in healthcare, and the ever increasing data exchange/processing requirements, and the increasing amount of patient generated health data one will relatively quickly have a scenario at hand which requires explicit patient consent - which consequently means the Data portability right applies to any data (either provided by, or observed on the patient) covered by the consent.
    • If one is involved in the shared provision of care, and one receives/stores any data from other healthcare providers which are labeled as being subject to the 'Data Portability' right (e.g. any data provided directly by the patient to the other healthcare provider) then one will be subject to the Joint Controllers GDPR article, which states that the patient has to right to ask any of the healthcare providers that hold a copy of their data for a machine-readable version thereof.
  3. Rob Madge wrote a blogpost GDPR Data Portability is a False Promise which is not limited to healthcare data; it focuses on the general use case. Please note that the second part of his post (about "Legitimate Interest") doesn't apply when it comes to health data.

PermaLink to this page: http://www.ringholm.com/column/GDPR_impact_on healthcare_data_interoperability.htm

Index of columns:

About Ringholm bv

Ringholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.
Rene's Column (English) Rene is the Tutor-in-chief of Ringholm.
[e-mail]