This crossed my desk this morning via Grahame Grieve (HL7 Product Manager for FHIR).
-- Keith
-- Keith
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:
<![if !supportLists]>· <![endif]>Improvements across all domains
<![if !supportLists]>· <![endif]>Cds-hooks integrated in FHIR Specification
<![if !supportLists]>· <![endif]>Query language framework
<![if !supportLists]>· <![endif]>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:
<![if !supportLists]>· <![endif]>Infrastructure (API, data types, XML/JSON formats, conformance layer resources like StructureDefinition and ValueSet)
<![if !supportLists]>· <![endif]>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:
<![if !supportLists]>· <![endif]>Dec 2017: publish first draft of R4 for comment (finalise plans for normative sections)
<![if !supportLists]>· <![endif]>Jan 2018: first R4 based connectathon(s)
<![if !supportLists]>· <![endif]>April 2018: ballot R4
<![if !supportLists]>· <![endif]>May – Sept 2018: ballot reconciliation
<![if !supportLists]>· <![endif]>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 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:
<![if !supportLists]>· <![endif]>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
<![if !supportLists]>· <![endif]>Most Argonaut members who are certifying an API with ONC are using the Argonaut specification; most certifications are expected in Q1/Q2 2017
<![if !supportLists]>· <![endif]>Software roll-outs have commenced — progress will vary depending on the vendor
<![if !supportLists]>· <![endif]>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
<![if !supportLists]>· <![endif]>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
No comments:
Post a Comment