Guest Post: FHIR Ballot Process

Jan 16, 2014

GE have asked for another round of FHIR balloting. See here and here. I don’t have time to commit my thoughts to the blog in a measured way - it’s very hard to comment rationally on this matter, and I don’t have time. So instead, Lloyd McKenzie volunteered this as a guest post: The FHIR Management Group and the FHIR Governance Board will be making the determination of whether to go back to ballot during one of their face-to-face meetings at the WGM next week.

A few things to keep in mind:

  • All balloters have had a two-week chance to review the dispositions of all ballot comments (not just their own) and the specification has been up to date reflecting those changes. Thus far, only one balloter  has indicated an issue with any of the resolutions, and it looks like we can resolve that.
  • In parallel with that opportunity for review by balloters, every page in the specification has undergone QA for style, formatting, etc. So most, if not all, minor readability issues resulting from the changes should now be cleaned up.
  • The DSTU specification is a draft. It will change and will continue to evolve.

Technically, the ballot has more than met the HL7 requirements to pass. The question is whether it would be in the interest of implementers to hold the specification back for another 6 months to go through another round of balloting, subsequent updates, QA and publication. I’m far from convinced that is the case.

One of the objectives of FHIR is to be “fast”. That doesn’t just mean “fast to design”, it means “fast to develop”. Thus far, we’ve managed to meet a pretty remarkable timeline, at least compared with HL7 v3. FHIR is also trialing some new processes and governance mechanisms. We’ve made significant use of QA reviews in addition to ballot cycles. We conduct distributed ballot reconciliation, etc.

It’s important to remember what DSTU is and what it is not. DSTU is not a “done specification”, though I realize it’s been treated that way in some cases. Anyone who treats the FHIR DSTU that way will likely regret it. FHIR **will** change as part of the DSTU process, almost certainly in a few ways that are not wire format backward compatible. While we have more implementation experience with FHIR than HL7 has ever had with a specification at this point in its development cycle, the reality is that there are significant parts of the specification that have not yet been well exercised, much less been exercised across the full diversity of the healthcare environment. The purpose of DSTU is to say “this specification is well reviewed and is solid enough to try applying it in the real world so that we may apply that real-world experience when crafting the final version of the specification”. Those who cannot tolerate risk of change should not implement based on a DSTU.

Most of the valuable feedback we’re getting now about FHIR is coming from those who are implementing it. I think we’re far better off releasing the specification for general use and implementing a responsive mechanism for dealing with implementer feedback as it’s received.

FHIR will be going to ballot again, and any interim tweaks we make in response to implementation issues will be vetted through a full ballot - as well the changes we’ve made as part of reconciliation of the first ballot. But it seems to me that we benefit implementers more by giving them our blessing to go forth and use it and then responding than we do to delay just for the sake of ensuring we dot our “I”s and cross our “T”s. (Reality is there will be plenty of undotted and uncrossed letters no matter how many cycles we go through.)

Balloting has a significant cost - it delays when many implementers can take advantage of it, it consumes HL7 and volunteer resources that could be focused on enhancing the specification and it can contribute to ballot fatigue - where reviewers get so tired of constantly reviewing content that they cease to bother anymore.

If you want to review the specification and didn’t take advantage of the two week window, go ahead and do so now (or more realistically, when you get through the WGM). If you have feedback, submit it via the gForge tracker so it can be triaged and incorporated in the next release (and if urgent, provided as “implementation guidance” to early DSTU implementers).