FHIR Product Roadmap January 2017

R3 plans

The FHIR project is presently finalising “STU3” (Standard for Trial Use, release 3). This 3rd major milestone is currently close to completion. We’ve been meeting in San Antonio this week to finalise ballot reconciliation, perform testing and quality activities, and we are now focusing on preparing the final publication package. Following our publication plan we expect to be publishing release 3 on or about Mar 20.

R4 plans

Once R3 is published, we will start working on release 4. The various committees that manage the different parts of Release 4 have been discussing their scope of work for R4, and planning their engagement and implementation activities to support that this week.

Some of the major things under consideration for Release 4:

  • Improvements across all domains
  • Cds-hooks integrated in FHIR Specification
  • Query language framework
  • Support for integrating research and clinical practice

The most significant change is that R4 is expected to be the first ‘normative version’. It’s important to understand what that means. We will continue to follow our overall maturity model, where content gradually matures through testing and implementation activities that demonstrate success in the real world. The end of the process is “normative” (“FMM level 6”), where the standard becomes stable, and breaking changes are no longer considered.

Only some portions of the specification are candidates for being normative. We are currently considering balloting the following parts of the specification as normative:

  • Infrastructure (API, data types, XML/JSON formats, conformance layer resources like StructureDefinition and ValueSet)
  • Administration (amongst others Patient, Organization, Practitioner)

We will continue to seek and receive comments about this. Some clinical resources may be considered, depending how implementation experience unfolds this year.

Overall planned R4 timeline:

  • Dec 2017: publish first draft of R4 for comment (finalise plans for normative sections)
  • Jan 2018: first R4 based connectathon(s)
  • April 2018: ballot R4
  • May – Sept 2018: ballot reconciliation
  • Oct 2018: publish FHIR R4

We will conduct a round of market consultations in Aug/Sept 2017 to seek comment on this timeline from the FHIR community.

Note that this timelines anticipates that we publish R4 in October 2017 irrespective of the outcome of the normative ballot. Anything that has not passed normative ballot will continue to published as STU. We are still working on preparation, quality and balloting processes to support the normative FHIR ballot.

Longer term, we anticipate following R4 with a roughly 18 month publication cycle, with increasing normative content.

Implementation Progress

FHIR is a specification for a common API for exchanging healthcare data between information systems. Any information system supporting the healthcare system can choose to implement the common API, and exchange data following the rules. FHIR enables a ‘healthcare web’ to exist, but doesn’t actually create it.

HL7 is pleased to work on the FHIR specification with many hundreds of partners, who are all implementing the specification to exchange data in service of the healthcare needs to their enterprises, their customers, and, ultimately, patients. HL7 does not ‘implement’ the specification (other than various prototype/test services) – our partners and other healthcare services do.

Argonaut Project

One particularly important sub-group of the FHIR community is the Argonaut project, which is a joint project of major US EHR vendors to advance industry adoption of FHIR and we’ve had many questions about the Argonaut implementation timeline for EHR access. With regard to the Argonaut community:

  • The Argonaut STU2 specification for Common Clinical Data Set elements is close to being finalized and will be announced shortly.  The Argonaut STU3 specification for Provider Directory will be published after final balloting of STU3
  • Most Argonaut members who are certifying an API with ONC are using the Argonaut specification; most certifications are expected in Q1/Q2 2017
  • Software roll-outs have commenced — progress will vary depending on the vendor
  • It is presently unknown what the adoption rate by provider institutions will be — MU and MACRA in the US provide incentives to make a patient-facing API available by the end of 2017
  • Some of the Argonaut interfaces provide additional functionality not yet described in the Argonaut specification, but there is considerable appetite for additional services beyond what is currently available. The Argonaut project will be making announcements about its future plans shortly which will be announced in a press release, through collaboration channels, and at www.argonautproject.org

 

New FHIR Milestone Publications

HL7 is is pleased to announce that yesterday, the FHIR team published of a new set of Milestone releases. Included in this release:

FHIR Specification

This release is the Candidate version for the 3rd release of FHIR – technical, STU3. We’ve done much of the reconciliation following the September ballot, and this is in effect, the candidate for STU3 for technical review post ballot. In addition, this publication serves as:

  • The stable base for the upcoming connectathon in San Antonio
  • The stable base for the open ballots on implementation guides (see below)

We’ll take QA and implementation feed back on this version, apply a new round of edits, and publish the final version of release 3 towards the end of February 2017.

Alert readers may note that out original plan was that we’d publish the final Release 3 at the end of this year, but during October it become clear that the cumulative load of ballot (1500 comments) and continuing change proposals from implementers (averaging 3-4/day long term), we could only meet that timeline by sacrificing quality, and – after consultation – the FHIR community preferred for us to hold off till February. But we still needed to publish the candidate release now for the other goals above.

We encourage all the FHIR implementers, current and future, to have a good look at this candidate version, and preferably, prototype systems against it (the change notes may help).Then tell us about any issues that you find. Use gForge (and/or chat.fhir.org), because this content is not open for ballot this cycle. Note, though, that this is transient version that won’t be supported by tools and reference implementations etc going forward, so make sure migration is part of your plan if you implement against this version.

Implementation Guides

This set of publications marks a significant maturation of the US realm FHIR implementation guides. We’ve taken the core content specifications out of DAF (previously known as DAF-Core) and moved them into a new US-Core implementation guide. This is the base implementation guide for all uses of FHIR in the US Realm. It’s presently heavily driven by the Common Clinical Data Set (CCDS) and other Meaningful Use Program requirements, but it’s going to be more than that – it’ll be the one place for all general US Realm rules about how to use FHIR, including:

  • Identifiers and Code Systems
  • Common Patient Demographics
  • Profiles on common clinical content (as now, per Meaningful use)
  • Standard Consent Profiles

On top that, there’ll be a series of domain/solution focused implementation guides. This ballot cycle, we are balloting the following US implementation guides that build on the US-Core:

  • DAF-Research: A specific set of profiles for research access to EHR data, developed in association with the PCORI project and others
  • CCDA: a set of profiles that make it clear how to implement the parts of CCDA not covered by US-Core using FHIR documents. This will be important for sharing the full patient record (not just CCDS)
  • Medications Maturity Project: a draft set of specifications that initiate a project to bring the Medications module in FHIR to maturity at least for US usage (also, many other countries are just launching into the same kind of project)

All these are open for ballot, and you are invited to participate if you’re an HL7 member (also, non-HL7 members can participate in HL7 ballots, for a small fee)

Note that these are all US specific implementation guides. If you’re an HL7 member, but not a US based implementer, you can still participate, but it’s better to do so through gForge directly rather  Other HL7 affiliates are also welcome to publish their content under hl7.org/fhir/[2-letter-country-code] but as yet none have asked to do so.

FHIR STU3 Ballot Documentation

FHIR STU3 (Standard for Trial Use) is open for Ballot. For those participating in the ballot (entrance to the ballot is already closed under ANSI rules), here’s a few notes about the ballot process to help focus your attention (note: If you didn’t enrol in the ballot pool, you can still make comments directly on gForge, though they won’t count as ballot formally).

Note, if you’re balloting on FHIR, the STU 3 Ballot Welcome is a useful place to start. In addition, see:

Beyond this, there’s some specific things for balloters to consider when balloting:

  • A significant amount of work has occurred around Workflow in FHIR, with an objective of improving consistency around definition, request and event-related resources, as well as providing guidance around the different mechanisms FHIR supports for managing various styles of workflows. One of the outcomes of this change is that some resources have been revised to align with the workflow patterns and many more resources are expected to undergo this alignment post-ballot. Reviewers are encouraged to consider the potential impact of alignment as part of their ballot feedback.
  • The proposed Vital Signs Profile is created to enable general interoperability between all all vital signs handling systems – particularly with an eye to consumer mediated exchange. If you think that’s a good idea (rather than every system doing vital signs differently) – or you think it’s a bad idea – ballot about it
  • A note about the CQF (Clinical Quality Framework) ballot: during the editorial preparation of the FHIR ballot, the editors integrated the clinical quality framework part of FHIR more directly with the FHIR publication itself. As a result of this, it’s no longer clear what exactly is FHIR, and what is CQIF. However this happened after the FHIR and CQF ballots were announced as separate ballots). We will combine the ballots for FHIR and CQF, and then sort the line items based on the content they address, so that balloters don’t need to worry about the separation between the two. Balloters need only vote against one of the two. We expect that in the future CQF won’t be a separate ballot – it’s just a module in FHIR
  • We’ve introduced a new navigational framework to the ballot, by breaking it up into “modules”. Each module has a page of it’s own that references key content, addresses common implementer use cases, and provides a roadmap for the planned future of the module. These are all a work in progress; comments are welcome

The next time we ballot a maj0r release of FHIR (release 4, perhaps in 12 months or so), we’re planning to bring some of the key foundations of FHIR forward with a Normative status. We don’t yet know exactly what parts (depends partly on how this ballot goes), nor have we worked through the process implications of taking some of the content normative. This may change how you ballot, particularly for artefacts with the higher level maturity levels. (btw, note that MnM is working on clarifying Maturity levels for more kinds of artefacts than just Resources).

Note: we have changed to “STU” from “DSTU” – we’ve dropped the “Draft” part, since FHIR is long past being a draft.

 

FHIR Meeting Report – Montreal, May 2016

Preparation for STU 3

The main focus of the meeting was preparing for the September ballot of release 3, which will be “STU  3” (note that we’re now using the title “STU” – Standard for Trial Use –  rather than “DSTU”  – Draft Standard for Trial Use – to reflect that important parts of the spec are well past the draft stage)

Planned key dates:

  • ballot sign up starts: Jul 27
  • ballot opens: Aug 12
  • ballot closes: Sept 12
  • Baltimore Connectathon / HL7 meeting: Sept 16-23
  • tentative target release date for STU 3: Dec 31

STU 3 is currently planned to include:

  • formats: no change to XML & JSON formats, but we will generate JSON schema. Introduction of RDF, tied to an ontological base
  • RESTful API: no change to existing API, bar some clarifications around transactions. Maybe add Patch?
  • Conformance – split out CodeSystem from Value set and minor changes to other resources, including the use of FluentPath instead of XPath
  • Core Clinical, Administrative & Financial resources – ongoing minor changes in response to trial use and improved quality
  • Continuing improvements to the Clinical Decision Support / Quality Measure framework
  • A new framework for workflow / task management
  • Draft mapping framework and CCDA/FHIR mapping guides

Alongside STU3, we expect to be providing a full tool chain to support implementation guides, covering editing, publishing, validation, and a public registry

Growing Maturity

One clear conclusion from this is that growing importance of the FMM (maturity model) – some areas of the specification are quite stable now, and are being managed accordingly. STU3 will probably be the last version of FHIR that doesn’t include any normative content.

With regard to FMM levels, In the lead up to the Montreal meeting, we surveyed the FHIR use base. From the results of that survey, we were able to make the following list of resources that are a priority for implementers:

Patient Observation Medication Condition
Practitioner DiagnosticReport MedicationOrder AllergyIntolerance
Organization DiagnosticOrder MedicationStatement Immunization
Encounter Bundle MedicationAdministration CarePlan
Person Conformance MedicationDispense Procedure

Specifically, these are resources that the community would most like to see move up through the maturity levels, so the HL7 committees will prioritize these resources when preparing for ballot. Note, though, that it’s mostly up to the community to trial these resources now.

Specification Road map

The FHIR specification is now starting to have real breadth and depth, and we’ve had some comment about growing complexity of the specification. In particular, these areas have attracted comments:

  • RDF / Base Ontology work
  • Fluent Path and the new mapping language
  • Clinical decision support resources
  • CIMI / logical model development

The concern around this work indicates that we need to provide better a better road map to the specification on the main page, and the documentation page, so that people can better understand how these parts of the specification relate to each other, and which parts are relevant for them to implement.

We will be working on this over the next few months.

Acknowledgements

The FHIR community continues to grow in both size and importance. 1000s of implementers have taken part in connectathons, and the number of active contributers – committers, editors, work group co-chairs, facilitators, evangelists – just keeps growing. And not just the number, but the volume and depth of their input.

The FHIR community is our biggest asset – and it’s getting bigger every day.

May 2016 FHIR Release

The FHIR team is pleased to announce that a new stable version has been released, at http://hl7.org/fhir/2016May. This version represents the first stable release of the candidate release #3 for FHIR, and has been released to support the Montreal Connectathon and the CQL on FHIR ballot.

This version includes a number of significant changes and new features:

These are just the highlights – there have been changes to nearly every resource in response to user feedback and new requirements and implementation projects. Note that there’s a few significant breaking changes in this version.

The Montreal Connectathon will be held on May 7 / 8 at the next HL7 WGM. We’re going to have a wide variety of tracks for implementers to participate in, including:

  • Introductory Patient track
  • Clinical Decision Support (CDS Hooks, CQF on FHIR, CDS Enablement Services)
  • Workflow (Lab Orders)
  • Terminology Services, Genomics, Structured Data Capture
  • A special Canadian SMART on FHIR track
  • And yet more…

Some of these are established tracks, while others are new additions. With that much going on, it’s quite likely we’ll run out of space (120 seats), so register early. For full details about the connectathon and the tracks, see the FHIR Wiki.

p.s. This is called the “May 2016 release” even though it’s actually released at the end of March because the connectathon, the ballot, and other feedback from the release will be processed at the May WGM.

#FHIR Publishing Plans

At the Orlando meeting, the FHIR Management Group (FMG) made an important decision around the future plans for the FHIR specification.

In March 2015, the FMG decided to publish DSTU2 that covered the base infrastructure, and to plan to release a DSTU 2.1 that left the infrastructure unchanged, and filled out additional details around the Financial and workflow resources, for ballot in the May ballot.

We’ve been following that plan until the meeting in Orlando, but it was evident that we needed to reconsider our plans. There were two reasons why:

  • Resolving the issues around the workflow resources was taking longer than we hoped, and sticking to our plan would mean no connectathon testing of the redesign
  • There was ongoing pressure to make changes to resources that were frozen for DSTU 2.1

After consulting with as many stakeholders as we could, and considering the ramifications of waiting until the September ballot, FMG decided that we will no longer publish a DSTU 2.1 version. We will instead plan to ballot DSTU 3 in September, with a likely publication date late this year.

At this stage, we don’t know all of what is planned for DSTU3. It certainly will include:

  • Significant changes to the financial resources
  • A total redesign of the workflow related resources
  • A set of new resources to support clinical reasoning and decision support

There will be other changes; these will be announced as the process continues.