I really like the work that Kantara is doing with Consent Receipt. I think they are doing what is needed. Specifically they are not trying to define an internal consent resource, nor one that would go from one data controller to another data controller.
They are focused on giving the Individual something (a receipt) that is evidence of the Consent Ceremony, and contains the terms agreed to. In this way, the Individual has evidence that can be used later when their consent terms have been violated. Much like a retail receipt is used by a consumer when the thing they bought turns out to be broken or defective.
The diagram here is the Kantara Consent Receipt
The FHIR Consent is shown here
The Kantara Consent Receipt is intended to be a self-contained message, where the FHIR Consent is one Resource to be used within a FHIR infrastructure. The FHIR Consent is just focused on the consent specifics.
Thus to create a complete equivalent one would need to assemble from FHIR:
Where:
They are focused on giving the Individual something (a receipt) that is evidence of the Consent Ceremony, and contains the terms agreed to. In this way, the Individual has evidence that can be used later when their consent terms have been violated. Much like a retail receipt is used by a consumer when the thing they bought turns out to be broken or defective.The diagram here is the Kantara Consent Receipt
Perspective difference between FHIR and Kantara:
The FHIR Consent is shown here
The Kantara Consent Receipt is intended to be a self-contained message, where the FHIR Consent is one Resource to be used within a FHIR infrastructure. The FHIR Consent is just focused on the consent specifics.
Thus to create a complete equivalent one would need to assemble from FHIR:
Bundle { MessageHeader(1..1), Consent (1..1), Provenance(1..1)}
Where:
- Bundle assemblies everything together
- MessageHeader explains to whom the message is going, and from who it originates
- I am assuming a pushed message, but FHIR clearly can be used RESTfully, or a Document could be created.
- Provenance carries the proof of origination (signatures)
- Consent specifics
Mapping FHIR Consent to Kantara Consent Receipt.
Not well mapped:
I am pleased and very surprised at how well these map. The following items are where there was differences. These differences seem reasonable given the purpose of each, and capabilities of the environments.
The following items from the Kantara Consent Receipt do map, but not perfectly.
- 4.3.4 Collection Method - a description of the method by which consent was obtained
- for FHIR, the current presumption is that the data is collected during treating the patient for healthcare reasons. This current presumption is likely not going to be true as FHIR matues
- 4.5.8 Primary Purpose -- indicates if a purpose is part of a core service of the PII controller
- Seems to be a way to differentiate primary purpose from secondary.
- FHIR Consent addresses purpose of use regardless of primary or secondary
- 4.5.9 Termination - conditions for the termination of consent. link to policy defining how consent or purpose is terminated.
- FHIR Consent has timeframe to automatically terminate, but does not address how the patient would take action
There are a few additional capabilities of the FHIR Consent that are not yet represented in Kantara
- verification -- these elements are there to hold who verified the consent ceremony. I am not convinced that this is commonly needed.
- dataPeriod -- often a patient is willing to allow some data to flow, but might want to block data from a specifically sensitive period of time. The timeframe is an easy thing to identify, and to enforce.
- data -- FHIR we can point at exactly which data is controlled by this rule
- nested provisions -- FHIR Consent can defined nested provisions. Thus enable this, but not that...
No comments:
Post a Comment