This is the product director’s report from the 2018 September Working Group Meeting, held in Baltimore.
Ballot Status
Our focus this meeting was ballot reconciliation for the R4 milestone. We balloted R4 in 5 parts:
- Infrastructure – RESTful API, formats, data types, etc
- Terminology and Conformance – Profile/Extension definition framework, and Code system/Value Set
- Patient
- Observation
- Everything else (‘core’)
The first 4 ballots were normative, which is an ANSI term for a full standard. That means that we’ll be more tightly constrained in the types of changes we can make – generally “no breaking changes”.
Negative comments for the Infrastructure and Patient ballots were able to be resolved without making substantive changes. However, for both Terminology and Conformance, and Observation, ballot reconciliation and editorial review led to 2 substantive changes each. As a consequence, we’ll be re-balloting a total of 4 substantive changes in an out-of-cycle ballot from Nov 6th to Dec 6th. These ballots are only on the 4 specific changes, and ballot responses may only be provided by the members who participated in the prior 2 ballots for FHIR R4 (so there’s no additional sign-up allowed during the “notification of ballot period”). If you signed up for the Sept. ballot but did not vote, by default you won’t be able to vote in this third ballot. However, if you’d like to be reinstated in the pool for this out-of-cycle ballot you should submit an appeal HL7 HQ.
We’ll be very strict about scope for this third ballot. You’re free to submit feedback about the specification for consideration for R5, but we won’t be accepting any feedback for R4 as part of the ballot process other than comments specifically related to the 4 changes up for review.
Recirculation ballot: if there are any negatives that are not withdrawn from our normative ballots for the FHIR content, then HL7 will conduct a special vote amongst the members that balloted on the document to check that they will agree with the committee’s disposition of all non-withdrawn negative comments. It provides all ballotters a chance to adjust their final vote – changing it to affirmative or negative. The recirculation process adds 2 weeks to the publication cycle, pushing it into the Christmas period. We’ll be talking with negative ballotters about whether they’re comfortable withdrawing their negatives votes so we can avoid this extra step if at all possible.
The final decision on pass or fail is based on the final count of votes for the final vote for each ballot grouping (Sept. for Infrastructure and Patient and Nov. for Terminology/Conformance and Observation) as adjusted by recirculation if that occurs. If we get 75% affirmative votes, the content will pass. If not and we pass by 60%, we have the option of publishing as STU instead. If that doesn’t happen, then we’re faced with a brand-new ballot cycle. We therefore encourage all of those who are part of the ballot pool to participate in the November cycle and, if necessary, the recirculation process, to ensure that the outcome reflects the will of the community.
Despite this complexity, we are still hopeful we will gain the support of the community so we can publish the final version of R4 in late December this year.
Fire Alarm
There was a fire alarm during one of the committee meeting slots. (yes- a real fire alarm, but as you can imagine, there was a great deal of joking about FHIR alarms). Here’s a photo of the FHIR-I committee demonstrating committee best practice by continuing the meeting in the park outside the hotel:
Quote from Michel from Firely: “Fire will not keep us from completing FHIR!”
.. and that serves as a great example of the spirit of the whole meeting. (btw, it was a false alarm)
Roadmap planning
It’s a few years since HL7 published a road map for the FHIR specification and community. We’ll be working on this in the lead up to the San Antonio meeting in January, and I’ll be publishing a formal roadmap soon after.
We’re getting strong feedback from the market about FHIR: the potential is great, but there are plenty of deployment and adoption issues. Of course, that’s not a surprise, given what we know of the healthcare system. Part of the roadmap will definitely be focused on identifying technical barriers to adoption and working with the market participants to resolve those (through new standards, connectathons, and supporting regulatory and market initiatives).
Connectathon
The connectathon at the start of the meeting was our biggest ever – 286 listed participants:
h/t Sandra Vance for the graph and for administering the connectathon again.
I’ve given up trying to even track the sheer variety of activities that are taking place at the connectathon – it’s a remarkable gathering of thought leaders and doers. But here’s some of the subjects that were worked on at the connectathon:
- CDS Hooks (the biggest track, as usual)
- Bulk Data / Data Analytics support
- Accessing Clinical Notes from EHRs
- Subscriptions / Application Synchronization
- Questionnaires
- International Patient Summary
- Practical security of data exchange
- Document handling
- Evidence Based Medicine
- Public Health case reporting
- Clinical Research
- … and many more
Implementation Guides
FHIR is a platform standard – a set of APIs and content models for supporting healthcare across the world. A few implementations (clinical data repositories, personal heath repositories) can use FHIR just as it is. But as soon as you start dealing with applications that depend on each other, or with clinical workflows, then you need additional agreements on top of what everyone agrees to internationally.
We call the documents that publish these agreements ‘Implementation Guides’ and they include a combination of:
- Human readable documentation (web site) and computer readable documentation (in an NPM package)
- Profiles and extension definitions
- Value sets, Code Systems, mappings between code systems
- API definitions & Choreography
- Examples & Test Scripts (and conformance requirements)
- Security and deployment agreements.
We’re still maturing our overall tool chain and publishing support for these documents – while we’re scaling up our ability to produce, review, and publish them. We’ve felt some growing pains around this process and we’re continuing to refine our tools and processes.
We’re going to see a lot more of these in the coming year. The September 2018 ballot included 14 implementation guides along with the core FHIR specification – and reconciliation is proceeding.
Note that publishing implementation guides is not a goal in itself; an implementation guide only has value if there’s a community that cherishes it, abides by it, and maintains it over time. One priority as we mature our processes is to ensure that this community perspective is maintained.
Personal Note
We’re just about finished publishing FHIR R4, our first with some normative content. All the signs are that it’s going to be a landmark milestone. Indeed, the opening of the HL7 WGM coincided with a pivotal blog from ONC that FHIR adoption is at an inflection point in the USA. It’s been a remarkable ride, and I look back on it with amazement. The real strength of FHIR is not the technical spec (though I’m proud of that), it’s the community: thousands of people contribute to the FHIR community development process, many going far beyond the call of duty.
Together, we’re going to change the world.
HL7 onFHIR 