Guest Post: Breaking a lance for #FHIR

Mar 10, 2015

A guest post about FHIR adoption from Andreas Billig, Fraunhofer FOKUS. I asked Andreas to write about his experience using FHIR to implement a terminology service. Although it seems not necessary to break a lance for FHIR, there might be some skeptics that need to be motivated to use FHIR for electronic health artifacts in future. The upcoming success of FHIR is directly related to past efforts for establishing a common modeling language and method for electronic health artifacts. One of the most prominent ambitions was HL7-v3 in the mid 2000s. So why trying to introduce a new language?

Past issues & consolidated goals

HL7-v3 was backboned with excellent concepts and techniques for developing models to ensure well-defined interpretation of the instances exchanged between various actors in electronic healthcare. It relies on model-driven approaches (MDA) well known in the software development community and on a sound architecture enabling re-use and refinement of model elements.

Starting from RIM (Reference Information Model) elements as a general vocabulary for the health care domain you can first define your DMIM (Domain Message Information Model) for specialized artifacts of a particular sub-domain. These models are not intended to be serializable and will be refined/constrained to so-called RMIMs (Refined Message Information Models). (Serializable) RMIMs have their direct equivalent in XML schemata which in turn are used as grammars for electronic artifacts exchanged between healthcare actors. A prominent instance of the RIM-DMIM-RMIM-XML chain is CDA (Clinical Document Architecture).

So far so good. But what were the issues? From our point of view there were at least five points where the development of FHIR went very good and learned from past issues:

  • dissemination bydocumentation
  • handling modelingcomplexity
  • extensibility
  • domain modeldiversity
  • integration with the method ofprofiling

The first point concerns the excellent documentation of the standard utilizing the hypertext paradigm. It can be seen as a domain-specific WIKI with concentrating on the essential elements with a consistent structure following the KISS-principle.

The Modeling complexity of FHIR is of low degree thanks to the profile- centric approach. Of course, HL7-v3 made very good efforts to handle complexity by introducing elements like class- and mood-code, shrinking the number of explicit classes (by the way, this was the reverse application of the principle of attribute discrimination). FHIR does not introduce them explicitly but due to the fact that most of the coding attributes are discriminating per se FHIR does not abandon this facility in general.

The extensibility approach of FHIR is at prominent place. Explicit language constructs to represent extensions of information items allows for managing and tracking extensions with direct machine support. It is expected that some extensions are gathered for reflow to standard resource profiles.

As said before, with HL7-v3 one can define arbitrary models to reach the goal of high domain model diversity by instantiating the RIM-DMIM-RMIM-XML chain as done in the CDA definition. From my point of view it was the HL7 intention that followers massively will define custom models for their projects. For reasons unknown to me (may be due to the understandable absence of modeling experts in projects) most of the users stuck with the CDA model to avoid the above chain and to profit from various resources developed around CDA. Unfortunately, this practice did not led to sound model diversity. Instead, many users tried to press everything in CDA - so the diversity was formulated within CDA and not sufficiently covered by tailored modeling language elements. FHIR minimizes this risks by its profile-oriented approach where strong model chaining cannot discourage users. Instead FHIR is initially equipped with a high diversity that can be refined or extended as needed for the project.

The present point is directly related to the last point. People and organizations, e.g. IHE, customized the chain end CDA/XML by defining various profiles - with the problems sketched above. FHIR is based consequently on profiling from the beginning to the end. This uniform way ensures low complexity and the absence of language breakings.

Ready for the web

Since many years easy-to-use web technologies are increasingly utilized. The most prominent examples are REST and JSON. I remember a telco two years ago where I asked “Will FHIR be the successor of V3?”. After a small pause the moderator analogously said “mmh, FHIR is merely intended for use on smartphones and tablets but we will see …”. Now we see that it makes no sense to artificially split the modeling techniques in dependence of distribution channel.

The lightweight profile-centric modeling approach of FHIR is directly targeted to main formats XML and JSON and therefore a perfect fit to the technological base of the web. Moreover, semantic web applications coming out of age and FHIR will easily be integrated by using RDF bindings. Of course we do not want to break up with MDA. Instead, many MDA results will flow in the FHIR development in future.

How we use fhir

Our institute have applied FHIR in several projects. First of all, the project DEMIS (German Electronic Notification System for Infection Protection) utilized FHIR resources to represent and exchange information of infectious diseases and pathogens, a project together with the Robert Koch Institute, the central federal institution responsible for disease control and prevention. Here we profited from the quick and easy definability of profiles for resources concerning infectious diseases. Moreover, the facility of handling FHIR profiles as first class citizens enabled us to generate input forms to be filled by healthcare actors.

Secondly, our terminology server CTS2-LE is able to import code systems and value sets represented by FHIR Value Set Resources. These artifacts are then mapped to the CTS2 standard. Here we benefit from their concise definition. As an side product, we were able to load all HL7-v3 code systems and the FHIR systems itself via this interface.

It has to be noted that of course we will continue with HL7-v3 as long as some market segments will base on this standard. HL7-v3 was a groundbreaking project that influences the FHIR development - or - one can say, made FHIR possible.

Thanks Grahame, for the opportunity to break a lance for FHIR in your blog