The SLS needs to provide an API interface through which the client can submit the data and receive either the labels or labeled data. There is currently no standard specification for such an API interface, but this is scoped to be part of the upcoming update to the FHIR DS4P Implementation Guide.

I previously wrote about using CDS Hooks as a possible standard but as my implementation revealed (and as the feedback from the community confirmed) that does not seem to be a suitable API interface for communicating with the SLS. Defining a FHIR Operation for this purpose seems to be a more appropriate approach for this use case. This will be included in the next update to the FHIR DS4P IG, I am planning to work on this year.

As part of my work with SHIFT, I separated the SLS capabilities from the LEAP Consent Decision Service into a separate service, LEAP FHIR SLS. The interface is currently a simple API that accepts a FHIR Bundle and returns a Bundle with the same resources but labeled.

This interface suits the use cases where the labeling takes place on the fly within the context of an exchange transaction. The transaction orchestrator, or the access control system, can submit the outgoing response bundle to the SLS, receive the labeled resources in the response bundle, and send it to the recipient —or the next stage of the transaction fulfillment workflow, for example, a redaction service to enforce policies like those expressed in a consent, as shown in a sample architecture below (which also aligns with the model I implemented in the LEAP FHIR Hearth project).

This API interface is, however, not optimal for the use case where the data must be labeled at rest, for example, batch-labeling data in an EHR. In this use case, an orchestrator has to submit a bundle of data (scheduled for labeling based on some event, such as newly-created or or bulk-imported resources) to the SLS. If the orchestrator receives the bundle of labeled data in response, it will have to figure out which resources in the bundle were updated with new labels and then invoke the logic to update those resources in the original data source to incorporate the new labels.

It is much more efficient if the SLS can provide a response that is more readily consumable by the orchestrator in this case. FHIR has specific operations for changing the metadata of a resource, $meta-add and $meta-delete. These operations enable changing the security labels, without having to update the entirety of the resource.

Aside from needing a much smaller payload, these operations also make it possible for the FHIR server to control access to resources in a more granular way, by granting a client access to update the metadata of a resource without necessarily allowing changes to its content.

Using these operations, the SLS can produce a response in the form of a FHIR transaction containing FHIR operations to update the labels. This simplifies the orchestrator logic by enabling the orchestrator to simply relay this transaction to the FHIR server to label the data.

This also leads to a much more concise response from the SLS; for example, if there are 50 resources in the SLS request bundle and only 5 of them are sensitive, the SLS response will only contain 5 update operations. Moreover, the resource contents are not echoed back in the response.

An example of this use case is batch labeling of data at rest shown in the following sample architecture. The batch orchestrator retrieves the data scheduled to be labeled (based on a labeling queue) and submits the bundle to the SLS. The response from the SLS, which is a transaction bundle is then submitted to the FHIR server by the orchestrator.

The labeling queue may be filled based on external events but also based on the events within the FHIR server, such as creating or updating resources. If the FHIR server supports FHIR subscriptions, they can be leveraged to use these events to schedule resources for labeling.

To support both of these use cases, I implemented a new endpoint in the LEAP FHIR SLS to support this mode. The following is a sample response from this endpoint:

{
  "resourceType": "Bundle",
  "type": "transaction",
  "entry": [
    {
      "fullUrl": "Observation/1001/$meta-add",
      "resource": {
        "resourceType": "Parameters",
        "parameter": [
          {
            "name": "meta",
            "valueMeta": {
              "security": [
                {
                  "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
                  "code": "SUD",
                  "display": "substance use disorder information sensitivity"
                },
                {
                  "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality",
                  "code": "R",
                  "display": "restricted",
                  "extension": [
                    {
                      "url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-sec-label-basis",
                      "valueCoding": {
                        "code": "42CFRPart2",
                        "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
                        "display": "42 CFR Part2"
                      }
                    },
                    {
                      "url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-sec-label-classifier",
                      "valueReference": {
                        "display": "LEAP+ Security Labeling Service"
                      }
                    }
                  ]
                }
              ]
            }
          }
        ]
      },
      "request": {
        "method": "POST",
        "url": "Observation/f204/$meta-add"
      }
    }
  ]
}

Aside from the common metadata, the Permission resource allows expressing a policy in the form of an array of rules (in the rule attribute). Each rule is based on a simple access control model that permits or denies some activity by an actor on some data.

Against a given context, each rule may evaluate to a permit, deny, or not-applicable decision. The combining attribute enables specifying a combining strategy that determines how to consolidate the decisions from different rules into a single final decision. For example, a deny-overrides combining strategy means that if any of the rules decides that access should be denied, that decision should prevail, even if other rules decide to permit access. This model (albeit simplified) is very similar to that of OASIS XACML.

One of the requirements currently not addressed by the Permission resource is the ability to link to other permissions in order to support modularization of policies. A simple example is to have different Permission resources for different purposes of use and linking them into a main policy.

Another example is to have a consent policy with the broad rule that denies sharing of substance use treatment data and a more specific rule that permits sharing this data with a particular actor. Since the broad rule will be common across many consents it can be modeled as a single Permission resource which is then referenced by the individual consent policies (each modeled as its own Permission) where more specific rules are articulated.

There has been discussions at the HL7 Security Work Group about the best way to model this in a Permission resource. My proposal is the following:

• Enable referencing another Permission resource from within an element in the rule array using a new attribute called import that holds a reference to a Permission resource.

• If this attribute is used, then no other attribute should be present in that rule element; in other words, each element in the rule array may either describe an access control rule or reference another Permission as shown in the figure below.

• The result of evaluating the referenced Permission will be combined with the decision from other rules in the array based on the decision combining strategy.

This will look like the following:

{
  "resourceType": "Permission",
  "id": "example",
  "status": "active",
  "validity": {
    "start": "2024-01-01"
  },
  "combining": "permit-overrides",
  "rule": [
    {
      "import": {
        "reference": "Permission/overarching"
      }
    },
    {
      "type": "permit",
      "data": [
        {
          //...
        }
      ],
      "activity": [
        {
          //...
        }
      ]
    }
  ]
}

In order to support a meaningful implementation of this feature, some semantic rules are also needed. The following is a starting draft:

• If the reference leads to an inactive or expired Permission, this should be interpreted as returning a not-applicable decision because the referenced permission is silent about whether access should be permitted or denied in the given context.
• A circular reference in processing linked Permissions should be treated as an error, leading to a not-applicable decision bubbling up from the Permission resource in which the circular reference was encountered.
• There should be a pragmatic limit on the length of the chain of linked Permission and the implementers should put reasonable guardrails against maliciously or erroneously large chains that could lead to draining of resources at the time of processing.

One of the requirement in these use cases is to mark certain granular data to be subject to specific protective policies. For example, the location of a women’s shelter may be considered sensitive information to ensure that access to this data element is restricted.

The current IG defines a rather complex mechanism for modeling such requirements:

• The Consent resource is profiled for modeling such restrictions. This profile defines an extension (called restrictFhirPath) to point to specific elements using FHIRPath expressions.

• Through the use of another extension (called base-ext-usage-restriction) a resource can point to a consent that carries the restrictions and include pointers to the restricted elements.

• The IG also requires that the Consent instance be embedded within the resource as a contained resource.

There are some issues with this approach: Policies like the one in this example usually apply to many resources. For example, restricting access to the location of women’s shelter usually applies to all such resources or a group of them (e.g., those in a particular jurisdiction). Embedding the policy within the resource leads to significant redundancy by repeating the same policy on each resource. Aside from adding to the volume of the data, this redundancy also makes it onerous to update the policy. If the overarching policy about the location of women’s shelter changes, for example, all of the resource instances need to be updated in order to change the embedded policy. This can be a costly and inefficient process which may also lead to inconsistencies –if for some reason some instances are not updated and end up bearing old policies. Generally, if a policy applies to many resources, it should be stored in a single place to avoid such redundancy and its negative consequences.

On the other hand, in this approach, if the consent policy is separated from the resource, determining whether a resource is subject to restrictions becomes complex. Because the link to the protected parts of the resource are in the consent, it is not clear by simply looking at a resource whether any restriction would apply. At the time of processing a resource (e.g., in response to a query), all consents need to be examined, and all the FHIRPath expressions in them have to be evaluated to find whether any of them may be applicable. This can be improved to some extent by using search parameters to narrow down the consents that should be examined but it is ultimately an inefficient process and would not scale well if the number of policies or FHRPath expressions grow.

Using Inline Labeling

The FHIR Data Segmentation for Privacy (DS4P) Implementation Guide has already addressed this use case through inline labeling.

To cover this requirement using the FHIR DS4P IG extensions the following mechanism should be used:

• Tag the resource with the PROCESSINLINELABEL security label (in the meta.security element) to indicate that there are inline labels in the resource and help the implementers decide whether a deep inspection is needed to identify element-level labels.

• Use the extension-inline-sec-label to record a sensitivity or confidentiality label directly on the sensitive element, for example, the location element in the HealthcareService for the women’s shelter.

• If needed, use the sec-label-related-artifact-extension on the resource (or the element) to point to a consent resource that models the applicable policy.

An example of this is given below:

{
  "resourceType": "HealthcareService",
  "id": "HealthcareServiceWomenShelter",
  "meta": {
    "lastUpdated": "...",
    "profile": [
      "http://hl7.org/fhir/us/ndh/StructureDefinition/ndhEx-HealthcareService"
    ],
    "security": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
        "code": "PROCESSINLINELABEL",
        "extension": [
          {
            "url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-sec-label-related-artifact",
            "valueRelatedArtifact": {
              "type": "depends-on",
              "resource": [
                {
                  "reference": "Consent/consent-usage-restriction"
                }
              ]
            }
          }
        ]
      }
    ]
  },
  "identifier": "....",
  "name": "Womens shelter",
  "active": true,
  "category": "...",
  "type": "...",
  "location": [
    {
      "reference": "Location/LocationWomenShelter",
      "display": "The W Womens Shelter",
      "extension": [
        {
          "url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-inline-sec-label",
          "valueCoding": {
            "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality",
            "code": "R",
            "display": "restricted"
          }
        }
      ]
    }
  ],
  "telecom": "..."
}

In this approach, sensitive elements are tagged directly which enables a straightforward mechanism for the implementer to invoke additional access control when handling a resource by simply examining whether inline labels exist, and if the answer is yes, inspecting the resource to find the labeled elements.

If a usage policy applies, it is modeled as a single consent rather than being repeated as part of every resource with sensitive elements. Therefore, if the policy ever changes, it can be updated once and would apply to all resources covered by the policy.

Note that in some cases, the labeling alone may be sufficient and the applicable restrictions may be implied by broader rules as part of the service agreement.

I think considering this is a common class of sensitive information in health and social care, sensitive location and sensitive contact information probably deserve their own dedicated sensitivity category reflected by a standard code. This is something that a future update to the FHIR DS4P IG should consider.

A final point about this is on the use of Consent resource. Using Consent to carry general access policy in this manner is not quite semantically aligned with the purpose of the consent resource. Consent is a specific type of policy fragment set by patients (or someone on their behalf) that articulate some rules about the use of their data. It is understandable that in the R4 version of FHIR this was the only way to express a policy, but in the later versions of FHIR, the Permission resource was added for capturing more generic access control policy that are not necessarily tethered to a patient of their data.

In technical discussions around consent management and enforcement, usually a simple transaction context is assumed: the custodian of the data wants to share it with a recipient and consent needs to be honored and enforced. This is reflected in the architecture proposed by the LEAP Consent project as well as the model in IHE PCF.

In this simple architecture, there are only two entities: the custodian and the recipient. Consent enforcement takes place as part of the general access control where overarching policies determine that in the context of a particular transaction, the decision whether to permit access (and to what extent) hinges on the patient’s preferences, captured by the consent.

In this scenario, it is often assumed that the custodian is in charge of enforcing the consent and either directly owns the consent decision and management services or has a direct integration with a partner entity that readily provides these services.

From a more general perspective, however, exchange transactions may be far more complex and involve other intermediaries. I use TEFCA as an example of a this more general model where multiple intermediaries may be involved in a workflow to fulfill an exchange transaction. Note that this is also a simplified model of TEFCA.

(adapted from the TEFCA Qualified Health Information Network (QHIN) Technical Framework (QTF))

In this simplified model, the recipient’s request for data exchange goes through the recipient’s Qualified Health Information Network® (QHIN) which effectively acts as a hub for the recipient’s community and a router for this transaction. Similarly, there is a QHIN in the custodian community with the similar role.

There are three major questions regarding the consent in this architecture as I will discuss in this post. Determining the answer to these questions depends on both policy and technical factors. Note that these models are not mutually exclusive and different combinations of these models can coexist within an ecosystem and be applied in processing different transactions.

Who manages the consent?

There needs to be an entity that handles the interactions with patients to collect and maintain consents. Consent management may be implemented by one of the entities directly involved in the transaction workflow shown above, or by a third-party (or third parties) with direct relationship with one or more of these entities. There are initiatives to standardize the functions of a consent management system (such as FHIR at Scale Taskforce (FAST) Scalable Consent Management Implementation Guide) in order to establish scalable mechanisms for these functions to be implemented by different entities. This also enables consent management to be handled as a third-party service by a community of vendors competing and innovating on the proprietary aspects of user experience and user interface, while relying on a standard specification to guarantee interoperable interfaces. I have discussed this in a previous post and will discuss further in future posts.

Who provides the consent?

One of the entities involved in the transaction must retrieve the consent and add it to the context of the transaction for enforcement. This could be either the raw consent object, or a consent decision obtained for the particular transaction context based on the consent. In order to retrieve the consent, this entity should either directly own consent management or be integrated with consent management services that collect and maintain consents.

It also need to align the identity of the patient in the context of the transaction with the digital identity of the patient as known to these consent management systems to ensure the correct consent is retrieves (for more on this see my previous post about consent and identity).

Recipient

In some cases, the recipient initiating the request already has the consent and can include it in the transaction context as part of the request. For example, in a referral workflow, when the recipient needs the patient’s record, if the recipient already has a relationship with the patient it can collect the consent from the patient and provide it as part of the request for data.

The question of patient identity is easier to resolve in this case because the recipient directly knows the patient and can retrieve (or collect) the consent from that very patient. Matching the identity of the patient with the identity of the patient as known to the custodian is still an issue but it is handled by the broader workflow, in this case, TEFCA’s patient discovery.

If the enforcer of the consent can trust this adjudication of identity then the enforcement of the consent also becomes easier and essentially boils down to verifying that the consent rules indeed permit the transaction to proceed and any additional obligations that must be applied.

Recipient QHIN

This is the case where the consent is managed at the community level on the recipient’s side. Once the request reaches the recipient’s QHIN, it retrieves and adds the consent to the transaction context. The QHIN needs to resolve the patient identity to ensure that the consent retrieved belongs to the same patient whose information is the subject of the transaction.

Custodian QHIN

In this case, consent is manages at the community level on the custodian’s side. When the request is received by the QHIN, it resolves the patient identity and retrieves the consent from the consent management system and adds it to the context of the transaction.

Note that in cases where there are many consent management systems, the QHINs as community hubs have the ability to use a discovery mechanism (similar to patient discovery) to find and retrieve any potentially applicable consent from the network.

Custodian

This is similar to the simple exchange use case in which it is up to the custodian to retrieve or collect the consent.

Who enforces the consent?

One of the entities involved in the transaction should enforce the consent rules either based on the consent object or by consuming the consent decision previously generated based on the consent. In the context of the transaction workflow, this entity should either be the same as the one who provides the consent, or an entity activated after the consent is added to the context of the transaction so that at the time of enforcement, the consent (or the consent decision) is already available.

There are usually two components to consent enforcement: (a) permitting or denying the transaction altogether based on the consent decision, and (b) applying obligations that may modify the data. For example, if the consent does not permit sharing a subset of the data, that subset can be removed (redacted) from the outgoing bundle.

Note that for the purpose of audit (and also as required by some overarching policies) the enforcer of the consent sometimes needs to log the consent that was used as the basis of the enforcement. So, if a consent decision is used (instead of the raw consent object), the consent that was the basis of the decision is often included in the decision metadata (as a link or an attachment).

Aside from the technical aspect, the decision of who enforces the consent is a policy question as it depends on who is trusted to control the flow of information based on the consent rules and to what point the overarching policies allow the information to flow. For example, if the overarching policies hold the custodian responsible for enforcing consent and do not allow the custodian to outsource this responsibility to the local QHIN, the custodian will have to be the point of enforcement.

Custodian

In this case, the custodian enforces the consent policy by either rejecting the transaction or modifying the data according to the obligations derived from the consent. In order for the custodian to be able to enforce the consent, the consent must be retrieved either directly by the custodian through an integration with the consent management system, or be provided at an earlier point in the workflow, by the recipient or one of the intermediary QHINs.

Custodian QHIN

If the overarching policies allow the data to flow from custodian to the custodian QHIN without consent, the custodian is able to rely on the community QHIN to enforce the consent for the rest of the workflow.

The QHIN may block the transaction or modify the outgoing bundle according to the consent policies. In order for this to be possible, either the QHIN needs to retrieve the consent directly or one of the other entities (the recipient, the recipient QHIN, or the custodian) should retrieve the consent and add it to the context of the transaction beforehand.

If the QHIN is acting as an aggregator, collecting data from multiple custodians, it is in a better position to enforce the consent by having a more complete picture of all the outgoing data.

Recipient QHIN

In this case, the overarching policies allow the data to flow from the custodian to the custodian QHIN and from the custodian QHIN to the recipient QHIN. For example, if overarching policies allow the flow of information within the jurisdiction and all of these entities are in the same jurisdiction (while the recipient is outside of the jurisdiction), the enforcement can be carried out by the last intermediary that resides within the jurisdiction, before the data leaves that jurisdiction. There must be trust that the recipient QHIN will enforce the consent and honor its rules. The recipient QHIN either retrieves the consent directly or relies on a consent already added to the context of the transaction prior to that point by one of the other entities.

Recipient

In this case, consent enforcement is left to the recipient. In essence, consent is not enforced on the transaction throughout the workflow, and instead the recipient is trusted to enforce the rules of the consent in its own domain in further service-to-service or end user data access. This is a rare case that is included here only for a more complete discussion; in most common use cases, consent has to be enforced before the data is given to the recipient.

One of the major components of this new rule is the requirement for the covered entity to obtain an attestation from the requester in which the requester affirms that the requested data will not be used for the purposes prohibited by the rule. The rule does not require the covered entity to do further investigation to ensure the veracity and sincerity of the attestation, and allows the covered entity to simply trust the attestation, unless it has reasons to believe otherwise. There is a requirement to cease any disclosure should it become clear that the attestation was false or erroneous.

The attestation should also include language that shows the requester confirms their awareness of the potential criminal liabilities for breaching the rule.

The rule allows the attestation to be in electronic form and electronically signed by the person requesting the disclosure but it does not mandate any specific format or standard.

It also stipulates that each attestation is limited to the specific instance of disclosure and each new disclosure request will require a new attestation. This rules out the idea of having a blanket attestation as part of the overarching trust agreement that would cover many disclosures over time.

Based on this summary I share some thoughts on the implementation of this part of the rule.

Workflow

The most important (and tricky) component of the implementation is the workflow for requiring the attestation.

Upon receiving a request, the covered entity can inspect the requested data to see if there is any reproductive health data (using a security labeling service) and then ask for an attestation only if such data is requested. This is problematic because it leaks the existence of reproductive data and effectively creates a mechanism for a requester to learn (by inference) whether such data exists about a patient by observing whether it is asked to provide an attestation. This is contrary to the spirit of the rule but perhaps also to its letter since the rule prohibits sharing any information that could lead to identifying anyone involved in reproductive health care which implies protection against sharing information that could lead to such conclusion by inference.

An alternative is to require the attestation to be present for every request. This will ensure that if there is any reproductive health care data in the response, the requirement for the attestation is met. But consider the case in which a request without an attestation is received. If the requested data does not indeed contain any reproductive health care data and this request is decline (merely because the attestation is not present), then the covered entity has declined a request for disclosure without a valid reason which could be a violation of information blocking rules.

To balance these two competing requirements, the covered entity can implement the following workflow upon receiving a request:

• If the request includes an attestation, proceed to next steps for sharing all the information (i.e., verify if sharing is authorized by other policies, such as consent where it is applicable),

• If the request does not include an attestation, identify all reproductive healthcare information subject to the rule (using a security labeling service), and redact them from the outgoing response.

With this workflow, the requirement for an attestation would not act as a signal confirming the existence of reproductive health care information but also valid requests without an attestation would not be declined.

Data Subject to The Rule

The rule deliberately establishes a broad definition of reproductive health care data. This is more expansive than the data subject to other similar legislations (e.g., Maryland House Bill 812 (2023)) that more specifically target abortion care.

This makes the implementation of sensitivity labeling more complex and nuanced since these categories of sensitive information need to be distinguished and a different sensitivity label should be used to tag each category.

The current sensitivity value set defined in the HL7 terminology does not include codes with sufficient granularity to distinguish these categories and therefore, custom labels have to be used to accomplish this.

We need an initiative to regularly update this value set in alignment with emerging jurisdictional policies and provide guidance on which sensitivity code to use for each category of sensitive data in the FHIR Data Segmentation for Privacy.

Delivery

To present the attestation to the covered entity, the requester can include a reference to it in the request as part of the authorization token. Depending on the type of the token this may be a custom attribute assertion in a SAML token (based on a profile such as IHE XUA) or a custom claim in a JWT token (based on a profile such as the IHE IUA).

Interoperable implementation requires an agreement on a standard name for this attribute to be used consistently across implementations. I think for clarity, it is helpful if the attribute name would include the name of the regulation directly (e.g., hipaa_rule_2024_attestation).

The value of this attribute should be a link to the actual attestation document where the covered entity can retrieve it. The requester can push the document into the covered entity’s server in advance, or host the document and allow the covered entity to access it (this requires the covered entity to have the credentials to access this document). It is also possible to include the document in the request itself as part of a bundle if the protocol in use allows it.

An appropriate trust agreement between the requester and covered entity may enable the covered entity to trust the claim included in the request and allow the process of retrieving the attestation document to take place asynchronously after the request is fulfilled to improve the response time. Note that this is only possible because the attestation is an opaque document and there are no choices (like options to opt out from) in it, otherwise, the covered entity would have to inspect the attestation before determining how to respond. This raises the question how much the covered entity is responsible in validating the attestation (see the note on freshness below).

Signature

The rule permits the use of electronic signature. This does not need to be a cryptographic digital signature, although with the appropriate infrastructure in place, cryptographic signatures can also be used. Even though the rule does not require the covered entity to verify the veracity of the attestation, arguably the validity of a digital signature still has to be determined to ensure that the attestation actually originates from the requester.

It seems to me that the rule requires the attestation to be signed by the human user initiating the request rather than the requesting organization, but that is ultimately a legal question. If an organization can (as the user) sign the attestation, it is also possible to argue that the signature on the authorization token (that includes the attestation claim) may suffice since the token is often signed by the organization or a trusted third-party vouching for the claims.

Attestation Format

The rule requires the attestation to be in plain language (and at another point it mentions that it could be in the form of accepting a number of checkboxes), but it does not prescribe any specific format. There are benefits in using a standard structured document such as a FHIR resource to record the attestation since this provides an interoperable way to convey and interpret the document and its metadata. Note that to use a FHIR resource for this purpose, the ecosystem itself does not have to be a FHIR-based exchange ecosystem; regardless of the format of the actual health data and the protocols used by the covered entity, the attestation can be shared as a FHIR resource.

The most suitable resource to carry this is a FHIR Contract resource which allows individual terms of the attestation to be stored granularly. If an end user actually submits a form for the attestation, the original form can be captured as a FHIR QuestionnaireResponse. A Contract resource can be derived from the QuestionnaireResponse based on the associations defined in the Contract resource specifications or via the more general and flexible $extract operation defined by the Structured Data Capture (SDC) Implementation Guide.

Since the attestation seems to be an opaque form (without a choice to opt in and out from some of the terms) I cannot think of any specific benefits for recording it in the more granular and computable format of Contract resource at the moment, but it may make the implementation easier in future if more complexity is added to the attestation or if more verification is required from the covered entity.

Freshness

The rule requires that a new attestation should be submitted for every request –therefore ruling out using a blanket attestation that applies to many requests. However, since the attestation is generic and does not differ in content from one request to another, it is easy to replay an old attestation for a new request. This raises the question whether the implementation should include technical mechanisms to ensure the freshness of the attestation. For example, a unique transaction identifier can be required to be included in the attestation before signing. The covered entity can then validate the freshness of the attestation by matching the request ID with the identifier included in the attestation.

Again, it is not clear to what extent the covered entity is expected to verify the attestation (including the requirement for freshness) and to what extent it can rely on the requester. If the covered entity can trust the requester that the attestation was obtained freshly for the request in question, this technical mechanism would be unnecessary.

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.

In order to communicate with the SLS, the client needs to submit the data in a request and receive the labels, perhaps incorporated into the data in the form of labeled data. There is currently no standard specification for such an interface.

Last year, for an academic project at Arizona State University, I added a very simple and rudimentary implementation of a SLS for FHIR resources to the LEAP Consent Decision Service code base. This service only works with FHIR data and does not accept other formats like CDS or HL7v2.

Since I had to decide on an interface for this API, I used the simplest possible interface: plain FHIR. The request body is either a FHIR resource or a FHIR Bundle containing a collection of resources, and the response body is identical to the request except that labels are added to the resource(s) if applicable. A labeled FHIR resource is a resource with the security labels added to its meta.security attribute.

Although this API was good enough as a proof of concept and for demos, it lacks some of the more sophisticated features. A more advanced SLS API needs to support the following:

1. Labeling Parameters: The client should be able to specify parameters about the labeling, for example, specify that it is requesting to assign sensitivity labels only.

2. Transaction Context: In cases where the labeling depends on the context of the transaction, transaction attributes such as the purpose of use or the identity of the requester should be communicated as part of the request. For example, assigning handling instruction labels may be specific to a recipient or the purpose of use for the transaction.

3. Related Data: In some cases, a granular FHIR resource alone is not sufficient for making a decision about the labels and other related data such as the context of the encounter or the organization where the data originates from are also important. Such related resources should be provided to the SLS in order to make the labeling decision.

4. Asynchronous Calls: When computationally heavy processing is involved (e.g., processing large volumes of unstructured text), the SLS may not be able to respond with the latency appropriate for a synchronous API call. Asynchronous API calls enable the SLS to involve such computations in the labeling process.

Among the available APIs around FHIR specifications, the CDS Hooks API (designed for interacting with a clinical decision support system) seems to be suitable for the SLS:

• The context parameter in the request enables providing the data to be labeled as well as any other parameters for labeling. These parameters can be defined and documented as part of the specifications for the hook. This addresses (1) and (2).

• The fhirAuthorization attribute provides a mechanism for enabling the SLS to retrieve additional related FHIR resources that may be needed for labeling directly from a FHIR server. This is made possible by providing the SLS with an authorization token for the FHIR server as part of the request. This addresses (3).

• The systemActions attribute in the CDS hooks response can be leveraged to return labeled resources in the form of update actions. This also allows the SLS to only return resources that bear new labels (and leave out any other resources that does not need to be labeled) leading to a shorter response.

• As for (4), asynchronous calls are not supported by the current specifications of CDS hooks but if future SLS implementations really need this feature it can be added as an extension.

As a proof of concept, I added a CDS hooks interface for the SLS in LEAP-Consent Decision Service. A sample request and response is shown below.

The request includes two observations one of which is sensitive and the other is not. This is submitted as an attribute named bundle under the context attribute of the request which takes a FHIR Bundle resource:

{
  "hookInstance": "...",
  "hook": "bundle-security-label",
  "context": {
    "bundle": {
      "resourceType": "Bundle",
      "entry": [
        {
          "fullUrl": "https://fhir.example/Observation/O1",
          "resource": {
            "resourceType": "Observation",
            "id": "O1",
            "status": "final",
            "code": {
              "coding": [
                {
                  "system": "http://snomed.info/sct",
                  "code": "724713006",
                  "display": "Harmful use of ketamine (disorder)"
                }
              ]
            },
            "subject": {
              "reference": "Patient/f201",
              "display": "Roel"
            },
            "issued": "2013-04-04T14:34:00+01:00",
            "performer": [
              {
                "reference": "Practitioner/P202",
                "display": "Luigi"
              }
            ],
            "valueBoolean": true
          }
        },
        {
          "fullUrl": "https://fhir.example/Observation/O2",
          "resource": {
            "resourceType": "Observation",
            "id": "O2",
            "status": "final",
            "code": {
              "coding": [
                {
                  "system": "http://acmelabs.org",
                  "code": "104177",
                  "display": "Blood culture"
                },
                {
                  "system": "http://loinc.org",
                  "code": "600-7",
                  "display": "Bacteria identified in Blood by Culture"
                }
              ]
            },
            "subject": {
              "reference": "Patient/f201",
              "display": "Roel"
            },
            "issued": "2013-03-11T10:28:00+01:00",
            "performer": [
              {
                "reference": "Practitioner/f202",
                "display": "Luigi"
              }
            ],
            "valueCodeableConcept": {
              "coding": [
                {
                  "system": "http://snomed.info/sct",
                  "code": "3092008",
                  "display": "Staphylococcus aureus"
                }
              ]
            }
          }
        }
      ]
    }
  }
}

The response includes one update action under the systemActions attribute which includes the labeled resource (only the one that needed labeling). Note that the LEAP-CDS SLS also adds the basis for labeling (references to the rules and policies based on which the labels were determined) using the sec-label-basis extension from the FHIR DS4P IG.

{
  "cards": [],
  "systemActions": [
    {
      "type": "update",
      "description": "labeled resource",
      "resource": {
        "resourceType": "Observation",
        "id": "O1",
        "status": "final",
        "code": {
          "coding": [
            {
              "system": "http://snomed.info/sct",
              "code": "724713006",
              "display": "Harmful use of ketamine (disorder)"
            }
          ]
        },
        "subject": {
          "reference": "Patient/f201",
          "display": "Roel"
        },
        "issued": "2013-04-04T14:34:00+01:00",
        "performer": [
          {
            "reference": "Practitioner/f202",
            "display": "Luigi"
          }
        ],
        "valueBoolean": true,
        "meta": {
          "security": [
            {
              "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality",
              "code": "R",
              "display": "restricted",
              "extension": [
                {
                  "url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-sec-label-basis",
                  "valueCoding": {
                    "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
                    "code": "42CFRPart2",
                    "display": "42 CFR Part2"
                  }
                }
              ]
            },
            {
              "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
              "code": "SUD",
              "display": "substance use disorder information sensitivity",
              "extension": [
                {
                  "url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-sec-label-basis",
                  "valueCoding": {
                    "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
                    "code": "42CFRPart2",
                    "display": "42 CFR Part2"
                  }
                },
                {
                  "url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-sec-label-basis",
                  "valueCoding": {
                    "system": "sample-rule-1",
                    "code": "ketamine"
                  }
                }
              ]
            }
          ]
        }
      }
    }
  ]
}

Labels are assigned based on applicable labeling rules; these rules may originate from various sources:

• clinical knowledge, for example, a rule that specifies which clinical codes are indicative of a specific class of sensitive information,
• security and privacy policies, for example, “any record related to substance use treatment should be labelled as restricted”, or
• business and workflow rules, for example, “any information received from a facility known to provide substance use treatment, should be labeled accordingly”.

In cases where the data contains unstructured text, natural language processing tools and services are sometimes necessary to infer clinical concepts implied by the unstructured text, in order to determine the security labels.

Figure 1. Security Labeling Service (SLS).

Implementing SLS requires some major components and design decisions which I discuss in this post. This expands on the brief Implementation Notes provided in the FHIR Data Segmentation for Privacy (DS4P) Implementation Guide.

The first step is to design and encode the labeling rules in a computable form so that they can be retrieved, parsed, and enacted by the SLS as applicable. For this, a rules language is needed, and if the rules are managed separately from the SLS, an API to interact with the rules is also required.

Labeling rules are designed by various stakeholders including policy experts and clinicians, so, usually a user friendly rules authoring and management interface is also desired.

Currently, there are no standard specification for the format of such rules or how they can be stored and retrieved. I wrote a brief proposal on using FHIR resources for recording SLS rules but that is admittedly too complex and perhaps an overkill at least for the current state of SLS adoption and implementation.

To record the labels on data, we need a standard mechanism consistent with the format of the data item to enable tagging the data with a label. For FHIR resources, meta.security attribute defined in the FHIR core can be used for this purpose. For more granular sub-resource labeling in FHIR, the inline labeling mechansim is defined by the FHIR Data Segmentation for Privacy (DS4P) Implementation Guide.

For CDA documents, the Data Segmentation for Privacy (DS4P) Implementation Guide for CDA defines how to record labels at the document, section, and entry levels.

For HL7v2 messages, guidance is provided in Version 2.9 for Patient Administration Access Control Restriction Value Segment (ARV), the Control description of the Batch Header Segment (BHS), the File Header Segment (FHS), and the Message Header Segment (MSH).

The standard formats for security labels define where in the data object the label can be recorded but in order to record a label, we also need to have standard codes for representing the label itself (e.g., substance use treatment or reproductive health). These codes are defined and maintained as part of the HL7 terminology and a summary of all the value sets for different types of security labels is included in the FHIR DS4P Implementation Guide.

These value sets need to be maintained and updated on a regular basis to accommodate new classes of sensitive data identified in emerging laws and regulations. There is also a need for standard specifications to provide unifying guidelines on the precise codes that should be used for each corresponding legislation and policy in the US realm in order to ensure that different SLS implementations use these codes consistently.

Finally, a standard API is needed to specify how to invoke the SLS, how to provide it with the data to be labeled, and the format in which the response should be returned. There is currently no standard specification for such an SLS API.

Aside from the data to be labeled, the request should optionally allow the caller to specify what type of labels it is expecting to be assigned (e.g., only sensitivity labels). Moreover, the caller also needs a mechanism to provide other contextual information such as the purpose of use or the identity of the data requester. This context is important for determining labels (such as handling instructions) that depend on such metadata.

Note that when processing granular data, such as FHIR resources, a sophisticated labeling decision may also rely on related data items not directly present in the request. This means the SLS may need to access some related data (e.g., the related FHIR Encounter) to establish the context for the data items in question and incorporate that in the labeling decision. One strategy is to provide the SLS with direct access to the data source. This is easier when the SLS is within the same domain but if the SLS is a third-party service, providing such access can be complex both from the policy and liability perspective, as well as technical perspective and authorization management. An alternative is to allow the SLS to ask for additional data items directly from the caller. These issues resemble those regarding data access in Clinical Decision Support (CDS) Hooks, so, that may be a good starter candidate for an SLS API.

The response may optionally include metadata about the label, such as the rationale for the labeling decision or the elements within the data object that matched a labeling rule. Such metadata may also be recorded on the data object alongside the labels when the specification is available. For example, the FHIR DS4P Implementation Guide defines extensions for recording the policy basis for the labeling and the identity of the labeler.

Finally, policy guidelines and agreements should be established to govern how the recipient of labeled data should process it and the measures it should take once it receives data bearing a particular label.

Operational Models

To integrate labeling into a system, at some point in the systems workflows, the SLS needs to be invoked and provided with the data to be labeled. There are two main patterns for incorporating the SLS into the system workflows.

In the batch model, data is submitted to the SLS by a batch processor that acts as an orchestrator for labeling by submitting the data (based on various criteria and priority heuristics) to the SLS, and subsequently persisting the labeled data back in the data source. The batch processor works offline, outside of the context of live transactions.

The labeling may be triggered based on events, such as a bulk import of new data or an update event that changes the content of a data item. It may also be based on a schedule to submit existing data to the SLS to be labeled. Ultimately, a priority queue may be used to trace the data awaiting to be labeled and to allow prioritizing certain labeling jobs over others.

Since the batch processor operates offline, it is not bound by the latency requirements of a transaction, and therefore can request labeling involving more heavy computations such as processing unstructured text.

But for the same reason, since it does not have access to the transaction context, it cannot call for assigning labels based on rules that depend on the context of a transaction such as the identity of a recipient or purpose of use. Furthermore, since data is labeled in advance and ahead of a transaction, it may have to be re-labeled if the content of the data item is updated, or in case labeling rules change.

Another disadvantage of batch labeling is the need for persisting the labels which may not be supported by the data source in case access to the data source is read-only, or if the underlying technology does not support persisting labels for other reasons.

Finally, if engineered poorly, batch labeling may waste resources by labeling a large volume of legacy data that may never be requested or used. This is particularly important for large data sources where only a fraction of the data may ever be accessed or requested to be exchanged.

Figure 2. Batch Labeling.

An alternative approach is to label the data on-the-fly and within the context of a transaction. In this model, the SLS is invoked by the authorization service, after a request for data is received, and before the data is returned to the requester. The requested data is submitted to the SLS together with the full context of the transaction. Subsequently, based on the assigned labels and other policies (including patient consent), the authorization service can decide whether to decline the request entirely or fulfill the request by sending only a subset of the data (i.e., after redacting what is not authorized to share), or share the labeled data and allow the recipient to appropriately process it based on the labels.

On-the-fly labeling has the advantage of having access to the full context of the transaction which enables assigning labels based on rules that depend on that context. For example, a labeling rule such as “all sensitive data sent to a recipient in a different state should be labeled with delete after use” hinges on knowing the geographical location of the requesting party.

The other advantage of this approach is that the labeling is always based on the most recent version of the data and labeling rules, so, re-labeling is not needed. For the same reason, it does not require the underlying data source to support persisting labels which enables further decoupling from the details of the data source implementation. This comes with the downside of having to repeat some of the labeling computations when data is requested again, since the assigned labels are lost once the transaction is completed.

Another disadvantage of on-the-fly labeling is that it is bound by the latency requirements for the transaction and if the transaction is synchronous, heavy computations such as processing unstructured text may not be feasible.

Figure 3. On-the-Fly Labeling.

Ultimately, a tailored solution to implementing the SLS usually requires a hybrid approach to balance the advantages and disadvantages of each model. For example, some of the assigned labels during an on-the-fly labeling can be persisted or cached to avoid re-labeling for frequently-requested data. Or, a batch labeler can be used to do some labeling (e.g., sensitivity labels that do not depend on the transaction context) while on-the-fly labeling may be used to add additional labels at the time of the transaction.

Consent management refers to various functions involving collecting, maintaining, and serving consents. As shown in Figure 1, a consent management system serves patients/clients, (internal or external) administrators, external consent consumer systems, and other consent management systems. A FHIR-based consent management system would rely on a FHIR server and FHIR resources to implement the corresponding use cases.

Figure 1. Consent management.

A FHIR IG for consent management should provide guidance on how to map these high-level functions to granular FHIR functions (e.g., creating or updating resources) and introduce profiles and example resources to support them.

Initiate Consent Capture

A provider may initiate capturing a consent by requesting a patient/client’s consent for a particular use case. In some cases, the patient/client initiates filing a consent without an explicit request.

The initiation may be by an administrator (internal or external) through a user interface, or it could be through an API request by an external system where consent is needed. We refer to such systems as consent consumers. This is usually triggered by an event in a workflow within the consumer system; for example, a referral which requires sharing sensitive information pending on the patient’s authorization.

Requesting consent may target one individual patient/client but it may also target a group, for example, a cohort of patients who qualify for participating in a clinical trial.

A mechanism (such as email, text message, or mobile app push notification) is needed for notifying the patient/client that their consent has been requested –if the consent capture is not initiated by the patient/client.

From the FHIR perspective, an IG should specify how to use a resource such as Task to record the request to capture consent from a patient/client.

Initiating a consent may seem to be doable with a single standard FHIR API call to create a new Task assigned to the patient/client. But this is only the case if the local FHIR ID for the patient is known. Since patient identity is often more complicated, initiating a consent capture usually involves multiple FHIR API calls, therefore, it may be worth defining a custom FHIR operation in the form of an OperationDefinition resource to encapsulate all the low-level logic. This also enables consumers to use a single API call to accomplish this.

Guidance on the use of a resource like Group and the nuances of invoking a bulk consent capture for a group are also within the scope of a consent management IG.

Review Consent

Once a consent capture is initiated, the patient/client needs to review the options available in the consent form and make decisions. This requires a user interface, often a web or mobile application, that allows patients/clients to navigate their options.

From the FHIR perspective, the choices given to the patient/client are formulated in a FHIR Questionnaire resource. These are usually based on existing paper forms used to collect consent in manual workflows. The responses from the patient/client are collected in a corresponding QuestionnaireResponse resource. Together with Structured Data Capture (SDC) profile, these resources offer a powerful and flexible mechanism to model consent forms in different configurations for various use cases.

A consent management IG should provide guidance on how to store the state of the consent navigation using Task and QuestionnaireResponse as well as guidance on capturing and storing partial responses from the patient/client, including cases where the response may be provided over multiple sessions.

Sign and Execute Consent

Once patients/clients finish navigating the consent options and finalize their decision, they sign the consent. This usually means that consent rules should be immediately enacted and enforced (unless the start date for the consent is in future). The signature may be electronic (e.g, by printing the name or drawing) or cryptographic (if the infrastructure for that is available).

From the FHIR perspective this event should lead to creating a Consent resource based on the QuestionnaireResponse resource resulting from the interactions of the patient/client with the consent management user interface. The $extract operation defined by the Structured Data Capture (SDC) Implementation Guide together with one of the mechanisms defined in that IG for extracting a resource from a QuestionnaireResponse can be used to accomplish this. A consent management IG should provide the necessary profiles and examples for this.

Figure 2. Capturing consent.

The signature may be stored on either or both of the QuestionnaireResponse and Consent resources. A record of this derivation may be captured either using the sourceReference attribute of the Consent resource or more extensively using a Provenance resource. Providing a profile of the Provenance resource and examples on how to record this is within the scope of a consent management IG.

Signing a consent is an important event and usually means that the consent rules should be enforced. Notifying the consumers of the consent (e.g., the entity that requested the patient/client for this consent) is essential in ensuring a reliable workflow for enforcement can be implemented. Further discussion on notifications will be provided below.

Review Existing Consents

The patient/client, an administrator, an external consent consumer, or an external consent management system, all have reasons to review existing consents for a patient/client. This may happen through a user interface or via an API call.

From the FHIR perspective this corresponds to searching for all of a patient/client’s consents (potentially with additional narrowing criteria such as status or consent type). The issue of identifying the patient, however, may make this a more complicated operation which may deserve defining a custom FHIR operation.

Revoke/Deactivate Consent

As a principle in consent, and as a right guaranteed by most overarching policies, patients/clients may revoke a valid consent whenever they choose.

At first glance, this may seem to be a simple FHIR API call to update and change the status of the respective Consent resource, but the revocation event needs to be memorialized and usually there are legal and policy requirements to retain (in some cases a signed) record of the revocation. So, the revocation may need its own form to sign which is modeled using FHIR Questionnaire and QuestionnaireResponse resources.

Once the revocation is signed and finalized, the state of the Consent resource may be updated to reflect the revocation. A Provenance resource should be used to record the event of revocation and link it to the signed request for revocation in a QuestionnaireResponse resource. Details and examples for the use of these resources in this use case should be provided by a consent management IG.

An administrator with appropriate privileges may deactivate a consent for reasons such as when a consent is entered in error. This is a similar operation even though the policy requirement about retaining the record may be different, so, it should be treated as a separate use case.

Revocation is a major event because it ends the validity of any permissions granted by the consent. Consumers of consent need to be made aware of the revocation in order to terminate any activities authorized by the revoked consent. This is further discussed below. See my previous post on revocation for a more detailed discussion on revocation and notifications.

Note that once signed and finalized, generally a consent should never be updated directly, unless when it is revoked. If the patient/client decides to change the consent, this is done by revoking the old consent and creating a new one and recording the details in a Provenance resource.

Notifications

A notification infrastructure enables the consent management system to initiate call-backs to other entities to alert them about consent events such as signing or revoking a consent. These notifications are important in enabling external systems to incorporate handling of consent events into their workflows.

From the FHIR perspective, SubscriptionTopic and Subscription resources should be used for implementing these use cases. Providing profiles and examples of the use of these resources is a key part of an IG for consent management.

Audit

It is important for patients/clients to see the consequences of their consents as they are enforced. This can give them confidence about the enforcement of the consent (e.g., seeing the actual rejection of a request that was not authorized by the consent), but also provide the feedback that can help them update and adjust their consents (e.g., noticing some rejected request and deciding to change the consent to be more permissive). In some cases, overarching policies and laws may require this as a right for the patient/client to be able to see the record of what has been permitted or declined based on each consent.

From the FHIR perspective, the AuditEvent resource is the right fit for recording the event of permitting or declining an activity based on the consent. A consent management IG should provide profiles and examples to clarify the details.

Since access events may take place in different consent consumer systems, providing a consolidated view of all the activities related to the consent also needs a subscription infrastructure to deliver AuditEvent resources back to the original patient/client-facing consent management system. This requires the use of SubscriptionTopic and Subscription resources. A consent management IG should provide examples and potentially profiles for these resources and how they can be used to set up a reliable infrastructure for collecting all relevant AuditEvents at a consent management system.

Consent Decision

In order to incorporate consent into various workflows, a consent consumer may ask the consent management system for the Consent resource (e.g., using a search based on the patient/client identity). Once the consent is received, the consumer can analyze the rules and determine whether or not an activity in is permitted based on these rules.

This requires the consumer to implement the capabilities to process the consent rules. But it is often more convenient for the consumer to avoid implementing these capabilities (and maintaining them as the details of how consent rules are formulated may change) and instead, directly query a Consent Decision Service whether the consent permits or denies an activity –similar to the way it would query an Access Control Service. This is a major capability implemented by the LEAP Consent project. Even though the Consent Decision Service is logically a distinct service, it can be offered by a Consent Management Service as an additional capability.

From the FHIR perspective, the API and formats for consent decision requests and responses need to be defined. The LEAP Consent Decision Service implements two ways to query for a decision: CDS Hooks (with extensive extensions) and XACML. The IHE Privacy Consent on FHIR (PCF) proposes using OAuth for this purpose but does not define a mechanism for specific queries for a decision (e.g., querying whether an action for a specific purpose of use about a specific patient and on specific data is permitted or denied), so this does not align with how LEAP Consent Decision Service granular queries work. Defining further details about how to query for a specific consent decision is another area where implementation guidance is needed.

Patient-Requested Restrictions should be modeled using FHIR Consent

The FHIR Consent resource provides a powerful model for articulating patient-requested restrictions and privacy preferences. Profiles of the consent resource have been proposed (including the one in the emerging IHE Privacy Consent on FHIR Implementation Guide) and there has been multiple reference implementations (including the ONC LEAP Consent Project). Adding a FHIR Consent profile to the US Core Data for Interoperability (USCDI) seems like a natural next step to support an interoperable mechanism for expressing granular patient-requested restrictions.

Granular Consent and Data Segmentation for Privacy (DS4P) are closely linked

Through the use of a Security Labeling Service (SLS), data segmentation identifies the granular segments of data that are noteworthy from the perspective of policies and regulations, or common-sense expectations of privacy. The SLS tags the data to identify and mark those segments that have significance in enforcing privacy rules and preferences; for example, FHIR resources or sections of a CDA document that contain information about reproductive health.

This service is integral in the capability to enforce granular rules and restrictions, including those requested by patients. For example, if a patient consent requires that a provider not share reproductive health data, the provider must be able to identify any data item that falls under this category. Without DS4P, granular rules and restrictions about the data would not be enforceable because the access control system would not be able to distinguish the data items that are subject to these rules.

Minimally, it is possible to enforce patient-requested restrictions while keeping data segmentation and labeling completely internal to the organization. The organization can provide a proprietary interface for patients to request restrictions and express their preferences, and these restrictions can then be enforced through proprietary mechanisms. But this approach has significant limitations because a common understanding of patient-requested rules across different organizations, requires a common understanding of security labels used in expressing these rules. Moreover, exchanging labeled data between organizations, hinges on having an interoperable framework for recording security labels as well as a common vocabulary and an agreement on the meaning of the labels.

Security Labels are not an alternative to consent

It is important to note that security labels are not an alternative to consent in capturing patient-requested restrictions. While some security labels communicate basic handling instructions, such as “do not re-disclose” or “delete after use”, security labels generally cannot encode complex rules that a consent can model.

In theory, it may be possible (and might be tempting) as an implementation strategy, to capture patient-requested restrictions and try to turn them into security labels persisted on data items, but this is often a very poor engineering decision because patients can change their minds about the requested restrictions, and this change may be frequent. Such a change would require re-labeling potentially a large volume of data belonging to that patient according to the new rules and this will have to happen again every time the patient’s preferences and restrictions change.

In most cases, requested restrictions (that are in nature a type of ‘policy’) should be persisted and maintained separately from the data, for example, in the form of FHIR Consent resources. This policy should be consulted at the time of sharing or using the data to ensure that latest version of the policy is enforced.

Interoperable Security Labels are the crux of interoperable DS4P and consent enforcement

Standard labels provide a vocabulary for expressing granular patient-requested restrictions and privacy preferences (and also other types of policies). While consent enforcement and segmentation methods can be proprietary, these labels need to be standard and interoperable in order to ensure a consistent interpretation and enforcement of consent rules in different organizations. For example, when a patient expresses a restriction about sharing of information related to substance use treatment, the code for referring to this type of data (which will be used in articulating this rule) must be consistently recognized and understood (both syntactically and semantically) by all the providers who are processing this patient’s data.

Agreement on the meaning of security labels is crucial in establishing an interoperable consent management ecosystem in which patients can author their preferences with a consent management service of their choice and have these preferences applied across different providers, rather than having to record, and perhaps repeat, their requested restrictions with every provider.

We need to start with a small well-defined subset of Security Labels

The FHIR DS4P IG provides the latest value sets for different types of security labels that are now incorporated into the HL7 terminology. This should supersede other, older value sets defined in previous standards (such as the vocabulary defined in the supplement of HL7 HCS).

However, there is a rather large number of codes in these value sets; some of these codes may not have clear-enough definitions for consistent implementation; some may not be a priority in common use cases, and some may even be outdated or replaced by newer codes. Large-scale implementation of DS4P requires identifying and adopting a well-defined subset of these codes which is most pertinent to common use cases.

The basic confidentiality labels:

• unclassified (U),
• restricted (R), and
• normal (N),

as well as the sensitivity codes for common types of sensitive data recognized in US jurisdictions:

• mental health (MH),
• substance use disorder(SUD),
• sexual and reproductive health (SEX), and
• sexually transmitted disease (STD),

seem to be well-defined and stable and backed by well-understood regulations. I think the value set for general purpose of use also seems to be well-defined and stable.

Ultimately, this subset should be determined based on feedback from vendors and health IT policy experts and come with more extensive guidance on the precise meaning and use cases for each label to ensure a common and consistent understanding across different implementations.

Some existing specifications (such as the emerging IHE PCF IG) have proposed a subset of most-commonly-used security labels. I think, ideally, this subset should be be part of a future USCDI profile of the FHIR Consent resource.

Assigning Sensitivity Labels is complex

Sensitivity labels provide an abstract language for the patient to request restrictions about their sensitive data. Naming individual data items in restriction requests can be infeasibly onerous for the average patient who may not be fully knowledgeable about the information contained in each data item and its implications, or have the time and resources to comb through large volumes of data to request restrictions on sensitive information. So, rather than articulating restrictions about individual data items (e.g., “this diagnosis, that observation, and those medications”) the patient can request a broad restriction about an entire category of sensitive information (e.g., anything related to substance use history).

Unlike confidentiality labels that are a function of policies and rules applicable to the data, sensitivity labels are inherent to the content of the data. Therefore, it is often reasonable to assume they can be assigned and persisted without the need to update them as a result of a policy change –they only need to be updated if the content of the data item changes, for example, if a new line item is added to a prescription.

Since sensitivity labels are semantically connected to the clinical content of the data, determining whether a data item belongs to sensitive category may be somewhat subjective especially in edge cases. For example, whether a particular medication is indicative of substance use treatment could be a subject of disagreement among experts which can lead to different systems labeling that data differently.

To ensure a sufficient level of consistency, there should be at least some high-level and broad guidance on the underlying clinical concepts for each sensitivity class. This is necessary to ensure consistent enforcement of restrictions and rules that are based on sensitivity labels. Without such guidance, there is a risk of inconsistent application of sensitivity labels by different implementations and thereby inconsistent enforcement of policies. This could lead to circumstances where one provider chooses to release a data item as not sensitive, while other providers restrict access to the same data item. Such lack of consistency could undermine the trust of patients in the enforcement of their preferences, and in extreme cases, could create loopholes for leaking sensitive data and inference attacks.

Enforcement should be cross-paradigm

Health data, even residing with the same provider, may flow in different formats and via different protocols. So, it is important to ensure that patient-requested restrictions are enforced consistently at all of the gateways where data may flow. Currently, there is guidance for data segmentation for FHIR, for CDA, as well as for HL7 v2.9.

Note that patient-requested restrictions do not need to be captured in different formats for different environment; they can be captured as a FHIR Consent resource once, and then be enforced in different environments through an appropriate consent enforcement service, as demonstrated in the ONC LEAP Consent Project.

A maturity model can pave the way for incremental implementation

Achieving advanced data segmentation and consent enforcement requires implementing and orchestrating a complex set of services and it may not be feasible to do this in one phase. A maturity model can help vendors establish a roadmap for planning an incremental implementation. It also enables different implementers to consistently and accurately communicate the features and the maturity of their implementation.

A maturity model is a roadmap item for future versions of the FHIR DS4P Implementation Guide. The emerging IHE PCF Implementation Guide have proposed a model of maturity (basic, intermediate, and advanced) that is specific to the recording and enforcement of consents. There is also an unpublished draft document within the HL7 Security Workgroup archives that was a first attempt at defining a maturity model for both Security Labeling Services (SLS) and consumers of security labels. I will publish a summary of this maturity model in a future post.