FHIR: Technology and Governance

Screen Shot 2015-03-21 at 3.47.47 PMThere has been much enthusiasm in the health IT industry regarding the health data standard that HL7 International is working on, HL7 FHIR, which is now a DSTU (draft standard for trial use). Everyone involved with health data – EHR vendors, interoperability vendors, medical app developers, “big data” proponents and hospital CIOs, to name a few – have high hopes that FHIR can be the golden ticket that leads to true health care interoperability.

Most of the enthusiasm is around the technologies being utilized in the standard including RESTful web services, JSON encoding, and granular data content called resources.

Technology-Empowered FHIR Data

RESTful web services, in particular, is a technology that has been strongly embraced by other industries and has the potential to be leveraged for engaging patients by connecting mobile technologies with their provider’s EHR system. This advancement represents a huge step toward building a patient-centered health care system.

FHIR Interest

Over the last decade, the healthcare industry has utilized SOAP-based web services to transfer documents. Most programmers today, if given their choice, would likely lean towards RESTful web services, preferably with data encoded in the JSON format. It is a better choice for mobile applications independent of whether the client device technology is iOS, Android, Windows, or even Mobile Web. Most social media sites today, such as Twitter and Facebook, publish RESTful APIs for connectivity.

This preference towards RESTful web services is based on some of the advantages that REST has over SOAP:

  • Simplicity: REST was designed to operate with thin clients, like a web browser, through all types of networking equipment, to a variety of service types.
  • Infrastructure friendly: Network load balancers, real-user-monitoring gear, firewalls and proxies are all currently optimized for RESTful traffic because they are optimized for HTTP/S traffic.
  • Scalable: By default, REST requests are stateless. Thus, the server does not have to remember the application state, enabling it to serve more requests in a shorter amount of time.
  • Efficiency. Although FHIR allows for either JSON or XML, JSON payloads are usually smaller than their XML counterparts. By comparison, REST+JSON payloads are dramatically smaller than SOAP+XML+envelope overhead.

While these technological aspects are indeed a move in the right direction, there remains a big concern: What about governance?

Technology-Enabled FHIR Governance
Data governance provides quality control for managing, using, monitoring, maintaining, and protecting PHI. It provides accountabilities for information-related processes, executed according to agreed-upon models that define what actions can be taken with the data.

Security must be designed into REST before it can be the interoperability answer for healthcare. REST assumes that the transport will be HTTP or HTTPS, and the security mechanisms that are built-in to the protocol will be available. It is the responsibility of the application developer to design for protected PHI.

With regards to privacy and security, HL7 says:

“Because there are a plethora of standards relating to the administration and functionality of the security system, FHIR does not provide user, profile, or other such administration resources. Instead, the FHIR resources are the targets of the policies expressed in these other approaches.”

In other words, someone else needs to tackle the issue of governance.

In addition to this statement, HL7 does a nice job of commenting on a number of aspects of privacy and security on its HL7 FHIR Security web page. For example, with regards to authentication for web-centric use, OAuth is recommended.

Looking at OAuth, while it is utilized heavily in the social media world, it will likely require some extra guidance for the particular needs of healthcare. OAuth is primarily used with proprietary web service APIs, such as the Facebook API. Interoperability is limited across these services with clients often not performing discovery (i.e., looking for specific patient data across systems) of any kind.

When discovery is introduced, token management becomes much more difficult to deal with. This is the type of workflow healthcare must be concerned with.

FHIR Governance: Beyond Technology

So if HL7 only establishes the infrastructure for privacy and security, who is left to figure out the details of FHIR governance?

In a recent THCB post, Fred Trotter, one of the architects of the Direct Project, questioned: “Why isn’t Direct being adopted?” The answer to his own question was:

“I have spoken to dozens of people in the Health IT industry about this issue. I think I have discovered most of the major problems, which are all complex technology and policy interaction issues. Who should I give my findings to? No one is in a position to rescue the roll out of interoperable EHR systems.”

Will we get to a similar point with FHIR? Everyone in the industry is extremely excited about the technology of FHIR – as well they should be. But, have we forgotten about the other half of the picture?

Healthcare has unique, complex issues with regards to protecting PHI that no other industry encounters, not even banking. How do we make sure that we don’t end up in a similar place as in Trotter’s assessment of Direct?

One organization that is trying help with governance is IHE International with their IUA (Internet User Authorization) profile that manages the tokens used for authorization of access to RESTful web services. If we want FHIR to be successful, then we need to put as much energy and enthusiasm around governance initiatives, such as IUA, as we do the FHIR technology itself.

Make no mistake, I’m not asking the industry to pump the brakes on FHIR progression and get bogged down in the same committee-driven bureaucracy that has weighed down Direct (e.g., DirectTrust). It would be wise, however, to involve IHE or some other governing body, to streamline, safeguard, and motivate provider organizations to utilize FHIR. Using these three principles may provide a better blend to achieve FHIR- inspired health interoperability.

Rob Brull is a senior product manager at Corepoint Health, a leading health IT vendor that delivers a simplified approach to internal and external health data integration and exchange for hospitals, radiology centers, laboratories, and clinics.

Categories: Uncategorized

Tagged as: , , , , ,

4 replies »

  1. What you refer to as patients becoming the intermediaries is similar to the VDT (view, download, transmit) requirement of Meaningful Use. I think this will be one likely workflow. The patient can use an app to look at data that was obtained via a FHIR interface, and then forward that to another care provider if they so choose. However, FHIR should also enable better EHR to EHR connectivity through what you call better “data maps”. In addition, an ACO might set up a FHIR repository as a centralized router of data to help eliminate some of the complexities discussed in the link that you shared.

  2. Good write up.

    Will hospitals and health systems change their policies to actively exchange with other “competitors’ for the good of the patient? It can be done now in a trusted manner with HL7 v2, yet it seems too few have policies that support incorporating data from outside sources. There is more to interoperability than just bits and bytes, hopefully after FHIR the industry can start focusing on policy as the major impediment to the free and easy exchange of patient data.

  3. Some clear, non-jargony plain English would help here. Is it implicit in all this stuff that patients are to become the intermediaries for (the misnomer) “interoperability”? That (fragments of) data concerning patient x will go out from EHR1 through FHIR APIs to patient x and subsequently then on to EHR2 (thru “n”)? And that as long as EHRS 1 thru n have all of the same APIs running atop their systems (which is why they’re called “interfaces” — i.e., effectively, translative proxy “data maps”) we’ll have seamless data exchange via which data can go out out EHR1 and find its way into the RDBMS’ of EHRs 2 thru n? So that data recipient providers 2 thru n can function in a way consistent with the IEEE definition of “interoperability”?

    Or, are we (more likely) going to “define interoperability down,” by adding additional workflow steps to providers using EHRs 2 thru n with respect to inbound data (whether their origin be EHR1 or patient-origination generated)?

    Just asking.