Starting a FHIR under HL7

I'm at the HL7 Working Group meeting in Vancouver, and Sunday I usually spend at the International Council Meeting, but today in the second half of the morning session, Lloyd McKenzie and Grahame Grieve presented a free tutorial on Fast Healthcare Interoperability Resources that was too promising to pass up.  I needed to see what all the excitement was about.  The tutorial provided a great overview of what FHIR is trying to accomplish, and was readily comprehensible.  The room was upgraded in size twice, and even so, it was filled to the rim (pun intended).

What follows is a summary of what I learned (gleaned from my twitter notes on #FHIR), and a quick prediction at the end.

Kudos
First of all, you need to understand that this is something that Grahame Grieve started nearly a year ago in response to outcomes from the HL7 Fresh Look task force.  He has donated his original ideas to HL7 with the proviso that they be freely available to all through the first normative release, in part to encourage adoption of the specification by folks who are and are not members of HL7.  The current project is being run by the HL7 Modeling and Methodology workgroup.  The specifications are still in draft form, and actually, were already out of date 20 minutes before the tutorial started, so it appears to be moving pretty quickly.

Why FHIR
FHIR is intended to address the most common (80%) interoperability needs of implementers, and consciously delegates the remaining 20% to extensions which must still fit within the structure of the standard, but which will not be addressed in the core parts of the standard. After getting rid of the stuff that deals with all the exceptional cases, it turns out that the core can be much simpler (some have estimated that it is 20% of the original, fully encompassed modeling that we currently do in HL7).

You really need to see the slides, which I will post here as soon as they become available, as they tell the story of what FHIR is really well.


The project team anticipates that upon completion, FHIR will provide specifications for 100 to 150 healthcare resources, the fundamental components needed in an interoperable healthcare exchange.
These will include things like people, problems, allergies, prescriptions, etc.  While still being based on the RIM, Datatypes and vocabulary, it won't put the necessities of the RIM and its infrastructure in the face of developers.  There will be no confusing mood codes or class codes.  Instead, everything will be an addressable resource, an atomic component of a healthcare related transaction.   Even the ISO datatypes (HL7 Datatypes Release 2.0) are simplified for developers.  In fact, the datatypes UML diagram fits in one slide easily readable from the back of the room.  FHIR is much more like "Green CDA" for all of version 3, (in fact you could even call it HL7 Version 4, but HL7 isn't marketing it this way).

Assuming at most 30 data elements per resource, this could be 3000 data elements total, across the EHR.  There is still a place for vocabulary in FHIR to capture the necessary detail (especially in extensions).  The project team notes that Vocabulary is still hard, and that they'd love to see someone tackle it the way that FHIR is tackling other problems.

FHIR is RESTful
FHIR is designed for, and supports RESTful approaches, thus Resources is part of the name of the specification.  Because of this, it gets the basic Create, Read, Update and Delete operations for free because they come with HTTP, one of the most common transports used with RESTful approaches.

Each of the resource specifications will be published in several formats, including UML diagrams, tables, a sample instance, an XML Schema.  Every resource will have a sample instance (it is one of the governing principles of the specification).  The sample instance presented for person in XML also fit into one slide, and if your eyesight was still good (e.g., you aren't an aging nearsighted geek like me), you could read it from the back of the room as well.  The normative definition includes three things I like:  An easy to understand written syntax for what is required (almost like a Microdata schema), written definitions for all resources, and most importantly, a rationale for each data element in the resource (tying it back to requirements!).

Squishing down in one place (as FHIR does on the basic models) pushes requirements elsewhere.  Some requirements will move out to the compositions of resources used in a message.  Message exchange using FHIR uses message profiles.  A message profile is a composition of FHIR resources put together in a certain way (we didn't get into the technical details).  Message profiles can be created by anyone, HL7, its affiliates, organizations like IHE, national programs, etc.

Compatibility
FHIR Resources map pretty well into HL7 Version 2 segments.  But you wouldn't build a Health IT Architecture around Version 2.  FHIR still retains the RIM as a core component, but it is used as an architectural artifact that ensures appropriate semantic mapping, not something that defines how classes are constructed or refined.  In fact, modeling by restriction (a "feature" of current RIM-based approaches in HL7) is eliminated in FHIR.  Because FHIR is based on RIM modeling, you still get the benefits of the RIM as the backbone.  That means that round trip exchange from V3 and CDA is also reasonably possible; it's just a matter of writing the transformation ;-)

There is also significant interest from OpenEHR to harmonize with FHIR datatypes.  Both the FHIR project team and the CIMI initiative understand that the two groups will need to coordinate.  They haven't established yet the how or why, because it is still to early to tell what they will need to accomplish.

Tooling
There was some discussion about the tooling and underlying model representation that FHIR will be based upon.  The current MIF is not applicable, nor are many existing HL7 tools.  There are certainly things that can be done using open source tools like MDHT, but the present tool-set for creation of the specifications is an Excel spreadsheet.  Simplicity is very much a driving factor here.

Governance
FHIR will need to spend considerable amounts of time figuring out governance.  We won't be able to just approve any element that we want to in a resource, instead, we'll have to figure out what it means to be within the 80% of needed stuff in the core.  That may require answering different questions, such as:  "If we put in X in this resource, will you implement it?" to the audience approving its inclusion, rather than "Should we put X in this resource?".

We'll also need to look at how extensions are vetted and published (e.g., a registry).  The former is needed to ensure good mapping back to the RIM.  The latter is necessary because an extension is useless if you cannot find it.

Timing
I'm hearing a couple of different viewpoints on timing about FHIR.  This can be implemented quickly, and we need it yesterday, and should get it published as soon as possible is one view.  Another view is that we'll have a draft for comment this summer (for the fall HL7 ballot), and that it may take a few cycles to pass thereafter, so 2 years is not an unreasonable time frame.  From my own viewpoint, FHIR is strategic, not tactical.  We need to do it right, but we should also build fail fast into the program.

The project team plans on issuing FHIR as a complete standard, not separate chunks where this chunk comes from Pharamacy, and that one from Patient Care, and that one from O&O over a particular time period.  I'm very happy with this approach, as it brings us back to the original V2 roots where you could actually get the entire standard in one document.  However, I think that core components may need to be prioritized so that key things are done first, and iterations address lower priorities in later stages.

No matter how it is done, neither I nor the project team expects to see massive migration to FHIR next year.  In fact, V2 will probably be with us for decades while it is still up to the demands being placed upon it.  Where FHIR will shine is in green fields, and I note an especial interest from the mHealth community in where it is going.  I don't think we need to drop everything and take up FHIR for Meaningful Use Stage 3 (rushing this kind innovation is not a good idea), but I do think we need to be paying attention.

What I Like
It's simple.  It requires few tools to create.  It has some rules about how the XML looks that make sense.  It focuses on implementers.  It explains why something appears in a resource, linking requirements to specifications.

What I Don't Like
It's new.  It has people excited.  It will change Healthcare IT.  I didn't think of it.

Actually, I don't know what I don't like because I haven't been involved deeply, yet.  That's about to change because no matter what happens...

A Prediction and a Prehumous Award
FHIR will emerge as a new standard, and will be very dangerous.  It applies many of the lessons of Christensen's "The Innovators Dilemma" to Health IT Standards.  Pay it no attention to your own peril.

This certifies that 

Grahame Grieve, Health Intersections

Has hereby been recognized for outstanding contributions to the forwarding of Healthcare Standardization by setting a FHIR under HL7

These awards aren't given out lightly, and to give one of these out in advance of the work being completed should mean something.  Listen up.