Transitioning Federated HIE from XCA to FHIR Query

I already have one proposal for the transition from the current Federated Health Information Exchange to supporting FHIR, that is based on a transition from CDA to FHIR-Documents. In that proposal, I make it clear that this is NOT an end-state, but rather a method to more smoothly transition. A key point of a smooth transition is that it does not stop what is working today, but provides methods of supporting the future for those early adopters. That proposal recognizes that today the communication pathway is XDS/XCA, and that communications pathway is content agnostic, meaning it can carry a FHIR-Document just as well as a CDA, PDF, JPEG, or TEXT document. 

Note that just because the content being published is a "Document" does not mean that it must be consumed as a document. There are solutions such as the one from IHE (Mobile Cross-Enterprise Data Element Extraction - mXDE) that shows how to decompose documents into FHIR Resources, and provides for proper Provenance back to the source Documents.

Federated FHIR Resource Servers

In this article I am going to add another step to the smooth transition. In this article I am going to show how we can leverage much of the infrastructure that has been put into nationwide federation of health information exchanges, while enabling communication that is natively FHIR Query/Retrieve. In this proposal the data holder never creates a "Document", they provide a FHIR Server endpoint that can be queried. This idea of having a FHIR Server endpoint is not new, it is the fundamental first step of any data holder.

What is missing is a federation mechanism that enables someone who needs data to find who has that data. We still need some way to discover the patient identity as known by the various parties participating in the federation, and determine which parties have data about that patient. Once you know the FHIR Server endpoints that have data, and the Patient identity at that endpoint; then you just use normal FHIR Query.

Note that "just use normal FHIR Query" is skipping the Security and Privacy aspects... I will get to those later. I mostly think that this is already addressed by the various security and privacy projects; they just haven't seen enough use to figure out where federation fits.

Federated Patient Record Location

We already have a functioning Patient Record Location standard that is being used with XCA to find the patient identities and locations where data are. The standard is XCPD. This standard is mostly used between the various communities, so is not something that a client app needs to care about. Yes, it is based on HL7 v3, and uses SOAP. I recognize that this is a drawback. My point is more that this is functional today, and it gives us what we need. Further the HL7 v3 and SOAP standard better supports the scale of federation that we need, something that http REST does not.

So, if we accept that XCPD can continue to be used to discover patient identities and locations where data are, then how do we determine the FHIR Server address? This is an important question as XCPD provides a "homeCommunityID" as the location, and that is an OID.

Converting homeCommunityID into a FHIR Server address

Fortunately, we already have the solution to this problem. 

Today, with XCA, the homeCommunityID needs to be converted into the address of the XCA endpoint, and this done with a centrally managed Directory. This centrally managed Directory is already managed for the purposes of supporting XCA, so it is already in place. This centrally managed Directory is already founded on FHIR. Mostly the FHIR Resources: Organization, OrganizationAffiliation, Location, and Endpoint.

It is the Endpoint resource that we need to further refine. Whereas it is understood how to define an XCA endpoint; we just need to have a flavor of Endpoint profiled to show a FHIR Server endpoint. Once we have that, then the normal FHIR Server processing progresses. Looking at the FHIR Server metadata endpoint, and oAuth well-known details.

There is a very important Whitepaper by IHE on "Document Sharing Across Network Topologies", that like this article clarifies is more than just Document Sharing, but also FHIR Server endpoint. Video introduction.

Intermediate or Direct

Now for the smooth transition:

1. A data holder can express that they both have XCA and FHIR endpoints. They don't need to choose which one they support.
2. Value-Add intermediaries can be expressed in this Directory as the endpoint for a given set of Organizations. 
3. Value-Add intermediaries can also implement mXDE to provide the FHIR Server support on behalf of Organizations that are not yet ready to transition.
4. Those that want data simply use the Federation discovery methods to find the patient identities and locations for a given patient, then lookup in the directory the alternatives for how to get data from that location and choose the best solution for them.

Like with the previous proposal to transition from CDA to IPS; the transition here is driven more by those that want to consume data, supported by the infrastructure and the data holders.

Thanks to Joe Lamy (AEGIS) for dialog resulting in this article. 

Test Data - in production

 As FHIR systems get bigger and bigger, and support more and more clients... It is more and more important to have Test Data to use to assure that:

1. Your client is connected to the right server
2. Your client is properly connected to the oAuth service
3. Your client understands the profiled data

This could be done with a sandbox server that contains only test data, but this only can address #3. 

There is a security tag available in the HL7 ValueSets for Security tagging. 

* meta.security = http://terminology.hl7.org/CodeSystem/v3-ActReason#HTEST

HTEST -- Healthcare Test Data -- 

To perform one or more operations on information that is simulated or synthetic health data used for testing system capabilities outside of a production or operational system environment. *Usage Note:* Data marked with a HTEST security label enables an access control system to permit interfacing systems or end users provisioned with a clearance, which includes a HTEST purpose of use attribute, to test, verify, or validate that a system or application will operate in production as intended based on design specifications.

I use this tag in the Implementation Guides that I write to distinguish the examples I provide. In this way it is clear that this data is "know as example test data" and can't be confused with real patient data. I also expect that this tag is a clear flag to someone that might copy/paste these examples and pass them off as real data. I don't always use this tag, as sometimes it is a distraction from the message the example is trying to convey.

So, going back to the use-case above... If I have a production FHIR Server, I could include the test patients with test data in the real server. This does not mean you should not have a sandbox, you should still have sandboxes for testing prior to being an approved app. But once you have an app that is approved, this HTEST data would be used first to assure that they are well connected. Testing #1 and #2 in addition to #3.

This real server HTEST data can also be used on a regular basis to test connectivity. Might be used when the client or server system is booted, to make sure it is well connected. Or might be tested after the system is updated. Could be regularly tested. Could be used when there is a network failure detected. 

Note that HTEST is not just for server data, the client applications should also be testing their full CRUD abilities with test data. Thus creating new resources for the test patient, with the HTEST tag. Indeed, the Access Control should be sure that any data Created or Updated on test patients does have the HTEST tag. 

Note that HTEST data should also have full variability expected of real data. That is to say that if you support security/privacy sensitivity segmentation, then you should have variously distinguished sensitive data, and the test patient should have a complex Consent. If you have a real-time Security Labeling Service, it can be tested against this test data.

Note that Test Data should be reset on a regular and known schedule. Test Data is not just for sandboxes.

Where do I get 'the' IPS?

 At a panel discussion at the IHE-Connectathon there was much discussion about the new IPS specification. This is a new FHIR specification that expresses what a International Patient Summary (IPS) would look like. This is a FHIR-Document, much like a CDA Document, but using FHIR fundamentals rather than the HL7 v3 model that is the basis of CDA. The IPS is further designed to support modern informatics and health use-cases, so it is really closer to the C-CDA 

A question was asked of the panel... "Where do I get the IPS for a patient?"

The panel did an excellent job given an ad hoc question. I would like to further refine this.

There was one answer that was focused on an HIE architecture that collects all the data within a region, and thus can produce a current summary perspective of this collection of all that patients data within that region.

I think this approach to the question is missing a key point. The IPS is a specification of what a International Patient Summary would look like using the FHIR standard. The IPS is not a policy or procedure document for how the IPS data was acquired. Thus to ask this question is not really a question about IPS, but rather about policies and deployment decisions. The IPS specification did somewhat address the fact that the creator of the IPS might be human driven, or automated. The committee writing the IPS understood this scope focus. 

This question did bring up that there is a perspective on the IPS that is being seen as critical. That is that the author has a perspective on why they are creating the IPS. That is that the consumer has a specific need and that there are a diverse set of consumers all with very different needs, needs that can be in conflict.

Note that the Document Sharing exchanges can handle very well this new FHIR-Document. The design of XDS/XCA/MHDS are content preserving but content format agnostic.

I suspect that some IPS will be created much like a C-CDA is created today. As a report from a healthcare organization representing what that organization knows about the patient. It might be created by a Patient managed application based on the collection of the health information that the patient has collected. It might be created by a regional or vendor driven organization that covers a larger domain of scope. And it might be created by organizations that pull from these authors and further refine a broader focused IPS.

Critical to this maturity is a strong need to maintain basic Provenance on all data elements to enable de-duplication. We must agree to always include business identifiers that have ever been assigned to data elements. I call this basic provenance, in that the global unique identifier enables de-duplication.

#FHIR up the API Secure community

I have been invited to speak at the API Secure conference, a virtual event coming up in a few weeks. 

UPDATED: 3/14/2023 -- Here is my slide deck 

My goal is to inspire cybersecurity consulting organizations to help out the FHIR community secure their implementations. The cybersecurity community is a specialty knowledge base and has specialty tools to aid with the securing of APIs, and the proofing that the API implementation is secure. This specialty knowledge is really needed by the FHIR community.

This cybersecurity community is well aware of how to secure and validate RESTful APIs, what I intend to focus on is the opportunity presented by the FHIR specification. The value of the data is well worth making sure your implementation is provably secure. Understanding how the FHIR specification defines use of REST, can help focus appropriate use and possibility for abuse.

This event is hosted by Knight Events, as in Alissa Knight, who two years ago showed the FHIR community that there are plenty of ways in which implementers have failed to apply simple cybersecurity to their implementations of FHIR. Her research showed that there are well done implementations, especially the EHR vendors. 

I highly recommend those that are deploying FHIR products, especially servers but equally applications, involve cybersecurity experts. This might be a skill that you have within your organization but might not be. Even if you have cybersecurity experts, it is good to have occasional audits by other cybersecurity experts that might come with a different perspective and tools.

This is a virtual event, and I and Grahame spoke at last years API Secure conference.

I am also working on other events, such as one by HL7 on applying cybersecurity to FHIR I know that many are uncomfortable with talk of cybersecurity hacking and FHIR, but it is a reality. We either hack ourselves and improve our implementations, or our implementations WILL BE hacked and patient safety and privacy are harmed.

References to Standards need to recognize that Standard's Governance about Errata

When pointing at a standard, do we expect that that standard organization governance on patch / errata / CP releases are followed? It might be common knowledge that when we reference a standard, that we do expect that standard governance applies and thus if that standard organization approves what they consider an effective erratum, that it is effective within IHE as well. However, this may not be common knowledge. I fear that there are many that are interpreting a reference to a standard to be NOT including errata.

The case for Errata or Patch, are when the change is not considered by THAT Standards Organization as being a change that would not be considered a major or minor change. These tend to be clarifications of text, fixing of spelling and grammar, and other clarifications that do not impact the meaning of that standard. Clearly there is some change happening, else the errata would not exist, but it is the governance of that standards organization that the change is simply an errata or patch. Thus, this discussion is about to what degree do we trust the governance of the standards organization from which the standard we are referring to operates within?

For example: IETF RFC 7540, has Errata. IETF is nice in that on their RFC 7540 they indicate that "Errata Exists", not all standards orgs do this.

Same is true of many standards (including internal to IHE references).

• IHE calls these Change Proposals
• DICOM calls these Change Proposals
• IETF calls these errata
• W3C calls these Errata
• OASIS-OPEN calls them Errata but I didn't find an obvious description
• HL7 has errata
• etc

This is NOT a discussion around when the standards organization makes a Major or Minor change; only when it is a patch or errata release. There are different arguments that a Minor change might be acceptable, but this is not the discussion and there are plenty of minor version changes that are not appropriate for automatic recognition.

Hacking #FHIR for the benefit of the FHIR community

I am co-chair of the HL7 Security, and IHE IT-Infrastructure working groups. The dominant topic in my scope over the past 5 years has been Privacy and Security of FHIR.  I have three events that are being discussed in three different organizations, each with a different audience, but all with similar needs and goal. Everyone wants to do whatever we can do to help those implementing and deploying FHIR to do an excellent job at securing from cyber-attack, and assuring patient privacy is preserved.

HL7 is looking to develop a cybersecurity 'event' (likely virtual) that covers explaining the world of cybersecurity in FHIR, covering many of my HL7 FHIR Privacy and Security tutorial topics with expansion and hopefully some implementer explanation. Day 2 would be more hands-on, putting theory to practice, hopefully lead by some who have implemented Privacy and/or Security in products. As part of Day 2 we would like to have some production class systems available for hacking exercises.

As part of this hacking exercise, I am actively working with Alissa Knight, of past Hacking FHIR fame, to have a similar thing done at her general API cybersecurity conference -- APIsecure Conference: The world's first and only API security conference. Last year I presented, this year we want to go more hands-on.  I am also working with IHE-USA/HIMSS for a similar event.  Alissa has agreed to help out with the HL7 and IHE/HIMSS events.

These three hacking exercises do have different audiences with different goals, where the APIsecure conference are mature hackers that don't know FHIR, the HL7 event will be mature FHIR people that don't know hacking, and the HIMSS/IHE-USA will be a broader audience. The goal is to enable the general cybersecurity professionals to be ready to help FHIR implementations, the FHIR implementers to understand the need and methods, and the executives an understanding of the risk and potential.

These three hacking exercises need volunteer FHIR implementations (similar to Alissa's last hacking FHIR exercise). Those that offer up their systems will get details of any problems found, but the details and attribution will not be made public.  So, I am looking for vendors that have a FHIR Server implementation that are willing to provide an instance that can be put before the attackers, preferably a VM that can be restarted easily.

I am also looking for people to sign up to present or help create/review content.

The APIsecure conference is in March; the other two have no set dates at this time.

 

Are there open-source implementations of IHE XCA and XCPD?

 Amazing how hard this is to figure out. So I asked Chat GPT OpenAI

Are there open-source implementations of IHE XCA and XCPD?

IHE (Integrating the Healthcare Enterprise) XCA (Cross-Community Access) is a set of standards for securely exchanging patient healthcare information across different healthcare organizations and systems. IHE XCPD (Cross-Community Patient Discovery) is a standard for finding and retrieving patient healthcare information from different systems.

There are several open-source implementations of IHE XCA and XCPD available. Some examples include:

XCA Adapter: This is an open-source implementation of the IHE XCA standard that has been developed by the University of Utah. It is written in Java and uses the HAPI library for HL7 messaging.


XCPD Adapter: This is an open-source implementation of the IHE XCPD standard that has been developed by the University of Utah. It is written in Java and uses the HAPI library for HL7 messaging.


OpenXCA: This is an open-source implementation of the IHE XCA standard that has been developed by the Open Health Tools project. It is written in Java and uses the HAPI library for HL7 messaging.


openxcpd: This is an open-source implementation of the IHE XCPD standard that has been developed by the Open Health Tools project. It is written in Java and uses the HAPI library for HL7 messaging.

These are just a few examples of open-source implementations of IHE XCA and XCPD that are available. There may be other options available as well.

are there links to that?

Certainly! Here are links to some open-source implementations of IHE XCA and XCPD that I mentioned earlier:

XCA Adapter: https://github.com/jamesagnew/xca-adapter


XCPD Adapter: https://github.com/jamesagnew/xcpd-adapter


OpenXCA: https://github.com/openhealthtools/openxca


openxcpd: https://github.com/openhealthtools/openxcpd

I hope these links are helpful! Let me know if you have any other questions.

are there others?

There may be other open-source implementations of IHE XCA and XCPD available. Here are a few additional resources that you might find helpful in your search for open-source implementations:

The IHE Wiki: This is a community-driven resource that provides information about IHE profiles, implementation guides, and technical frameworks. You can find more information about IHE XCA and XCPD, as well as links to open-source implementations, on the IHE Wiki.


Open Health Tools: This is a community of developers, users, and researchers who are working to create open-source tools and technologies for the healthcare industry. The Open Health Tools project includes several open-source implementations of IHE profiles, including XCA and XCPD.


OpenEMPI: This is an open-source enterprise master patient index (EMPI) system that has been developed as part of the IHE project. It includes support for IHE XCPD, as well as other IHE profiles such as XDS (Cross-Enterprise Document Sharing) and PIX (Patient Identifier Cross-Referencing).

I hope these resources are helpful in your search for open-source implementations of IHE XCA and XCPD. Let me know if you have any other questions.

are there links to that?

Certainly! Here are links to the resources I mentioned earlier:

The IHE Wiki: https://wiki.ihe.net/


Open Health Tools: https://www.openhealthtools.org/


OpenEMPI: https://openempi.github.io/

I hope these links are helpful! Let me know if you have any other questions.