Previous: Securing your REST API »

Outcomes from Atlanta HL7 Meeting for FHIR

May 12, 2013

Well, I’m now nearly home from the long week that is the HL7 Working Group meeting. It now goes for 7 long days from Saturday morning through to Friday afternoon. This meeting was held in Atlanta - I’d like to make some comment about Atlanta but the only time I got out of the hotel was to go to Dave Shaver’s Corepoint Party (thanks Dave). This post is a summary of the progress that occurred at the meeting for FHIR.

General

Two years ago, I conceived of something that has grown into FHIR. Since then, I’ve watched the ripples of our work expand - from just a narrow community in HL7, to include all of HL7 and the wider standards community, and then out into the middleware vendors. Now, the EMR vendors are starting to pay attention. The process is accelerating too - I never expected the EMR vendors to start paying attention to our work until at least after we had completed the DSTU phase (ballot for a “Draft Standard for Trial Use”). And as the ripples spread, the community of people working on FHIR or excited about it grows, and our growth accelerates. This creates it’s own firestorm.

(Oh, and yes, I’m now starting to come to terms with the never-ending FHIR jokes and puns).

Connectathon

For FHIR, this meeting commenced with the 3rd FHIR Connectathon. This Connectathon continued on the linear progress that we’ve been making, with more participants, more structure, and more success. We continue to have people turning up to do a cold start, where they have had their interest ignited, but have done no reading or code prior to the day. As usual, the participants are exchanging resources by the end of the first day.

Other participants have established code bases, and perhaps have attended Connectathons previously, and are honing the breadth of their implementations and working on their conformance.

Each Connectathon, we collect a list of issues - things that are broken in the specification, or where the decisions we’ve made make things harder than they should be. Also, each Connectathon, the list gets shorter and more about the corners of specification, which shows that the Connectathon process is really paying off.

The next Connectathon will (probably) be focused on PHR access to EMRs, and promises to be bigger and better (and some new participants are planning to bring physical devices that talk FHIR to the Connectathon, which should be cool).

Preparation

Our major focus right now is on preparing the specification for ballot. In order to be ready for ballot, there’s a bunch of things that we need to do around ensuring that the basic structures and quality assurance processes are in place that ensure that the resources really are useful. Like all such processes, the depth of detail that goes into this preparation is necessary but not of interest to the implementers. But it’s all going well, I think. And my particular thanks to the 30-40+ people from vendors, governments, consultants, and academics who are now working on the under-appreciated task of bringing the breadth of their experience to bear on the design of the resources.

Right now, out focus is on rounding out the resource definitions by mid-July so we can do quality assurance prior to opening the DSTU ballot in Mid-August.

There’s still some outstanding issues that we haven’t cracked yet. I’ll be making some blog posts on these in the future to solicit input from outside the community.

There’s been a little talk about FHIR having teething difficulties - and certainly there’s lots of heated discussion inside HL7 over design, approach, and so on. I’m not worried about this - these things need to happen and they bring value to the standard (see Establishing Compromise). It’s a dialectic thing.

Security

We made some real progress on the question of what the FHIR specification needs to say about security at this meeting. There’s a draft security page on this now - please look at this and comment.

Note that while the page says that it’s not really HL7’s business to develop the resources to administer the security engine, we’ve had a number of requests to do exactly that - given enough pressure from the users, it might happen, though if it does, we’ll have to find the right group of people to work on that.

Positioning & Marketing

One thing that we’re now going to have to start working on is how to position (and then market) the specification. As the specification has rounded out, it’s become quite fully featured, and a full fledged implementation is now quite a bit of work - not that simple. I’m not really concerned, though, because few systems will need to implement all the features that we’ve defined (this is a classic problem with standards).

But I’m starting to hear people express the belief that maybe FHIR isn’t quite as simple as they thought. Well, it’s never going to be simple - FHIR is going to be a standard for exchanging information about healthcare, not a simple cookbook for REST to be adapted to healthcare applications in a bespoke manner (why do that? there’s already plenty of advice and examples out there). The re-usability of FHIR, and the fact that it grapples with difficult things like patient linking/merging, for instance) means that it’s necessarily more complicated than a simple single application API, but also worth while. Still, I think that some people are thinking it’s more complicated than it is.

Part of the solution to this is to start working on a use-case based view of the specification: given a particular problem, how do I use FHIR to solve it? Some initial work is here. Contributions to this page are welcome. We’ll be doing other things as well, so watch this space. The FHIR Button is coming at you!

Using FHIR outside HL7

One big issue was resolved at this meeting. We’ve been having this running discussion about how to use FHIR outside the scope areas that HL7 plans to cover. I’ve [[blogged about this before]]. At this meeting we agreed that people will use the FHIR methodology to define their own resources, whether we want them to or not (and, indeed, we in the core team are all doing that ourselves).

So we’ve agreed that we’re going to define a process for people to do this, and work on enhancing the tooling and the public servers to support this process, and to work on ways to bring this work back towards HL7.

Partnerships

Finally, our partnerships outside HL7 are going well. We’re going to be balloting resources in partnership with DICOM, IHE and the ISO Healthcare Devices Community. There’s still some open process issues around quite how these are going to work, but the actual design is coming along well.

A commonly asked question is whether ONC is going to start using FHIR. ONC have been interested in FHIR from the start, but they are driven by their requirements to deliver working standards in very short time frames. ONC won’t be able to use FHIR in their work until it’s a DSTU, and even then they will have to take things on a case by case basis. Pretty much the same applies to other national programs - some things they need to do will lend themselves to FHIR, and they’re looking hard at what it might become, but you don’t lightly change direction of such a big and expensive ship.

IP Rules & the HL7 community

HL7 is starting to wrestle with a number of difficulties caused by the decision to make it’s IP freely available for implementation. The community is still trying to figure out exactly how free free is, how unencumbered free actually is, and what the consequences are for HL7 structure, revenue and expenditure. Maybe revenue will go up, maybe it will go down - we don’t know yet.

FHIR, on the other hand, remains truly free, open and unencumbered, and will continue to do so. FHIR is already driving new participation at HL7 - people who haven’t been able to take part before (or haven’t been interested). I’d like to think that this will make a significant contribution, but whether it does or not, FHIR is starting to really take off.