Erasure Receipt

During the GDPR discussions at the HL7 workgroup meeting in Cologne, we uncovered a potential 'nice to have' in the general information technology space, an 'Erasure Receipt'. The idea is that GDPR includes Article 17 the Right to Erasure (Recital 65 - Right of rectification and erasure), which is similar to the 'Right to be Forgotten' (Recital 66 - Right to be forgotten). In GPDR there are requirements that the data controller must pass on the Erasure request to other downstream Controllers that they have disclosed the data to; AND they must inform the Individual of each of these downstream Controllers (Article 19 - Notification obligation regarding rectification or erasure of personal data or restriction of processing). The Erasure Receipt would focus on making statements about the act of Erasure. 

I think this would be good to get as domain independent, not something that Healthcare does alone.

Like a Consent Receipt

Much like the "Consent Receipt" work that Kantara has developed. Where the Consent Receipt is a consistent concept that states the facts about a Consent that an individual has agreed to. The first versions of this Consent Receipt was not structured or coded, but had some requirements of the text and would be delivered to the Individual. The main goal of a "Consent Receipt", much like any cash register receipt, has very little use when everything works as expected, but is there as evidence in the case where things do not progress as expected. Specifically when the terms of the Consent are not enforced, the Individual can leverage their Consent Receipt against the violating custodian.

Erasure Receipt

So an "Erasure Receipt" would be given to the Individual after they have asked for data to be Erased. When that Erasure works as expected, the Erasure Receipt has very little usage. However if at a later time it is found that the data was not properly erased, then the Erasure Receipt can be used against the violating custodian. We also envisioned that the Erasure Receipt might be useful to probe the custodian to check that there is no current evidence of the data that was erased. So the Erasure Receipt is an artifact that shows due diligence, transparency, and trustworthiness. 

One reason why an Individual might request Erasure is when they withdraw their consent. In this case the Erasure Receipt and Consent Receipt might be the same.

"... where a data subject has withdrawn his or her consent or objects to the processing of personal data concerning him or her, ..."

Requirements of an Erasure Receipt

I am not a lawyer, so this is not legal advice... So the overall requirements that I think an Erasure Receipt has is:

• Date of Erasure Request
• Date of Erasure Receipt (typically must be within 90 days of request)
• Jurisdiction
• Human Language
• Identification of the individual
• Identification of the data controller
• Description of data to be Erased
• Purpose of Use the data was collected under
• Type of data that was collected
• Identifier of previously capture Consent Receipt
• Exceptions
• Reason why data could not be Erased (e.g. Medical Records Retention, Obligation to Report)
• Identification of Purpose and Type of data not deleted
• Success
• Identification of Purpose and Type of data deleted
• Method used to Erase (e.g. Deleted, De-Identification, etc)
• Downstream Recipients
• For every downstream Recipients of the data being asked to be Erased.
• Identification of downstream Processer
• Response if any received from request made to downstream Recipient
• Pseudonym -- given the Individual has been Erased, a pseudonym (i.e. GUID) can be assigned to the remaining data, proof of erasure, and the Erasure Receipt.
• This might be useful by the individual in the future to probe the erasure facts
• This might be most useful where the data are de-identified and maintained for other required purposes. A probe of the pseudonym would show integrity of that data, while assuring the Controller no longer knows who the individual is.

Once the Erasure has happened, and the Erasure Receipt has been delivered. The Custodian must now erase the individual details around the Erasure Request. Thus the power of the Erasure Receipt is that it is placed into the Individuals hands and only that Individual. Thu the Erasure Request likely does need to be Digitally Signed by the Custodian.

Erasure Exceptions

Given my discussion is most around Healthcare, the first clarification that I always express is that the GDPR Erasure Request does not override a Healthcare organizations regulated requirements (Article 23 Restrictions), such as Medical Record Retention regulations. Thus an Erasure Request in these cases might be completely denied. The likelihood is that there might be some data held by the Healthcare organization that is not protected by a regulated responsibility, such as social contacts and interactions. This exception puts many in Healthcare at ease. I then remind them that under GDPR, once that regulated reason expires they MUST erase the data. Thus if your country has a requirement to maintain Healthcare data for 30 years, once that has expired the data must be erased.

Other similar use-cases

This similar concept might also be applied to the Article 16 - Right of rectification, Article 18 - Right of restriction of processing, and Article 21 - Right to object.  I simply did not look further into this.

Conclusion

Erasure is different than Consent, but the receipt processing and overall use as a token when things do not progress as expected is similar. The big advantage of an Erasure Receipt comes when it can be Digitally Signed and include structured content. 

I am not a Lawyer, this is not legal advice...

GDPR on FHIR

I just finished a very long week in Cologne at the HL7 workgroup meeting and FHIR Connectathon. I had the idea that I could host a discussion of how to use FHIR in a GDPR compliant organization. So I created a FHIR Connectathon track. This track was hopeful that we could do testing with various parts of the FHIR specification. We ended up talking more about generally how to use the various capabilities that exist in FHIR to meet the various Articles in GDPR.

FHIR is GDPR enabled

The Security Workgroup and the Privacy (CBCC or CBCP) are global workgroups, so we have been aware of GDPR for many years. As concrete needs came up we would add that capability. Thus FHIR includes many capabilities that can be leveraged to meet GDPR needs. From a purely geek perspective the GDPR is not technically unusual, it simply places some higher emphasis on Privacy and Security capabilities. Thus overall the GDPR is a good thing to me, as it validates and will leverage the work I have spent 20 years developing in HL7, IHE, and DICOM.

More on this later in this article

GDPR is more than Privacy

I have heard a few people express that GDPR is more than Privacy and Security. I think that these people are misguided at the extent of the real definition of Privacy. The Privacy Principles that are generally included in many standards and guidance are inclusive of giving the Individual the right of Access, the right of Correction, and the right to control how their data are used.  Too often people think Privacy is only about restricting access. The HL7, IHE, and DICOM workgroups I have participated in have always used the more expansive definition of Privacy Principles.

Even the GDPR right to Erasure, related to the EU Right to be Forgotten, is an extension of the Privacy Principles rights to control data about the individual and the rights of the individual to correct improper information.

Adding emphasis: GDPR is very much patterned after "Privacy by Design", indeed it requires that "Privacy by Design" is used.  I have lots of experience with Privacy by Design, and like it. In my GE days, I made it the backbone of the Security and Privacy guidance for all products at GE Healthcare.

Thus GPDR is primarily about Privacy...

GDPR is more than technology

This is a fundamental truth. GDPR will drive far more work in the space of writing Policies, Procedures, Communications, and such. There are many publications, consultants, and lawyers that can help with this. There are many publications that will explain GDPR to you. I am not going to try to explain GDPR.  The law itself is not that hard to read.

So at this point I assume the reader is knowledgeable in GDPR. If not, then go learn that much first....

How is FHIR GDPR enabled?

This week we agreed to write a whitepaper that will explain this. It has the general ouline

1. Introduction and Scope -- that will explain we are only addressing FHIR specific topics
2. Mapping of GDPR Articles to the existing Security or Privacy capability in FHIR -- this section will provide terse guidance on how we visualize the use. 
3. Identification of some gaps we identified -- nothing critical, mostly nice-to-have operations
4. Conclusion -- FHIR is GDPR enabling

We are targeting the audience that is aware of FHIR and GDPR, that just needs some help extracting out the specifics. This paper should be about 8-10 pages.

The expectation is that once published, the external community may ask for clarification, or for specific actions. We might revise the paper. We might make it more visible through balloting as informative. We might convert it into an Implementation Guide.

Which parts of FHIR are useful?

Not to get ahead of myself. The following are the capabilities that we have already in the FHIR Specification today:

Security & Privacy    and  Security

• Provenance, Resource
• Includes a signature mechanism that can be leveraged in many comprehensive ways.
• AuditEvent Resource, and Guidance
• Consent, Resource
• any Resource can be tagged with Security/Privacy tags
• De-Identification guidance
• Secure Communications
• Common recommended use of TLS (HTTPS)
• May use Client Authentication
• Recommend follow good TLS principles such as BCP195
• Authentication and Authorization
• SMART-on-FHIR - leverage OpenId Connect for User Authentication. Provides a pattern for OAuth scopes
• IHE  - Internet User Authorization - defines a set of OAuth token attributes
• HEART -- a mechanism for externalized Consent to be managed and Authorization decisions made
• Identity -- various FHIR resources are tied to identities that can be used in Policy (e.g. Consent), and would be used in AuditEvent and Provenance to record Who did some action.
• Patient
• RelatedPerson
• Practitioner
• PractitionerRole
• Group
• Organization
• Location

Gaps -- those that we found this week.

We did identify some gaps. But all of these gaps are 'nice to have'. They all are new functionality that helps automate an Organization's actions on the Individual actions:

• Operation that would provide response to an Individual "Right of Access" Article 15
• assemble all the PurposeOfUse the organization utilizes, which would be beyond those used in the FHIR infrastuture
• For each PurposeOfUse assemble the types of data utalized
• And how the data are processed
• etc...
• Operation that would provide response to an Individual "Right to Data Portability" Article 20
• assemble ALL the data in the best encoded format. 
• This includes data not found in FHIR format
• Possibly that data can be just described in meta terms
• Possibly that data can be encapsulated in DocumentReference + Binary
• etc...
• Operation that would provide capability and response to Individual "Right to Erasure" Article 17
• NOTE that Erasure does not override other regulated reasons to keep the data. Thus Medical Records are not subject to Erasure.
• Erasure affects all data, not just FHIR data
• Identity must be confirmed. 
• Action must be confirmed
• Various Erasure methods might be used
• simple delete
• de-identification
• etc
• An Erasure Receipt might be useful to define as a standard.
• Possibly others...

Although these were discussed, it is very unclear how realistic their use would be.

Conclusion

I assert that FHIR is ready for GDPR use. I welcome engagement that helps enlighten me.