Consent and Identity
- 8 minsA lot has been said on consent management and enforcement recently, including the technical strategies and architecture to fulfill the requirements (see my previous posts on this topic here and here and also John Moehrke’s presentation on IHE PCF).
A critical, and yet challenging piece in managing and enforcing consent is the correct identification of the entities involved, and to ensure that the digital representation of each entity linked to the consent precisely matches the real-world entity it is intended to represent.
This may be less challenging when the consent is collected by the same organization/system where it should be enforced, but when consent is managed by a third-party system, the issue of getting these identities right across the systems becomes more challenging and crucial.
So, managing identity is an important technical component for any Consent Management System that offers the services of collecting and maintaining consents for different organizations.
Note that the question of identity also applies to non-human entities (such as organizations and devices) but it is far less of a challenge in those cases since those entities are often easier to identity based on unique identifiers, and to discover through directories.
Subject
The core identity in a consent is the subject of the consent –the individual to whom and/or whose data the consent applies. This is represented in FHIR as a reference to a Patient, Practitioner, or Group resource (and a change request approved recently will also enable a reference to ResearchSubject resource). This reference is the id of a resource in the local FHIR server. For keeping the rest of this discussion simpler, I will only focus on the Patient resource, but the same discussion applies to other resources.
The identity of the subject is crucial in two major workflows: the consent capture workflow in which a client initiates a request to collect a consent for a patient, and the consent decision workflow where a client requests an authorization decision (based on the consent) for access to a patient’s data.
The workflow for creating consent capture request starts with some entity (e.g., a provider) requesting to collect consent for a patient who would be the subject of the consent. If the Patient resource corresponding to the intended subject is already known to the initiating system, it can correctly link the invite (which is usually in the form of a Task resource as I have discussed here) to that Patient resource.
The user experience for initiating a consent collection often provides the administrator the ability to look up the patient via some search function and selects the correct patient to be assigned to the invite.
When the request to collect consent is through an external Consent Management Service, the correct identity for the patient must be established such that the FHIR server of the Consent Management Service and the initiating system both refer to the same individual in the real world. In other words, the Patient resources residing within the Consent Management System’s FHIR server must be synchronized with the patient entity (FHIR or non-FHIR) as known to the initiating client.
Note that at the time of initiating a request to capture consent, the corresponding Patient resource may not exist in the Consent Management System, so the client may have to create the resource before initiating a consent capture.
Grantor
In most cases, the grantor is the same as the subject of the consent; for example, patients make their own decision about their data. But if a substitute decision maker is assigned (either by the patient or by a legal authority such as the case of an assigned guardian), the grantor will be a different individual, and, again, the identity of this individual must be correctly established.
At the time of assigning the substitute decision maker, the patient (or the administrator) must be able to either search and select the correct individual, or identify them to the system through sufficient identifying information that could be used to establish a RelatedPerson resource.
In either case, if a third-party Consent Management System is used, the identity of the grantor must be synchronized between the client and the FHIR server of the Consent Management System.
Grantee
The grantee is the entity to whom the permissions recorded by the consent are granted. This could be an organization, a care team, or a generic practitioner role, but it could also be an individual practitioner identified by a Practitioner resource. Unlike patients, practitioners usually have sufficient identifying information that could uniquely identify them within a system or a jurisdiction. However, at the time of creating the consent, the grantor of the consent must be able to somehow find the unique identifiers for the individual which may require a directory search.
At the time of collecting consent, the FHIR server at the Consent Management Service needs to either already have a resource associated with the practitioner (and allow the grantor to search and select it) or has to create the resource after the practitioner in question has been identified through another mechanism such as a directory lookup.
In some cases, the practitioner’s identity is pre-populated in the consent form by the initiator of the consent request, for example, the admin at the provider organization. In such case, the corresponding Practitioner resource should be created (unless it already exists) at the FHIR server of the Consent Management Service.
The more challenging issue around grantee’s identity is at the time of enforcing the consent rules. This is because the enforcement of the consent hinges on:
- correctly identifying the actors involved in a workflow that enables access to the patient’s data, and
- matching the identity of these actors against the grantee as expressed in the consent to determine if the consent rules apply.
For example, if the grantee in the consent is Dr. Bob, recognizing the same Dr. Bob in a workflow (where consent needs to be enforced) via unique identifiers is crucial for correctly enforcing the consent. If in the workflow where consent needs to be enforced, Dr. Bob is known by a different identifier that is not known to the Consent Management System and is not recorded in the corresponding Practitioner resource, the enforcement would fail.
Referenced Individuals in Rules
Similar to the case of a grantee, it is also possible to reference an individual in the consent rules. For example, a common case is to make an exception to the general consent permission and deny access to a practitioner or staff member in a care team who knows the patient outside of the care relationship (e.g., a friend or a neighbor). Such exceptions can be modeled using the actor attribute as part of the provision structure in the consent which takes a reference to a Practitioner in the local FHIR server. This is very similar to the case of grantee both at the time of creating the consent and at the time of enforcing it in a workflow.
Handling Identity
A number of different strategies can be used to enhance identity management for consent.
The Consent Management Service may collect and retain the id of the Patient or Practitioner resources at its client systems to enable clients to refer to these resources by the identifier known to them. For example, the Consent Management System may record each client’s FHIR id for these resources as an identifier on the local FHIR resource thereby allowing a search based on the client’s id.
This can lead to more complexity if the Consent Management System has many clients in which case it must record the id of these resources for each of its clients and ensure that the same real world entity such as a patient or practitioner is represented by the same FHIR resource across different clients.
Alternatively, the client and the Consent Management Service may rely on unique identifiers (such as an insurance ID, or drivers license), instead of the local FHIR id, to uniquely identify individuals across their systems. This is the strategy taken by the LEAP Consent project. In a query for a consent decision in the LEAP Consent Decision Service, the client should identify the patient and actors using a set of identifiers that are then matched against the identifier attributes in the respective resources in the consent FHIR server to find the patient and to match the actor’s identity to the grantee and any actors referenced in the consent rules.
In the absence of such unique identifiers (or if such identifiers are not guaranteed to be reliably known to all the systems involved), it is inevitable for the client to have to rely on demographic queries and a probabilistic match (using the $match operation) to find the local id for the patient. To ensure such harmonization, it may be necessary that the Consent Management System and all of its clients rely on a Master Patient Index and a practitioner directory to ensure that patients and practitioners are consistently identified across the ecosystem.