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:
- 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.
- 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.
- 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
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 ?
- 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.
- 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.
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.
Some interesting questions were raised during discussions after this blog had been published:
- 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.
- 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.
- 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:
- Advantages of online training courses (Oct 12, 2020)
- Combining the best of IHE XDS with HL7 FHIR (Jun 27, 2019)
- FHIR DevDays and the year in review (Dec 27, 2018)
- Creation and Curation of FHIR Profiles - process and governance (Dec 14, 2017)
- De Algemene Verordening Gegevensbescherming (AVG) in de zorg (Dutch, Sep 19, 2017)
- Impact of the GDPR on the use of interoperability standards (Jun 27, 2017)
- News from the FHIR DevDays in Amsterdam (Dec 15, 2016)
- Next XDS Release (Oct 27, 2016)
- Five years of FHIR (Aug 11, 2016)
- Interoperability projects in Ireland - FHIReland (Mar 14, 2016)
- 2016 FHIR Jedi Calendar (Jan 06, 2016)
- Top 10 HL7 videos watched in 2015 (Dec 24, 2015)
- Update from the trenches on CDA R2.1/R3 and HL7v2. (Oct 15, 2015)
- FHIR DevDays - UK GP System APIs (Sep 16, 2015)
- IHE XDS - testing and implementation tools (Aug 25, 2015)
- Most often implemented IHE Profiles (Jun 08, 2015)
- Why we sponsor the HL7 WGM (May 10, 2015)
- FHIR in Paris (Apr 21, 2015)
- Mapping HL7v2 messages to FHIR. (Apr 13, 2015)
- Analysis of CDA R2 testing tools - most requirements are neither tested nor respected. (Feb 13, 2015)
- HL7 and IHE in Sweden (Feb 08, 2015)
- 2015 FHIR Chiefs Calendar (Jan 07, 2015)
- The Merry FHIR Choir caroling the 12 Days of Christmas (Dec 09, 2014)
- Chicago FHIR Update (Oct 13, 2014)
- Internationalization of HL7 (Sep 25, 2014)
- New XDS Advanced training course on offer by IHE Services and IHE Academy (Jul 14, 2014)
- Recent and Future developments of the DICOM standard (Mar 06, 2014)
- Top 10 HL7 videos watched in 2013 (Jan 02, 2014)
- Report from the HL7 WGM in Cambridge (Oct 16, 2013)
- Documenting the history of HL7 (Sep 03, 2013)
- Histology Lab Device Automation using HL7 version 2 (Jul 23, 2013)
- HL7 FHIR Elevator Pitch (Jul 15, 2013)
- Interoperability Standards - the no-sales pitch (Jul 09, 2013)
- HL7 UK - new landscape, new opportunities (Jun 26, 2013)
- Validation and error correction at the IHE Connectathon (Apr 25, 2013)
- CDA Implementation Guides - (not) invented here (Apr 17, 2013)
- Usage of IHE Profiles (Feb 25, 2013)
- 10 year anniversary - Dutch Ringholm HL7 v2 training courses. (Feb 19, 2013)
- About IHE Academy and new IHE training courses (Jan 12, 2013)
- CDA implementation experiences in the UK (Dec 04, 2012)
- Musings on free HL7 IP (Oct 01, 2012)
- HL7 Connectathons (Sep 09, 2012)
- Renovate HL7 version 3 (Aug 03, 2012)
- Frequency of use of HL7 message types (Jul 24, 2012)
- Lighting the FHIR, HL7s new major interoperability standard (Jun 15, 2012)
- Reflections on the HL7 membership model - the affiliate life cycle (Dec 28, 2011)
- Thinking like an OWL reasoner (Sep 17, 2011)
- RFH (Resources for Health): HL7 version 3 taken to the next step (Aug 18, 2011)
- What's so great about the HL7 organization? (Aug 04, 2011)
- Kerndossier: een Nederlandse versie van CCD (Dutch, May 03, 2011)
- A HL7 RIMBAA update (Apr 21, 2011)
- Timezone Hotel (Mar 29, 2011)
- HL7 and openEHR are cooperating (finally) (Jan 21, 2011)
- Increasing demand for IHE training courses (Dec 18, 2010)
- Context issues with the IHE QED profile (Dec 15, 2010)
- The changing role of HL7 country organizations (Jul 16, 2010)
- Implementing HL7 version 3 - the book (May 06, 2010)
- Adding openness to a closed world (Feb 09, 2010)
- How to lower the hurdle for HL7 v3 implementers (Jan 21, 2010)
- HL7 v3 deployment statistics (Dec 17, 2009)
- There's Trouble in Paradigm (Sep 25, 2009)
- Internationalization of HL7 (Sep 24, 2009)
- HL7 UK signs deal with Ringholm to deliver HL7 v2/v3 training courses in London (Sep 17, 2009)
- The use of HL7 in South Africa (Aug 20, 2009)
- The Next Web Conference in Amsterdam (Apr 17, 2009)
- The HL7 UK AGM and RIMBAA (Apr 16, 2009)
- The HL7 Wiki reaches 2000 pages (Mar 02, 2009)
- The HL7 roadmap for CDA R3 and the CCD (Jan 17, 2009)
- HL7 Affiliates Meeting in Orlando (Jan 11, 2009)
- Swiss and Dutch HL7 News (Dec 31, 2008)
- Devices and Prizes (Nov 22, 2008)
- HL7 in Norway: a situation report (Sep 02, 2008)
- Russian whitepaper (Jul 09, 2008)
- The HL7 Interoperability Conference - IHIC 2008 (May 30, 2008)
- HL7 creates a RIM Based Application Architecture (RIMBAA) group (May 18, 2008)
- Notes from the HL7 WGM in Phoenix (May 08, 2008)
- HL7 v3 RIM based applications: an unintended side effect (Jan 19, 2008)
- Collaborative Tools (Jun 21, 2007)
- HL7 ist Pflicht in der deutschen Telematikinfrastruktur (German, Mar 16, 2007)
- HL7 based Tree inventory system (Jan 30, 2007)
- The link between HL7 and Open Source Software (Jan 06, 2007)
- Workflow Bribery (Sep 15, 2006)
- Timezones in HL7 (Jan 23, 2004)
- Controlled vocabularies: "@*%!!!" ? (Sep 01, 2003)
- Trusting the other Party (Nov 01, 2002)
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.
See http://www.ringholm.com or call +31 33 7 630 636 for additional information.
Rene is the Tutor-in-chief of Ringholm.