Stream: Security and Privacy
Topic: GPDR
Grahame Grieve (Apr 03 2018 at 23:04):
hey @James Agnew: https://www.ctrl.blog/entry/gdpr-web-server-logs
Grahame Grieve (Apr 03 2018 at 23:04):
does this affect the way we gather stats for our public test servers?
Grahame Grieve (Apr 04 2018 at 21:25):
further to GDPR: I think that we should define
- how to request for transfer of data
- how to request erasure
- how to respond with a confirmation or rejection of either request
.. we should have a GPDR implementation guide
Grahame Grieve (Apr 04 2018 at 21:47):
though of course, most of the exceptions to erasure apply in healthcare, and there'll rarely be any actual erasure:
Organisations can refuse to comply with a request for erasure if:
- The processing is protected by the right to freedom of expression;
- Processing the data is necessary to comply with a legal obligation for the performance of a public interest task or exercise of official authority;
- The data is for health purposes in the public interest;
- The data is being used for archiving purposes in the public interest, scientific or historical research, or statistical purposes; or
- The processing is necessary to exercise or defend legal claims.
John Moehrke (Apr 04 2018 at 22:31):
yes, but we are not giving legal advice... I am happy to provide a capability that is needed broadly.
David Pyke (Apr 05 2018 at 16:55):
So, we'd need to create workflows and a GDPR resource to handle the requests in a simple way?
John Moehrke (Apr 05 2018 at 17:03):
we might figure this out at the FHIR Connectathon. That is one of the goals... to determine what gaps we have.
Peter Jordan (Apr 11 2018 at 23:16):
Just read an opinion in an Australian Health Information Blog (https://aushealthit.blogspot.co.nz/2018/04/showing-benefits-from-digital-health-is.html?showComment=1523486912070) stating that " one of the other requirements for GDPR is that you should be able to ask that all your data be deleted." Do those on here who've studied the regulations in detail agree? If so, what about clinical audit requirements? Deleting data on which a diagnosis and treatment was based doesn't seem right to me?
Grahame Grieve (Apr 12 2018 at 05:00):
See my note above:
Organisations can refuse to comply with a request for erasure if:
- The processing is protected by the right to freedom of expression;
- Processing the data is necessary to comply with a legal obligation for the performance of a public interest task or exercise of official authority;
- The data is for health purposes in the public interest;
- The data is being used for archiving purposes in the public interest, scientific or historical research, or statistical purposes; or
- The processing is necessary to exercise or defend legal claims.
Grahame Grieve (Apr 12 2018 at 05:01):
most real healthcare data (as opposed to casual stuff collected through the web portals) will fall into categories 2, 3, or 5
René Spronk (Apr 12 2018 at 05:40):
Agree with Grahame and others that we need some implementation guide for GDPR, erasure/correction requests are probably modelled best using a FHIR operation. 'request transfer of data' (as Grahame calls it) probably is the 'data portability right', this could be handled by the access control mechanism (but that will need to be GDPR aware, hence guidance will be needed). The 'data access right' requires that all sorts of stuff be logged about e.g. to whom any FHIR resource has been disclosed, and for what reason.
If an item of data was captured with a 'lawful ground' provision-of-care you IMHO won't be able to deny erasure on any ground except "comply with a legal obligation for the performance of a public interest task or exercise of official authority" - mostly because there is some mandated retention period. If the data was captured for the reason of it being used in public-health, or research, then yes, one can deny erasure. You can't add a 'lawful ground for processing' after capturing the data, to do so means you'd have to ask consent from the patient.
I'll be presenting on the GDPR and its impact on interoperability standards (using FHIR and XDS as examples) at the WGM in Cologne. A short version in the joint EHR/Security/.. meeting WED Q1, and a full version at some other point in time (a BOF session perhaps).
I have approached HL7 Europe (and discussed this with them 2 weeks ago) to suggest they need to take the lead in creating a GDPR implementation guide, after all this impacts them the most. Discussions in Cologne (between the European affiliate chairs, as well as at the technical level) will serve as input to scope the effort. It's time for the Europeans to step up to the plate - all help is welcome, but to solely have Antipodians and Americans discuss EU legislation and its impact just doesn't make a lot of sense.
Grahame Grieve (Apr 12 2018 at 05:42):
well, we feel the right to discuss US legislation as well. but GDPR is actually special in this regard, since it asserts the right to legislate my behavior, even when I am not in EU
René Spronk (Apr 12 2018 at 05:48):
No disagreement there, as it is extraterritorial legislation. I'm just stating that the Europeans on this forum have been too silent about the subject - we should 'activate' them somehow. One of the problems is that the Commonwealth and the US have a common-law tradition whereas continental Europe has not - this makes it harder (but certainly not impossible) for people with a common-law background to understand EU legislation.
To make things even more interesting: the GDPR allows for 'member state extensions' in various places, and these can be 'modifier extensions' (to use FHIR speak). I'm aware of some of those for some EU countries - but we need to get more such examples to the table.
Peter Jordan (Apr 12 2018 at 07:40):
Some 'antipodeans' on here remain citizens, and passport holders, of their EU country of birth. :) EU law was a component of my English LLB and, from memory, it was an awful lot easier to understand than a lot of common law some of which dated back to the middle ages! As my question above suggests, I haven't read too much about GDPR, but hope to attend at least one of Rene's sessions in Cologne.
René Spronk (Apr 12 2018 at 10:43):
@Giorgio Cangioli (HL7 europe) wrote in an e-mail (the nature of which suggests I can qoute it here)
Following up the email that Rene sent last week and a conversation we had, I’m asking your support for helping the creation of an EU REALM project related to GDPR and FHIR.
This is for sure a European hot topic that requires EU REALM HL7 guides.
At this stage the need is to socialize it and facilitate the engagement of affiliates’ experts and interested parties that could lead/support this effort.
The Cologne WGM is for sure a good occasion to meet.
Rene will make a tutorial (short version: Wed Q1, long version probably Monday) on this topic, we might invite people to attend it and discuss then how to tailor this potential European HL7 Project (a general white paper; a FHIR implementation guide; both; something else,….) drafting a first PSS; who can support the project and so on.
It would be perfect if we had at that time already, someone that could offer to facilitate this project and lead the discussion.
Grahame Grieve (Apr 13 2018 at 20:44):
Rene, I am interested in the forget use case for my public server - using the FHIR Api to send a request to forget about an IP address on my server.
René Spronk (Apr 14 2018 at 11:00):
That's a fairly technical scenario. Forget from logging, forget Provenance / Audit resources. Notify third parties that have recieved any FHIR resources that mention the IP address, i.e. if a Provenance with an IP address was sent to another server X (the sending of a resoyrce should be in the audit log), X should be notified to erase its record of that IP address. That's why this is probably a FHIR operation, the logic is fairly complex, and it allows the primary server to invoke the operation on any other FHIR enabled servers.
Same principle would apply to 'ease resource X', the operation to erase would evaluate a set of rules (using security tags, local rules/legislation as to what the appropriate minimal retention period is), and either erase or update the security labels, and informs other systems to erase any local copies of this information.
Lloyd McKenzie (Apr 14 2018 at 13:48):
Presumably GPDR requires that you have paperwork/audit trail demonstrating your attempt to comply with a "request to forget". How do you audit a request to forget something without recording the thing you've been asked to forget?
Grahame Grieve (Apr 14 2018 at 21:13):
don't ask stupid questions
Peter Jordan (Apr 15 2018 at 23:24):
Freedom of Information (FOI) requests sent to NHS trusts in England reveal that more than £1 million has been spent preparing for the General Data Protection Regulation (GDPR)... https://www.digitalhealth.net/2018/04/nhs-trusts-gdpr-preparation-foi/
Grahame Grieve (Apr 16 2018 at 00:18):
chicken feed
John Moehrke (Apr 16 2018 at 12:23):
Most organizations know that they should focus on the things most likely to get them into trouble. This being those things that an individual can see. The audit logs and backup tapes are not things that the individual can see. It is few, mostly academics, that are worried about the impact of regulation clauses that are 'absolutes'. This said, this approach is not defense against a leak that the data was not totally forgotten... It is all about RISK management. Manage the risks, knowing full well that the risks never go to zero.
René Spronk (Apr 16 2018 at 14:14):
Via @Jose Costa Teixeira : whitepaper by IHE "IHE perspective on the
European Union GDPR " https://www.ihe-europe.net/sites/default/files/GDPR_WEB_00.pdf
René Spronk (Apr 17 2018 at 11:45):
The whitepaper is fairly high-level, and focuses on the security side of things. A good starting point however.
John Moehrke (Apr 17 2018 at 11:55):
It was high level. I gather the point was simply to draw attention to the Privacy and Security profiles that already exist. @René Spronk what do you think was missing?
Jose Costa Teixeira (Apr 17 2018 at 11:55):
Yes, it is one of the perspectives. There was some effort in asserting a few things like
Jose Costa Teixeira (Apr 17 2018 at 12:01):
a) GDPR is not consent. Consent does not grant all, withdrawing consent does force data deletion
Jose Costa Teixeira (Apr 17 2018 at 12:02):
b) GDPR is not only security and access.
Jose Costa Teixeira (Apr 17 2018 at 12:04):
and basically to imply that GDPR does require that any data exchange (or use, but that was not the focus) is well-governed... thus enter IHE.
Jose Costa Teixeira (Apr 17 2018 at 12:04):
at least that is how i read it now
John Moehrke (Apr 17 2018 at 12:19):
I don't disagree... but, what more could IHE have said? I ask because I am working on equivalent for FHIR. I want to be complete. But we must all recognize that a standards body like IHE or HL7 can only point out appropriate use of their standards, and identify gaps for standards development. They can not give legal advice. They can not address the policy or operational side of the regulation. There are plenty of other resources covering that anyway.
Jose Costa Teixeira (Apr 17 2018 at 12:23):
i think the problem in the field is that many people have misconceptions about GDPR and they are looking for one universal solution.
Jose Costa Teixeira (Apr 17 2018 at 12:24):
so they try to think "how can i solve gdpr with technology X or standard Y" - which is not possible
John Moehrke (Apr 17 2018 at 12:32):
is there something IHE should have said?
Jose Costa Teixeira (Apr 17 2018 at 12:44):
for awareness, i think it is a good start. But there are requirements outstanding for GDPR in healthcare
John Moehrke (Apr 17 2018 at 12:54):
when you say "good start", that is a clear message that it is not "good enough"... so, what more should be said?
Jose Costa Teixeira (Apr 17 2018 at 12:55):
it is a good start and intro to the topic
Jose Costa Teixeira (Apr 17 2018 at 12:56):
but does not attempt to solve gdpr - nor it should
Jose Costa Teixeira (Apr 17 2018 at 12:57):
so, for awareness it is ok
John Moehrke (Apr 17 2018 at 13:25):
okay, if you think of something please let me know.
John Moehrke (Apr 17 2018 at 13:25):
The approach I am taking with FHIR Connectathon track is to draw a relationship between the Security and Privacy capabilities that exist within FHIR and the GDPR article and section that they most address. This is mostly a one-to-many relationship. The relationship details are most likely going to be sparse. This then becomes discussion points at FHIR Connectathon. We might work out more detailed examples, define need for profiling, or need for new capabilities.
Jose Costa Teixeira (Apr 17 2018 at 13:25):
There will be a discussion in Cologne
John Moehrke (Apr 17 2018 at 13:26):
yes. First at the FHIR Conectathon - GDPR track. Then at the Wednesday Q1, EHR workgroup. I am not aware of other
Jose Costa Teixeira (Apr 17 2018 at 13:26):
on the one:many relationship, i expect some articles will not be mapped
John Moehrke (Apr 17 2018 at 13:27):
I expect many will not map. as they are policy or operational or procedural.
John Moehrke (Apr 17 2018 at 13:28):
which is why I am starting with the S&P capabilities and mapping those to the GDPR articles. Not the other direction.
Jose Costa Teixeira (Apr 17 2018 at 13:28):
art 30 is functional. and is not mapped to anything (i asked that around here quite some time ago) so that is possibly a good exercise
John Moehrke (Apr 17 2018 at 13:29):
Seems Art 30 very clearly maps to AuditEvent
Jose Costa Teixeira (Apr 17 2018 at 13:29):
not really
Jose Costa Teixeira (Apr 17 2018 at 13:29):
but we can take that offline for koeln
Jose Costa Teixeira (Apr 17 2018 at 13:30):
Art 30 is not an event thing.
Jose Costa Teixeira (Apr 17 2018 at 13:31):
art 30 is more about "list here the interfaces you have in your hospital"
Jose Costa Teixeira (Apr 17 2018 at 13:31):
(the IHE GDPR article mentions this somewhere, but does not explain this is Art 30)
John Moehrke (Apr 17 2018 at 13:31):
ah, so Art 30 is about a list of activities broadly. We do this, that, and those... Not the recording of activities during the activity
Jose Costa Teixeira (Apr 17 2018 at 13:32):
yes
John Moehrke (Apr 17 2018 at 13:32):
In one perspective a ValueSet of PurposeOfUse would be 30.2
John Moehrke (Apr 17 2018 at 13:33):
good perspective of a perception problem. thanks
Jose Costa Teixeira (Apr 17 2018 at 13:33):
i was thinking it was an "event" thing, until lawyers changed me
John Moehrke (Apr 17 2018 at 13:33):
see. and that is why we can't give legal advice
Jose Costa Teixeira (Apr 17 2018 at 13:34):
(well , this was an operational discussion. doing this on event basis would be impractical)
Jose Costa Teixeira (Apr 17 2018 at 13:34):
so the current approach is to do this on a design basis.
Jose Costa Teixeira (Apr 17 2018 at 13:42):
but one key idea is that no single technical solution can cover the legal framework.
GDPR education is at a basic level, saying that e.g. even if you don't consent to share TB findings, the hospital can still process that data for you.
Jose Costa Teixeira (Apr 17 2018 at 13:43):
so finding a technical solution can sometimes hide the basics and give the impression that GDPR is a bunch of tecnhical mechanisms.
René Spronk (Apr 17 2018 at 13:46):
To me we can take this one step further (than the IHE whitepaper): articles 13,14,15 (at the implementation level, if one were to attempt to support the requirements electronically) have implications as to how one should use FHIR AuditEvent and Provenance. as such one can create a more detailed description of how one would do so. That's a not a 'solution' for there's variability in various contexts, but at least it provides more technical/implementation oriented guidance. Just referring to the GDPR a a law won't make implementations happen. Education needs to be done at multiple levels, one of them is to sketch the solution space.
John Moehrke (Apr 17 2018 at 14:29):
That is indeed the kind of thing that I think could come out of the FHIR Connectathon. That is to say, someone might want to work up a profile or just an example where they use the Consent as the set of rules, Provenance for the set data collection attribution, and AuditEvent for the ways the data was used. Where Provenance.target points at all the data collected, and Provenance.entity points at the Consent resource that authorized it. --- However the majority of the work for 13,14, 15 is in creating a report that combines this raw information with organizational policies and practices and contacts.
Grahame Grieve (Apr 17 2018 at 15:48):
fyi, with regard to GDPR, HL7 is working on a soliciting an legal opinion that says that we are required to retain our records to demonstrate that we have followed our processes, and that means that contributions made to member / public forums (email lists, Zulip) etc, are not subject to GDPR erasure requests
René Spronk (Apr 18 2018 at 06:48):
Well, processing would have to be based on either 6.1(a) consent or 6.1(b) contract, but then both the contract or the consent would have to be much better worded, it can't be a click through type of thing and it has to use 'friendly wording' instead of legalese mumbo jumbo. Irrespective of that the right of erasure will apply to all data, art 17.3(d) [if anything] may be a way out.
@John Moehrke We all know most of the work is procedural/organisational. IMHO, as IHE and HL7 we should be especially focused on its impact on the use of our standards. So whilst acknowledging a lot of work needs to be done in other areas (and there are tons of cross-industry whitepapers on these aspects of the GDPR) my focus tends to be on the 'how to use HL7 to support GDPR', i.e. what would a FHIR profile for GDPR look like? If a researcher has a spreadsheet with data on her laptop, one would support the GDPR stuff related to it using procedures. If one has a fullblown FHIR based EHR one probably wouldn't. If we can detail the use of FHIR in the latter context it will serve as inspiration in those contexts where FHIR isn't used to a similar high degree.
Peter Jordan (Apr 27 2018 at 05:37):
As an EU citizen who hasn't been an EU resident for 25 years, I'm very interested in who is a 'Data Subject' under GDPR. Having read a number of articles, I found this to be the most useful https://cybercounsel.co.uk/data-subjects/. It also contains a fairly clear overall statement on the global applicability of GPDR.
John Moehrke (Apr 28 2018 at 12:58):
In our context here in FHIR, the data subject is very clear from the specification pattern. There will be a .subject or .patient element that points at the description of the subject. Most of the time it is the Patient. Indirections are possible, and the data intended use is important.
Jose Costa Teixeira (Apr 28 2018 at 19:22):
Data Subject can also be staff, right?
John Moehrke (Apr 29 2018 at 12:15):
Yes, The W5 report in the FHIR specification might make this more clear. The column "who.focus" would be the element in that Resource (the rows) that points at the subject of that resource data. http://build.fhir.org/w5
Jose Costa Teixeira (Apr 29 2018 at 13:31):
Thanks, just wanted to point to that.
Jose Costa Teixeira (Apr 29 2018 at 13:33):
Apologies if I'm too often saying that GDPR is not just about consent, nor just about patients, nor just about security.
Professional Deformation from me :)
Jose Costa Teixeira (May 11 2018 at 14:04):
@John Moehrke (or others) - i think i remember there being a way to exchange only selected information about a patient.
For example, using GET ../Patient/1...
- User 1 gets the full resource
- User 2 gets some of the data in the resource, but some info like marital status is excluded.
John Moehrke (May 11 2018 at 14:59):
This is where good Resource design is critical. In a REST environment the Resource should contain all similar sensitivity information. Extracting out elements that are more sensitive is possible, but is not easy or common. So we should be very careful when we see Resources that have a huge number of elements. This might be the right solution, or might have been made too big.
John Moehrke (May 11 2018 at 15:01):
In the most basic world where only SMART is used. The scopes in SMART cover only the authorizations the app is given. So there is nothing in SMART that covers user authorizations (RBAC), nor Patient Consent authorizations. Both of these are expected to be implemented inline as part of the Resource Server.
John Moehrke (May 11 2018 at 15:03):
Add HEART, and one has a way to offload the consent decisions. HEART is designed to indicate authorizations and scopes that describe the authorizations from the Privacy consent perspective. When this is combined with SMART (like using shadow masks), you end up with that which is authorized by this patient, and which is authorized by the custodian to the app. Still RBAC is expected to be implemented within the Resource Server, as well as harmonizing all these other decisions.
John Moehrke (May 11 2018 at 15:04):
The problem with these abstractions is that they add complexity and failure modes... This is why SMART started very basic.
Jose Costa Teixeira (May 11 2018 at 18:25):
ah but I was not looking for resource design. I was assuming that, given this design, (how) can we mask some information?
I assume that even if the server knows everything about the patient, it will decide at runtime which parts to present in the resource.. i was wondering if there was any other solution.
So, patient info is all in the DB. But what you GET in the fhir frontend depends on a couple of aspects.
Lloyd McKenzie (May 11 2018 at 18:33):
Systems are free to filter the data they expose based on who's asking. And they can choose to send the Redacted security tag and/or withhold the eTag and version in the response to prevent updates
Jose Costa Teixeira (May 11 2018 at 18:35):
OK. For some reason I had the (wrong) impression that we had some mechanism to define the data screen in the FHIR layer.
Jose Costa Teixeira (May 11 2018 at 18:35):
but this ok.
Lloyd McKenzie (May 11 2018 at 18:38):
Exchange is hard enough. We're staying well away from UI :)
Grahame Grieve (May 11 2018 at 18:38):
_elements
Jose Costa Teixeira (May 11 2018 at 18:38):
in GDPR requirement terms, I am looking at sending only the data needed for a given purpose.
Jose Costa Teixeira (May 11 2018 at 18:39):
_elements is defined in the request, right?
It would have to be on the server side.
Jose Costa Teixeira (May 11 2018 at 18:39):
but I think the solution is ok - the server decides
Jose Costa Teixeira (May 11 2018 at 18:42):
(i just had an impression i had seen this somewhere. Possibly i had seen _elements and then my memory tricked me).
Elliot Silver (May 11 2018 at 18:44):
If you include a purpose-of-use in your authorization, then the server can filter appropriately on all responses with for authorization token. (Assuming that the server knows what elements are appropriate for the purpose of use.)
Jose Costa Teixeira (May 11 2018 at 18:45):
yes, that is the idea.
Grahame Grieve (May 11 2018 at 18:45):
that's possible but we sure haven't described linking those ideas up
Jose Costa Teixeira (May 11 2018 at 18:46):
it would definitely make sense for GDPR to provide this kind of guidance and detail it further.
Elliot Silver (May 11 2018 at 18:48):
If you get a redacted resource back, you shouldn't update it, but can you patch it? (Only update the elements you can see?)
Jose Costa Teixeira (May 11 2018 at 18:50):
so, @John Moehrke @Alexander Mense @René Spronk @Giorgio Cangioli for our talks:
one use case is: how to ensure that we don't share more data that is needed for a purpose. e.g. when 2 systems ask for Patient 1, they will both get name, DoB, but one system will get maritalStatus, the other one will not get the marital status.
Jose Costa Teixeira (May 11 2018 at 18:50):
(this is a tentative use case)
Grahame Grieve (May 11 2018 at 18:56):
you can patch it, I guess. But you could easily get your self into a mess
John Moehrke (May 12 2018 at 09:36):
It is possible for a fragment of a Resource to be communicated. When this is done, there are security tags to tag that Resource as not complete. The _elements query parameter is a way for a requesting organization to ask for a subset. The _summary is another.
John Moehrke (May 12 2018 at 09:36):
We have started a draft of a spreadsheet showing mapping from FHIR capabilities to GDPR articles; second sheet is a listing of gaps. https://docs.google.com/spreadsheets/d/1--6HKnMY7QCqsorpJXdgIm9lC-MJ-O_qIPTcjPdUGKg/edit?usp=sharing
John Moehrke (May 12 2018 at 09:50):
BREAKOUT Saturday 3pm-5pm in Salon 14 - To discuss existing FHIR capabilities mapping to GDPR, and gaps. This is not a general GDPR discussion
John Moehrke (May 12 2018 at 09:52):
Video from Rene Spronk on the GDPR topic https://vimeo.com/267769545
Emmanuel Helm (May 13 2018 at 07:27):
When will be today's breakout session?
Alexander Mense (May 13 2018 at 07:34):
There will be two breakout sessions today:
a) 11-12 room 14: working on spreadsheet (mapping / gaps)
b) 2-3 pm room 14: presentation from Cecil Lynch / Accenture who designed FHIR based GDPR solution for a large online platform
Jose Costa Teixeira (May 17 2018 at 04:37):
Hi. I have been hearing about the possible mechanism for addressing GDPR deletion of data (the one where you pseudonimize and give the patient the token).
I think it is technically a good idea when needed, but I do not expect it to be mandatory guidance.
Jose Costa Teixeira (May 17 2018 at 04:38):
I am awaiting feedback from a couple DPOs and a lawyer, but from my former discussions on this matter, this is a bit simpler: You don't have to delete the request to be forgotten. You actually have to keep it.
Jose Costa Teixeira (May 17 2018 at 04:53):
I am not a lawyer but how does this sound to others?
the right to be forgotten is a legal requirement and therefore processing and storage supported by GDPR.
the right to be forgotten does imply that the controller/processor can justify why they did that.
As long as you keep that data for this purpose (keeping record of who deleted data), you should be ok.
René Spronk (May 17 2018 at 06:56):
The GDPR is full of "guiding principles" and doesn't address implementation mechanisms. As such (as I've read) it's closer to 'common law' than to the EU-Continental law system. However, the guiding principle is that a person can request erasure of their data, and if there is no other legal reason which would override the right of erasure, then erasure it is.
If you tell the patient you'll be pseudonimizing, and they request full physical deletion, you'll still have to do it. Anonimisation would be a better option: effectively it would disassociate the data from the person. If one anonimises the legal ground for doing that upon an erasure request could be a) research, or b) management of healthcare processes.
Jose Costa Teixeira (May 17 2018 at 07:47):
i think you mean "if one anonimises - instead of deleting - the legal ground for doing that...."
Jose Costa Teixeira (May 17 2018 at 07:49):
and i'd suggest that regardless of keeping the data, if one keeps the anonimisation request and the response, we are in fulfillment of legal obligations. but ianal
John Moehrke (May 17 2018 at 13:51):
Given the participants of this tool are clinicians, interoperability, and technical; meaning very few are Privacy Lawyers, you would be better asking this legal question from legal experts on the topic. All we can address here is: If policy ( a ) or ( b) is decided to be used, then how would one implement ( a' ) or ( b' ) in using FHIR standards or the security stack currently endorsed by FHIR. We can't indicate if ( a ) is legitimate, or if ( b ) is legitimate, or even which is more legitimate between ( a ) and ( b ).
Jose Costa Teixeira (May 17 2018 at 13:53):
so we can provide that guidance for WHEN a given policy requirement exists.
I am suggesting that we make it clear in any guidance that this is a big WHEN.
Jose Costa Teixeira (May 17 2018 at 13:54):
similar to consent: we can tell people how to use consent for GDPR, but we must make it very clear that consent is not really covering a lot of the GDPR requirements.
Jose Costa Teixeira (May 17 2018 at 14:02):
so I would ask around: Most here are not lawyers, so why are we considering a mechanism that we don't know is needed?
Jose Costa Teixeira (May 17 2018 at 14:05):
from my perspective, practical GDPR adoption points at no need for pseudonymisation.
John Moehrke (May 17 2018 at 14:05):
We have been told, and have LONG history that proves that the functions we have in FHIR are relevant. We must simply stop short of saying that use of X is GDPR compliant. That sentence is a legal advice, which we can't make as we are not lawyers. We certainly can, and will, indicate that use of X seems useful for GDPR Article Y. Thus leaving the final legal step to the lawyers.
Jose Costa Teixeira (May 17 2018 at 14:07):
i dont see an issue with the functions in FHIR. I am stating that looking at a few implementations, i see no need for pseudonimisation of a request to be forgotten
John Moehrke (May 17 2018 at 14:07):
You can have an opinion on pseudonymization relative to GDPR... but someone else can have a different interpretation... Such as the one voiced by some at the meeting this week that indicates that when asked to erase when one has no other regulated reason to keep the data, one solution is to de-identify the data.
Jose Costa Teixeira (May 17 2018 at 14:08):
anonimisation i have seen, yes.
John Moehrke (May 17 2018 at 14:08):
This is helpful when the customdian organization has continuing need for population data analysis
Jose Costa Teixeira (May 17 2018 at 14:08):
pseudonimisation i asked one DPA, the answer was simple: No.
Jose Costa Teixeira (May 17 2018 at 14:08):
so if the mechanism is there, it's fine.
Jose Costa Teixeira (May 17 2018 at 14:10):
i would be careful we don't signal it as "this is what you need".
Jose Costa Teixeira (May 17 2018 at 14:10):
(in 80% of the cases, that is not what the doctor will order :)
John Moehrke (May 17 2018 at 14:11):
that is a perfect example of how we are addressing GDPR... We can make a statement that de-identification might be useful. This allows lawyers to make the final decision.
John Moehrke (May 17 2018 at 14:15):
Decision from WGM discussion
Whitepaper -- start on confluence (public read) (would like comment mechanism at bottom, not inline)
Would be promoted by HL7 news
Audience -
Analysts. Those that support the CxO offices -- Technical AND Executive
Not to the IT and Privacy Offices (CIO, CTO, CPO, CMO, CMIO), except to excite them that it is useful for them to give to their technical/policy people
not focused on FHIR geek - don't use FHIR terms without explaination
Goal - to inform reader about what we have, and known gaps. Ask audience for feedback on gaps, and identification of new gaps.
Encourage reader to use references for more details
Only FHIR REST
Target Page Count - 5-10
Taget Deadline - June 30
T-Con - Mondays 4pm Central Europe starting May 28
Outline
Introduction
This is not a GDPR tutorial, it expects the reader has GDPR understanding
Goal of the introduction is to set scope, and convince CxO this is useful and should be handed to their support people
Express Current Capabilities - GDPR Article mapped to the FHIR capability (Inverse of current spreadsheet)
sparse list -- explain we are only speaking to those that have a support function in FHIR
When needed -- Scenarios that describes some specifics on how to use the FHIR capabilities
e.g. How to use AuditEvent to enable knowing where data was exported to
Identification of Gaps
set of operations that could support an API to an organization (not just FHIR server) to support user access and erasure
Conclusion
We have critical capabilities
We have identified some nice-to-have gaps
We need feedback from the community on importance of the gaps
Possible Future Actions
If community expresses need for more normative detail on specific use-cases, we could create an IG
If community expresses some small gaps in FHIR, they can be managed using gForge and CR process
John Moehrke (May 17 2018 at 14:17):
sorry indenting got lost... but I suspect you can tell the whitepaper as just 4 sections: Intro, Mapping, Gaps, and Conclusion. The other detail is notes within those sections
Jose Costa Teixeira (May 17 2018 at 14:23):
thanks. Should we split this topic? I did not wonder about the white paper, but about the pseudonimisation mechanism.
Lloyd McKenzie (May 18 2018 at 08:43):
No flag to do that. You can use the "redacted" security tag and/or no share the etag or version to prevent subsequent updati
John Moehrke (May 18 2018 at 15:41):
My reportout on GDPR experience at this weeks HL7 workgroup meeting https://healthcaresecprivacy.blogspot.de/2018/05/gdpr-on-fhir.html
John Moehrke (May 22 2018 at 12:21):
My summary of our discussions around GDPR "Erasure Receipt" https://healthcaresecprivacy.blogspot.com/2018/05/erasure-receipt.html
Jose Costa Teixeira (May 24 2018 at 14:04):
As today is "consent day", it is interesting to see how some companies are assuming implicit consent , or are asking for consent when no consent is needed.
John Moehrke (May 24 2018 at 14:12):
Likely driven by the specific risk tolerance of each. Some have done their homework and know the right thing for them to do, others are being conservative and asking for consent regardless. Hopefully this doesn't cause consumers to become exhausted about all the noise, and start agreeing to things they should not be agreeing to.
Jose Costa Teixeira (May 24 2018 at 14:14):
Risk tolerance and knowledge.
Jose Costa Teixeira (May 24 2018 at 14:14):
if someone asks consent to send consent for something that does not require consent, it is kind of revealing.
Jose Costa Teixeira (May 24 2018 at 14:17):
some of these mails seem close to inadequate.
Peter Jordan (Aug 27 2018 at 09:55):
Interesting article about the practical difficulties involved in the complete removal of individual records from databases. Mainly in the context of the Australian MyHealth Record, but also covers GDPR... https://theconversation.com/my-health-record-deleting-personal-information-from-databases-is-harder-than-it-sounds-100962
John Moehrke (Sep 12 2018 at 17:53):
The security wg is working on a paper discussing how to use the various FHIR capabilities to meet GDPR. There will be discussion of this in a breakout session during the FHIR Connectathon. Sunday morning at 10:00 in the Conway room. We invite all FHIR Connectathon individuals interested to learn and interested in contributing to attend. Further discussions will happen during the WGM in the Security WG. This bi-directional communication -- aka a "Chat-a-Thon"
http://wiki.hl7.org/index.php?title=GDPR_(General_Data_Protection_Regulation)
Jose Costa Teixeira (Oct 01 2018 at 08:59):
I don't know if discussions are being held on this topic, but I see that we are still using "consent" a lot, and most of it is about erasure and audits. Is that intentional or provisional?
If the focus of the discussions is "consent" and "right to be forgotten", then it is understandable just to focus on that. (But IMO, if that is the case, the important scope of GDPR is missed)
Jose Costa Teixeira (Oct 01 2018 at 09:00):
i mean, if that is the case, the most important part of the GDPR scope is missed.
John Moehrke (Oct 01 2018 at 13:16):
Seems there is some document you are looking at that is not keeping up with our current actions. Can you please show us where you see a discussion about GDPR that is focused on Consent alone? @Jose Costa Teixeira
Jose Costa Teixeira (Oct 01 2018 at 13:17):
the link in this chat points to a wiki page which says The whitepaper will be published on the HL7 confluence page: FHIR - GDPR
John Moehrke (Oct 01 2018 at 13:37):
I look at the current draft and find it to be more balanced. Did you find this link on that wiki page? https://confluence.hl7.org/display/SEC/FHIR+-+GDPR
I suspect you got distracted by the background links on that wiki page
Jose Costa Teixeira (Oct 01 2018 at 14:16):
i did not take enough time to get distracted. I just read that
The scope of this paper is limited to the specific FHIR resources and operations that may best respond to a GDPR request such as a Request for Disclosure or Request for Erasure.
Jose Costa Teixeira (Oct 01 2018 at 14:18):
it just seems about erasure and consent.
Jose Costa Teixeira (Oct 01 2018 at 14:21):
Right for processing personal data / Explicit consent?
i don't see rest of GDPR there
Jose Costa Teixeira (Oct 01 2018 at 14:21):
seems that right of processing is being equated with consent (?)
Jose Costa Teixeira (Oct 01 2018 at 14:22):
and i understand that there is much more to interoperability in GDPR
John Moehrke (Oct 01 2018 at 14:24):
well, it is first draft... so good feedback, I will get it to @Alexander Mense
Alexander Mense (Oct 01 2018 at 14:26):
Actually the article covers these main aspects:
- Right for processing personal data / explicit consent
- Transparency about processing personal data
- Right to rectification and right to erase (“right to be forgotten”)
- Right for portability
- General security (TOMs)
Currently the most of the dicussions is around transperancy ...
Alexander Mense (Oct 01 2018 at 14:27):
So I really can not see a limitation to consent and erasure ...
Alexander Mense (Oct 01 2018 at 14:27):
But any further feedback really welcome!
Jose Costa Teixeira (Oct 01 2018 at 14:35):
if right of processing = lawfulness of processing, consent is 1 in 6
Jose Costa Teixeira (Oct 01 2018 at 15:31):
so, GDPR challenges to be addressed
1. how to handle the other justifications of processing? Consent is one and arguably not the most important (IMO not one of the top 3)
Jose Costa Teixeira (Oct 01 2018 at 15:34):
2. For gdpr I would look at (..) operations like finding data related to a patient under a given legal grounds of processing, or data stored at or before a given date...
Alexander Mense (Oct 01 2018 at 15:49):
ad 1) you are right! But in the context of our work the question is what FHIR artefacts and mechanisms can be utilized for e.g. implementing 6c "legal obligation" or 6d "vital interest". For instance we had a discussion around using Security Labels (PoU) to tag data which is processed under one of these specific conditions.
Alexander Mense (Oct 01 2018 at 15:50):
ad 2) good point. This was also adressed by Graham in our yesterdays break-out session
Alexander Mense (Oct 01 2018 at 15:51):
Thanks - this is exactly the type of comments we are looking for :-)
Jose Costa Teixeira (Oct 01 2018 at 16:02):
what FHIR artefacts and mechanisms can be utilized for e.g. implementing 6c "legal obligation" or 6d "vital interest".
IMO we would not use FHIR artefacts for _implementing_ legal obligation; we need to know whether/how we can convey the grounds for data use using FHIR.
Jose Costa Teixeira (Oct 01 2018 at 16:03):
for me, security labels seems insufficient.
Jose Costa Teixeira (Oct 01 2018 at 16:05):
simple use case: how would we use FHIR to say "this data is here for us to be able to perform the contract we established with the patient".
Jose Costa Teixeira (Oct 01 2018 at 16:08):
i think the answer has 2 components but i did not want to push this further before, i just wanted to know the status of the discussions and to see if we were still looking at consent and erasure
Grahame Grieve (Dec 07 2018 at 06:16):
same for this one:
My system follows Privacy by Design Principles sufficient to support compliance with the privacy policies in which it is implemented
Which is also grammatically broken
Grahame Grieve (Dec 07 2018 at 06:16):
this is some vague motherhood and apple pie thing here... can we make it more solid? And if not ( as I expect), why even say it? What's the point?
Grahame Grieve (Dec 07 2018 at 06:16):
then there's this:
NEW My system ensures that the level of assurance for identity proofing reflects the appropriate risk, given the issued party’s exposure to health information
Grahame Grieve (Dec 07 2018 at 06:16):
My system sends an Accounting of Disclosure to the consenter as requested when permitted actions on resources are performed using a FHIR AuditEvent or Provenance Resource
Why either? or is it both? I can only add something like that if there's some text somewhere explaining what this means.
Jose Costa Teixeira (Dec 09 2018 at 09:06):
Sorry, lost track. For context: where are these statements? Are they principles and idea(l)s, or requirements?
Jose Costa Teixeira (Dec 09 2018 at 09:20):
nevermind, found the safety checklist.
Jose Costa Teixeira (Dec 09 2018 at 09:29):
in GDPR implementation, here is what i look for : "wherever data is processed (used/stored, deleted), can I demonstrate one of the lawful bases for processing?"
Jose Costa Teixeira (Dec 09 2018 at 09:29):
lawful bases= (most common first)
1. Compliance with legal obligations
2. Vital interests e.g. Medical diagnosis and treatment
3. Public interest
4. Legitimate interests - e.g. Legal claims
5. Contractual necessity
6. Consent
7. National law
Jose Costa Teixeira (Dec 09 2018 at 09:30):
and "demonstrate"= e.g. 6. For consent, do I have evidence to the consent for processing the data? Can i demonstrate that consent was free, specific, explicit...
Jose Costa Teixeira (Dec 09 2018 at 09:35):
if I can show that, then we are ok from the Art 30 perspective.
Jose Costa Teixeira (Dec 09 2018 at 09:35):
from FHIR perspective, I do not know where this metadata is available.
Jose Costa Teixeira (Dec 09 2018 at 09:36):
has this been defined?
Grahame Grieve (Dec 09 2018 at 20:14):
Consent resource?
Jose Costa Teixeira (Dec 10 2018 at 04:33):
I think that is stretching the notion of consent. I am not native English speaker but I thought Consent was specific for a person's agreement on whether to use the data. If I need to retain demographics to do billing there is no consent.
Jose Costa Teixeira (Dec 10 2018 at 04:34):
I mean there is no need for consent but for gdpr I still need to have the metadata somewhere that this data is being kept because I need to do billing which is an allowed purpose.
John Moehrke (Dec 10 2018 at 13:27):
The Consent resource could be used to capture a consent that is other than PurposeOfUse Treatment. So, yes a Consent can be used to capture a consent to authorize use of simply demographics. Part of the Consent resource can be explicit listing of resources, types of resources, types of data, etc... and a Consent can be specific to one or more identified PurposeOfUse, where we are looking to expand the PurposeOfUse vocabulary to include some new ones inspired by GDPR that are beyond existing codes. (Billing is already a recognized PurposeOfUse available across all HL7 standards (DICOM and IHE too).
BUT, no technology can assure that the subject has understood what they are agreeing to. That will always be in human interaction space. Many parts of GDPR will stay in human space, or be organizational policy/procedure. All that Consent can do provide an element .source[x] where exactly what the subject saw (possibly with their signature) can be stored, so that there is a record of proof of that ceremony.
Jose Costa Teixeira (Dec 10 2018 at 17:58):
The Consent resource could be used to capture a consent that is other than PurposeOfUse Treatment. So, yes a Consent can be used to capture a consent to authorize use of simply demographics.
... All that Consent can do provide an element .source[x] where exactly what the subject saw (possibly with their signature) can be stored, so that there is a record of proof of that ceremony.
If I read that well, this is still about a patient agreeing or acknowledging that their data will be used. I agree, although my point was for those cases where the patient's awareness or agreement or opinion is irrelevant
Jose Costa Teixeira (Dec 10 2018 at 18:00):
in other words, my question had an implicit "..which is an allowed purpose, and i don't need to care if the patient agrees or is aware or not, because I have all justification i need"
John Moehrke (Dec 10 2018 at 22:55):
ah, so if "implied consent" is your use-case, then yes the absence of a Consent on that topic is an indication that implied consent rules would apply. It is important to assure that there is not a Consent resource on the topic, as that would be the method to record that the patient has revoked implied consent.
The difference between Implied Consent and Explicit Consent is simply the meaning of null. Logically this should be defined in the overall policy.
I have heard some organizations have decided that when any Patient resource is created, they will create a stub Consent to indicate the Implied Consent state. This can be done, nothing forbids that in the Consent resource.
Jose Costa Teixeira (Dec 11 2018 at 03:37):
It's not about implied consent, it is nothing to do with consent. It is about how you record a justification to use data. Consent is not in the picture.
Jose Costa Teixeira (Dec 11 2018 at 03:40):
There are many use cases. One can be : exchange TB infection, (including location data). The patient has no right to consent..in some cases the patient does not have the right to know that his information is sent
John Moehrke (Dec 11 2018 at 13:52):
okay. so that is organizational policy. So would be outside the scope of FHIR.
Note, that one could use a Consent if you wanted... Consent in R4 does not force a subject. This because there was interest in defining access rules that were not patient specific.
I am not convinced that FHIR is the right solution for these organizational policies. Seems a more general purpose business infrastructure is more relevant. Especially since the overall policy likely permits/denies information that has nothing to do with healthcare.
Jose Costa Teixeira (Dec 11 2018 at 20:29):
I do not want to capture the organisational policies, I want to capture the purpose of processing (among which we can have many values including consent in a few cases).
Jose Costa Teixeira (Dec 11 2018 at 20:32):
IMO the question i asked is the same as asking for security tags. Is it outside of the scope of FHIR?
Sure this is metadata that is needed for healthcare and for other industries, so not strictly healthcare specific, but so is consent (from the GDPR perspective). Why is there so much more emphasis on consent than on other purposes of processing for healthcare (which IMO are much more important for GDPR)? i could argue that with every resource instance i could require to carry the purposes of processing. Consent is one of the possible values.
Jose Costa Teixeira (Dec 11 2018 at 20:35):
I fear we are trying to fit GDPR to our toolbox (consent and right to deletion - which are not the top priority things for a healthcare institution).
Jose Costa Teixeira (Dec 11 2018 at 20:39):
I think we should have another paper on what GDPR means for healthcare :)
John Moehrke (Dec 11 2018 at 21:04):
There is a vocabulary for PurposeOfUse. This vocabulary is under consideration for adding more vocabulary values that are inspired by GDPR. This updating of the vocabulary is something we discuss on the Monday GDPR call.
John Moehrke (Dec 11 2018 at 21:06):
As a vocabulary it can be used in various ways. It certainly can be used in a Consent, to identify what the activities that consent is authorizing. It can be used in OAuth and http headers to indicate the reason why a request for data is being made (I intend to use the results of this query for the PurposeOfUse of XYZ). And it can be used on FHIR data to indicate the kinds of PurposeOfUse that data has been captured onbehalf of (This data was captured under the purpose of use of XYZ).
John Moehrke (Dec 11 2018 at 21:08):
There is no intent to force GDPR into our toolbox. I am just struggling with understanding your use-case. I am sorry that my struggle has caused you frustration. This is not my intent.
Jose Costa Teixeira (Dec 11 2018 at 21:11):
This data was captured under the purpose of use of XYZ.
Yep, that is it (or closer). I would be looking for "this data is here because...". Seems the same. So I am looking at where to put it - and I feel that consent is not the answer.
Jose Costa Teixeira (Dec 11 2018 at 21:16):
so, question is whether/where to attach this metadata in a resource. Use case could be the one we opened a few months ago - how can we search data for patient X that is used under the purpose Y
John Moehrke (Dec 11 2018 at 21:16):
That would be in the Resource header that is at the top of every FHIR Resource http://build.fhir.org/resource.html
in .meta.security
see http://build.fhir.org/security-labels.html#rsl
John Moehrke (Dec 11 2018 at 21:17):
ah, that is different... That meta element is for recording security tags about the data.... Use of data for a purpose would be a query against the AuditEvent resource
John Moehrke (Dec 11 2018 at 21:18):
see http://build.fhir.org/secpriv-module.html#audit
Jose Costa Teixeira (Dec 11 2018 at 21:18):
ok i will read that. thanks
John Moehrke (Dec 11 2018 at 21:19):
the text in the spec is not as specific as your use-case
John Moehrke (Dec 11 2018 at 21:21):
hmmm, it seems your usecase brings up a missing query parameter on AuditEvent. There should be a query parameter on AuditEvent on purposeOfEvent or agent.purposeOfUse
John Moehrke (Dec 11 2018 at 21:22):
Your environment would also need to require that ( a ) AuditEvent is recorded for all security/privacy relevant events, and ( b ) that PurposeOfEvent or agent.purposeOfUse are populated with a value from a declared valueSet. to assure that the audit log is complete and useful for your use-case.
John Moehrke (Dec 11 2018 at 21:23):
Note that environment policy would need to be sensitive to failure-modes where that value is not known
John Moehrke (Dec 11 2018 at 21:26):
I created GF#19755 for this query parameter need
René Spronk (Dec 12 2018 at 05:43):
After some discussions I concluded that legal-ground-for-processing is not the same concept as what is generally understood to be purpose of use. They're related but not the same, it's a different dimension. Right now legal-ground feels like something one would captured in Provenance. Or perhaps even/also Auditevent. But not as a security label, for it is not a property of the data, but of the processing activity itself.
Jose Costa Teixeira (Dec 12 2018 at 06:16):
and perhaps that is the missing element - we have information on the data, but not on the processing activity.
Not sure that can be solved with our current construct. Not sure it should be solved (i can imagine it should, because i would like to move from "give me data" to "give me data to use for this purpose")
John Moehrke (Dec 12 2018 at 14:31):
Both Provenance and AuditEvent make a distinction between PurposeOfUse and Activity. However this is not what I think @René Spronk is meaning. In our case Activity is a specific task a human or agent does. This definition of activity is aligned with V3 and V2... so it is more of a task within a purposeOfUse.
But within Provenance and AuditEvent there is a higher level element of the Policy underwhich the action was. It is this that I think more aligns with Rene's description.
The problem operationally is that there is not a current security authentication/authorization model that supports specifying policy, there is hardly any support for PurposeOfUse. We only have SMART-on-FHIR today, which is a basic starter kit. SMART will work fine when the purpose is treatment or patient access. However other policies of access have not been any focus. Which is really the more important part, we are focused in FHIR on things that are needed broadly while not doing academic theoretical work. This is not to say GDPR is theory, but more that we need those struggling with these non-treatment use-cases to come forward so that we can see it is real vs theory.
John Moehrke (Dec 12 2018 at 14:32):
That said... I am working with the Clinical-Research group... Unfortunately they are focused on the data accessibility, and have scoped out the security/privacy model.
John Moehrke (Dec 12 2018 at 16:17):
@René Spronk do you see the 'legal-grounds' to be contrary to specifically PurposeOfUse of Treatment/Billing/Operations ? That is not to say that these more refine PurposeOfUse are not needed, but rather that the engagement between Patient and Treatment is clear (and authorized by consent). Given that this purpose of use is the primary one that is used today for much activity, and when it is the purpose of use today it is often NOT stated but rather presumed by context
- the data is sitting in a treatment medical records repository, therefore it was captured for the legal grounds of treatment/billing
- the requests for data are coming from treatment based systems and people, therefore that request must be for legal grounds of treatment/billing
- the treatment privacy consent would cover the legal grounds of treatment/billing etc... as stated in what ever paperwork the patient is presented with...
This is NOT to exclude the other use-cases.. but I want to make sure that we cover our HL7 prime responsibility well... while we then move to improve the syste to support other use-cases.
Last updated: Apr 12 2022 at 19:14 UTC
