Brian Gammon on Mar 14, 2016 9:21:29 AM

NaviNet Connects at HL7 FHIR Connectathon

NaviNetOpenHL7ConnectathonTeam.jpgLess than two weeks into the New Year, a group of us from the NaviNet Open Product Research team had the opportunity to attend the HL7 FHIR Connectathon in Orlando, FL. The Connectathon was a prelude to the HL7 Working Group Meeting and Payer Summit, and it brought together developers and integrators from many different organizations with a goal to get connected using FHIR. As part of NantHealth, our NaviNet Open team sees FHIR as an important advancement to help stitch together clinical and administrative workflows, and the HL7 Connectathon was a great chance for our team to create something useful using FHIR. Needless to say, I jumped at the chance to roll up my sleeves and write code, which is something I don’t get to do often in my role as a Solutions Architect. Here’s a few of my key observations from the experience. 

CDS Hooks on FHIR

The Connectathon offered several tracks that covered a wide range of subjects and FHIR resources. We choose to participate in the CDS Hooks on FHIR track, which was co-led by Dr. Josh Mandel, a leader of the SMART on FHIR initiative. One of the reasons we opted for the CDS Hooks on FHIR track was because the pattern proposed by CDS Hooks compliments NaviNet Open’s event-based architecture. The CDS Hooks design calls for SMART-enabled HIT systems to play a specific role in a clinical decision support (CDS) scenario. User activity inside the EHR emits the “hook”, which is a real-time event notification, to subscribing systems. These other systems, called CDS Services, analyze the information in the hook and respond with “cards” to be rendered in the user interface of the EHR in a standard way. An extensible set of triggering events is defined, starting off with patient_view, medication-prescribe, and order-review. Be sure to check out the CDS Hooks wiki on GitHub to learn more. 

For our work in the CDS Hooks on FHIR track, we split our team to divide and conquer work on two different use cases we wanted to tackle:

  1. NaviNet Open as a CDS Service- the goal of this team was to build a CDS Service which subscribed to triggering events from the two EHRs that were also in the CDS Hooks track.
  2. NaviNet Open as the EHR- Focused on adding functionality to NaviNet Open in order to play the role of the EHR, rendering cards sent in from subscribing CDS services.

Use Case 1 – NaviNet as a CDS Service:

This is the use case I worked on, along with Dheeraj Duvvuru (@duvvuru), a Principal Software Engineer from our Research Team. We set out to demonstrate how we could add value to the EHR workflow by providing an insurance eligibility card that gives the clinician a quick look at the patient’s coverage status, along with an app link to open an expanded view of the eligibility and benefits in NaviNet Open. We’re excited because we believe this use case could easily be expanded to provide an app link directly into an Authorization or Referral workflow right from the EHR.

To get going, we created a Node.js app to host our CDS Service REST endpoint, and below is a high-level overview of how it all flows:

  • Our service endpoint is registered with the patient-view trigger in the two participating EHRs. The registration specifies that the EHR should include the patient FHIR resource. The CDS Hooks spec calls this the “Pre-Fetch bundle”.
  • When the patient-view event occurs, the EHR posts a FHIR Parameters resource to our service endpoint, passing the contextual information about the patient being viewed.

 

  • Once posted, the CDS Service parses and analyzes the message, looks up the patient’s insurance information, then uses an internal REST API to run a 270/271 transaction against the health plan. The 270/271 is a standard HIPAA X12 transaction for eligibility and benefits (E&B). This part was mocked out given the time constraint of the Connectathon.
  • The E&B response is then used to create a “card” which is returned to the EHR for real-time rendering in the user interface. The card contains a link to launch an expanded view of the E&B details.
  • The card in CDS Hooks is also a FHIR Parameters Resource, with a specific set of name/value pairs to define the data for a card.

 

Below is NantHealth’s NaviNet Open CDS Hooks card, rendered inside the CDS Hooks’ mock EHR:

 CDSHooksDemoScreenShot.jpg

 

Use Case 2 – NaviNet as the “EHR”:

Although NaviNet Open is not an EHR in the traditional sense, we felt it could play the role of one in a CDS Hooks scenario, sending out triggering events and displaying the CDS cards returned by subscribing services. Jason White (@jsnwhte), Chief Architect and head of the NaviNet Open Research Team, led this work along with Dheeraj and Isaac Kulka, UX Architect. To do this, Jason added support in NaviNet Open for registering other vendors’ CDS Hook operations, calling those hooks with the appropriate pre-fetch bundle, then rendering the cards returned in a carousel component on the E&B Details page. The screenshot below is a rendering of the concept, demonstrating some potential use cases:

HL7FHIRConnectationScreenShot.jpg

This would be a great way for payers, provider networks, and other participants to inject decision support information into NaviNet Open workflows, such as an eligibility check, or an authorization submission.

Closing Thoughts on CDS Hooks on FHIR:

CDS Hooks on FHIR shows a great deal of promise, but there is still a bit of a journey ahead to make it real. The lack of a unique patient identifier across the boundaries of a health system presents a large challenge. For example, in a real-world implementation of our NaviNet Open Eligibility CDS Service, we would need the patient’s insurance information passed in the patient resource from the EHR. Without that information, an eMPI would need to be used to perform a lookup and match the patient’s MRN to his/her health plan Member ID. It’s also important to note that for this Connectathon, our track decided to focus on the hooks and the FHIR resources. This meant that saving the subjects of authentication and authorization for future sessions. However, there is a plan to use web standards like OAuth 2.0, and OpenID Connect to solve these challenges.

The Future of FHIR and NaviNet Open

As part of NantHealth, our NaviNet Open team, is excited about FHIR, and aim to be on the forefront of interoperability using this emerging standard. We are actively engaged with customers and vendor partners in real-world projects using FHIR. In participating in events like the HL7 Connectathon we are eager to work with other organizations that are looking for meaningful, practical opportunities leverage FHIR. While it was hard work, it was also fun to dust off my development skills and write some code. We worked right up until the last minutes before our report-out, doing a final deployment of our code to AWS, just in the nick time!

If you or your organization are interested catching FHIR with NaviNet Open, please reach out to me directly or anyone from our Product Research team!

Like this post? 

Subscribe Now

Tags: Standards

Subscribe to Blog

NaviNet, part of NantHealth, is America’s largest interactive healthcare network. Our flagship multi-payer provider website is built on deep payer integration and the innovative use of technology to deliver real bottom-line value for both payers and providers.