[{"innerBlocks":[],"name":"core\/freeform","postId":3708,"blockType":{"name":"core\/freeform","keywords":[],"attributes":{"content":{"type":"string","source":"raw"},"lock":{"type":"object"}},"providesContext":[],"usesContext":[],"selectors":[],"supports":{"className":false,"customClassName":false,"reusable":false},"styles":[],"variations":[],"apiVersion":3,"title":"Classic","description":"Use the classic WordPress editor.","category":"text"},"originalContent":"As the healthcare industry eagerly awaits a normative version of Health Level Seven International\u2019s Fast Healthcare Interoperability Resources data exchange standard, the timeline for realizing a stable version remains murky, with HL7 executives offering different opinions.

Work is continuing to advance FHIR, and it's being used by some large vendors in an increasing number of situations. But many vendors are waiting for HL7 to get farther along in its standard-setting process before investing in the development needed to incorporate FHIR into their products. A significant milestone for any standard is when it reaches a normative version--that is, a mature standard that works in most cases and most industry participants accept as essential to use.

FHIR continues to mature as an open standard for exchanging healthcare data between information systems. According to FHIR Product Director Graham Grieve, STU3 Standard for Trial Use, release 3 (STU3)\u2014the third major milestone for the initiative\u2014is expected to be published in late March.

\u201cOnce STU3 is published, we will start working on release 4,\u201d wrote Grieve in a product roadmap<\/a> posted online last month. He noted that release 4 (R4) is expected to be the first normative version of FHIR, \u201cwhere the standard becomes stable, and breaking changes are no longer considered.\u201d

Under the planned timeline, the first draft of R4 will be published for comment in December 2017; the first R4-based connectathon will take place in January 2018; an R4 ballot is slated for April 2018; ballot reconciliation would be set for May to September 2018; and final publication of FHIR R4 would occur in October 2018.

However, this schedule stands in contrast to the timeline outlined by HL7 CEO Chuck Jaffe, MD, who said last month that the normative version of FHIR is slated for release sometime in 2017.

Also See:<\/b> 2017 emerges as pivotal year for FHIR interoperability standard<\/a>

\u201cRelease 4 should be introduced in the fall of this year, although I don\u2019t think anyone on the FHIR development team wants to be held to a specific date,\u201d comments Jaffe, who says that he and Grieve have discussed the schedule at length.

Grieve was not immediately available for comment.

Asked why Grieve\u2019s timeline differs significantly from his own, Jaffe suggests that perhaps the FHIR product director is offering a more conservative timeframe \u201cbecause he doesn\u2019t want to disappoint people\u201d and \u201cif he says something that delights people because it\u2019s six months earlier (than he proposed), well that\u2019s great and nobody will complain\u2014but, if he proposes a date and can\u2019t meet it, then there will be all sorts of disappointment.\u201d

Jaffe goes on to say, \u201cI can\u2019t tell you with any real honesty that I know that by the end of calendar 2017 we\u2019ll be balloting a stable version of (FHIR) release 4\u2026It\u2019s safe to say that we\u2019re encouraged that we\u2019ll be on that timeline, but no one wants to commit to a date with which we\u2019ll promise to ballot release 4.\u201d

David McCallie, MD, Cerner\u2019s senior vice president of medical informatics, agrees with Jaffe that \u201cwe\u2019ll probably see a normative ballot in 2017.\u201d At the same time, McCallie contends that \u201cthe fact that it\u2019s a normative ballot is less important than the maturity level of a particular FHIR resource.\u201d

He emphasizes that, \u201cwithin FHIR itself, there is a wide range of what they call maturity index, so you may have a normative ballot that includes some very immature specifications\u2014and, that\u2019s different from the way HL7 did it in the past.\u201d As a result, according to McCallie, electronic health record vendors such as Cerner will \u201cpay attention to that maturity level in their decisions as to whether to implement it or not, rather than to the fact that it\u2019s the normative ballot.\u201d

At the same time, just because the normative version of FHIR is not yet finalized and published does not mean that providers and vendors are waiting for release 4.

\u201cPeople aren\u2019t waiting for the normative version to implement,\u201d says Stan Huff, MD, chief medical informatics officer at Intermountain Healthcare. \u201cWe have some not only FHIR but also SMART on FHIR based applications that are in production use.\u201d

Cerner is also committed to implementing FHIR, which is already a part of its product offering, with the emerging standard serving as the basis for the company\u2019s open application programming interface (API), according to McCallie.

\u201cWe\u2019re quite excited about FHIR and are actively supporting it both through collaborative work like the Argonaut Project as well as allowing developers to use FHIR to access data in the Cerner EHR,\u201d says McCallie. \u201cWe will continue that and support expansion of the APIs that we can offer using FHIR as the standard.\u201d

Micky Tripathi, president and CEO of the Massachusetts eHealth Collaborative and manager of the Argonaut Project, an industry-wide effort to accelerate the development and adoption of FHIR, says this kind of vendor-specific decision is common regarding when the emerging standard is mature and stable enough for their production purposes.

Vendors, particularly smaller companies, might \u201cskip\u201d STU3 and wait for release 4, Tripathi believes. \u201cSome of them may decide to hold off, particularly if release 4 is really just around the corner,\u201d he says. \u201cHowever, the Cerners, Epics and athenahealths of the world are not sitting around waiting for the normative version of FHIR before they implement. Epic and Cerner already have FHIR implementations out there, and they\u2019re continuing to build on those.\u201d

Nonetheless, Cerner\u2019s McCallie adds \u201cthat doesn\u2019t mean we\u2019ll implement all of FHIR.\u201d He sees the emerging standard as a \u201cgiant moving target\u2014you can\u2019t sort of say the whole thing is ready, although there may be parts of it that are quite stable and mature.\u201d When it comes the normative version of FHIR (release 4), McCallie believes different parts of it will be more ready for implementation than other parts, even once it goes through a normative ballot.

\u201cThere are parts of FHIR, even though they may become normative sometime later this year, we might not put them into the EHR for years,\u201d says McCallie. \u201cIn fact, there are parts of FHIR that will never get implemented by any EHR vendor. It\u2019s not all equally relevant to us.\u201d

While Huff is \u201cvery positive\u201d about FHIR, he observes that \u201ceven when FHIR is a normative standard, it will not be truly interoperable,\u201d adding a \u201cnote of caution\u2014there\u2019s still a lot of work to do.\u201d

Huff, who is co-chair of HL7\u2019s Clinical Information Modeling Initiative (CIMI) aimed at improving the interoperability of healthcare systems through shared implementable clinical information models, warns that what\u2019s needed is the \u201cstandard use of terminology and codes\u201d to ensure that these systems are \u201ctruly semantically interoperable.\u201d

Also See:<\/b> Emerging FHIR standard just the start of interoperability efforts<\/a>

\u201cI don\u2019t want anything that I\u2019m saying to be taken as disparaging or understood as me saying we shouldn\u2019t do FHIR\u2014we should do FHIR,\u201d concludes Huff. \u201cI\u2019m saying we need to get it to the level of true semantic interoperability.\u201d","saveContent":"As the healthcare industry eagerly awaits a normative version of Health Level Seven International\u2019s Fast Healthcare Interoperability Resources data exchange standard, the timeline for realizing a stable version remains murky, with HL7 executives offering different opinions.

Work is continuing to advance FHIR, and it's being used by some large vendors in an increasing number of situations. But many vendors are waiting for HL7 to get farther along in its standard-setting process before investing in the development needed to incorporate FHIR into their products. A significant milestone for any standard is when it reaches a normative version--that is, a mature standard that works in most cases and most industry participants accept as essential to use.

FHIR continues to mature as an open standard for exchanging healthcare data between information systems. According to FHIR Product Director Graham Grieve, STU3 Standard for Trial Use, release 3 (STU3)\u2014the third major milestone for the initiative\u2014is expected to be published in late March.

\u201cOnce STU3 is published, we will start working on release 4,\u201d wrote Grieve in a product roadmap<\/a> posted online last month. He noted that release 4 (R4) is expected to be the first normative version of FHIR, \u201cwhere the standard becomes stable, and breaking changes are no longer considered.\u201d

Under the planned timeline, the first draft of R4 will be published for comment in December 2017; the first R4-based connectathon will take place in January 2018; an R4 ballot is slated for April 2018; ballot reconciliation would be set for May to September 2018; and final publication of FHIR R4 would occur in October 2018.

However, this schedule stands in contrast to the timeline outlined by HL7 CEO Chuck Jaffe, MD, who said last month that the normative version of FHIR is slated for release sometime in 2017.

Also See:<\/b> 2017 emerges as pivotal year for FHIR interoperability standard<\/a>

\u201cRelease 4 should be introduced in the fall of this year, although I don\u2019t think anyone on the FHIR development team wants to be held to a specific date,\u201d comments Jaffe, who says that he and Grieve have discussed the schedule at length.

Grieve was not immediately available for comment.

Asked why Grieve\u2019s timeline differs significantly from his own, Jaffe suggests that perhaps the FHIR product director is offering a more conservative timeframe \u201cbecause he doesn\u2019t want to disappoint people\u201d and \u201cif he says something that delights people because it\u2019s six months earlier (than he proposed), well that\u2019s great and nobody will complain\u2014but, if he proposes a date and can\u2019t meet it, then there will be all sorts of disappointment.\u201d

Jaffe goes on to say, \u201cI can\u2019t tell you with any real honesty that I know that by the end of calendar 2017 we\u2019ll be balloting a stable version of (FHIR) release 4\u2026It\u2019s safe to say that we\u2019re encouraged that we\u2019ll be on that timeline, but no one wants to commit to a date with which we\u2019ll promise to ballot release 4.\u201d

David McCallie, MD, Cerner\u2019s senior vice president of medical informatics, agrees with Jaffe that \u201cwe\u2019ll probably see a normative ballot in 2017.\u201d At the same time, McCallie contends that \u201cthe fact that it\u2019s a normative ballot is less important than the maturity level of a particular FHIR resource.\u201d

He emphasizes that, \u201cwithin FHIR itself, there is a wide range of what they call maturity index, so you may have a normative ballot that includes some very immature specifications\u2014and, that\u2019s different from the way HL7 did it in the past.\u201d As a result, according to McCallie, electronic health record vendors such as Cerner will \u201cpay attention to that maturity level in their decisions as to whether to implement it or not, rather than to the fact that it\u2019s the normative ballot.\u201d

At the same time, just because the normative version of FHIR is not yet finalized and published does not mean that providers and vendors are waiting for release 4.

\u201cPeople aren\u2019t waiting for the normative version to implement,\u201d says Stan Huff, MD, chief medical informatics officer at Intermountain Healthcare. \u201cWe have some not only FHIR but also SMART on FHIR based applications that are in production use.\u201d

Cerner is also committed to implementing FHIR, which is already a part of its product offering, with the emerging standard serving as the basis for the company\u2019s open application programming interface (API), according to McCallie.

\u201cWe\u2019re quite excited about FHIR and are actively supporting it both through collaborative work like the Argonaut Project as well as allowing developers to use FHIR to access data in the Cerner EHR,\u201d says McCallie. \u201cWe will continue that and support expansion of the APIs that we can offer using FHIR as the standard.\u201d

Micky Tripathi, president and CEO of the Massachusetts eHealth Collaborative and manager of the Argonaut Project, an industry-wide effort to accelerate the development and adoption of FHIR, says this kind of vendor-specific decision is common regarding when the emerging standard is mature and stable enough for their production purposes.

Vendors, particularly smaller companies, might \u201cskip\u201d STU3 and wait for release 4, Tripathi believes. \u201cSome of them may decide to hold off, particularly if release 4 is really just around the corner,\u201d he says. \u201cHowever, the Cerners, Epics and athenahealths of the world are not sitting around waiting for the normative version of FHIR before they implement. Epic and Cerner already have FHIR implementations out there, and they\u2019re continuing to build on those.\u201d

Nonetheless, Cerner\u2019s McCallie adds \u201cthat doesn\u2019t mean we\u2019ll implement all of FHIR.\u201d He sees the emerging standard as a \u201cgiant moving target\u2014you can\u2019t sort of say the whole thing is ready, although there may be parts of it that are quite stable and mature.\u201d When it comes the normative version of FHIR (release 4), McCallie believes different parts of it will be more ready for implementation than other parts, even once it goes through a normative ballot.

\u201cThere are parts of FHIR, even though they may become normative sometime later this year, we might not put them into the EHR for years,\u201d says McCallie. \u201cIn fact, there are parts of FHIR that will never get implemented by any EHR vendor. It\u2019s not all equally relevant to us.\u201d

While Huff is \u201cvery positive\u201d about FHIR, he observes that \u201ceven when FHIR is a normative standard, it will not be truly interoperable,\u201d adding a \u201cnote of caution\u2014there\u2019s still a lot of work to do.\u201d

Huff, who is co-chair of HL7\u2019s Clinical Information Modeling Initiative (CIMI) aimed at improving the interoperability of healthcare systems through shared implementable clinical information models, warns that what\u2019s needed is the \u201cstandard use of terminology and codes\u201d to ensure that these systems are \u201ctruly semantically interoperable.\u201d

Also See:<\/b> Emerging FHIR standard just the start of interoperability efforts<\/a>

\u201cI don\u2019t want anything that I\u2019m saying to be taken as disparaging or understood as me saying we shouldn\u2019t do FHIR\u2014we should do FHIR,\u201d concludes Huff. \u201cI\u2019m saying we need to get it to the level of true semantic interoperability.\u201d","order":0,"get_parent":{},"attributes":[],"attributesType":{"content":{"type":"string","source":"raw"},"lock":{"type":"object"}},"dynamicContent":""}]

Timeline is uncertain for release of normative version of FHIR

More for you