Stream: implementers
Topic: EU GDPR Legislation
René Spronk (Jun 26 2017 at 10:43):
Are you located in the EU, or does your application use/process data from EU citizens? Then the GDPR (General data protection Regulation) legislation is likely to impact your application, see http://www.ringholm.com/column/GDPR_impact_on%20healthcare_data_interoperability.htm for (initial) analysis.
If you are like me (dismissive of such laws: who cares about such legislation, it's mostly procedural/organisational) - this will have an impact at the coalface and on the use of interoperability standards such as FHIR.
Grahame Grieve (Jun 26 2017 at 10:51):
I'm not yet aware of any direct impact on FHIR itself. It does mean that you mean to by more careful around provenance, auditing, and your policy (and adherence)
John Moehrke (Jun 26 2017 at 12:17):
We also designed Consent with these rules in mind. Hence why we included a place to record the actual text the patient saw and agreed to, so that it can be shown that it was crafted such that it would be understood by that patient. Yes, Provenance and Auditing are always important .
John Moehrke (Jun 26 2017 at 12:23):
The unique view Rene has captured is the requirement to provide to the subject any data about the subject ... in a standardized form... that is useful... hence "Interoperability Standards" (PDF likely not good enough). As with the human-language-comprehension requirement, this Interoperability Standards requirement is the right thing for the goal of Privacy (which is more than confidentiality http://healthcaresecprivacy.blogspot.com/2015/04/privacy-principles.html ). But these requirements are hard to achieve, especially for small organizations. Ewout pointed this out at the Madrid meeting.
René Spronk (Jun 27 2017 at 06:48):
The post is more of a wake up call: if your application is involved in any data processing scenario which requires a patient consent, then under the GDPR you SHALL have an API by May 2018 which allows the patient to pull all of the data out of the application in a structured fashion.
That's a challenge above and beyond the more general requirement of taking better care of general privacy and security issues.
Vadim Peretokin (Jun 27 2017 at 06:56):
Does this legislation mention anything about you receiving private patient information accidentally? For example if you're neither a processor nor a controller, but someone emails it to you by accident
Grahame Grieve (Jun 27 2017 at 06:58):
I think it would make EU adoption of an argonaut like process and API somewhat urgent, but I'm not hearing very much noise about that
Kevin Mayfield (Jun 27 2017 at 07:47):
Alpha version of UK API - https://nhsconnect.github.io/CareConnectAPI/explore.html
Kevin Mayfield (Jun 27 2017 at 08:16):
The section on security labels and provenance. I'm seeing this as applying more to messaging rather than API's - a big spanner for traditional (HL7v2) messaging?
René Spronk (Jun 27 2017 at 09:29):
You're wrong - this requirement spans all paradigms. In REST, labels need to be present as part of the matadata of all resources, and Provenance (&Consent) resources much be both created on the server and they must by queryable. Same for AuditEvents.
In a bundle (e.g. of type message) one would include the Provenance & Consent resources. If the bundle were in to be in response to a $gimme-GDPR-everything operation, it would also include all AuditEvent resources.
The impact of GDPR may be wider than that, that section is just an initial analysis.
Grahame Grieve (Jun 27 2017 at 10:07):
perhaps we could work towards a connectathon about this at DevDays?
John Moehrke (Jun 27 2017 at 14:37):
I would be very happy to find a set of people interested in testing security-labels, Provenance, AuditEvent, and Consent. Mike Davis has sent Duane to the last 5-6 connectathons only to find no one ready to address this level of Access Control or Audit Logging... He has great materials on how he has implemented it.
Kevin Mayfield (Jun 27 2017 at 15:11):
@René Spronk I was commenting with an engineering hat on. It will take far longer for messaging systems to adapt, if it is built into EU FHIR it's a big plus for adoption. Is it worth having an EU stream for these topics? Zulip can be difficult to follow at times.
René Spronk (Jun 28 2017 at 06:50):
I'm aware some of the US HIPAA consultants have been working on extending HL7v2 and HL7 v3 (CDA) to include Consent and other bits that would also be needed for the GDPR. We may wish to look into that.
We could try and arrange a stream, but we'll have to see how we can raise awareness about this issue first - if we don't get sufficient interest in the issue any initiatives will be dead in the water. Usually there's not that much which binds the various EU Affiliates, not the various EU Vendors, so an EU Argonaut type initiative will be very hard to organise. We should probably go for generic guidance around the use of certain resources, and test that at a FHIR connectathon.
Grahame Grieve (Jun 28 2017 at 08:10):
yes. I just read what you wrote. Some of the legislation is astonishing, actually. Outright fantasy. I'm guessing that the EU or national governments haven't actually allocated money to cover their own costs in meeting the law, let alone any one else's costs - only to mandate that you can't recover them. As for investing in the infrastructure that they assume exists...
Grahame Grieve (Jun 28 2017 at 08:10):
anyway, we definitely need a stream on consent at DevDays.
Grahame Grieve (Jun 28 2017 at 08:10):
I'll look into that
Grahame Grieve (Jun 28 2017 at 08:11):
on the subject of EU Argonaut... I expect that will be problematic, yes
René Spronk (Jun 28 2017 at 12:34):
The May2018 deadline will never be met in healthcare - we all know that. I don't know about the specifics of all EU governments, but certainly the Dutch governoment doesn't seem to be aware of the consequences of this requirement.
Having a CAT stream on consent/security labels/AuditEvent would seem desirable.
John Moehrke (Jun 28 2017 at 12:35):
I am not convinced that this changes the Privacy Consent landscape, yes it makes it more prominent. I need to point out that just because Consent is necessary, does not mean it must be gathered and/or communicated in an standard form. Consent is authorization for you to disclose the data you have to specific others. The result of you capturing consent rules is that YOU enforce those rules. Everyone else simply asks for the data they want and either get it or are denied. There are very few use-cases where one party captures the Consent (rules) and another party is asked to enforce those rules... This is why there is little interest in standardized consent, it is unnecessary to be standardized. So it might feel like we must do something about Consent, but reality is that consent is a local problem. This is even true of solutions like HEART (using UMA OAuth), the capturing of consent and enforcing of that consent are proprietary within the AuthZ actor. The only other consent standard is the 'Consent Receipt', which captures what was signed in non-coded form so-that the subject has a copy. Even when a HIE choose to have a central consent management, it is responsible for capturing and enforcing (not using HEART, but very HEART like).
Grahame Grieve (Jun 28 2017 at 12:44):
that's not my understanding of heart. It's certainly true about smart on FHIR, where the contract between the auth server and the resource server is private, and the app requests are just indicative.
Grahame Grieve (Jun 28 2017 at 12:45):
OTOH, in UMA/Heart, there's a standard contract between the AS and RS, and so they must agree about the impact consent. That's not quite the same as exchanging consent, but it's more than what you said
John Moehrke (Jun 28 2017 at 13:17):
In the case of HEART, one needs to describe how one asks for an authorization token in such granularity that it can get approved or denied. So very much like generic OAuth. It is all about defining how to use 'scope' to express a boundary of what you want, what access you have been granted. This is no less hard than defining a Consent, in some cases it is much harder. But it is real-time authorization decisions, not one-time consent capture.
John Moehrke (Jun 28 2017 at 13:19):
The man difference with HEART is that one separates the authorization decision responsibility. Otherwise spoken of as 'cascaded oAuth', where one cascades decisions. Two (for example) decisions that both must result in a PERMIT decision. The HEART authority is responsible for Privacy decisions, there is another that is responsible for Security (organizational) decisions.
René Spronk (Jun 28 2017 at 14:16):
In GDPR the right to 'data protability' applies to all data controllers and data processors involved. It that sense it's 'contageous'. If as a healthcare provider A I have captured consent 1 to share data within an XDS affinity domain in the form of a PDF, and that PDF is consumed by provider B, I as the patient could go to either the XDS affinity domain, A, or B, to get hold of my data. Being in the know I'd go to A, because they could probably give me the data in a better format than a PDF.
That's why my blog talks about "downstream consequences". Note that there are (according to the GDPR) also legal grounds for sharing data within an XDS affinity domain. So at the very least there must be a set of privacy labels to distinguish between the reasons for sharing (consent based, or legal ground). If consents are purely local they act a bot like Provenance to back up the security label. If consents are wider in scope (in a national consent registry, Austria has this, some other countries are planning for it) it actually has a wider value (although receivers could just go to the national registry and see what consents have been given by a patient). Value for including Consent (to me): it is the consent the author of the information "thought to be applicable" - whether they applied the consent correctly or wrongly, we need to know what ground they thought they had for sharing the data (but that info could also be part of the AuditTrail).
John Moehrke (Jun 28 2017 at 14:35):
Rene, Yes an audit is a technical backing of that kind of a report. One would not give direct (Raw) access to the audit, but one would create access reports given the data in the log. The AuditEvent can capture what was exported, to whom, when, where, and why... An audit reporting tool would search and filter these into a report. This report might be on-demand, monthly, daily, or in-real-time. This report might be delivered by many different means. This report is itself, PII... And PII about not just the subject, but also all those mentioned in the report (the subject's data recipients).... which causes a whole new set of AuditEvents to be logged.
John Moehrke (Jun 28 2017 at 14:35):
--- Another solution is the Kantara 'consent receipt', like a cash-register-receipt this is a blob that is dispensed when data is disclosed. this consent-receipt is, in theory, sent to the subject and expresses what data was released and under what authorization it was released. -- This combined with my prior message is simply a container for that access report.
John Moehrke (Jun 28 2017 at 14:38):
Note the access report can also leverage the FHIR AuitEvent resource schema to hold the details in computable form... wrapped in a Composition so that there is a nice viewable narrative followed by the computable form. I have mocked this up in my head and in PPT; but failed to get it more detailed than that.... Would love to have someone actually put that together... Would make a nice Implementation Guide...Oh to have infinite time
Jens Villadsen (Jun 28 2017 at 14:46):
FYI: for easy reading: https://gdpr-info.eu/
Jens Villadsen (Jun 28 2017 at 14:50):
Regarding export of data in a standardized form ... take that with a grain of salt. It might as well be a CSV file ... that is a broadly accepted standard - and so is PDF. While FHIR may seem as a good alternative, GDPR has no intention of bruteforcing FHIR into the field 'just' to be able to export data to the individual.
Jens Villadsen (Jun 28 2017 at 14:55):
@René Spronk Where do you see it stated that there SHALL be and API access to the data? https://gdpr-info.eu/art-20-gdpr/ ? It does not mention anything about an API
René Spronk (Jun 28 2017 at 14:57):
See http://ec.europa.eu/information_society/newsroom/image/document/2016-51/wp242_en_40852.pdf - official guidance , this also states: 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.
Jens Villadsen (Jun 28 2017 at 14:58):
Seems like an interpretation to me
Jens Villadsen (Jun 28 2017 at 14:59):
"On a technical level, data controllers should offer different implementations of the right to
data portability. For instance, they should offer a direct download opportunity for the data
subject but should also allow data subjects to directly transmit the data to another data
controller. This could be implemented by making an API5
available. Data subjects may also
wish to use of a personal data store or a trusted third party, to hold and store the personal data
and grant permission to data controllers to access and process ..." - they should ... they SHALL not
René Spronk (Jun 28 2017 at 14:59):
"encourages" is not a SHALL, but i didn't state that either in my blog (I hope). This is bu EU Workgroup 29, and as such is official guidance by the group that authored the GDPR, something not just to guide the implementation, but also to guide the legal interpretation.
Jens Villadsen (Jun 28 2017 at 15:01):
pasted image - I recited you @René Spronk , not GDPR
Jens Villadsen (Jun 28 2017 at 15:02):
I'm just playing the devil's advocate here. I agree the GDPR could be aided by the features of FHIR
Jens Villadsen (Jun 28 2017 at 15:02):
But it is not a hard requirement
Jens Villadsen (Jun 28 2017 at 15:03):
But I guess it could make sense to spec a FHIR operation that is to return a bundle of all kinds of stuff
Jens Villadsen (Jun 28 2017 at 15:03):
And maybe also an operation that deletes all kinds of stuff (the right to be forgotten)
René Spronk (Jun 28 2017 at 15:04):
When one summarizes, one simplifies :-)
Jens Villadsen (Jun 28 2017 at 15:05):
When one operates as an engineer, one take things very literally :D
René Spronk (Jun 28 2017 at 15:05):
Even if all vendors had some sort of API that exported CSV, that would already be a radical change. But given the WG 29 guidance it's likely they wouldn't be able to get away with that for very long, given that industry standards already exist
René Spronk (Jun 28 2017 at 15:07):
v2, CDA, XDS, or (in denmark) Edifact ;-)
Jens Villadsen (Jun 28 2017 at 15:10):
Roger that. 2 things - 1) CSV is broader accepted that any healthcare standard, so which standard is the most 'standard' 2) It won't be long before all danish healthcare actors are required to support and report according to the CDA spec found on http://art-decor.org/art-decor/decor-project--lpr-
Jens Villadsen (Jun 28 2017 at 15:17):
And don't forget https://gdpr-info.eu/recitals/no-73/ - which is considered as an emergency exit by some public organizations
John Moehrke (Jun 28 2017 at 15:52):
I would caution EU to be careful what you wish for.. You might end up with something like the USA Direct Project...
Kevin Mayfield (Jun 28 2017 at 16:00):
What is the (national) scope of the portability requirement? Does it extend nationally (or home countries as in Wales, England, Scotland and NI).
Kevin Mayfield (Jun 28 2017 at 16:29):
As I understand it, it's to ensure citizens have access to their data primarily aimed at social networks. As a citizen I would expect that to also extend to my health data and would enable me to give an EU medical practitioner access to my health record. (Expect that to be a PDF across the EU and England, maybe moving to FHIR Composition)
Jens Villadsen (Jun 28 2017 at 17:22):
@Kevin Mayfield Don't get your hopes up high: "... in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided ... " (https://gdpr-info.eu/art-20-gdpr/) . I wouldn't call PDF a machine-readable format (as a software engineer) given that it can be a scanned note written on a piece of papyrus using morse code filled with blood stains and being on fire and the scan resolution is 4 DPI. While this crispy PDF document may be crap for engineers, it does however conform to the GDPR as PDF is machine-readable from a lawyers point of view.
René Spronk (Jun 29 2017 at 06:53):
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. In cases where a data
controller is able to provide choices to the data subject regarding the preferred format of the
personal data a clear explanation of the impact of the choice should be provided. However,
processing additional meta-data on the only assumption that they might be needed or wanted
to answer a data portability request poses no legitimate ground for such processing." (http://ec.europa.eu/information_society/newsroom/image/document/2016-51/wp242_en_40852.pdf)
René Spronk (Jun 29 2017 at 06:56):
So yes, one could use a CSV format to dump ones database records, but you'd have to enrich them with metadata in such a way that it would be fairly easy for a patient to re-use the data and upload it somewhere else. The legislation is meant to support "portability", not simply "access" .
René Spronk (Jun 29 2017 at 06:58):
PDF also doesn't cut for data portability, unless one happens to use PDF-with-XML-attachments.
René Spronk (Jun 29 2017 at 06:59):
@Kevin Mayfield This applies accross all of the EU, but each and every healthcare provider currently can choose to do this in their own way, as long as there is no agreed upon format. One can only hope for a certain level of standardisation at the national (or UK home country) level.
Jens Villadsen (Jun 29 2017 at 07:00):
I would love to see that in action
Jens Villadsen (Jun 29 2017 at 07:03):
What metadata would you provide for eg. a Patient resource? The FHIR documentation along with vendor specific extensions?
René Spronk (Jun 29 2017 at 07:04):
@Jens Villadsen Recital 73 will (IMHO) only be an escape if there's additional danish legislation which adds additional scenarios for data processing that don't require patient consent (remember: any scenario which needs consent, then the data will be subject to data portability rights).
Recital 73 limits the scope of how the EU, or its member states, could define additional "legal reasons" for processing data without explicit patient consent. In and of itself Recital 73 doesn't offer a "way out" of the GDPR requirements, unless one can point to more specific legislation by the EU or members states.
René Spronk (Jun 29 2017 at 07:05):
When using FHIR, a link to a profile would be sufficient I think.
Jens Villadsen (Jun 29 2017 at 07:06):
ie. the tax authorities does not require consent
Jens Villadsen (Jun 29 2017 at 07:07):
and ... keeping of public registers kept for reasons of general public interest ...
Jens Villadsen (Jun 29 2017 at 07:07):
thats a pretty broad definition
Jens Villadsen (Jun 29 2017 at 07:08):
but sure, that limits the amount of scenarios
René Spronk (Jun 29 2017 at 07:09):
for the registers: probably things like quality registries, cancer registries et.al. Anonimized/pseudonimized.
René Spronk (Jun 29 2017 at 07:10):
I agree the definition is wide ranging - but definitely not all -encompassing.
Jens Villadsen (Jun 29 2017 at 07:11):
right - now,if using FHIR, it would then pretty much require all vendors to put their documentation out there in the open (which sounds great to me), but that is probably not the intention with GDPR
Kevin Mayfield (Jun 29 2017 at 07:22):
Screen-Shot-2017-06-29-at-08.19.47.png Ok, I jumped to PDF without showing any working out. Attached documents health systems within an organisation and what types of systems they are likely to have. The terms Wacther A, B and C indicate digital maturity with around 80% of hospitals being B and C.
Kevin Mayfield (Jun 29 2017 at 07:25):
The systems are broken down into what resources they could provide (easy wins), so resources like Patient, DocumentReference, Binary, EpisodeOfCare, Encounter, Observations feature quite highly. Yes it's focusing on low hanging fruit but also shows FHIR is possible rather than 1990's csv format with all the interop problems that will create.
Kevin Mayfield (Jun 29 2017 at 07:33):
I'd also be concerned that adding security labels and complex consent can effectively place the interop into a concrete bunker and make it unusable to most. That would also be against the spirit of GPDR and prevent the patient from being able to transfer their records from A to B.
Kevin Mayfield (Jun 29 2017 at 07:39):
If we have ways of avoiding these complexities, such as Patient can use OAuth2 to generate an extract records from an EPR to populate their PHR and then populate another EPR (with implied consent).
René Spronk (Jun 29 2017 at 07:49):
If in terms of scope that EPR extract covers at least that which is covered by the Data Portability right then you're all set. Be aware that the Data Portability right may extend to quite detailed things such as all diagnostic images, all videos, ECGs etc. - these normally aren't included in an EPR extract.
René Spronk (Jun 29 2017 at 08:24):
I've added a "questions" section to the blog at http://www.ringholm.com/column/GDPR_impact_on%20healthcare_data_interoperability.htm - to address the following questions:
As a vendor, can I get away with creating a CSV-formatted database dump to satisfy the Data Portability Right ?
As a healthcare provider, can one avoid ever being subject to a patient exercising their Data Portability right?
Kevin Mayfield (Jun 29 2017 at 08:37):
They are still DocumentReference + Binary plus you can be fairly certain the project staff advocating CSV won't be supported by the engineering staff who are quite likely (90%) to say yes to JSON(/XML), RESTful and OAuth.
John Moehrke (Jun 29 2017 at 12:55):
Note that a CSV file can be published as a Binary with a DocumentReference (metadata)... :-) I don't think this is the right thing to do, but it is possible.
John Moehrke (Jun 29 2017 at 12:58):
The usual measurement is level of effort. If one is communicating CDA documents with others, then it will be expected that one communicates CDA with the patient. Right? If all your EHR can communicate is CVS, then wouldn't that be considered in GDPR as the best you can do? What level of effort is expected of organizations to 'modernize'? I presume there is an expectation that one keeps up with their peers, so the market analysis showing that most peers are using CDA and XDS, would be hard evidence. right?
Kevin Mayfield (Jun 29 2017 at 13:48):
Wouldn't CSV start failing on Integrity and so fail existing legislation?
John Moehrke (Jun 29 2017 at 13:58):
transport tends to add integrity, confidentiality, and authenticity (aka TLS)
Elliot Silver (Jun 29 2017 at 23:02):
Interesting discussion. I wonder if you could take the position that for most patients, a PDF is far more usable than a dump of FHIR resources.
René Spronk (Jun 30 2017 at 07:04):
@Elliot Silver The whole point is "portability", not "access". I should be able to download my data from provider #1 and upload them to provider #2, regardless of whether we're talking about my social-media-posts, my audio-playlist, or my healthcare-data. GDPR applies to all those use cases in the same fashion.
GDPR isn't healthcare specific, its scope is all encompassing. It does contain a few healthcare specific requirements, but other than that one of the difficulties is interpreting a piece of general legislation and how that would impact healthcare IT.
For simple "access" PDF would probably be more useful, and the GDPR does allow it.
René Spronk (Jun 30 2017 at 07:11):
@John Moehrke I agree that given the way it's specified in the GDPR it would be rather difficult to defend ones decision to provide a CSV to the patient if at the same tome one already supports one or more common interoperability standard (e.g. CDA, FHIR, v2, DICOM) for other purposes.
Fines for non-compliance with the GDPR range up to 4% of the organisational revenue, also for healthcare provider organisations. However, quite a few contracts between healthcare providers and software development companies state that the software development company should add support for newly legislated requirements at no or low cost - if they don't, they may end up paying the fine. I'd say there's plenty of motivation for software development companies to get cracking on this thing.
Kevin Mayfield (Jun 30 2017 at 08:17):
@Elliot Silver I think whatever is done, what the patient wants to do with portability should come first. So yes a patient would want a PDF copy, a patient would want to import their health record into their PHR, the Patient would want to export observations from their PHR to the clinicians EPR. A patient (on holiday) would want want the clinician to have enough accurate information to provide care.
Kevin Mayfield (Jun 30 2017 at 08:30):
Also patient devices such as heart rate monitors, scales, etc. These already have consent and transportability built in (not CSV or PDF)
John Moehrke (Jul 09 2017 at 13:41):
Found this article with a more pessimistic (realistic) perspective on GDPR ability to cause person centric data portability. https://medium.com/mydata/gdpr-data-portability-is-a-false-promise-af460d35a629
René Spronk (Jul 10 2017 at 06:54):
It's a good analysis, although its second part (parties will try and hide behind any of the legal reasons for data usage/exchange, to avoid having to deal with consents and the portability right) is hardly a new issue. The authors assume data controllers will be able to get away with this, I'm personally less worried because that would circumvent one of the core aspects of the GDPR.
The first part of the article is absed on https://iapp.org/news/a/european-commission-experts-uneasy-over-wp29-data-portability-interpretation/ - the interpretation of "data provided by the patient". Is that the same as "data observed on the patient" or not? If I have an X-Ray taken, will that be considered as "data knowingly provided by me (as a patient) to a healthcare provider"?
If I listen frequently to a particular piece of music, is that observation by the app (which maintains a list of my favorites) part of the data portability right, or will it just be the play list itself (which was certainly provided by me) ?
Anyway, good to see that there is discussion around this, and as the article notes we may have to wait until a case is brought in court to get some further guidance as to how it should be interpreted in the healthcare context.
Kevin Mayfield (Jul 10 2017 at 09:02):
My opinion is we should start pushing towards this http://wiki.hl7.org/index.php?title=201709_Consumer_Centered_Data_Exchange Simple use of FHIR plus Patient consent.
Jose Costa Teixeira (Jul 24 2017 at 21:35):
Nice that this is being discussed. Note that "Lawfulness of processing" != "consent"
Jose Costa Teixeira (Jul 24 2017 at 21:36):
Consent is one thing that may allow processing but there are others
Jose Costa Teixeira (Jul 24 2017 at 21:37):
(i understand from the discussion that we were taking Consent as the equivalent to "justification for a lawful processing", which i don't relate to)
John Moehrke (Jul 25 2017 at 14:19):
Jose, yes there are other ways to have the authority to collect, process, or disclose... However what I am interested in is improving the FHIR Consent resource to support those cases where a Consent is needed or useful. Sometimes a consent is gathered because it is the right-thing-to-do; and not just because it is compelled by law/regulation.
René Spronk (Jul 26 2017 at 06:48):
@Jose Costa Teixeira From a FHIr perspective we'll need to capture two things: if the lawful ground for processing/exchange (under the GDPR) is Consent, then we'll need to capture that consent and associate it with the appropriate resources; if the processing/exchange is being done on another lawful ground then we'll need to identify which specific legal ground (https://www.privacy-regulation.eu/en/6.htm see 6.1) we have for using the data, and associate that with the FHIR resources in question.
The first part clearly maps to the FHIR Consent resource.
The second part (capturing the legal ground) is a bit more tricky, it has more aspects related to auditing than it has to provenance. Security tagging probably doesn't play a large role in this, given that a FHIR resource could be used by different parties who all have their own/different lawful reason for the processing. @John Moehrke ?
Jose Costa Teixeira (Jul 26 2017 at 07:21):
Glad to see the difference between consent and other possible justifications for lawful ground for processing.
Jose Costa Teixeira (Jul 26 2017 at 07:24):
I don't know our full picture, so i am picking on a few things that draw my attention, possibly echoing recent discussions on the subject. For example, the association between consent(/others) and the FHIR resources. I believe that is an indirect relation:
The Consent (or others) is not associated with the resources, but with the processing of the resources. The resources usually represent the data, not the processing of the data.
Jose Costa Teixeira (Jul 26 2017 at 07:26):
in other words, GDPR does not care if for you need consent for a surgery. GDPR cares that if during that surgery you need to check the patient's name or age, then you have registered somewhere in a registry something like "when our patients undergo surgery, we need to take their name and age, and they explicitly give us consent to use their name and age. the evidence of such permission is in the consent document/resource".
Jose Costa Teixeira (Jul 26 2017 at 07:27):
so the chain IMO is not Consent - Data, but Consent -- Processing - Data
Jose Costa Teixeira (Jul 26 2017 at 07:28):
and i believe that our FHIR resources represent Data in the chain above, not the processing
John Moehrke (Jul 26 2017 at 12:20):
The FHIR Consent has many abilities to identify the 'set' of data that the consent is about. If one only identifies the Patient, with no other constraints on the 'set' then it means all current and future data associated with this Patient. However i can also list Resource by Resource; or it can give a timeframe; or it can give a tag; or by an episode ...... Thus it can identify the set of data in many ways. Mostly ways that have already been found to be useful.
John Moehrke (Jul 26 2017 at 12:22):
The AuditEvent is more inclusive of being able to record 'use' and 'disclosure' events; where Provenance is more concerned about Create and Update (aka 'collection'). AuditEvent is also able to cover attempts of access that were blocked from happening. So, yes AuditEvent is more intended to support an Access Log, Accounting of Disclosures, or simply evidence that the policies given have been followed.
John Moehrke (Jul 26 2017 at 12:25):
To your last point about Consent -- Processing -- Data... I think I agree and understand, but I am not 100% clear... We do have a few elements in Consent intended to make it clear what activities and/or purposeOfUse are authorized (denied). But these are processing of data, not activities as in a 'consent to treat'. Consent to treat is a work item the committee is now looking at understanding.
John Moehrke (Jul 26 2017 at 12:43):
We are going to try to model this at the September connectathon. Not specifically GDPR, but close -- http://wiki.hl7.org/index.php?title=201709_Consumer_Centered_Data_Exchange
Jose Costa Teixeira (Jul 26 2017 at 15:39):
On the consent - processing - data:
GDPR says: If you are going to be using anyone's data, you must have a documented data processing.
Jose Costa Teixeira (Jul 26 2017 at 15:44):
for example: to use my clinical history, the hospital shall have a documented processing called "gather clinically relevant information", and link that processing to a justification, or a lawfulness of processing, which can be "consent" or other - to ensure the vital interest of the patient, or to ensure the business of the hospital...
Jose Costa Teixeira (Jul 26 2017 at 15:46):
I think the AuditEvent is at a different level - in healthcare we are usually interested in capturing every instance of the processing (e.g. if someone gets my history yesterday and today, that is 2 events).
For GDPR it seems the predominant understanding is that the processing is not captured as an event, but as a type.
Jose Costa Teixeira (Jul 26 2017 at 15:50):
The hospital has to describe their processes and where their processes dictate they use the data: "in my hospital, we use this kind of data at admission and in consultations".
GDPR does not impose to capture each instance of the data processing. And I think that AuditEvent is for this latter challenge.
Jose Costa Teixeira (Jul 26 2017 at 15:50):
With that in mind, i would not want to invent a FHIR solution for GDPR. Only for the parts that matter: consent, as you are doing.
John Moehrke (Jul 26 2017 at 19:08):
Not inventing a new process just for GDPR... but rather mock it up to assure that GDPR 'can' be satisfied in reasonable way using FHIR consent.
John Moehrke (Jul 26 2017 at 19:11):
As to the 'documented data processing'. Agree that this documentation should exist before a consent is captured, else that consent is not valid, as it is not informed. The documented data processing 'document' would be published as their processing document. This document would have a unique identifier. That unique identifier would be referenced in each consent gathered, as the Consent.policy.uri.
Jose Costa Teixeira (Jul 28 2017 at 16:20):
To be sure: when I say Documented data processing, it is kind of in the realm of Enterprise Architecture.
I think I understand and agree with your statement - basically when you get a consent, you point to one of those pre-documented uses of the data, so that patient knows what they are consenting to, in terms of data.
Ewout Kramer (Feb 15 2018 at 15:41):
perhaps we could work towards a connectathon about this at DevDays?
Maybe that's still a good idea worth persuing!
Grahame Grieve (Feb 15 2018 at 20:28):
need a very tight story board that everyone agrees to...
Bo Dagnall (Feb 15 2018 at 20:29):
I believe the work accomplished at the CCDE track in the last 2 connectathons has relevance to GDPR (at least that is what I have been told). I am happy to discus this with anyone with interest.
Ewout Kramer (Feb 16 2018 at 13:29):
@Rien Wertheim ?
René Spronk (Feb 18 2018 at 16:11):
To me it seems a bit early to have a testing event - I don't know anything about CCDE, but IMHO there'd need to be at least some GDPR+FHIR analysis/whitepaper to have as a starting point.
Jose Costa Teixeira (Feb 18 2018 at 19:58):
Agree some analysis is needed. And some work in this matter is a good idea. I am looking at gdpr requirements and would like to contribute to the discussion.
Grahame Grieve (Feb 18 2018 at 22:19):
fundamentally, GPDR says that you must keep consent records from patients to approve sharing their data, ye?
John Moehrke (Feb 19 2018 at 14:05):
Note that GDPR has been in the analysis for the Consent resource and the various security contributions (Provenance, AuditEvent, tags, etc).
Jose Costa Teixeira (Feb 19 2018 at 14:06):
GDPR says a few things besides that:
if you use (even if not sharing) data, there must be a valid reason
John Moehrke (Feb 19 2018 at 14:06):
the existing CCDE track, as Bo points out, is applicable to GDPR use as well.
Jose Costa Teixeira (Feb 19 2018 at 14:07):
one of those reasons may be "we got consent", if consent is in the right conditions (...)
John Moehrke (Feb 19 2018 at 14:07):
Yes, PurposeOfUse is more critical in GDPR. Which is included in Consent
Jose Costa Teixeira (Feb 19 2018 at 14:08):
GDPR also says that you may not need consent if there is another valid reason (among those listed)
John Moehrke (Feb 19 2018 at 14:08):
Yes, we have workflows where the access is under a more specific project under a broader PurposeOfUse like Treatment.
Jose Costa Teixeira (Feb 19 2018 at 14:08):
and GDPR says that any use of data (incl transfers) must be declared
Jose Costa Teixeira (Feb 19 2018 at 14:11):
so, consent and authentication are some transactional components of GDPR compliance.
But GDPR compliance will also require a hospital / lab system to explain why they have this or that interface, independently of transactional aspects.
John Moehrke (Feb 19 2018 at 14:15):
Jose, as I indicated GDPR has been in the analysis of Consent and the security resources since it was just a proposal. We have global participation in these workgroups. --- However if you have a specific point of improvement, please submit a CR with details of the problem and your proposed solution if you have one.
Jose Costa Teixeira (Feb 19 2018 at 14:18):
I am just replying to @Grahame Grieve 's question
fundamentally, GPDR says that you must keep consent records from patients to approve sharing their data, ye?
and provide info that GDPR is a bit more than consent.
Jose Costa Teixeira (Feb 19 2018 at 14:20):
i trust consent is GDPR-compatible (haven't done that analysis) but just state that GDPR includes requirements that are not covered in FHIR yet imo.
John Moehrke (Feb 19 2018 at 14:22):
Please be specific about what is not covered in FHIR yet... The privacy and security teams would be happy to help get that covered.
Jose Costa Teixeira (Feb 19 2018 at 14:29):
@John Moehrke , i said
Agree some analysis is needed. And some work in this matter is a good idea. I am looking at gdpr requirements and would like to contribute to the discussion.
During that analysis we may see whether there are gaps. Not sure if there are gaps in the standard, or in guidance...
Aaron Seib (Feb 20 2018 at 19:46):
I suspect what Jose is getting at is that a consent artifact alone is not sufficient to be able to adequately satisfy the requirements of GDRP. You know how there are people that declare their offering is HIPAA compliant and that doesn't make any sense (since it requires organizational conformance to policy and involves Humans at the customer site doing what they need to do) and I sense that is what he is alluding to maybe?
Aaron Seib (Feb 20 2018 at 19:47):
In any case - I am in agreement with Bo that there is some aspects of what we've done that overlap with what is required to support GDRP requirements...
Jose Costa Teixeira (Feb 20 2018 at 20:03):
Yes, @Aaron Seib that is what I mean: consent is just a part of GDPR compliance. Other things are included in GDPR - list of interfaces, list of data that is used, retention....
I will gladly join an effort to do that analysis (which i think we need, as @René Spronk suggests ).
René Spronk (Feb 21 2018 at 06:03):
On this site we've discussed a lot about the 'problem space', but not a lot about the 'solution space'. My analysis last year (but I'm not a security pundit - http://www.ringholm.com/column/GDPR_impact_on%20healthcare_data_interoperability.htm) was to use at least a combination of consent, provenance, and security labels.
There has been discussion (without a real outcome) on this and other GDPR threads as to how to model 'legal ground for processing' (of which consent is just 1, we need to capture the other 5 as well). It's simple if a database contains data all having the same legal ground for processing, because one would document that legal ground on paper. But if one collects data of different kinds from all sorts of sources, one needs to know what the 'legal ground' was for capturing the data, for that means one is not allowed to use the data for purposes that are a different 'legal ground'. If one transmits data, it should be accompanied by the original 'legal ground'.
We need to capture retention policies and have the ability to send those along with the data (if resource X has a retention policy for 4 years, and I sent it to another database after 3 years, it will still have '1 year to go' in the other database). Patients have the right to ask for the deletion of their data, and all copies thereof that may exist because data has been sent elsewhere - how would we facilitate that, or would this be solely based on audit logs?
That's just me sketching the likely impact of GDPR on FHIR, someone more in the know about security and similar legislation elsewhere (US?) may have to tackle a more detailed whitepaper as to how we should solve this. Part of the puzzle is the fact that there may be things currently not covered by the FHIR standard, so this may involve the definition of new resources as well.
John Moehrke (Feb 21 2018 at 14:19):
Also use of AuditEvent to track actual use and support apps that would provide the consumer with an account of use/disclosure as appropriate.
John Moehrke (Feb 21 2018 at 14:19):
Yes, I am very interested in providing this kind of guidance.
John Moehrke (Feb 21 2018 at 14:23):
A good way to indicate policy with data is through Provenance.policy. Where the Provenance.recorded date can be used for the starting time.
John Moehrke (Feb 21 2018 at 14:33):
lighter weight is to use a security-tag in the resources meta element. Where the tag value is likely regional to indicate the specific policy (local vocabulary management). The advantage of this is that it is more likely to be carried in all uses of the Resource, so less likely to get disassociated (without specific intent to remove the tag).
John Moehrke (Feb 21 2018 at 14:37):
hence... why it is important for us to create some document that cross-references a set of principles that fall out of GDPR with mechanisms in FHIR. This would not be a mandate to use that mechanism, but rather informative to those looking for solutions. Is there a generally accepted 'good' set of principles that fall from GDPR? We should not invent this. It surely is already available somewhere...
Jose Costa Teixeira (Feb 21 2018 at 15:44):
For me, the core of GDPR is Art 30.
And Art. 30 is not transactional data, it is design aspects.
Jose Costa Teixeira (Feb 21 2018 at 15:45):
In other words, Art. 30 requires that a company has a list of all their processing activities (etc etc)
Jose Costa Teixeira (Feb 21 2018 at 15:46):
and that is not transactional, so it is not covered by the current mechanisms.
Jose Costa Teixeira (Feb 21 2018 at 15:47):
A white paper would be a good starting point. We can bring some GDPR requirements.
Grahame Grieve (Feb 22 2018 at 06:14):
so it seems to me that we should have a GPDR track at the connectathon, and clearly marked as a conceptual track, where thought experiments will be used to see what a conformant system would have as an API
John Moehrke (Feb 22 2018 at 14:09):
I have proposed this on the connectathon stream, and would be happy to help coordinate it. I need EU experts involved. Alex Mense (Security co-chair) will likely be one of those experts.
Jose Costa Teixeira (Feb 23 2018 at 15:42):
Will this be trying to address problems of consent, security, or addressing the GDPR in its scope? I am working in Data Governance for GDPR, handling reference data, design and transactional issues, and I would love to see some proper interoperability mechanisms there, but it seems that these discussions are mostly only around security and consent.
René Spronk (Feb 24 2018 at 08:39):
Given the background of the FHIR community it would be about the question: how does one, minimalistically if possible, satisfy the requirements of the GDPR when using FHIR and its associated (commonly used) security stack ? But perhaps others see a wider scope than that.
John Moehrke (Feb 25 2018 at 17:16):
The answer is more simple... it will address whatever those involved in the activity choose to address... So, if it consists of just Privacy and Security people, then that will be the focus. I am interested though in what other aspects people see within GDPR? @Jose Costa Teixeira can you explain?
Jose Costa Teixeira (Feb 25 2018 at 17:37):
I am good if the focus is security and privacy. So,
How do we handle Security in FHIR transactions in a GDPR-Compliant way seems a great topic.
There are other parts of GDPR which may be out of scope - my quest is only that we should not try to think "we're GDPR ready because we have security and access control..."
Jose Costa Teixeira (Feb 25 2018 at 17:40):
some other aspects of GDPR:
How can a patient say "please forget me"? and How that gets propagated?
How can an institution say "Here is the list of my interfaces, and the data we expose / require in each of them, and with whom"?
Jose Costa Teixeira (Feb 25 2018 at 17:42):
I don't say these are needed in this effort, just that GDPR is more than our transactional stuff - consent, access control etc.
John Moehrke (Feb 25 2018 at 18:20):
To be clear, we can't claim GDPR at all... all we will be able to say is that we divine that GDPR seems to be asking for X, and the Y functionality in FHIR is a good way to achieve X. This is all that standards can say. We can't make legal advice. We can't declare that someone has implemented it properly.
John Moehrke (Feb 25 2018 at 18:22):
BTW: There are aspects of "Please forget me" that can be addressed by mechanisms in FHIR. Including use of Consent, Security-tags, Provenance, and version specific access controls. That statement alone is not helpful, so we need to get more specific about how one could use these mechanisms in at-least one reasonable way...
René Spronk (Feb 26 2018 at 08:36):
"Please forget [this specific data]" probably requires an operation. If A sends stuff to B, one can request A to delete some data, but if that data was sent to B, then A (based on its Audit Logs) is aware that it has sent data to B, and should send a request to B to delete. Either one states this is not an automated process, or if it is, it probably calls for an operation because this won't be a client orchestrated activity; the server will have to determine how/what to purge from its records.
René Spronk (Feb 26 2018 at 08:36):
To me this needs to be in scope for the discussion.
Jose Costa Teixeira (Feb 26 2018 at 08:38):
I like the idea of an operation that propagates to impacted parties
Grahame Grieve (Feb 26 2018 at 08:39):
I can't get my head around the idea that you instruct information systems to forget about data. Sounds like pretending you can rewrite history
Jose Costa Teixeira (Feb 26 2018 at 12:21):
It's the same as Google's right to be forgotten.
Jose Costa Teixeira (Feb 26 2018 at 12:24):
Right to be Forgotten allows people to say
"I no longer allow you to store or use any of my data (if it is identifiable) for any purpose".
Jose Costa Teixeira (Feb 26 2018 at 12:25):
of course, this right is not absolute - it cannot be used to go to the tax authorities and say "please forget all my data" :)
Grahame Grieve (Feb 26 2018 at 12:25):
I can get my head around 'no longer use' but you can't magically erase the past. That's like the patient advocates who demanded that we be able to
(a) suppress their clinical records
(b) suppress the fact that they've suppressed their clinical records
Jose Costa Teixeira (Feb 26 2018 at 12:28):
forgotten may mean removal but may also mean anonymization (or pseudonymization, but the EU authorities don't seem to agree on the validity of pseudonymization).
Jose Costa Teixeira (Feb 26 2018 at 12:31):
I had the question "If a customer identifies himself and requests to remove data, isn't that request also PI?" and the answer was Yes.,
So theoretically the authorities are expecting it to be deleted/anonymized as well, if the information is no longer needed for any purpose.
Grahame Grieve (Feb 26 2018 at 12:32):
I can't believe that they require you to redact your audit trail... it should be signed...
Jose Costa Teixeira (Feb 26 2018 at 12:33):
so, if I call my hospital and ask them to forget my data, they may simply anonymize my records, and they may be required by law/public interest to keep track that I deleted it.
Jose Costa Teixeira (Feb 26 2018 at 12:34):
you mean whether this would require deleting Patient X from the audit trail?
Jose Costa Teixeira (Feb 26 2018 at 12:35):
IMO audit trails are not in control of the patient, and are needed for other purposes, so the patient cannot ask those to be deleted.
Grahame Grieve (Feb 26 2018 at 12:36):
oh. well, that was my point. so what can they ask for then?
Jose Costa Teixeira (Feb 26 2018 at 12:39):
in my view, if a patient Jack Bauer wants to be deleted, their personal identifiable data can no longer be used for any purposes except those required by law. So, in the reports, mailings, letters, etc. there is no longer a Mr. J Bauer, but a Mr X. And Mr. X still counts for statistics.
John Moehrke (Feb 26 2018 at 12:55):
The other big worry with this chain is: It might be reasonable for me to forget, but to then expect me to tell all those that I have communicated the data to and get confirmation that they too forgot.. this is NOT what google is expected to do, in fact it is explicitly not in their scope. To forget locally is either a normal Delete operation, or a tagging of data such that it will not be returned. These are 'reasonable' solutions that FHIR has mechanisms for. As I stated before, we can't claim GDPR compliance. We can only look at the needs that are accepted as falling from GDPR, and map them to reasonable mechanisms that the FHIR standard includes. Going beyond the standard will be the creativity of products/services...
John Moehrke (Feb 26 2018 at 12:57):
And in medicine we must also protect the patient safety... so there must be recognition that rejecting a 'forget' action is in the best interests of the patient. I thought I understood GDPR did include healthcare exceptions for safety... (but I am not a lawyer, nor a GDPR expert)
Jose Costa Teixeira (Feb 26 2018 at 13:09):
if you have communicated the data, it was with an identified party, and for a documented reason, so you can actually follow the data. I don't think we need to get confirmation that they too forgot.
And theoretically, the customer is entitled / required to know that you have communicated the data.
René Spronk (Mar 28 2018 at 09:58):
https://chat.fhir.org/#narrow/stream/social/subject/Apple.20Health.20Authentication.20Flow
@John Silva Most EU countries have a layer of additional legislation 'on top of' the GDPR, or acts that modify the GDPR (where such modifications are allowed, article 9.2(h) being an example). Actually those acts are related to the prior EU privacy directive, but those will work as well in the context of the GDPR, for the most part it doen't differ that much from the earlier directive.
Last updated: Apr 12 2022 at 19:14 UTC
