#FHIR Report from the Paris Working Meeting

May 18, 2015

I’m on the way home from HL7’s 2015 May Working Group Meeting. This meeting was held in Paris. Well, not quite Paris – at the Hyatt Regency at Charles De Gaulle Airport. Memorium

A sad and quite unexpected event occurred at this meeting – Helmut Koenig passed away. Helmut Koenig was a friend who had attended HL7 and DICOM meetings for many years. Recently, he had contributed to the DICOM related resources, including ImagingStudy and ImagingObjectSelection resources.

Helmut actually passed away at the meeting itself, and we worked on resolving his ballot comments the next day. Links:

Ballot Summary

The FHIR community continues to grow in leaps and bounds. That was reflected in the FHIR ballot: we had strong participation and many detailed comments about the specification itself. Once all the ballot comments had been processed and duplicates removed, and line items traded amongst the various FHIR related specifications, the core specification had 1137 line items for committees to handle. You can see them for yourself on HL7’s gForge.

This is a huge task and will be the main focus of the FHIR community for the next couple of months as we grind towards publication of the second DSTU. At the meeting itself, we disposed of around 100 line items; I thought this was excellent work since we focused on the hardest and most controversial ones.

Connectathon

We had about 70 participants for the connectathon. Implementers focused on the main streams of the connectathon: basic Patient handling, HL7 v2 to FHIR conversion, Terminology Services, and claiming. For me, the key outcomes of the connectathon were:

  • We got further feedback about the quality of specification, with ideas for improvement
  • Many of the connectathon participants stayed on and contributed to ballot reconciliation through the week.

The connectathons are a key foundation of the FHIR Community – they keep us focused on making FHIR something that is practical and implementer focused.

We have many connectathons planned through the rest of this year (at least 6, and more are being considered). I’ll announce them here as the opportunity arises.

Collaborations

Another pillar of the FHIR Community is our collaborations with other health data exchange communities. In addition to our many existing collaborations, this meeting the FHIR core team met with Continua, the oneM2M alliance, and the IHE test tools team. (We already have a strong collaboration with IHE generally, so this is just an extension of this in a specific area of focus).

With IHE, we plan to have a ‘conformance test tools’ stream at the Atlanta connectathon, which will test the proposed (though not yet approved) TestScript resource, which is a joint development effort between Mitre, Aegis, and the core team. We expect that the collaboration with Continua will lead to a joint connectathon testing draft FHIR based Continua specifications later this year. Working with oneM2M will involve architectural and infrastructural development, and this will take longer to come to fruition.

FHIR Infrastructure

At this meeting, the HL7 internal processes approved the creation of a “FHIR Infrastructure” Work group. This work group will be responsible for the core FHIR infrastructure – base documentation, the API, the data types, and a number of the infrastructure resources. The FHIR infrastructure group has a long list of collaborations with other HL7 work groups such as Implementation Technology, Conformance and Implementation, Structured Documents, Modelling and Methodology, and many more. This just regularises the existing processes in HL7; it doesn’t signal anything new in terms of development of FHIR.

FHIR Maturity model

One of the very evident features of the FHIR specification as it stands today is that the content in it has a range of levels of readiness for implementation. Implementers often ask about this – how ready is the content for use?

We have a range – Patient, for instance, has been widely tested, including several production implementations. While the content might still change further in response to implementer experience, we know that what’s there is suitable for production implementation. On the other hand, other resources are relatively newly defined, and haven’t been tested at all. This will continue to be true, as we introduce new functionality into the specification; some – a gradually increasing amount – will be ready for production implementation, while new things will take a number of cycles to mature.

In response to this, we are going to introduce a FHIR Maturity model grading based on the well known CMM index. All resources and profiles that are published as part of the FHIR specification will have a FMM grade to help implementers understand where content is.

FHIR & Semantic Exchange

I still get comments from some parts of the HL7 community about FHIR and the fact that it is not properly based on real semantic exchange. I think this is largely a misunderstanding; it’s made for 2 main reasons:

  • The RIM mappings are largely in the background
  • We do not impose requirements to handle data properly

It’s true that we don’t force applications to handle data properly. I’d certainly like them to, but we can’t force them to, and one of the big lessons from V3 development was that we can’t, one way or another, achieve that. Implementers do generally want to improve their data handling, but they’re heavily constrained by real world constraints, including cost of development, legacy data, and that the paying users (often) don’t care.

And it’s true that the RIM mappings have proven largely of theoretical value; we’ve only had one ballot comment about RIM mappings, and very few people have contributed to them.

What we do instead, is insist that the infrastructure is computable; of all HL7 specifications, only FHIR consistently has all the value sets defined and published. Anyone who’s done CCDA implementation will know how significant this is.

Still, we have a long way to go yet. A key part of our work in this area is the development of RDF representations for FHIR resources, and the underlying definitions, including the reference models, and we’ll be putting a lot of work into binding to terminologies such as LOINC, SNOMED CT and others.

There’s some confusion about this: we’re not defining RDF representations of resources because we think this is relevant to typical operational exchange of healthcare data; XML and JSON cover this area perfectly well. Where RDF representations will be interface between operational healthcare data exchange and analysis and reasoning tools. Such tools will have applications in primary healthcare and secondary data usage.