Tuesday, October 25, 2022

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


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)

Monday, October 24, 2022

IT-Infrastructure Fall 2022


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