#FHIR DSTU ballots this year

Last week, the FHIR Management Group (FMG – the committee that has operational authority over the development of the FHIR standard) made a significant decision with regard to the future of the FHIR specification.

A little background, first. For about a year, we’ve been announcing our intent to publish an updated DSTU – DSTU 2 – for FHIR in the middle of this year. This new DSTU has many substantial improvements across the entire specification, both as a result of implementation experience from the first DSTU, and in response to market and community demand for additional new functionality. Preparing for this publication consists of a mix of activities – outreach and ongoing involvement in the communities and projects implementing FHIR, a set of standards development protocols to follow (internal HL7 processes), and ongoing consultation with an ever growing list of other standards development organizations. From a standards view point, the key steps are two-fold: a ‘Draft for comment’ ballot, and then a formal DSTU (Draft Standard for Trial Use).

  • Draft For comment: really, this is an opportunity to do formal review of the many issues that arose across the project, and a chance to focus on consistency across the specification (We held this step in Dec/Jan)
  • DSTU: This is the formal ballot – what emerges after comment reconciliation will be the final DSTU 2 posted mid-year

In our preparation for the DSTU ballot, which is due out in a couple of weeks time, what became clear is that some of the content was further along in maturity than other parts of it; Some have had extensive real world testing, and others haven’t – or worse, the real world testing that has occurred has demonstrated that our designs are inadequate.

So for some parts of the ballot, it would be better to hold of the ballot and spend more time getting them absolutely right. This was specially true since we planned to only publish a single DSTU, then wait for another 18months before starting the long haul towards a full normative standard. This meant that anything published in the DSTU would stand for at least 2 years, or if it missed out, it would be at least 2 years before making it into a stable version. For this content, there was a real reason to wait, to hold off publishing the standard.

On the other hand, most of the specification is solid and has been well tested – it’s much further along the maturity pathway. Further, there are a number of implementation communities impatient to see a new stable version around which they can focus their efforts, one that’s got the improvements from all the existing lessons learned, and further, one with a broader functionality to meet their use case. The two most prominent communities in this position are Argonaut and HSPC, both of which would be seriously impeded by a significant delay in publishing a new stable version – and neither of which use the portions of the specifications that are behind in maturity.

After discussion, what FMG decided to do is this:

  • Go ahead with the ballot as planned – this meets the interests of the community focused on PHR/Clinical record exchange
  • Hold a scope limited update to the DSTU (planned to be called 2.1) later this year for a those portions of the DSTU that are identified as being less mature

The scope limited update to the DSTU will not change the API, the infrastructure resources, or the core resources such as Patient, Observation etc. During the ballot reconciliation we’ll be honing the exact scope of the DSTU update project. Right now, these are the likely candidates:

  • the workflow/process framework (Order, OrderRequest, and the *Request/*Order resources)
  • The financial management resources

For these, we’ll do further analysis and consultation – both during the DSTU process and after it, and then we’ll we’ll hold a connectathon (probably October in Atlanta) in order to test this.

2 Comments

  1. Lloyd McKenzie says:

    Small correction: I think you meant to say “The scope limited update to the DSTU will not change the API, the infrastructure, data types, or the core resources such as Patient, Observation etc.”. Obviously it’ll change some of the resources that were identified as having limited readiness. Profiles based on those resources would likely change as well.

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen

*

%d bloggers like this: