FHIR R5 Roadmap

General

Now that we have published FHIR R4, our attention at our January 2019 meeting (in San Antonio) was focused on producing a roadmap for FHIR R5.

FHIR R5 will build on R4 by:

Moving more content to formal Normative status
Further improving the support for publishing implementation guides
Adding additional content in newly developing domains
Improving support for applications using multiple FHIR releases seamlessly, and also multi-language support and federated servers
Adding new facilities for migrating data to and from v2 messages and CDA documents

In addition, the community will continue to develop the adjunct specifications to FHIR – SMART App Launch, CDS Hooks, FHIRCast, CQL, Bulk Data specification, and others – that build out a complete API-based eco-system for the exchange of healthcare data.

HL7 will also continue to collaborate with our many partners across industry, government, and academic communities to support the overall development of data exchange and health process improvement.

Implementation Guidance

We expect some specific implementation guidance to arise out of our collaborations and both ongoing and new projects that will lead to better processes in healthcare:

Use of Smart App Launch, FHIRCast and combinations of the FHIR and DicomWeb stacks to lead to better imaging related workflows
Build in on initial Public Health collaborations to further improve bio-surveillance and morbidly/mortality reporting
Improved integration around prior authorization and financial processes
Finalize detailed genomic reporting specifications ,and develop processes to integrate translational science into operational healthcare
Provide access to the complete medical record for a patient

Timeline

Our normal cycle is about 20 months, so R5 would be expected to be published in Q3 2020.

We will be surveying our members and partners later this year to determine whether our normal cycle is appropriate, or whether the community would prefer for us to wait longer to publish so that there can be more convergence on a single version.

In addition, we may consider publishing patch releases that introduces changes only to the draft resources, since these are earlier in their maturity process, and changing more quickly.

Committee plans

FHIR is maintained by a set of committees, each responsible for a portion of the specification. Here are further details for the roadmap by committee:

Biomedical Research and Regulation aims to have the ResearchStudy and ResearchSubject advanced to maturity level 5 and will continue to work on the regulated product-related resources
Community Based Collaborative Care aims to bring Consent resource to Normative status for patient-privacy and will work on resolving the Research, Advance Directives and Treatment use cases
Clinical Decision Support and Clinical Quality Information aim to support the representation and sharing of clinical knowledge that enables a continuous quality improvement cycle and pilots of the same (e.g. business as usual)
Clinical Genomics will continue to work on refining MolecularSequence, rationalise the existing genomic content to the Genomics Reporting IG, and work with patient care on the family history pedigree representation/profile
FHIR Infrastructure’s focus will include reviewing the trial use parts of CapabilityStatement, improved facilities for managing Composition content (including use of GraphDefinition), Subscriptions, and Digital Signatures
Financial Management goals are to bring the eClaims resources to Normative status, and continue to be develop the other resource
Imaging Integration anticipates defining new resource “SpecificImageReference”, and profiling DiagnosticReports, Observations, and Procedures for imaging use cases, potentially producing formal profiles
Orders and Observations aims to bring DiagnosticReport and Device to Normative status, and to work on resource scope/boundaries for a number of resources
Patient Administration aims to bring several resources to normative status – including Encounter, improve the linkage between the administrative and financial domains, along with defining the patient merge/link functionality and completing the VhDir Implementation Guide.
Patient Care: Patient Care is targeting several resources to go normative, and working to increase the maturity of other resources, with a focus on care planning
Public Health will continue to evolve Immunization resources as experience is gathered by implementers and also support parties interested in writing FHIR IGs in the public health domain
Pharmacy continues work on the MedicationKnowledge resource and will work with the community to mature the existing medication resources. The Medication, MedicationRequest and MedicationStatement resources may be normative candidates in the R5 ballot.
Structured Documents: Consider DocumentReference for normative, and decide what to do with DocumentManifest
Security WG will focus on gaining confidence in AuditEvent Resource, Provenance Resource, and Signature datatype. New work will focus on Implementation Guides on Basic Provenance use, new operations to support GDPR (e.g. $erase), and Document Digital JSON Signature
Vocabulary: In addition to maintaining existing terminology content and processes, vocabulary will focus on finalising ConceptMap, business rules for Code System Supplements and terminology identifiers, and start working on support for Code system maintenance and development

Normative Resources

Normative resources are maintained for stability so that implementers do not have to rework existing software as new FHIR versions are published. Before bringing a resource to normative status, we require considerable real word experience to demonstrate that the design is robust and ready to be made stable.

We will work to bring the following resources to normative status for FHIR R5. Note that this is not a commitment; whether a resource will achieve normative status depends on how implementation experience unfolds.

AllergyIntolerance
AuditEvent
CareTeam
Claim
ClaimResponse
ConceptMap
Condition
Consent
CoverageEligibiltyRequest
CoverageEligibilityResponse
Device
DiagnosticReport
DocumentReference?
Encounter
ExplanationOfBenefit
ImagingStudy
ImplementationGuide
Location
Medication
MedicationRequest
MedicationStatement
Organization
PaymentNotice
PaymentReconciliation
Practitioner
PractitionerRole
Procedure
Provenance
Questionnaire
QuestionnaireResponse
SearchParameter
Subscription
VisionPrescription

Question: Publication Date for FHIR R4

Question:

Do you know if there is a firm date set for R4 being released? Or a timeframe? I have not been able to find any dates when searching online.

The short version is that we inted to publish Release 4 at about the end of this year. We still don’t have a precise date yet – it’s subject to going ballot and feedback, and we have processes that we have to follow and how long they take depends on the feedback we get.

You can see the full details of the schedule on the FHIR Wiki

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