Monday, August 22, 2022

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
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

surely I missed something? Please comment or email me.


Saturday, August 13, 2022

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.

Tuesday, August 9, 2022

Break-Glass

 I was asked to explain how Break-Glass works. There is not a solitary answer, as the context is very important.

Define Break-Glass 

A method used by authorized clinical people to gain access to information that the patient has indicated they want held more confidential, when that clinician has made a medical assessment that there is a safety concern that the confidential information may help shed light.


  • Used only in Treatment use-cases. It would be inappropriate for a Billing/Payment use-case to invoke Break-Glass. 
  • Not the Emergency-Room use-case. The Emergency-Room tends to focus on stabilizing the patient and this can often be done in complete absence of historic data. Further when data are available, the clinicians in the Emergency-Room tend to already be operating at elevated privilege.
  • Used only by authorized users. Not all clinicians are going to be given this authority.
  • Medical safety concern. The clinician is expected to be making a medical safety decision. This concern is often gathered as rational for invoking Break-Glass.
  • Post analysis. Break-Glass events should happen very rarely, but when they do the Audit Log must be relied upon to provide transparency to the activities. Thus, the Audit Log might be more detailed during a Break-Glass activity. The activity of Break-Glass should cause a post analysis, where the Audit Log is examined for if the declaration of Break-Glass was necessary and appropriate.
  • Patient Privacy Consent restricts some data for Treatment. Note that if no restrictions for Treatment are given, then Break-Glass doesn't apply as it would result in no additional data access.
    • Patient Privacy Consent does not forbid Break-Glass. There are some settings where it is allowed for a patient to indicate they would rather suffer safety concerns than have the data exposed. Most settings don't allow this kind of thing, trusting their clinicians more.

So, by this point we know there this is a use-case where break-glass applies, the patient has authorized break-glass, there is a need to blind some information from this clinician, and that the clinician does possess the permission to declare break-glass; so it is only now that we need to do something special.
 
historic article from 2015  

Solution Considerations:

In general there are a variety of ways to solve. 

  • Internal logic of the EHR. If the use-case does not need to extend outside of the EHR, then there is no need for a standardized solution.
  • Some workflow mechanism. It is possible for Break-Glass to be supported in ways that have nothing to do with the Security layer. These solutions tend to treat Break-Glass as a pathway thru the other clinical flows. 
Thus for Security layer solutions tend to focus on use of
  • PurposeOfUse of BTG (Break-the-Glass). Typically, clinical flows use TREAT as the PurposeOfUse to indicate the request is triggered by a normal treatment use-case and that the data returned would be used for normal treatment use-cases. The BTG would be an additional PurposeOfUse to indicate that Break-Glass has been appropriately declared.

How BTG is declared is covered below...

How does User know Break-Glass could be used?

This section is looking at how the user would know that Break-Glass 'could' be used. In theory, the non-authorized users would not be told that there are data that are blinded to them. Thus, only the users that hold the authority to declare Break-Glass would be notified that there are data that are blinded to them under normal treatment.
  • It is possible that there is no feedback mechanism. Thus, those with the authority to Break-Glass would simply declare Break-Glass when they "felt" that data might be being blinded that might have some impact on safety. 
    • The advantage of this is that the clinician is never presented with some indication. There have been incidents that some clinicians overly focus on the blinded data if they know that there are data that are blinded.
    • The disadvantage of this is that unnecessary Break-Glass events will be declared. This disrupts the clinician's flow, forcing them to detect if the Break-Glass action gave them more data or not; and causes safety / privacy investigation of many Break-Glass actions.
    • An advantage is that this does not require any additional detection logic on normal transaction requests, and does not have an atypical response.
    • This approach might be useful as a steppingstone to a more mature solution. 
  • FHIR OperationOutcome. All responses to requests in FHIR can carry a OperationOutcome. The OperationOutcome could indicate that BTG could be used. This would be indicated with an issue in the OperationOutcome that is clearly just information / informational. But would require that there be some yet-to-be-defined code to indicate that Break-Glass may be useful
  • The FHIR Bundle that is returned might have a Bundle.meta.security tag that indicates that some data were redacted (REDACTED). This is a Bundle security tag, as it is about the transaction results, and not about any specific data inside the Bundle (actually about data not in the Bundle). This tag would not be included for those users not authorized to declare Break-Glass.
  • There might be a service request to see if data are blinded. Might be a simple service that returns true if some blinding rules are found in the patient's Consent. 
    • With OAuth, if the JWT was exposed (possibly thru an introspection API), then the conditions in the JWT might indicate if blinding rules are expected to be applied. This does not indicate they were needed to be applied, just that there are residual obligations to be enforced at the Resource Server / Enforcement Point.
  • ???? I don't know of another method. There might be something in http? I don't know of anything that would be linked to OAuth or any profile of OAuth.

FHIR Technical Solutions for declaring Break-Glass

At this point we know that the clinical user has the rights to declare Break-Glass, and has come to some clinical decision that it is appropriate to invoke Break-Glass. I think this looks different in the case of an end-user app accessing data via FHIR, from a clinical organization requesting healthcare data from another clinical organization.

Business-to-Business

In the case of Business-to-Business, where both businesses are part of a Trust-Framework that has enabled Federated Access Control, the initiating organization would have some logic within that organization that checks that their user is authorized to Break-Glass, and some mechanism for that user to declare Break-Glass. Thus in the Business-to-Business use-case the only thing that gets exposed at the Interoperability layer is that the requesting organization security token needs to look different for normal Treatment from Break-Glass. This nicely fits in the PurposeOfUse.
  1. OAuth. The OAuth flow could provide the User-Interface that the Clinician uses to request and get Break-Glass permission. The token issued would indicate normal or break-glass in some token opaque way (many tokens are opaque to all but the OAuth authority and the resource-service enforcement).
    • OAuth using the BTG PurposeOfUse. There are JWT mechanisms for encoding PurposeOfUse in the JWT in the IHE Implementation Guide on using OAuth with FHIR.
  2. SAML. Predating the use of OAuth is the use of SAML within nationwide health exchanges (XDS/XCA using SOAP). In the SAML flow it has always been one organization declaring the context of their request to the other organization. This SAML assertion would include the user identity that triggered the event, but the request authorization was always an organizational request. These SAML assertions relied on PurposeOfUse to set much of the context. And thus the use of BTG (or historically ETREAT) was the indicator for Break-Glass.
  3. Break-Glass service. It is possible to have a workflow mechanism that is invoked to indicate that Break-Glass is being invoked. This would not involve the security layer. This would require some state management at the server side.
    • An advantage of this is also that the declaration of Break-Glass is later followed by a return to normal. Which tends to follow the flow seen at the Clinician side, meaning the clinician is not exposed to each FHIR request/response; they are presented with a set of data retrieved over many FHIR request/responses; they then declare a Break-Glass and then more FHIR request/responses happen. 
    • It is possible this is simply an AuditEvent that indicates that Break-Glass is declared. Thus the Enforcement Point would look to AuditEvent for a Break-Glass declaration that is outstanding.
    • It is also possible that some other FHIR Resource is used.
    • It is also possible that no FHIR Resource is used, but some non-FHIR mechanism
    • Possibly OAuth Authorization Decision point 
  4. http header as outlined in FHIR Core on the Security Labels page. This mechanism uses a web category draft IETF standard. This also uses the PurposeOfUse vocabulary. 
    • This mechanism is not using security mechanism, so it should not be seen as a security solution. It would be very easy to hack the FHIR API to add this.
    • Note this solution could also be used to carry the other PurposeOfUse indiators, like TREAT

End-User-Client

I separate this as End-User-Client often are more driven by the OAuth authorization service. I think that most of the Business-to-Business solutions can happen here. I simply think that the OAuth authorization service might get more involved in the User Experience at declaring Break-Glass, capturing the reason for the Break-Glass.  I am not clear on how the user / app would indicate to the OAuth authorization service that a Break-Glass UX should be brought forward. I look to OAuth experts on that front.

Conclusion

I am so sorry that there is not one solution. I assert that the reason there is not one clear solution has to do with the very fact that there is not much discussion of this flow in public spaces. I think that if there were a public discussion, we could eliminate some of these with rational as to why they are not as good as others, and likely come up with solutions I have not thought of.