Why Your Healthcare Organization Needs to Catch FHIR Part II

By: Charlie Provenzano

Unlike some technologies that have been talked about everywhere but seldom implemented (blockchain?), FHIR is finding widespread adoption both in systems and in policy. This month, the U.S. Department of Health and Human Services (HHS) proposed new rules to support interoperability and in the process endorsed new rules from CMS and ONC, both of which are built around the FHIR standard. There’s plenty of new reading (724 pages for the HHS rule alone), but how can you apply it to your own institutions and your own systems? What are your institution’s FHIR priorities?

Value-Based Care and the Da Vinci Project

If part of your institution’s mission involves value-based care, the chances are pretty good that you will be focusing on interoperability outside the four walls, and that the Da Vinci Project use cases will be of primary interest. The Da Vinci Project is a private sector initiative (full disclosure, HealthLX is a founding member) tasked with addressing the needs of the value-based care community using the FHIR standard. The goal of the Da Vinci Project is to help payers and providers to positively impact clinical, quality, cost and care management outcomes.

At HIMSS19, members of the Da Vinci Project, successfully demonstrated use cases involving data sharing between payers and providers using FHIR endpoints. These use cases were modified in each demonstration to use different EHRs and different payer systems in order to demonstrate that the same FHIR interfaces can be applied across the industry when the standards are followed. If payer/provider interoperability is one of your priorities, you should pay close attention to the Da Vinci Project use cases as they develop. The use cases can be found here: http://www.hl7.org/about/davinci/.

US Core – The Fundamental Elements of Exchange

Maybe your priorities are not focused around a particular set of use cases.  Perhaps you’re building a new system or are updating an existing system and you just want to be able to share that data using the FHIR standard. Just about every current FHIR implementation is built around some portion of a set of resources referred to as US Core. The US Core implementation guide defines the minimum requirements for accessing data via FHIR and is intended to be the foundation for all US-realm FHIR implementation guides. (It’s also at the center of the new HHS proposed rule.) Whether you are building out your own FHIR server, building FHIR workflows, or working with a vendor, if your solution covers the US Core endpoints you’re off to a good start.

The US Core profiles cover obvious elements such as allergies, conditions, procedures, medications, and results. (For a full list of profiles, visit: http://www.hl7.org/fhir/us/core/.) Each profile specifies the minimum required elements to request the profile, as well as minimum elements that must be returned. For example, AllergyIntolerance has “Patient ID” as the one required argument, but must return: a status of the allergy, a verification status, a code which tells you what the patient is allergic to, and a patient ID. As with most things produced by HL7.org, the documentation is excellent.

Internal vs. External Servers

Most of the use cases proposed by the various agencies understandably focus on interoperability between healthcare entities, but FHIR can be an effective tool for data exchange within your organization as well.  If you work in a large enterprise, it’s not uncommon for your IT programmers to spend hundreds of hours a year integrating internal systems via proprietary APIs.  What if all of your systems used the same interfaces for the same types of data?  Interop programming would become a much simpler endeavor.  So then, it’s quite possible in a large or complicated enterprise that you may want to have more than one FHIR server.  Perhaps you will want a server for external inquiries, and a second or third for internal data integrations. 

Let’s take allergies as an example again.  Suppose that a particular payer institution has two sources for allergy data: a care management system where that data is collected by care management (CM) nurses, and a data warehouse that collects and manages that data from an HIE and other internal and external sources. For an external query, you would want to provide allergy data from the warehouse because it’s going to contain data on more members, not just those in the CM database.  But you probably also want an internal FHIR server which can make the CM allergy data available to the warehouse, because it’s a direct and reliable source.  In fact, for internal queries, you will probably want to ping that source before the warehouse.  The FHIR resources and call syntax are the same, but the server address, the purpose, source and destination are all different.

Build vs. Partner

The technical aspects of FHIR are not too difficult to comprehend, and the decision to create a RESTful API was made in part in order to use a technology that is already commonplace. Therefore, finding trained resources who understand the technologies involved shouldn’t be a difficult task. If your environment is simple, or you have an established team for interoperability programming that is up to the task, all of the tools are publicly available for you get started on your own.

However, consider a partner if any of the following statements are true:

• • • You are resource or time constrained but FHIR is still a high priority

    • Your IT environment is large and complex (i.e., multiple clusters, a mix of new and legacy, purchased and home-grown systems)

    • You have multiple sources for the same data types

    • You have internal AND external interoperability challenges 

If any of the above describes your environment, you probably want to consider partnering with a firm to envision and execute your overall FHIR strategy.

As you develop your own plans around FHIR, ask yourself these questions:

• • • What are your use cases?

    • Does your plan conform to new and impending regulations?

    • Do you need internally and externally facing FHIR servers?

    • Do you need to consider value-based care (Da Vinci Project) use cases?

    • What are your most trusted sources of data for sharing externally?

    • Do you need to partner, or can you build this with existing resources?

As I mentioned, there is plenty of reading material out there.  I’ve included some primary sources in the links above. I hope this post has helped you focus your research into FHIR and illuminated for you some of the considerations for this type of project. Click here to continue reading and check out Part III.

In case you missed it, check out Part I.