IHE FHIR Privacy Consent IG

 IHE IT-Infrastructure has agreed to start a new work item on the topic of Privacy Consent, using FHIR. This minimally would be a re-evaluation of the use-cases in BPPC for use with FHIR Consent, but likely will go beyond that scope simply because of modern needs, modern toolings, and ease at which the FHIR Consent can support them.

I really don't want to call this new IHE-Profile "BPPCm", the BPPC acronym is hard enough to say without tacking on an 'm'.   What should this implementation guide be called? The inclusion of the technical solution (FHIR) is discouraged as it indicates a solution before the problem is identified. The name could be very generic, like Privacy Consent IG, but we do tend to indicate in the title the scope limits in the use-cases. 

Proposed Scope

Much like BPPC does for XDS community. This Implementation Guide (IG) would do for FHIR community. This IG could be used with MHDS, which already has some of the framework for more specific Consents, but BPPCm would be more complete than what is indicated in MHDS. This IG could also be used for organization use or community use beyond MHD/XDS, which would include use-cases like QEDm, and IPA. This would leverage BasicAudit to record access control decisions and recording of consents.

This IG would

• Define a set of privacy policies with canonical URI and/or code.
• Define a set of Consent patterns that are foundational.
• Define actors for creation/update of Consent, Registry of Consents, Decision actor, and Enforcement actor.

See article - https://healthcaresecprivacy.blogspot.com/2022/05/explaining-fhir-consent-examples.html and - https://healthcaresecprivacy.blogspot.com/2019/11/fhir-consent-mapped-with-bppc.html

Use-cases

This section includes explanation of some example scenarios and points at example Consent resources for them. These example scenarios are provided for educational use only, they are not an endorsement of these scenarios.

Consent Policy

some policy URI could be defined for common consent terms. Not clear that these will be detailed enough to use in practice, but would be useful categorization of policy types.

• Explicit Permit (patient elects to have some information shared) is required which enables document sharing
• Explicit Deny (patient elects to not have information shared) stops all document sharing
• Implicit Permit allows for document sharing
• Explicit Deny of sharing outside of use in local care events, but does allow emergency override
• Explicit Deny of sharing outside of use in local care events, but without emergency override
• Explicit Permit authorization captured that allows specific research project
• Change the consent policy (e.g., change from Permit to Deny)

In each of these cases the provisions of the instance of Consent could further constrain.

Notice of Privacy Policy

Some realms only require that the patient be given access to the organizations privacy policy. In these realms the patient is not given the choice to accept, reject, or change the terms of privacy policy. The expectation is that the patient can stop the engagement with the healthcare provider if they don't like the privacy policy (yes, we know this is a fallacy in many situations).

Basic signed acknowledgement

This section covers the most basic of privacy consents, that simply records an acknowledgement to a given privacy policy permitting data sharing. This is only slightly different than the Notice of Privacy Policy, in that with this example, there is some evidence captured from the ceremony. Such as a patient initialing or signing a form indicating they have received the Privacy Policy. Similar to the Notice of Privacy Policy, the Patient is not given a choice to reject or change the terms of the privacy policy. The specific version of privacy policy recorded can also be helpful to know when a given patient needs to be presented with the new version of the privacy policy.

Change to deny sharing

This section covers the case where a basic permit has been used, but for some reason the authorization is revoked or rejected. An example might be where the organization does allow the patient to reject a previously permitted action, and the patient has expressed they want to deny sharing now. Another example might be where legal action has happened compelling an organization to revoke the consent.

Some patient specific provisions

Authorizing or Denying access to:

• who by a given Practitioner, CareTeam, RelatedPerson
• why by a given Purpose Of Event codeswhy by a given named Research projects
• data by Confidentiality class (Normal, but not Restricted) -- presumes a mature SLSdata by sensitivity class -- presumes a mature SLS
• data by authored timeframe
• data by authorship (authored by someone in organization XYZ)
• data by identifier (explicit reference)
• when specific period of time data can be accessed

Not likely to be in scope

These seem to be possible with Consent resource in R4, but not clear they are priority or even possible.

• Use of Consent besides Privacy (consent to treat, advanced directives)
• .action -- this is not well enough defined in Consent
• applied obligations or refrains -- no clear place where these go in Consent
• .class -- this is not well enough defined in Consent
• data related to an identified data resource (e.g. all data related to this Encounter)

IT-Infrastructure Fall 2022

Releases 

Four publications released from IHE IT-Infrastructure, one in Public Comment

• Release for Public-Comment -- Mobile access to Health Document (MHD) - Improvements
• changed to AuditEvent profiling leveraging Basic Audit Log Patterns (BALP) Release 1.1
• changes to RESTful type, and query subtype
• Added new features
• Add a Generate Metadata that adds the ITI-106 operation that allows for one structured/coded document to be published.
• Add a Simplified Publish option that allows for one DocumentReference with the document in the .data element to be published, expecting the Document Recipient to create the SubmissionSet derived off of the DocumentReference and Community mapping policy.
• Add an ITI-65 FHIR Documents Publish option with support in ITI-65 to include a FHIR Document Bundle as an alternative to Binary. This makes less the burden on the Document Source to serialize the content into an appropriate Binary format, as that requirement is moved to the Document Recipient. There are use-cases where the Document Recipient will use the FHIR Document Bundle directly, and there are requirements on the Document Recipient to serialize the FHIR Document Bundle when grouped with non-FHIR Actors like XDS/XDR/XDM.
• Each of these new options may survive or may be removed. Please voice your interest, and sign up for IHE-Connectathon to test these options. Based on interest these Options may survive or be removed.
• better clarity on types of Identifier 
• a method has been added to support DocumentReference replace that is used by the Document Source to mark the old/replaced DocumentReference instance as superseded.
• Patch release -- Basic Audit Log Patterns (BALP) Release 1.1.1
• There are no functional changes or breaking changes. This release is primarily to address validation messages that have been made more strict by HL7 than when 1.1.0 was released.
• clarify explanation of each structureDefinition profile
• cleanup examples with explicit slice use to eliminate validation warnings
• add some oAuth AuditEvent examples
• fix the Actor definitions
• switch to new IHE template
• Trial Implementation - Sharing Valuesets, Codes, and Maps (SVCM) Release 1.5.0
• Converted from PDF to a FHIR IG. 
• Added in conformance resources and Basic AuditAudit events with examples. 
• Clarified the use of business identifiers.
• Trial Implementation - Secure Retrieve (SeR) Release 2.1
• Expanded scope of services that can be secured beyond XDS Retrieve

These releases are continued improvement and advancement of the Document Sharing Health Information Exchange, and enabling of Community exchanges that are more than Document Sharing. Very focused on #FHIR, but also enabled by existing and successful XDS/XCA Health Information Exchange.

In development

The IT-Infrastructure committee is continuing to advance the state of the art. There are three specifications in development at this time.

• New Implementation Guide on Scheduling (aka calendar). This work item is taking lessons learned from the Argonaut project on scheduling that has stalled at STU3. The work is in cooperation with the Argonaut project approval. The project is focusing on simple appointments with proposed #FHIR Operations for finding appointment slots, holding an appointment slot, and booking an appointment slot. Current committee draft
• A whitepaper that focuses on how various Health Information Exchange topologies can be architected. Indicating the various design decisions, with benefits and drawbacks. These topologies that will be described will start with simple single-depth, but will be more focused on the complexity as multiple-depth networks are needed and where various sub-networks have different architectures. Current committee draft
• XCPD Revoke Transaction - This was a CP, but has become a work item due to the scale of the changes -- The XCPD Health Data Locator and Revoke Option supplement adds a Revoke message to ITI-55. The Revoke message is really an entirely separate message, with its own Message Semantics, Trigger Events, Expected Actions, etc. separate from the main Cross Gateway Patient Discovery message in ITI-55. Therefore, it would make more sense for the supplement to introduce this message as its own transaction rather than add it on to ITI-55.
• A FHIR centered Patient Privacy Consents Implementation Guide -- The name of this will be determined sometime in the future after the set of use-cases are decided upon. Initial scope is to replicate the BPPC functionality except using FHIR Consent rather than CDA. There may be some of APPC brought in given the functionality of FHIR Consent. Thus the use-cases would tend to be around the same Consent functionality at controlling HIE access to Document scoped data. Future versions might expand to data scope at the FHIR resource level.

I welcome participation in IT-Infrastructure to help with these work items, and propose work items of your own. IHE is a much lower overhead than HL7, yet focuses on producing tightly conformance specifications that are formally tested at IHE-Connectathon.

Future projects

Some potential next projects, based on interest and resources:

• Profiling of $match for Patient lookup
• Federating MHDS communities (using XCA or not)
• Converting more of the existing FHIR Profiles to IG format
• mXDE
• QEDm (not formally an ITI project, but we touched it last)
• RESTful ATNA
• NPFS
• mACM
• Impact of the HL7 Gender Harmony IG on ITI profiles
• Broader workflows such as 
• Maternal Health full care flows using HIE
• EMS full care flows using HIE
• Social Determinants of Health full care flows using HIE

Security Labeling Service

Data may be “Normal” medical data or “Restricted” medical data. The distinction is for this IG focused purely on data classification for sensitive topics.

The various clinical Resources in FHIR are very complex and highly variable. Although Observation is the most often used Resource, sensitive data may exist in ANY other FHIR resource including Allergies, Procedures, CarePlan, Medication, Problems, DiagnosticReport, DocumentReference, ImagingStudy, Genomics, etc… By assessing the sensitivity classification and placing that assessment into a well-known location found in all FHIR Resources - .meta.security, the Access Control does not need to be aware of the kind of FHIR Resource, it can just process the data as a DomainResource and simply look at the .meta.security element.

The classification of data into sensitive topcs is the role of the Security Labeling Service (SLS). The SLS inspects the data, and may use the context of the data to identify the sensitivity classification. It is expected that most data will not be considered sensitive, aka “Normal”.

Data tagging Considerations

Some data are direct and clearly in a sensitive category. But there can be indirect relationships, such as three medications prescribed together are a clear indication of a sensitive category but are not individually.

Some data may also not be sensitive in the coding, but rather sensitive in the narrative, this would be poor data quality but it is a reality that should be considered. Thus an SLS may need to include some Natural Language Processing to find sensitive human words in narrative.

Some approaches use well-defined ValueSets, where others use a list of words. The list of words can be search across the data without regard for the data structure, which has the benefit of not needing to have the SLS data schema aware. The list of words can be codes, such as snomed numeric codes.

Architecture approaches to data tagging

When the SLS is executed is a systems design decision. General alternatives are:

Pre Tagging data

Tagging the data as it is created, updated, or imported.

Which has the advantage that the access to the data does not need to assess the data, it just uses the existing sensitivity tag.

This solution is likely to be more performant on use of data, but may not have as accurate sensitivity tags due to the dynamic nature of policies around sensitivity, and dynamic nature of data relationships. This solution also requires that the EHR database support data tags.
Use time tagging data

Alternative is that the data are temporarily tagged prior to use, thus the sensitivity is freshly determined and used only for that access enforcement

This solution does not require that the EHR database be updated to support tagging of data, but may incur a performance impact on data use.

Example ValueSets

One way to understand a very basic SLS is that it looks for clinical codes in the data. It might do this using ValueSets, but likely would need to do this in a more performing way.

There are some valueSets that were authored 9 years ago by SAMSA (requires a free login to see the details). This was during a critical point in the early development of the use of Security Labeling. These valueSets are old, but they are informative. Any standards based managed ValueSet would need to be used as input to a organizational use in an SLS. So the fact these are 9 years old is not as important as that they are a well informed base to start with. I have put the SAMSA valuesets into some ValueSets of my own. 

• Set of codes that indicate ETH
• Set of codes that indicate PSY
• Set of codes that indicate SEX
• Set of codes that indicate HIV

Example Data with tags

• Observation of Alcohol Use marked with ETH
• Observation of a Blood Sugar not marked sensitive

MHD Document Responder: patient.identifier chaining

This is a quick article on a requirement of the MHD Document Responder that may be less obvious to some. The specific requirement is related to chained search parameters, like `patient.identifier`;  `source.given` and `source.family`; and `author.given` and `author.family`. These search parameters have a `.` that indicates that one is to search deeper, aka chaining the search value to a different kind of resource and use the results in the primary search.

The requirement is hinted at being special with a mention of FHIR Chaining Parameters:

This use of patient.identifier follows the FHIR Chaining Parameters search methodology.

But these hints might not be enough, because they do not tell you how to solve the requirement, and this is because there are many ways to solve this, and the implementation details of your system are more important than any factor.

The hints just indicate that the parameter provided is to be matched in a chained way. For example with patient.identifier the parameter is an identifier that should be first looked up with the Patient Identity Manager to find the Patient resource that is then used to find the DocumentReference resources.

That hint tells the Document Responder, that when the Document Source chooses to use `patient.identifier` rather than `patient`; that the Document Source is expecting the Document Responder to do this lookup, rather than the Document Source to do that very same lookup. So, it seems reasonable that queries using chained search parameters might be slower than those that are not.

There are cases where this is inverted, such as when the MHD has an XDS or XCA backend; in these cases the use of patient.identifier that is from the Affinity Domain or Community is better than providing the Patient link. As when a Patient link is the search parameter then a MHD front end to XDS or XCA would need to convert the patient link into the Affinity Domain or Community. This case is likely to be a system such that the Document Responder can quickly do this lookup.

Another place where patient.identifier is going to be preferred are environments that have a national patient identifier. In these cases the national patient identifier is more readily available to both Document Consumer and Document Responder. In these cases it is possible that the DocumentReference.subject element could hold both the Patient id link and the national patient identifier.

The chaining of given name and last name are similar but different in how one must support them on the Document Responder given the system design you have.

eConsent standards

 As with any standard, one more is clearly needed. 

as to the different Consent Standards.. I likely don't know about all of them, but here are some. I am also not indicating that there should be no improvement or even new standards. I just don't want historic lessons-learned to be lost.

for use in Document Sharing exchanges like XDS/XCA/XDR/XDM/MHD/MHDS

• IHE - Basic Patient Privacy Consent - https://profiles.ihe.net/ITI/TF/Volume1/ch-19.html
• IHE - Advanced Patient Privacy Consent - https://profiles.ihe.net/ITI/TF/Volume1/ch-43.html

This fall I hope to get a FHIR Consent - basic patient privacy project going.

There is an orchestration of various things referred to as Point-of-Care, which is an interaction model using BPPC and XUA - https://healthcaresecprivacy.blogspot.com/2017/01/enabling-point-of-care-consent.html

- this is part of CareQuality, and is built into Epic's CareEverywhere

The FHIR Consent - http://hl7.org/fhir/consent.html FHIR Consent is rich to be profiled. 

There are some projects that claim to be profiling Consent, but they are not yet published.

There is work in FHIR to add a Permission Resource. This would possibly be used by Consent in the future, but that future is likely 5 years out - http://build.fhir.org/permission.html

There is also the OpenID - UMA - HEART - https://openid.net/wg/heart/

There is a broader (beyond healthcare) project in Kantara to support a Consent Receipt

 -- https://healthcaresecprivacy.blogspot.com/2018/03/fhir-consent-resource-mapping-to.html

surely I missed something? Please comment or email me.

Quick intro to BasicAudit IG

 

IHE IT-Infrastructure Summer 2022

 Four publications released from IHE IT-Infrastructure, three in development:

• Release for Public-Comment -- Sharing of Valuesets, Codes, and Maps (SVCM) -- This is now published in Implementation Guide format, previously in PDF supplement format. This IHE-Profile (aka Implementation Guide) provides guidance on how to implement the sharing of terminology ValueSets, CodeSystems, and ConceptMaps. It is not a full Terminology Service, just the basic starting point that can be used to get a Community aligned.
• Release for Public-Commet -- Secure Retrieve (SeR) -- This is now a html publication, previously in PDF format. In addition to the conversion, the scope of the Access Control Decision and Enforcement is expanded beyond the Document Repository to the other services in a Health Information Exchange -- Community. 
• Release to Trial-Implementation -- Patient Master Identity Registry (PMIR) -- This is newly converted to Implementation Guide format, previously in PDF supplement format. The release recognizes the reconciliation of public comment. This IHE-Profile (aka Implementation Guide) provides for a Health Information Exchange Community to cooperate on a golden (master) identity for the Patients. This is distinct from a PIXm, which is a Community cooperation on cross-references of many identities for each patient. The PMIR does not forbid local participants from having their own internal identifier for patients, but rather expects that organization utilize the Community agreed to Patient Identity when communicating outside the organization.
• Release to Trial-Implementation -- Mobile Care Services Discovery (mCSD) -- This release is in Implementation Guide format, and has also been improved to support Communities using a variety of network topologies. The mCSD provides a Directory/Registry feature to enable a Community and/or Cross-Community discovery of Organizations, Facilities, Locations, and Endpoints.

These releases are continued improvement and advancement of the Document Sharing Health Information Exchange, and enabling of Community exchanges that are more than Document Sharing. Very focused on #FHIR, but also enabled by existing and successful XDS/XCA Health Information Exchange.

In development

The IT-Infrastructure committee is continuing to advance the state of the art. There are three specifications in development at this time.

• Improvement to Mobile Health Documents (MHD) to support more simple Document Source applications. Recognition that the current methods for Publishing or Pushing documents is not always needed to be fully implemented in Document Source actors. Thus there is developments to support a more Simplified Publish, an operation that will extract the metadata out of a well-formed CDA or FHIR-Document, and a few more clarifications. Current committee draft
• New Implementation Guide on Scheduling (aka calendar). This work item is taking lessons learned from the Argonaut project on scheduling that has stalled at STU3. The work is in cooperation with the Argonaut project approval. The project is focusing on simple appointments with proposed #FHIR Operations for finding appointment slots, holding an appointment slot, and booking an appointment slot. Current committee draft
• A whitepaper that focuses on how various Health Information Exchange topologies can be architected. Indicating the various design decisions, with benefits and drawbacks. These topologies that will be described will start with simple single-depth, but will be more focused on the complexity as multiple-depth networks are needed and where various sub-networks have different architectures.

I welcome participation in IT-Infrastructure to help with these work items, and propose work items of your own. IHE is a much lower overhead than HL7, yet focuses on producing tightly conformance specifications that are formally tested at IHE-Connectathon.

Future projects

Some potential next projects, based on interest and resources:

• Basic Patient Privacy Consents on FHIR
• Profiling of $match for Patient lookup 
• Federating MHDS communities
• etc.