Implementing shared care records with external FHIR repositories… how hard can it be?

In this blog, our HealthStore® product management leads, Tim Kaschinske and Adam Coombes, discuss BridgeHead’s recent participation in the HIMSS Interoperability Showcase. They talk about the task at hand – a demonstration of a shared care record in action, the successful integration and data exchange with some of the world’s leading EHR systems (EPIC and Oracle), and the lessons learned from the experience.

There’s nothing like a deadline to galvanize action

Imagine being told that you have six weeks to get your product working seamlessly with the two largest systems vendors in the healthcare market, who between them command more than half of US hospital EHRs, a significant chunk of the UK market, and with whom you’ve not actually worked before. Oh, and the American Government body responsible for data collection for population health to boot! Well, that’s what happened to us when we decided it would be great if BridgeHead Software took our HealthStore Clinical Data Repository (CDR) to HIMSS24 in Orlando, to be part of the Interoperability Showcase in March. And, you know what? It was great. Nerve-wracking, challenging and, at times, a bit chaotic, but every participant in our ‘pathway’ worked together and we were able to successfully demonstrate the power of true interoperability and open standards across systems and organizations in healthcare. We also learned a lot!

What did BridgeHead achieve?

BridgeHead was tasked with providing the central Clinical Data Repository in the ‘Cancer pathway’, integrating with Epic, Oracle Health, and the National Centre for Health Statistics (NCHS), represented by the Centre for Disease Control (CDC). The aim was to show how interoperability and, in our case, a patient-centric CDR (that we call HealthStore®); makes the patient’s and clinician’s journey through diagnosis and treatment easier, faster, and safer.

In this scenario, we utilized HealthStore’s FHIR capability to access data from Epic and Oracle Health, treating them as external FHIR repositories. That means we utilized FHIR connections to access data from those external applications in ‘real time’ and present that data as part of the patient’s record. But, importantly, we were also able to provide historical data for the same patient that, in this scenario, is assumed to have been aggregated from a range of disparate facilities and source applications over time – all from within the same HealthStore instance. We also made it clear to users in HealthStore’s graphical user interface (GUI) which data was from which system, providing a single shared care record showing the data from all three applications.

Not only could users choose to view the data (for example text reports, clinical notes, and lab results) from the external repositories, but we also provided a ‘sync’ button to allow a user to pull the data from the external repository into the HealthStore repository (where the data was subsequently labelled as a local copy, rather than an external copy).

Of course, interoperability is a two-way street. Right? Absolutely! And not only were Epic and Oracle Health able to use our diagnostic grade, zero footprint viewer (ResMD) to fetch and display radiology images and reports from HealthStore (enabling seamless transfer of care across organizations and disciplines) but, since we already had historical data for our cancer patient from several other systems, the NCHS were able use our FHIR APIs to retrieve years’ worth of data and feed it in to their population health analytic systems (which are very impressive by the way).

So, what did BridgeHead learn about ‘seamless interoperability’?

First and foremost, we learned that FHIR does indeed provide the ability to create a shared care record across multiple applications. The FHIR APIs provided by all the vendors were implemented in a consistent manner that allowed us to access the data without any changes to our HealthStore FHIR implementation. I can’t stress enough the importance of this standardization – it enabled everything to work quickly and (relatively) painlessly.

Also, having the ability to correctly identify the patient was crucial to implementing a shared care record. At the interoperability showcase, each application had its own Patient ID (MRN) associated with the data in its repository. Because HealthStore can track multiple identifiers for a given patient, across different applications, we were able to query each application using its own Patient ID and then associate the query results from those multiple applications to a single patient record.

Probably the biggest lesson learned was related to performance. When querying data from an external FHIR repository, your performance is directly related to the performance of the external application. If the external application is busy or the network is loaded (and let’s face it, a large trade show with a temporary network used by thousands of vendors and delegates is a good example of this), the retrieval of data from that system will inevitably be impacted. This requires applications to be smart about how they query an external application using FHIR. Querying too frequently will cause delays and result in ‘clicks’ becoming very expensive from a performance perspective.

FHIR helps in this regard by providing a bulk data API. The FHIR bulk data API allows for the transmission of large amounts of data between applications in an asynchronous fashion.  Applications can continue without waiting for the query to finish, and then display the data when notified that it is available. This method is most helpful when pulling data from an external repository into a local repository where users can initiate a ‘sync’ and then carry on working while the data processes continue in the background.

Knowing what we know now, would BridgeHead do it again?

You bet! Overall, the HIMSS Interoperability Showcase was a great experience. It gave us the opportunity to integrate with other vendors in a simulated ‘live’ environment and allowed us to test our FHIR API against other vendor implementations, learning valuable lessons along the way. We also made some new friends – who were each instrumental in our collective success. I’m looking forward to our next opportunity to demonstrate the power of HealthStore’s interoperability to healthcare organizations as well as gleaning ever-valuable feedback and learnings.

Here we all are, making interoperability look easy

BridgeHead’s Adam Coombes explaining how FHIR allows live and historical patient data to flow to and from BridgeHead’s Clinical Data Repository to support care pathways.

About the authors

Adam Coombes

Adam Coombes is Product Owner for BridgeHead’s HealthStore® Clinical Data Repository. His goal is to enhance care delivery by enabling healthcare providers to create a safe, available, and complete clinical history for patients and make it easy to move data in and out of HealthStore, as and where needed.

Adam is an established Business Analyst, Product Owner, and self-confessed ‘physics geek’. For the last 15 years, he has worked with clinical and technical teams to develop solutions that improve patient outcomes.