Monthly Archives: January 2012

FHIR Report to HL7 Architecture Co-ordination Council

This is a written version of the report I gave to the HL7 Architecture Co-ordination Council (technically, the SAIF roll-out project), at HL7 concerning the development of the FHIR project (It has considerable similarity to the last post, made before the HL7 meeting):

At the last meeting, in San Diego, the RFH project (as it was known then) was an idea, with considerable smoke and mirrors. This meeting, we (myself, Lloyd McKenzie, and Ewout Kramer) have rounded it out, and it’s now a complete methodology (where complete means, no missing holes, not finished and ready to use). FHIR has been fairly thoroughly reviewed in various working groups within HL7 and while there are many identified specific issues with the specification, the overall shape of the specification has generally gained enthusiastic support.

The FHIR development team now has the following 4 priorities for ongoing development in the near future:

  • Collaborating with several domain content work groups in HL7 to either review or develop resources. In particular, we have a formal collaboration with the Pharmacy workgroup, and informal ones with Patient Administration and Orders and Observations. In addition to building actual resources, these collaborations are as much about building processes, knowledge and culture around doing good resource design
  • Further developing the underlying tool chain, the RIM mapping framework, the way terminology is handled, and the integration with existing HL7 content and publishing frameworks
  • Doing implementations to test the basic framework ideas. (there is already a server publicly available, but more on that later)
  • Writing a SAIF mapping between the canonical SAIF (HL7’s internal master architecture framework) and the FHIR specification (this will in effect be the formal FHIR methodology definition)

We have provisional agreement around transferring the FHIR ownership and development resources to HL7 – this should be resolved soon, and then the FHIR specification will more from it’s current place to either http://www.fhir.org or somewhere on the HL7 website.

We’ve also taken this opportunity to strengthen the nascent governance council, and I’m very pleased to welcome Bo Dagnall to the team – FHIR already owes some it’s overall design to Bo, and he’ll provide some real insight and discipline to the council and the overall architecture of FHIR

FHIR Report for the San Antonio Meeting

The prototype HL7 standard I am working on with a few others used to be called “RFH” (Resources for Health) but the marketing committee has now branded it “FHIR” (pronounced “Fire”, as in HL7 Fire). It can be found here.

At the last HL7 meeting (San Diego), RFH was just an idea, with a lot of smoke and mirrors behind it, and a whole lot of unresolved questions about how the specification would be developed and implemented. Since the last meeting, I’ve worked with several friends (principally Lloyd McKenzie and Ewout Kramer) to resolve all these outstanding issues, and polish up the rough parts. Now FHIR is ready for wider review.

Major changes:

  • There’s now a methodology for producing resources, and we’re ready to start working with a few key committees to start producing resources
  • There’s messaging, document and SOA frameworks now, and the RESTful framework is much better defined
  • Policy around extensibility – which is a central piece of managing the complexity of standards – has been extensively discussed and described
  • A whole bunch of implementation collateral has been added – schemas, examples, reference implementations, UML definitions, resource dictionaries
  • The terminology binding/definition part has been simplified and finished
  • The data types were overhauled and simplified further with substantial further input from CIMI members

What comes next?

  • Defining the key clinical resources – synopsis, medications, problem lists, vitals and other diagnostic reports (Lab already exists) and validating the existing resources with the relevant domain committees
  • Finishing out the reference implementations
  • Validation and conformance tooling
  • testing the specification in the real world
  • ..starting the long march towards ballot

When will FHIR be discussed at the San Antonio meeting?

This is the (possible) times I know about:

  • Mon Q2, RIMBAA: RIM with DDD principles, includes discussion about FHIR(?) (George De La Torre, and no, I don’t know anything more about this)
  • Mon Q3, RIMBAA/Tooling: implementation tools, standardized resources to be incorporated into software as API’s as beiing discussed in MnM from Grahame’s FHIR (again, I’m not sure when this will be discussed)
  • Tues Q1, MnM: Ongoing FHIR development (MnM sponsors the FHIR project)
  • Tues Q6, Tooling BOF (after the Corepoint party, thanks to Dave): introduction to FHIR (aimed at content developers and implementers)
  • Wed Q1, ITS: ITS consideration of FHIR (technology focus)
  • Wed Q6, RIMBAA BOF: FHIR topics of interest to RIMBAA (Ewout/Lloyd)

In addition, we are trying to find a time to discuss FHIR with the pharmacy workgroup, but I haven’t yet got a time for that.

Who is FHIR for?

Finally, a note about the target audience for FHIR: The HL7 v2, CDA, and v3 specifications are in the latter part of the development cycle. Adopters have invested substantial amounts in them, and aren’t lightly going to simply adopt a new specification. Yet most implementers and HL7 members believe that there must be a better way to define standards, and that HL7 needs to find it.

I’m regularly approached by projects or companies who are doing new types of integration, building new architectures around web and mobile technologies, looking to exchange data cheaply. They ask me what specification to use – they’re looking for an option that fits their architecture and technology and offers a good balance between useability and re-useability. I don’t have anything good to recommend to them – v2 is old tech, venerable, but not flexible and adaptable. CDA is a document spec, and while bits are useful, it’s too heavy weight to be a good option. And v3 messaging… no. Looking wider afield, the SOA specifications, IHE specs, nothing really hits the sweet spot… yet there’s a lot of this work going on.

For now, we are aiming to meet these requirements with FHIR – green fields sites. Also, we’ll be trying to position FHIR as a logical option for augmenting existing v2 implementations. If FHIR works, if it’s a real good way to produce an implementable specification, then it will start to get a good rap, and then we’ll start looking at the wider questions around HL7 product life – but we’d like to get there as soon as possible, because there are large questions in that regard.