The efforts are:
- IHE – Privacy Consent for Document Sharing that supports patient specific exceptions, an advancement over their Basic Patient Privacy Consent (BPPC)
- HL7 FHIR – Privacy Consent Directive Implementation Guide that supports capturing a Privacy Consent using FHIR friendly mechanisms and leveraging the FHIR model
- HEART – Cross functional effort of the communities from OpenID/OAuth/UMA and Healthcare to leverage the User Managed Access (UMA) infrastructure to put the controls at the Patient’s finger tips.
Patient Privacy Consent Domains of InfluenceThe main difference is the domain of the data each of these is looking to control, and thus the infrastructure they have to leverage.
- IHE -- they are focused on Document Sharing (XDS, XDR, XDM, MHD), where the atom that is being controlled are documents, the metadata that can be leveraged to do that control is the XDS metadata, the metadata describing the requester is the XUA (SAML) assertion. In the case of an XDS (MHD) there is an “XDS Affinity Domain” concept to also bound the sharing.
- HL7 FHIR – they are focused on the FHIR, where the atom being controlled are the FHIR Resources, the metadata that can be leveraged to do that control is the Resource header and related resources such as Provenance, the metadata describing the requester is less defined but is likely an OAuth token. The big problem is that FHIR as a core standard has no boundary, so there is no theoretical limiter on the domain of control.
- HEART – they have just the opposite problem from FHIR, although they are mostly talking about FHIR as the data-model and access-model; they can’t necessarily rely on FHIR Resource model, metadata model, or supporting Resources. However HEART has a strong set of Profiles on OpenID Connect, and OAuth. What they have the most strength in is User Managed Access, a profile on OAuth, that allows for user to identify access rules to the data that user controls (hence the name – User Managed Access). This means they have a control domain, that which is in the control of the Patient. Thus their system will work great once it is fed with the data, and once fed with the data the original author must not share through other means or it thwarts the Patients user managed access.
The similarity of all these efforts is that they are all looking to add fine-grain controls so that the Patient is enabled to control where and when their data is Created, Accessed, and Disclosed. They are working on the same set of use-cases, mostly because the people involved are involved in all three efforts. Why write use-cases multiple times when they have already been written once. Now their use-case descriptions are not perfect copies, we do customize them with flavor.
Advanced Privacy ConsentSo the policy can leverage the following kinds of metadata from the user and data. Having rules that specifically exclude data with specific values in these metadata elements, or specifically including in sharing.
- Episode of care
- Location of care
- Diagnostic Order and results
- Publication date/time
- Identity of a Document/Resource
- Privacy/Security tags
- User Identity
- User Authentication strength
- User Role
- Organization user is from
Privacy Consent Enabling Use-casesThus we support (this is not an exhaustive list)
- Organization focused Treatment scenarios (payment)
- Patient centric data management
- Research scenarios – Patient directed and Organization requested
- Clinical Trials
- Precision Medicine
- User Identity and Authentication
- Patient Privacy Controls
- Access Control (including Consent Enforcement)