FHIR R4 is published

HL7 is pleased to announce that FHIR R4 is now published.

R4 is the culmination of 18 months of extensive work to finalize the base parts of the specification, and incorporate changes and enhancement requests received from implementation partners across the world.

The most significant change in FHIR Release 4 is that the base platform of the standard has passed a normative ballot, and will be submitted to ANSI as a normative standard. This means that future changes should be backward compatible, so that applications that implement the normative parts of R4 no longer risk being non-conformant to the standard. The following portions of the standard are now normative:

  • The RESTful API, the XML and JSON formats, and the basic datatypes
  • The Terminology layer (CodeSystem and ValueSet)
  • The Conformance Framework (StructureDefinition and CapabilityStatement)
  • The key resources Patient and Observation

Thousands of other R4 updates and changes have been made in response to implementation experience and quality review processes.

FHIR Release 4 marks a significant milestone with the introduction of a normative base. This new maturity will help support our very active and growing community

Credits

Publishing a new Version of FHIR is a massive piece of work involving  a big community. It’s impossible to track – let alone acknowledge – everyone who’s contributed to publishing FHIR R4. We’ve given it a go in the credits page.

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.