Here’s a FHIR progress report from the HL7 working meeting in Chicago held the week before last.
Overall, the hype about FHIR is astonishing, and I don’t see any evidence that it’s starting to slow. While we were in Chicago, Wes Rischel made some interesting comments about where FHIR is (though following his logic, our current task is to bring on the trough of disillusionment as soon as possible) . The FHIR project team is aware that there is a duality here: expectations and excitement about FHIR are high, but what we have published is still an early beta, and FHIR is not yet ready to meet the expectations that people have about it. We intend and expect to get there, but it is important that stakeholders and implementers understand that there’s still a lot of work to be done.
At the Chicago meeting, we held two connectathons: our normal implementer connectathon, and a clinical connectathon.
The normal connectathon was a largest yet (close to capacity). Each connectathon, we grow in 3 respects: the number of attendees, the scope of the specification that we test, and the sophistication of the outcomes. What really pleases me is that it’s not just old hands that produce sophisticated outcomes, but first time attendees who are able to use FHIR to extend their existing applications and platforms to create interesting new solutions. Sadly, the things that are seen and/or shown at the connectathon are not packaged in a way suitable for publication – maybe this is something we can change next time? (There’s an opportunity for a volunteer there). This connectathon included a focus on Smart on FHIR, and this created something new for us: a strong focus on servers rather than clients.
The clinical connectathon was something new. We held the clinical connectathon because we recognise that the connectathon process is fundamental to the strength of the specification – we’ve tested the technical interoperability aspects repeatedly, and improved the specification in response to what we’ve learnt. We know that the strength of FHIR isn’t because we’re clever, but because we keep testing it. However our existing connectathons are limited in that they require users with development tools – they are focused on system implementers. Users with clinical knowledge are generally excluded from participating, and we’ve not tested the suitability of FHIR for clinical interoperability. In fact, this is the gap between hype and reality that is our most pressing concern. The clinical connectathon intended to begin addressing this gap.
The clinical connectathon focused on clinical exchange – that is, clinical users connecting with each other. For this, the patient care group co-chairs prepared a set of clinical scenarios, and the FHIR project team provided a single tool that all the users would use to enter a set of data for an exchange associated with the scenario. Users would then review what they received and compare it to the scenario. Because all the users have the same tool, and the tool is focused on the specification, rather than being a normal EHR, this is about testing the specification, not some other software.
Technical note, for those interested: the tool has 2 parts, client and server. The client was written primarily by Peter Bernhardt (a huge effort, thanks) with assistance from David Hay and Viet Nguyen, and the server is http://fhir-dev.healthintersections.com.au. For the data entry, the server converts a profile to a questionnaire, the client presents the questionnaire, creates a set of answers, and then the server converts these answers into a resource that conforms to the profile.
On the day, the clinical connectathon reminded me of the first normal connectathon we had – the potential of both FHIR and the connectathon was evident, but we didn’t get that much achieved on the day. For the clinical connectathon, we identified plenty of opportunities to improve the tool, and identified a number of questions about how the common clinical scenarios should be represented in the resources. Most importantly, for me, my success criteria for the first connectathon were met: all participants agreed that it was a worthwhile exercise, and that it’s worth continuing, and that we now have a better way to drive clinical engagement with the specification.
Status of the FHIR community
Up to now, FHIR has primarily been a standards project: a group of people with a core task of producing a standard. In order to do produce a good standard, we’ve had a strong implementation focus. That is, we worked with implementers in order to produce a better standard. But we recognize that the focus now needs to change: we produce a standard in order to enable implementations to solve important problems. The FHIR project and management teams will place increasing focus on implementation and engagement with a wider community. One tangible result of this is that we’ll create a home for the FHIR community at http://fhir.org, which presently simply redirects to the specification. I’ll post more about this later.
This meeting also represented the first ballot of a FHIR implementation guide – a draft for comment ballot of the U.S. Realm ONC Structured Data Capture project). It received over 200 comments from 20 voters. We still have work to go on how implementation guides will be produced, but this is a start. In the December-January ballot cycle, the entire IG will go back to ballot, this time with the entire FHIR specification as part of a second “draft for comment” in preparation for the DSTU ballot cycle in May.
Generally, the infrastructure to produce implementation guides will be a major focus for the core team in the next couple of months – we’re now working a number of implementation guides in addition to this one.
- We published an initial set of “FHIR principles” for consideration. These are important because they define the scope of what FHIR is and is not, and the principles that we keep in mind when evaluating change proposals
- We initiated a process to QA review all the codes that are defined as part of FHIR, and to see whether we can get them from somewhere else. Also, we will be working on a social-media driven process for design review of FHIR value sets, since these codes often have a different life cycle than simple ballot (e.g. once published, they can be pre-adopted by users without going through ballot first)
- We are getting closer to publishing a registry for FHIR profiles, value sets, etc. An RFP calling for the provision of the services to support this will be released soon (if you are interested, subscribe to the FHIR email list)
- Exactly what the letters “FHIR” stand for is a little difficult to pin down. The specification itself offers 2 different meanings, and educational material offers more. The correct name is “Fast Healthcare Interoperability Resources”, and the specification will be updated soon
We have now started on the work of preparing the next version of FHIR in earnest. It’s going to be big task; as of today there are 316 open tasks relating to the next specification. While in Chicago, we made a number of decisions that are breaking changes for the next version of the FHIR specification:
- We will change two data type names: “Schedule” to “Timing” (We want to use Schedule as the name a resource), and “Contact” to “ContactPoint” (to resolve implementer confusion about double use of the name “Contact”
- We will change the way that extensions are represented in JSON (I’ll post about this more later)
- We will change the way a Composition is stitched with it’s content (next blog post)
- We will change the way that version specific updates are performed to align with other web specifications
- We will add multi-lingual support to the value set resource (and will extend the specification infrastructure to make use of it)
Note there are other changes already made, see http://hl7-fhir.github.io/history.html
In addition, we’ll be working on adding a bunch of new resources:
- Nutrition Orders
- Financial transactions
- Information sharing consent
- Device management
Finally, we decided that future connectathons at HL7 working meetings will be based on the future DSTU version
- We were pleased to welcome the OpenMRS team to the connectathon for the first time. We expect to have an ongoing and increasingly fruitful collaboration between the FHIR and OpenMRS communities. One aspect of this that we will be looking at is what we can do to make FHIR more suitable for use in communities other than the developed world – this has both technical and requirements based implications.
- We are hoping to add sections to the specification dealing with the complicated issues around handling identification and record keeping associated with the birth process, and how to code genetic mutations for oncology.