IHE IT-Infrastructure Summer 2024

 This summer IHE IT-Infrastructure has been working on three very different work items. All are very clear IT-Infrastructure scoped projects, but two of them are very new territory.

Document Digital Signature - JSON signature option

This work item is updating a long standing, and "Final Text" profile, the Document Digital Signature (DSG). The original DSG used XML-Signature standards, as that was the signature standard of choice back then. This original DSG is still available, as there are environments that want to use XML-Signature standards. 

With the XML-Signature we additionally leveraged the profiling of the XML-Signature standard done by ETSI in the XAdES-X-L standard profile for Long Term signatures. Using Long Term signatures as Documents in an HIE (aka Document Sharing) would tend to be available for a long time, and over a broad distance. 

The new work is to add an Option that uses the JSON Signature standards. The JSON Signature standards are getting mature and are gaining in interest. One of the key milestones for us is that ETSI has released their Long Term signature profile of the JSON Signature - JAdES-B-LT.

This work item has been out for Public-Comment. We are still trying to work out some specific details about how IHE Document entries are to be indicated in the JSON Signature. As part of this we will be providing examples and pointing at some code that people could use.

The details are in the supplement that is still available for review and comment.

Finance and Insurance Service (FAIS)

The Finance and Insurance Service (FAIS) stores, categorizes, and facilitates the administration of centralized claims and finance related data to care provision to patients within the HIE. The service receives claims/financial data from Point of Service applications (including financing applications acting as a point of service interface outside of other PoS systems) and curates the management of them.

This collection of workflows allows an external system to save and retrieve Finance and Insurance Information. The workflows are designed to support the following types of data exchanges with systems.

1. A point-of-care system can enroll a beneficiary
2. A point-of-care system can check a beneficiary’s eligibility
3. A point-of-care system can run a pre-determination, pre-authorization and claim
4. A point-of-care system can track a claim’s status

This is a very new ground for IHE and is coming from the emerging markets where they have this need and don't have existing solutions. 

This should be available for Public-Comment in the coming weeks at the IHE IT-Infrastructure Public Comment section

Scheduling

The IHE FHIR Scheduling Profile is a specification providing FHIR APIs and guidance for access to and booking of appointments for patients by both patient and practitioner end users. This specification is based on FHIR Version 4.0.1 and specifically the Schedule, Slot, and Appointment resources.

This work item is based on the previous work of the Argonaut Project.  This is an evolution in cooperation with the Argonaut Project.  The following are some of the major differences from the Argonaut IG:

• The IHE Profile is based on FHIR R4
• The IHE Profile is intended for international use, and it does not have required bindings or any dependencies to national profiles
• The operations described are $find, $hold, and $book
• A separate transaction describes the use of FHIR Search for the Appointment resource

This should be available for Public-Comment in the coming weeks at the IHE IT-Infrastructure Public Comment section

New Projects

Given that all of the current work items are in Public-Comment, and that we still need to resolve any comments we get, we are being conservative at adding new projects. 

Sharing Verifiable Health Links

This said we are picking up a new work item proposed by the WHO (Who brought the DSG JSON, and Finance projects). This new work items are also backed by Canada and Australia. The new work item looks to profile a portable Verifiable Health Link, to enable patients to provide specific access to their current health data, such as an International Patient Summary (IPS). 

This project will leverage other IT-Infrastructure profiles where appropriate, such as MHD and sIPS.

Ongoing Projects - aka Important Change Proposal work

• Integrating the Sex and Gender support into the existing appropriate Profiles, such as PDQ/PDQm.
• Increasing support in XCA and XCPD for searches to be targeted to a given home community, so as to limit the unintended visibility of searches (aka Privacy). 

Mention simply because it was my contribution (QEDm)

PCC will be publishing for Public-Comment the conversion of the Query for Existing Data for mobile (QEDm) from a PDF publication to a full Implementation Guide. This should be very similar intent as the existing PDF, but as an IG is far more specific and includes examples. This also adjusted to the update that ITI made to mXDE last year regarding Provenance. This will be followed with efforts to build QEDm upon HL7 IPA in a future public-comment.

Watch PCC Public-Comment section for soon release of this

Join and Help

Please look to join IHE as a member, or benefactor. If these are not possible, then please do continue to watch for Public-Comment and help out with your comments. IHE does not require that you are a member in order to comment.

Consent is a small part of Overarching Policy

There is always so much focus on Consent, and Consent is highly important. But what often is missed is that Consent is just a portion of the overall policies that control the activities. The relationship to the Overarching policy is merely an element in the Consent Resource (Consent.policy), but that linkage is not simple. 

That linkage is contextual. Meaning the linkage involves all of the context in the Consent resource, such as who the patient subject is, and who the grantee is. Such as who is the organizational party that is equally agreeing to this Consent, and who is the custodian of the data that will be expected to enforce the terms. There are other context like dates, expirations, provisions, etc.

Therefore, within an organization there would be many thousands of Patient(s) and their Consent(s). So, we are getting closer to the topic of this article, the Overarching policy.

The Overarching policy is what I want to stress as being far more critical, and far less understood. This is not to say that those that write these 'corporate policies' don't know what they are doing, they surely do. These Overarching policies tend to be written by the legal division of an organization, and thus are exacting, long, and impossible for anyone other than the authors to understand. It is these overarching policies that are often the scorn of "Privacy Policy... yeah, I didn't read it". I can't solve that problem, as they are indeed very important to be exacting and comprehensive.

Comprehensive is a good word that I want to point out, because the topic I have had to explain multiple times in the past few weeks is that the Overarching policy MUST cover the normal activities but must also cover abnormal activities. Some so abnormal that they are covered simply by some section about how to handle abnormal activities not covered in the Overarching policy.

As you can see from my outline. The Overarching policy must explain how the organization is structured. Who are clinicians, what kind of clinicians have access to what kind of data. Who are employees / contractors that have limited access to data, such as food-service employees have access to patient allergy and careplan information that would affect what food they would serve. Where there are other employees / contractors, that have to the Patient resource and the scheduling so as to handle registration desk duties. These Roles and Clearances are important to define. These data access activities are important to define. 

Safety vs Privacy is an example of risk management that would need to be addressed. There needs to be rules as to who is allowed to say that safety risk is more important than a privacy violation, possibly using a Break-Glass mechanism. When break-glass is used, what remediation and followup is performed by the Safety and Privacy office to assure that the violation was acceptable?

Overarching Policy covers Consent decision impact

Last thing I want to point out is that the Overarching policy has sections in it that express

• The activities that are permitted or denied when there is no Consent on file
• The activities that are permitted or denied when there is a Permit Consent.
• The activities that are permitted or denied when there is a Deny Consent

That is to say that the definition of a Deny Consent is just as reliant on the Overarching policy explaining what is allowed as is a Permit or an absence of a Consent. For example, as with the absence of a Consent, the Deny Consent likely still authorizes Emergency Department minimal access to enable stabilizing of the patient. Such as being able to access allergies and medications to assure safety. This level of access is not the same as normal treatment would have access to, but it is not a complete blocking of life critical data. So it might not give the ED access to the total list of medications. 

This is all the kind of details that need to be considered when writing the Overarching Policy. For a deeper dive please see the IHE Privacy Consent on FHIR Appendix P

 

Enhancement of Patient Demographics Query for Mobile (PDQm) with FHIR $match operation

IHE has enhanced the Patient Demographics Query for Mobile (PDQm) with a FHIR $match operation to enable more powerful Patient identity matching to produce better matches and reduce false matches. The original search is still available and fits specific use-cases, where now the $match operation can be used as well. This presentation will introduce PDQm, and describe these two methods that are now available.

Why does IHE-XDS not have a Delete Document?

This also applies to IHE: MHD, MHDS, XDS, and XCA. To some extent it applies to normal use of FHIR R4 DocumentReference

The IHE Document Sharing model is focused on document lifecycle, and thus supports Create, Append, Transform, Replace, and Signs of a document. When an existing document is replaced with a new document, the Replace action is used. This marks the old document as superseded and the new document points to the old document (in XDS the Association Object is bidirectional, but in FHIR the new document points at the old). Thus, when someone finds the document they have, they can see that it has been replaced.

This is a well understood model when one thinks about a clinical document. That clinical document may have various revisions, each replacing the prior document. With a clinical document the final version is left available forever (or for as long as the legal persistence policy identifies). This is the typical lifecycle, that is that eventually one gets to a final version of the document.

However, there are some documents that need to be deleted / removed / revoked / deprecated / etc. Some examples:

• Basic Patient Privacy Consent -- when the consent is revoked by the patient
• Advanced Directives -- when the advanced directive is revoked by the patient
• Entered in Error -- when a document gets incorrectly registered, and needs to be removed because of this error

With only Replace, these needs seem to be unachievable in XDS/MHDS.

Native FHIR R4

In FHIR R4 DocumentReference one can set the status to entered-in-error, but there are two very important considerations

1. This status is not supported in XDS, so it is not going to interact properly with any exchange that uses IHE Document Sharing. I will cover this later in the section on Just delete it.
2. This status does not include any evidence for why the document is marked as entered-in-error.  Meaning that there is often a need to explain why it was marked as entered-in-error. 
3. The status of entered-in-error is reasonable when a mistake was made. But the first two use-cases are cases where the original publication was not an error, the change is to indicate removal.

In FHIR R4 DocumentReference one can set the status to superseded, but there are is an implication that it has been superseded by another DocumentReference. This is not a requirement, so it is not a problem.

One could use an extension in FHIR DocumentReference that can carry a more refined status code... but that is not going to guarantee that everyone understands it... And those extensions will not be understood by IHE Document Sharing transports. Most important is that the .status codes in the Event pattern does not have a 'deleted' status.

Just delete it

FHIR Resources can be deleted, provided policy allows. A Deleted resource can be handled in multiple ways. If the FHIR Server supports versions, it can mark the version as deleted in a way that one could retrieve the deleted resources. 

XDS does have some methods available for document delete - Remove Metadata and Documents (RMD). The problem with delete in XDS is similar in that it does not convey the deletion to those that might have used it before, and certainly doesn't understand why it was deleted.

Document Sharing -- Recommended Approach

In Document Sharing, one would Replace the current document with a new document. The new document likely will be a brief summary of why the document was revoked or replaced. This kind of a flavor of the document would need to be profiled anyway to support the use-cases.

The new document could be an empty document, provided the policy allows that. 

The new document metadata could be either

1. A variation of the original document, so that it is discoverable in the same way the original is discoverable
2. Very different metadata that clearly indicates deletion. 
3. A variation of original content to support some discoverability, but also clear indication of the deletion.

So, how can the Metadata (e.g. DocumentReference) look like to indicate to everyone that might have pulled the previous document?  Well, realistically the fact that the previous document was Replaced, is the signal to any previous uses of the previous document. 

But, should the Metadata (e.g. DocumentReference) be good to have an indication that the previous has been rejected and that there is no new content. Meaning, a way to send a terminal signal using just the Metadata?

• In pure FHIR, the DocumentReference.docStatus  could indicate this, especially in newer versions of FHIR (given that FHIR R4 has a very limited vocabulary on docStatus).
• However, this element is profiled out of IHE Document Sharing
• The DocumentReference.type or .category could be different to indicate this is a Terminal document; but this might make it harder to find. So likely these should be the same as the original.
• The DocumentReference.content.format is the indication of the profile / formatCode of the document content. If one defines a new profiled document for this use-case of a Terminal / Revoked / Removed document. Then one could put this value here.
• The DocumentReference.context.event is the MOST USEFUL. This in both FHIR and XDS is a general useable code. Thus any code can be put in here. 

So, use DocumentReference.context.event and define a specific code to indicate a Terminal state of the previous document. I don't know if there is a useable code, but likely there is a code in CDA. Or you could put the Composition Status code from the updated CodeSystemComposition Status code from the updated CodeSystem in here

Conclusion

So, my conclusion is

1. Use Replace, with some differently profiled document

2. This document would be defined to indicate the context of the Removal / Revocation / Rejection / etc.

3. This document would have a defined set of codes to use inside the document

4. This document would have a different FormatCode / profile

5. This document would profile the Metadata (e.g. DocumentReference) to indicate this terimal status document. This could be all of the above, but most likely would be the FormatCode and an Event code.

Meaning this is a normal use-case analysis that results in a specific profiled document that replaces the previous document. This will be understood in simple FHIR Server, and would be understood in XDS / XCA / MHDS. Thus it has the broadest useability and clarity.

FHIR Security and Privacy - Open Educational Session

For those going to HL7 WGM in Dallas. I will be available Wednesday afternoon in an open educational session on FHIR Security and Privacy:

The best case is that everyone that comes to the session would have reviewed the freely available recorded tutorial sessions, and/or the freely available slides; so that we can have discussions and solve the world's problems regarding FHIR Privacy and Security.

- Recorded session -- https://vimeo.com/853094845/671e02f6db

- My slide deck -- http://bit.ly/FHIR-SecPriv 

Bonus points if people come having reviewed my IHE Privacy Consent on FHIR webinar

Super excited if people come with FHIR Security and Privacy problems that I have not yet written about. I would love to come out of this session scratching my head and inspired to create more solutions.

Why does IHE-MHDS not have a Document Repository?

The IHE-MHDS does not define a Document Repository Actor but does include architecture support for distributed FHIR Servers and thus the concept of a Document Repository is included in MHDS. The MHDS profile specifies how a collection of IHE profiles can be used by communities for exchanging health information, which includes support for patient identification, health document location and retrieval, provider directories, and the protection of privacy and security https://profiles.ihe.net/ITI/MHDS.

The Document Repository and Document Registry is an architectural construct that is foundational to XDS, but not necessarily part of Document Sharing. For example: XCA also does not make a distinction between a Document Registry or Document Repository, having a Responding Gateway Actor.

The MHDS profile defines a Document Registry Actor that persists, manages, and provides access using the MHD access methods. This supports IHE Document Sharing as described in the Health Information Exchange: Enabling Document Sharing Using IHE Profiles White Paper. The central HIE infrastructure defined in MHDS profile might be a single FHIR Server implementing all the defined central service actors or may be a virtual cloud of systems implementing the defined profile actors.

IHE-MHDS does not define the Document Repository Actor, as the concept of a set of distributed FHIR Servers is very natural to REST architecture. Thus IHE did not add complexity by defining a formal Document Repository Actor, as the concept can be addressed naturally with REST. For more detail see the Storage of Binary section in the MHDS profile. This is also explained in the HIE Whitepaper in section 3.2 Centralized Discovery and Retrieve

If you're looking for details on the functionalities or its implementation, the MHDS Volume 1 documentation would be a good resource to explore further. It outlines the core business functions provided by the MHDS Profile, including the publication of document-based information, persistence and lifecycle management of documents, and patient identity management among others. For broader discussion on the Document Sharing concept the whitepaper is more inclusive.

recording of my IHE Privacy Consent on FHIR webinar

I thank Health Samurai for making the recording of the Access Control meetup sessions available. Here is my presentation, and from that you can find the others.