Thursday, January 30, 2014

Will FHIR make the Electronic Health Record look like Facebook?

Being able to attend a working group meeting in San Antonio in the spring is one of the
best benefits that membership in the Health Level Seven International (HL7) organization offers. Imagine, walking along the river walk, temperature in the 70’s, plenty of good places to eat, what else does your heart desire?

The conference center was, virtually speaking, on fire (spelled FHIR in HL7 terminology) as FHIR was the hot topic of the meeting Jan. 19-24. FHIR stands for Fast Health Interoperable Resources, which is basically using web technology to exchange medical information. It is touted as the new interface standard that will eventually replace the versions 2 and 3. But before describing what this is all about, let’s take a step back and find out how HL7 got to this new venture.

HL7 has a lot of experience when it comes to defining new interface standards and there have been good learning experiences. The first widely implemented iteration, version 2.x has been a huge success from an implementation perspective as it has pretty much become the way that the vast majority of the healthcare applications exchange information in the US and many other countries. The main complaint is that “if you have seen one interface, you have seen one interface,” meaning that no two implementations are alike. Also, even though the messaging is kind of ugly and ancient, people know the weaknesses and use Interface engines extensively to map the messages to provide interoperability. So, in short, “it kind of works.”

Version 3 was supposed to solve many of the flaws in version 2, however, except for a few implementations in Canada and the UK, it has gained very little traction. The main complaint of version 3 has been its complexity and verbosity. Take specification of patient sex as an example. In version 2 one would specify in the eighth element of the Person Identifier (PID) Segment, the value of “M” for male. In version 3 this same element would have to be encoded in XML and basically specify that “of a particular code system with a specific code name,” the AdminsitrativeGenderCode would be “F,” with the display name being “Female” etc. In other words, what takes a single character in version 2 takes at least 3 lines of text in version 3 to describe exactly the same information. Therefore, early implementers would find out that going from version 2 to version 3  would choke the bandwidth of the system due to the lengthy message exchanges. This is in addition to the fact that there are not very many version 3 tools, and it is complex. Furthermore, its information model (Reference Information Model or RIM) is trying to cover all of the possible constraints, use cases, and specializations, and that makes it very cumbersome. In a nutshell, it is great for academics, but a pain for implementers.

There are quite a few implementations of the Clinical Document Architecture (CDA) in the US, as the Meaningful Use (MU) requirements for Electronic Health Record (EHR) implementations have made it a major priority. However, the level of interoperability for these documents has been a challenge. Yes, the definitions of templates such as the Consolidated CDA (CCDA) has been a major help, but they are still relatively verbose and complex to create and parse. As with other v3 components, the standard does not have very many friends among implementers.

What does Fast Health Interoperable Resources, FHIR, do that you can’t do by using either version 2, version 3 or a CDA? First of all, the specification started with a clean slate, so instead of making an attempt to model the world of healthcare, which is what the RIM did for version 3, and trying to cover every possible use case, it started bottom up and defining the entities or what FHIR calls the resources that are needed to exchange information. The maximum number of these resources is estimated to be 150, the draft standard for trial use (DSTU) as published recently has about 50 to start with. Then it put restrictions on these resources by stipulating that they should cover 80 percent of the common scenarios, no less, but definitely no more. The remaining 20 percent that is critical to achieve interoperability is then achieved by profiling and extensions. The requirement is that these extensions be published, and therefore be accessible to anyone who is trying to exchange information.

The requirements for FHIR are that it should be very easy and fast to implement, it leverages web technologies, messages are human readable, and it supports multiple architectures. There are several reference implementations and test servers available, all in the public domain. There is also a big library of examples. Collections are represented using the ATOM syndication standard. Without going into too much technical detail, ATOM is how Facebook and Twitter feeds work, and has become a semi-standard in the web environment.

I initially thought to myself that FHIR was equivalent to REST (Representational State Transfer), in other words the equivalent of the recent DICOM extensions for web access to images (WADO-RS). REST considers everything to be a web resource, which can be identified by a uniform resource identifier (URI) or internet identification. However, FHIR is more than that, there are actually four different interoperability options, which are called paradigms. Yes it includes REST, but also a document standard, messaging standard, and a set of services. REST provides standard operations using http, using the widespread experience of implementers in this domain. The documents defined in FHIR are similar to CDA, and consist of a collection of resources. Example resources are a patient, practitioner, allergy, family history, care plan, etc. Resources can be sent as an ATOM feed, which allows also for sign-in and authentication. Messaging is also very similar to v2 and v3. The services are based on a Service Oriented Architecture (SOA). Remember that regardless of which paradigm is used, the resource, i.e. content of the information, is still the same, so it can be shared using different paradigms. Compare this with sending a letter from A to B using FEDEX and then from B to C using UPS. Similarly, the content might be a lab result that is received in a message and forwarded in a discharge document. The profile definitions that are critical for interoperability are also shared among the different paradigms.

Based on the many advantages, one might wonder why there are no implementations (yet) of FHIR to speak of. First of all, it is brand new, and there is obviously a learning curve for implementers (albeit very small compared with version 3 or CDA implementations). Second, there is no incentive to replace a huge installed base of v2 and a decent number of CDA implementations. However, for new domain areas where healthcare is just starting to get traction, such as mobile implementations, it is a great tool. In addition, for any social media applications, it would fit in very well too. To the extent that new applications are being driven by implementers, there could definitely be a major push towards its adoption.

FHIR has a lot of potential, not necessarily as a replacement for existing implementations but to augment new applications, which are based on web technologies. Its many examples, public domain reference implementations, and test servers are a major draw. During the recent FHIR connectathon at the HL7 meeting, it became obvious that it is relatively easy to create a simple implementation very quickly. FHIR might become the backbone of the next generation healthcare IT implementations, but then… who knows what might come along in another five years or so. Time will tell, in the meantime, there is no question that there was a lot of smoke around FHIR at the HL7 meeting.