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

 

Summary Report from SNOMED Meeting

Last week, IHTSDO held their main annual business meeting and SNOMED CT Expo in Wellington, New Zealand. I attended, along with a number of other key players from the FHIR terminology community, and we took advantage of the opportunity to hold a joint meeting between the FHIR community and the IHTSDO community.

From the FHIR community’s point of view, this was an important meeting because many of the FHIR stakeholders make extensive use of SNOMED CT and we still have a long way to go before we’ve truly mastered all the issues associated with using SNOMED CT. From IHTSDO’s point of view, FHIR is a very important implementation mechanism by which SNOMED CT content is used in production, and their stake holders have identified working well with FHIR as a priority.

The joint meeting was split into 2 parts – a general exploration of the known issues, and a technical exploration of some of them. During those 2 meetings, we discussed the following issues:

  • Progress since Montreal. In the HL7 working meeting in Montreal (May 2016), the HL7 Vocabulary WG (on behalf of IHTSDO) asked the FHIR project to make several changes around the way the FHIR Publication tools handle SNOMED CT editions, versions, copyright statements, and mappings. These were almost all completed prior to the the Wellington meeting, but we’ve been unable to transition fully to the International Edition for the base FHIR specification because of some specific value sets using US specific content. We agreed that we will change to the International Edition once this content has been promoted to the International Edition.
  • Terminology Service Implementation Guide for SCT. The Terminology service API published as part of FHIR has a very active community, and we’ve been testing the API with SNOMED CT content since we first started using it (it’s already in production in Australia). However our work has primarily focused on the API, and there’s an opportunity for us to improve the service for consumers by being more consistent in how SNOMED CT structures and semantics are exposed through the API. To that end, it was recommended that HL7 and IHTSDO should collaborate on a set of detailed rules about how the SNOMED CT concepts are exposed on the terminology servers. Most of these are things that the server providers have already discussed and agreed on informally, but it would be useful to get formally documented agreement around this. IHTSDO will also look at the feasibility of providing a reference FHIR terminology server.
  • Versioning – IHTSDO is planning to move towards a more continuous release cycle. While the details of this aren’t worked out yet, it may present some issues to the way we use SNOMED CT in FHIR – though FHIR is not special in this regard: all users will have the same challenges and opportunities. We agree that we will have to consider the impact this would have on the FHIR eco-system
  • Cross-Edition support – Presently, the SNOMED CT implementation space is divided by the national release center system – many affiliates have their own edition, with additional concepts, descriptions, relationships, and reference sets. As long as all records come from within the same jurisdiction, this is ok, because you just choose an edition. But if your records cross jurisdictions – which is something that will happen for many systems implementing patient focused record support, then there is currently no specific guidance to support this. IHTSDO agreed that this is something that implementers will need.
  • Value set review – IHTSDO has performed a review of a number of SNOMED CT value sets in the FHIR specification and provided feedback to HL7 on the results. IHTSDO has also developed a reproducible review process that may be applied to other SNOMED CT value sets. It was agreed that the review of SNOMED CT value sets in the FHIR specification should be completed, and that additional SNOMED CT value sets may be identified. IHTSDO has also previously offered to provide HL7 international with a set of SNOMED CT concepts that may be used for free in its international products. Part of the value set review will include looking at opportunities where this might be useful for the FHIR specification.
  • Binding/Mapping progress / Implementation Advice – Linda Bird from IHTSDO has been working on bindings and mappings (both words are used slightly differently across IHTSDO and HL7) between SNOMED CT and FHIR resources, both a simple attribute mapping, and a more complete template binding. So far, we’ve looked at Condition, AllergyIntolerance, Observation, Procedure, Goal and Family Member History. This has identified a number of issues in terms of gaps between the relevant SNOMED CT concepts and the design of the FHIR resources. Some of these may be flaws in the FHIR resources, or in the SNOMED CT content, or they may just be inevitable results of different perspectives – that’s yet to be resolved. We need to work on this jointly, and that might lead to changes to either FHIR or SNOMED CT, or implementation guidance for FHIR implementers that use SNOMED CT, or a formal FHIR Implementation Guide. We’re not sure where that will end up yet.
  • Simplification – we also discussed an idea for providing a framework for sharing additional views on SNOMED CT as a way for helping implementers. We agreed to pursue ideas around making SNOMED CT easier to use for beginning implementers informally for now. The draft SNOMED CT Machine Readable Concept Model (MRCM) currently out for community review (http://snomed.org/mrcm) may allow these simplified views to be created automatically.

A small group of IHTSDO and HL7 participants has been selected to form a joint project group to turn all these ideas into a working project plan. We’d welcome further comment from people who are interested in this area who weren’t at the joint meeting. On the HL7 side, contact me. For the IHTSDO perspective, contact Jane Millar. We’ll be working on this over the next few months.

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.