[{"innerBlocks":[],"name":"core\/freeform","postId":1389,"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":"This week\u2019s move by HL7 to publish its eagerly awaited normative version of the Fast Healthcare Interoperability Resources is seen by industry stakeholders as the evolution of a mature, stable standard.

On Wednesday, HL7 announced the release of FHIR Release 4 (R4) and that the base platform of the standard has passed a normative ballot and will be submitted to the American National Standards Institute for designation as such.

\u201cThe publication by HL7 of Release 4 of the FHIR standard is a milestone of great import,\u201d says Russell Leftwich, MD, senior clinical advisor for interoperability at software vendor InterSystems and assistant professor of biomedical informatics at Vanderbilt University School of Medicine.

\u201cConformance with this normative base will mean that applications based on FHIR R4 will have a long life cycle and greater portability,\u201d Leftwich adds. \u201cIt will be easier to upgrade rather than replace such applications.\u201d

Also See<\/b>: HL7 publishes normative version of FHIR standard<\/a>

Stan Huff, MD, chief medical informatics officer at Intermountain Healthcare, sees the FHIR R4 announcement as a significant milestone for exchanging healthcare data between information systems and as an important step towards a \u201chigher level\u201d of interoperability. .

\u201cThe new release is more mature and provides greater standardization than previous releases,\u201d says Huff. \u201cIt makes many\u2014but not all\u2014of the FHIR Resources \u2018normative,\u2019 that is, they are now considered \u2018standard\u2019 with only rare changes expected in the future. This means that people can use the new release with fewer worries about needing to make future changes in their software.\u201d

Micky Tripathi, manager of the Argonaut Project, an industry-wide effort to accelerate the development and adoption of FHIR, points out that\u2014in practical terms\u2014normative approval means that any future changes will require broad HL7 community approval and must be backward compatible.

\u201cIf you\u2019re a developer that gives confidence that what you build won\u2019t have to be thrown away when the next version is released,\u201d says Tripathi, who is president and CEO of the Massachusetts eHealth Collaborative. \u201cNormative approval thus gives further confidence and impetus to any vendor who is still sitting on the fence about whether they should build FHIR capabilities.\u201d

As a result, Huff contends that R4 \u201ccreates a more stable foundation on which to build products and services,\u201d which he believes \u201cshould cause even faster uptake of FHIR across the healthcare industry.\u201d

Still, Tripathi observes that normative approval isn\u2019t a prerequisite to industry adoption, as evidenced by the Argonaut Implementation Guide, which he notes \u201cwas not based on any normative content but nevertheless has been widely adopted by EHR vendors, Apple, and lab companies such as LabCorps and Quest.\u201d

At the same time, Tripathi makes the case that normative approval further establishes FHIR as the basic application programming interface (API) building block for common healthcare transactions.

\u201cThere will always need to be room for other novel API approaches where FHIR isn\u2019t applicable, but it\u2019s important to have an open industry standard as the basis for common, high priority, day-to-day healthcare transactions such as transitions of care, referrals, diagnostic results delivery and patient access,\u201d he adds.

He also sees normative approval as an important potential factor for FHIR\u2019s Office of the National Coordinator for Health IT certification.

\u201cIt\u2019s not a requirement but anything that becomes part of a federally-approved standard should have a certain degree of stability and market ecosystem support\u2014and, normative approval is an indicator of that,\u201d according to Tripathi.

Leftwich adds that while grounded by the normative base of R4, the evolution of other resources that are part of the FHIR specification will continue.

\u201cWe can expect that FHIR will continue to evolve with increasing value and utility to be realized in each release,\u201d he concludes. \u201cI would compare this new concept of standards evolution to the evolution of other technology that we have become familiar with. For any particular brand of smartphone there is never a final version\u2014they just continue to evolve and improve. Similarly, with Bluetooth or WiFi. the next version is better\u2014more useful\u2014but there is not going to be a final version.\u201d","saveContent":"This week\u2019s move by HL7 to publish its eagerly awaited normative version of the Fast Healthcare Interoperability Resources is seen by industry stakeholders as the evolution of a mature, stable standard.

On Wednesday, HL7 announced the release of FHIR Release 4 (R4) and that the base platform of the standard has passed a normative ballot and will be submitted to the American National Standards Institute for designation as such.

\u201cThe publication by HL7 of Release 4 of the FHIR standard is a milestone of great import,\u201d says Russell Leftwich, MD, senior clinical advisor for interoperability at software vendor InterSystems and assistant professor of biomedical informatics at Vanderbilt University School of Medicine.

\u201cConformance with this normative base will mean that applications based on FHIR R4 will have a long life cycle and greater portability,\u201d Leftwich adds. \u201cIt will be easier to upgrade rather than replace such applications.\u201d

Also See<\/b>: HL7 publishes normative version of FHIR standard<\/a>

Stan Huff, MD, chief medical informatics officer at Intermountain Healthcare, sees the FHIR R4 announcement as a significant milestone for exchanging healthcare data between information systems and as an important step towards a \u201chigher level\u201d of interoperability. .

\u201cThe new release is more mature and provides greater standardization than previous releases,\u201d says Huff. \u201cIt makes many\u2014but not all\u2014of the FHIR Resources \u2018normative,\u2019 that is, they are now considered \u2018standard\u2019 with only rare changes expected in the future. This means that people can use the new release with fewer worries about needing to make future changes in their software.\u201d

Micky Tripathi, manager of the Argonaut Project, an industry-wide effort to accelerate the development and adoption of FHIR, points out that\u2014in practical terms\u2014normative approval means that any future changes will require broad HL7 community approval and must be backward compatible.

\u201cIf you\u2019re a developer that gives confidence that what you build won\u2019t have to be thrown away when the next version is released,\u201d says Tripathi, who is president and CEO of the Massachusetts eHealth Collaborative. \u201cNormative approval thus gives further confidence and impetus to any vendor who is still sitting on the fence about whether they should build FHIR capabilities.\u201d

As a result, Huff contends that R4 \u201ccreates a more stable foundation on which to build products and services,\u201d which he believes \u201cshould cause even faster uptake of FHIR across the healthcare industry.\u201d

Still, Tripathi observes that normative approval isn\u2019t a prerequisite to industry adoption, as evidenced by the Argonaut Implementation Guide, which he notes \u201cwas not based on any normative content but nevertheless has been widely adopted by EHR vendors, Apple, and lab companies such as LabCorps and Quest.\u201d

At the same time, Tripathi makes the case that normative approval further establishes FHIR as the basic application programming interface (API) building block for common healthcare transactions.

\u201cThere will always need to be room for other novel API approaches where FHIR isn\u2019t applicable, but it\u2019s important to have an open industry standard as the basis for common, high priority, day-to-day healthcare transactions such as transitions of care, referrals, diagnostic results delivery and patient access,\u201d he adds.

He also sees normative approval as an important potential factor for FHIR\u2019s Office of the National Coordinator for Health IT certification.

\u201cIt\u2019s not a requirement but anything that becomes part of a federally-approved standard should have a certain degree of stability and market ecosystem support\u2014and, normative approval is an indicator of that,\u201d according to Tripathi.

Leftwich adds that while grounded by the normative base of R4, the evolution of other resources that are part of the FHIR specification will continue.

\u201cWe can expect that FHIR will continue to evolve with increasing value and utility to be realized in each release,\u201d he concludes. \u201cI would compare this new concept of standards evolution to the evolution of other technology that we have become familiar with. For any particular brand of smartphone there is never a final version\u2014they just continue to evolve and improve. Similarly, with Bluetooth or WiFi. the next version is better\u2014more useful\u2014but there is not going to be a final version.\u201d","order":0,"get_parent":{},"attributes":[],"attributesType":{"content":{"type":"string","source":"raw"},"lock":{"type":"object"}},"dynamicContent":""}]

Interoperability experts welcome new normative version of FHIR

More for you