Sign all the FHIR IPS

The International Patient Summary (IPS) is gaining more and more visibility as it gets more mature. The IPS is a Document, and there is a definition for this document using CDA and using FHIR. The FHIR Document is the one most are interested in. At the technical level, they are equivalent, and they meet the same abstract definition defined by ISO/CEN. But FHIR is the hot new standard, so everyone wants to use it. More details on IPS background and process is available.

The IPS can be carried in all of the Document Sharing methods that IHE has available. This is explained in the IHE Sharing of IPS Implementation Guide. 

The IPS can also be carried by many other methods. Including where the patient just emails it, or uploads it, or otherwise shares it.

Is it Authentic

So, when an IPS is consumed, how does one know that it is authentic to what the author intended?

This could be simply trust in the transports that got the IPS to you. IHE Document Sharing includes trust frameworks. Most patients are not out to deceive, so they tend to provide authentic data.

But any method of getting you the content has the possibility of having 'trusted intermediaries' or 'malicious intermediaries'.  Some IPS may bounce around many places before getting to you. Anyone that is between you and the author have the possibility to change the content, so how can you detect a change?

CDA and FHIR Documents don't come with a form of integrity check. So, changing them along the way is easy.  The change might be an appropriate change, like adding consistent clinical codes to all the data so that it is easier to consume. These changes may be beneficial, or malicious. These changes might be appropriate, or dangerous. So detecting changes is important but not enough, see discussion at the end of this article.

Thus, how do you have "end-to-end", vs "point-to-point" trust?

Digital Signature

The only way to get end-to-end authenticity proof is to have Digital Signatures. A Digital Signature uses cryptographic algorithms, not to encrypt the content, but to provide a mathematic proof that the content you got is the content that was signed. It is important to know that a Digital Signature does not keep the content from being seen or copied; and there is no way to keep the Digital Signature from being removed. But if there is a Digital Signature available, then it can be used to validate that the content you got is exactly what was the content that was signed.

FHIR R4 has some Signature datatypes and recommendations. But there is very little experience with these, and there is not a defined way to sign a FHIR Document. That is to say that the 'canonicalization algorithms' that are defined for use with digital signatures do not exclude the Bundle.signature element, and thus will fail to work. This method of signing is a focus for FHIR R6, so experience and improvement.

IHE Document Digital Signature

IHE has a Document Digital Signature (DSG) profile that can be used to sign ANYTHING. Thus it can be used to sign a CDA document, and also a FHIR Document. The DSG has historically profiled XML-Signature but has now been updated with a profile JSON Signature. 

DSG is mostly used with IHE Document Sharing, where the document is shared normally and there is an association to the signature document. The signature document is either an XML-Signature or a JSON Signature. The signature technology has no relationship to the technology of the signed document. Thus, one can use JSON Signature to sign a CDA document, and you can use XML-Signature to sign a FHIR Document encoded in JSON. The signature is across the bytes that are stored of the signed document. Thus, there is no canonicalization of the signed document, just the serialization to put that document into Document Sharing. With this method, when you have a document received over Document Sharing, you can look for a SIGN association to find any signatures. You can then validate that signature against the document you received.

DSG also has options for enveloping of the document. This would tend to be used when Document Sharing is not used. In this method the signed document is enveloped within the Signature. The benefit is that the signature and document are in one object, thus less likely to be accidently lost. But, any use of the document must pull it out of the envelope, which makes use of the document significantly harder.

Long-Term Infrastructure 

The signing of a document is rather easy, many tools are available that can do these for you. The validating of a signature is also mostly easy, using available tools. 

The hard part is that when validating a signature, you MUST check the date/time stamp and validate that the signing certificate was valid at that date/time. 

And to support that, the PKI must be designed and managed to support this certificate validation well into the future. Thus, the signature must be able to meet "Long Term" requirements, and the certificate management must also meet "Long Term" requirements. This is unusual with Certificate Management today, which focuses on TLS (https) certificates that don't need to be remembered for decades.

Governance of Signing

It might be a good idea for all authors of IPS documents to sign them. However, this might also not be helpful overall. So, let's look at some factors involved in the signing.

• What is the meaning of the signature. The signature will/should include an indication of the intended type of the signature. Such as ProofOfOrigin, ProofOfCreation, Author's Signature, Source Signature, or Timestamp Signature.
• The signature may be applied by someone other than the author as an endorsement of the IPS content: Review Signature, Modification Signature, Addendum Signature, etc.
• What format of digital signature will be used and what encoding of the IPS will be signed. Any conversion of the IPS (e.g. from FHIR XML to FHIR JSON) will break any signature, thus you want to be sure to sign the encoding form that the recipient will get.

Governance of Validating

With Digital Signatures there is an important need for governance on how to handle receiving an IPS.

• Do you process an IPS that has no signature?
• Do you warn the user that there is no signature, but continue to process?
• Do you not validate the signature? 
• not unusual to only validate the signature when there is a specific need, such as a legal challenge.
• What do you do when a signature is present, but it is invalid?
• Do you not process the IPS at all?
• Do you allow the user to continue to process the IPS?

Authorized modifications

Any modification will break the signature. However, there are methods that can be used to support authorized modifications. 

When using IHE Document Sharing, the original document will still exist, and the modification can have an association with the original. This one can validate the original and new.

A more general solution would leverage the trust in the authorized modifier. This authorized modifier would be required to validate the signature of the content it consumes, and it would be required to place a signature on the new content. In this way the new signature on the new content is a proof of authenticity on the new content, and by way of the purpose of the signature it can also be viewed as a statement that the original signature was validated.  

This could be done using FHIR Provenance, but that is a much more detailed article.

Conclusions

This article started with an assertion that all IPS should be signed by the author of that IPS. I point out that the signing and validating technology is very mature; but that the long-term need presents special requirements for the PKI supporting the signing identities. 

One could rely on Document Sharing to provide the infrastructure for making the signatures available, or one could use enveloping signatures. The enveloping signatures add even more requirements regarding signature format, content encoding, content serialization, and content accessibility.

I have been involved in the Digital Signature domain for 30 years. Not much has changed in that time, but there is also no broad use of Digital Signatures as described above. This is because the infrastructure and governance are far more difficult and expensive than the benefit that signatures bring.  There are far more to it than I have expressed here. There is no shortcut, these are all needed.

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.

Updated 8/14/2024 to include published links

Announcements

• PCC - QEDm
• ITI - FAIS and Scheduling

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. 

The FAIS Implementation Guide

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

The Scheduling Implementation Guide

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 has published 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.

The QEDm Implementation Guide

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