Let's Start this FHIR Right

A long time ago in HL7 there was a rule that any specification had to be re-balloted if there were substantive changes before it could be published. Back then, getting a specification published also took a very long time, and the bars to getting things past were very high. For a normative specification you had to have 90% approval, and for DSTU or Informative, you had to have 75% approval or something like that. So things took very long, and in fact, some specifications took almost a decade to get out.  HL7 was made fun of and everyone was very sad. Once HL7 realized it had a problem, it began a process improvement effort, and many of these constraints were reduced or removed as being barriers to completing the work of creating standards in a timely fashion.

So now we get to the point where, if some 50-75% of members are agreed, a (non-normative) specification can pass ballot and be published in one balloting cycle. However, this means that many substantive changes can be made, and it is up to the working group developing the standard to decide whether or not a re-ballot should be performed. I've not seen a case where they ever do in the work groups that I'm involved in, and I think that's a mistake.

Which brings me to the real topic of this post. I've been firmly behind FHIR as a specification since very early on. I've been involved in some of the early Connectathons (hack-a-thons really), and in promoting the use of it for IHE specifications and ONC specifications. I firmly believe this is great stuff. But…

We just went through a HUGE ballot cycle (HL7 received over 800 comments from 122 ballots), and made numerous changes, many of them substantive. The last time we had more than 100 votes on an HL7 Ballot was in May of 2011 on CCDA Release 1.0 with 104 people voting (and CCDA Release 2.0 had more than 900 comments).

I haven't been able to be involved in many of the reconciliation discussions (although I know my colleague John Moehrke has). So, I'd like one more chance to look over the specification and comment on it ONE LAST TIME before it becomes a DSTU. I firmly support the effort of Graham and the entire FHIR team. I've been promoting the standard internally and externally in the strongest words I have. But I'm not ready to say that it is fit to be published as a DSTU yet, and I don't want people to think that I'm against FHIR when I say that. I just want to make sure we get it right. This is brilliant stuff, the best thing to come out of HL7 in many, many years. Just let me have one more ballot. FHIR and HL7 will be better for it.

See John's post over on his blog for his thoughts on the same issue.  And if you have any questions for either of us, feel free to ask us.  We'll both be at the HL7 WGM next week!