So today, to mark the end of the year, we’ve posted the final DSTU candidate version of FHIR.
This is not the DSTU itself: it’s the editors draft, which is now undergoing several weeks of QA review for ballot completion, technical errors, layout issues, and spelling mistakes etc.
Our intent is that we won’t be making substantiative changes to the DSTU any more, but if there’s changes that really are justified, we’ll still make them – we have one last connectathon to test everything out. Btw, early registration for that connectathon closes today.
Today’s version of FHIR is the product of 100’s of hours of review, argument, and work., and many people have contributed to the process. We (the FHIR project team – myself, Lloyd, and Ewout) would like to thank all of the contributers (they are named in the specification). We decided to turn FHIR into a real standard very nearly 2 years ago. We originally targeted the end of this year, but earlier this year we reset to the end of January, to give us one more meeting to work on it. I’m pretty pleased that we’ve pretty much stuck to the schedule, though it’s certainly been a grind.
When I compare the final version of FHIR to what we first envisaged 2 years ago, the principle difference is how deep the specification is. There’s some technical stuff there we didn’t anticipate, like the strength of the terminology under-pinnings, and the amount of work the publication tooling does to validate what is published. But the real difference in depth is the amount of interest that we’ve had, the amount of review that we’ve had. And now, adoption, implementation, engagement: these are our focus from now.
A question for any readers: we’ve been discussing what version to call the DSTU version of the specification. There’s a variety of views in the team on the matter. Here’s some relevant facts:
- The existing version is 0.12 – I started at 0.01, and I’ve incremented the minor version only when we’ve needed a version break for connectathons
- We plan to implement Semantic Versioning from here on, though with a significant proviso: our current plan is that there won’t be breaking change once the normative version is published (DICOM has run for many years like this)
- The existing framework is solid and really well tested. Far more than other full standards I’ve worked on, even though it’s only a DSTU
- We don’t want implementers to think that this is a shaky alpha release that can’t be relied on
- The domain resources are far less baked than the framework – there’s definitely draft content here
- We’d usually plan to go to 1.00 as the first full normative standard, though I’m not aware of any formal rules in this regard
If there was any consensus in the team, it would be for calling the DSTU v0.8 – the 80 number has this ring for us. But if we’re not going to target 1.00 for the first normative (which seems unlikely if we follow semantic versioning during the DSTU period), then why not just call it v1.00? Comments welcome on this below, and I’ll feed them back to the team for consideration.
Finally, if you would like to make QA type comments on the DSTU candidate, you’d be welcome. Download this template: FHIR DSTU Review Template, and submit it to me by email (see right) when you’re done (deadline: January 12th 2014).