[{"innerBlocks":[],"name":"core\/freeform","postId":1626,"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 providers and vendors continue to embrace HL7\u2019s Fast Healthcare Interoperability Resources to share health data, supporters are calling on federal agencies to make the standard a requirement.

Micky Tripathi, manager of the Argonaut Project, an industry-wide effort to accelerate the development and adoption of FHIR, contends that the open health data standard is now mature enough to be leveraged by the Department of Health and Human Services\u2014specifically the Centers for Medicare and Medicaid Services and the Office of the National Coordinator for Health IT.

\u201cWhen we started the Argonaut Project less than four years ago on the building blocks created by the SMART on FHIR program, we believed strongly in FHIR and (application programming interfaces), but we were concerned that the standard was too immature,\u201d says Tripathi. \u201cWe were especially concerned that FHIR not become an ONC EHR certification requirement before the industry was ready for it.\u201d

However, he observes that the \u201crapid embrace of FHIR by the industry in three years, from major EHRs to Apple iPhones, has been faster than we could have hoped and is a testament to what can happen with strong industry collaboration and leadership coupled with judicious regulatory action.\u201d As a result, Tripathi believes that ONC and CMS can now \u201csafely build requirements based on FHIR to help give focus to FHIR API implementations across our fragmented healthcare delivery landscape.\u201d

Stan Huff, MD, chief medical informatics officer at Intermountain Healthcare, also would like to see the federal government make FHIR a requirement\u2014but with a caveat.

\u201cIf possible, ONC, CMS, FDA and others should require the use of FHIR but not specify a particular version because that would tend to freeze FHIR at its current state, and block future improvements and innovations,\u201d says Huff.

CMS\u2019s final Meaningful Use Stage 3 rule requires certified EHR technology to provide an API through which patient information can be viewed, downloaded and transmitted to a third party. However, of all the federal agencies, arguably the one most suited to codify FHIR is ONC\u2014that\u2019s because the agency\u2019s 2015 Edition of Health IT Certification Criteria requires certified EHRs to demonstrate the ability to provide a patient-facing app access to the Common Clinical Data Set via an API.

ONC\u2019s 2015 Edition didn\u2019t specify that the API has to be FHIR, but going forward, the agency could make the standard a requirement if it wants to, says Tripathi.

Earlier this month, ONC released data on the growing use of the FHIR standard. Specifically, the agency found that 32 percent of health IT developers are using FHIR Release 2 to meet 2015 Edition certification requirements. ONC\u2019s assessment is that the United States \u201cmight be at a turning point\u201d when it comes to the adoption and implementation of FHIR.

Also See<\/b>: FHIR standard adoption in the U.S. is at a turning point<\/a>

\u201cONC should safely feel like they can now say to the industry that it\u2019s time to use a FHIR API,\u201d adds Tripathi.

Nonetheless, the agency is not willing to discuss any hypotheticals on the regulatory front or any potential plans it might have for the interoperability standard.

\u201cONC supports the use of FHIR, but it\u2019s not going to comment on making it a requirement,\u201d said an agency spokesman. \u201cWith respect to the standard\u2019s maturity, FHIR Release 2\u2014on which the Argonaut specifications are built\u2014progressed to a point where this version was stable and specified enough to be deployed in production to support certain uses.\u201d

At the same time, the ONC spokesman emphasized that it\u2019s \u201cimportant to remember that FHIR Release 3 was published over a year ago, and FHIR Release 4 is expected in the coming months\u2014so, like the WiFi standard, we expect FHIR to keep being refined and improved so that it will address new business needs as well as the overall complexity of healthcare.\u201d

Regarding this point, Chuck Jaffe, MD, CEO of HL7, observes that it\u2019s precisely because of the fact that FHIR continues to evolve that makes any potential effort on the part of the federal government to codify the standard so difficult.

\u201cIf they mandate FHIR, they\u2019ll have to mandate it at a certain point in time,\u201d says Jaffe. \u201cI don\u2019t know how the government could word the regulatory language without specifying a version of FHIR. What version they require is important so it doesn\u2019t put the brakes on the really good stuff that\u2019s coming down the pike. And I don\u2019t know how they get it into regulation without stifling the advancements.\u201d

Yet, Huff maintains that \u201cpeople need to expect and plan for continued evolution and improvement in the FHIR standard\u2014it is pretty stable, but it continues to change, and that is a good thing.\u201d

Josh Mandel, MD, chief architect for Microsoft Healthcare and a strong supporter of FHIR, points out that ONC has sent a proposed rule to the Office of Management and Budget for review <\/i>that seeks to implement certain provisions of the 21st Century Cures Act, including requirements for health IT developers under the agency\u2019s certification program.

According to Mandel, ONC\u2019s proposed rule\u2014which has not yet been released for public comment\u2014could modify the 2015 Edition certification criteria to comply with the 21st Century Cures Act\u2019s interoperability provisions, among them a mandate from Congress requiring certified HIT to have an API that enables health information to be accessed, exchanged and used \u201cwithout special effort\u201d and to provide access to \u201call data elements of a patient\u2019s electronic health record,\u201d as permitted by law.

\u201cWe've seen great convergence, even from \u2018functional requirements\u2019 like the patient access provisions in the 2015 certification rule,\u201d comments Mandel. \u201cOver time, there's an opportunity to start layering on more specific technical requirements. But we need to keep in mind that there will always be a gap between well-standardized-and-growing \u2018core data\u2019 definitions and the long tail implied by the Cures provision for \u2018all data elements.\u2019 \u201d

He concluded that \u201cregulations will need to ensure that standards like FHIR can be used to capture core data with increasing specificity, while there\u2019s still a strong functional mandate to expose the entire record, beyond what is well standardized.\u201d
","saveContent":"As providers and vendors continue to embrace HL7\u2019s Fast Healthcare Interoperability Resources to share health data, supporters are calling on federal agencies to make the standard a requirement.

Micky Tripathi, manager of the Argonaut Project, an industry-wide effort to accelerate the development and adoption of FHIR, contends that the open health data standard is now mature enough to be leveraged by the Department of Health and Human Services\u2014specifically the Centers for Medicare and Medicaid Services and the Office of the National Coordinator for Health IT.

\u201cWhen we started the Argonaut Project less than four years ago on the building blocks created by the SMART on FHIR program, we believed strongly in FHIR and (application programming interfaces), but we were concerned that the standard was too immature,\u201d says Tripathi. \u201cWe were especially concerned that FHIR not become an ONC EHR certification requirement before the industry was ready for it.\u201d

However, he observes that the \u201crapid embrace of FHIR by the industry in three years, from major EHRs to Apple iPhones, has been faster than we could have hoped and is a testament to what can happen with strong industry collaboration and leadership coupled with judicious regulatory action.\u201d As a result, Tripathi believes that ONC and CMS can now \u201csafely build requirements based on FHIR to help give focus to FHIR API implementations across our fragmented healthcare delivery landscape.\u201d

Stan Huff, MD, chief medical informatics officer at Intermountain Healthcare, also would like to see the federal government make FHIR a requirement\u2014but with a caveat.

\u201cIf possible, ONC, CMS, FDA and others should require the use of FHIR but not specify a particular version because that would tend to freeze FHIR at its current state, and block future improvements and innovations,\u201d says Huff.

CMS\u2019s final Meaningful Use Stage 3 rule requires certified EHR technology to provide an API through which patient information can be viewed, downloaded and transmitted to a third party. However, of all the federal agencies, arguably the one most suited to codify FHIR is ONC\u2014that\u2019s because the agency\u2019s 2015 Edition of Health IT Certification Criteria requires certified EHRs to demonstrate the ability to provide a patient-facing app access to the Common Clinical Data Set via an API.

ONC\u2019s 2015 Edition didn\u2019t specify that the API has to be FHIR, but going forward, the agency could make the standard a requirement if it wants to, says Tripathi.

Earlier this month, ONC released data on the growing use of the FHIR standard. Specifically, the agency found that 32 percent of health IT developers are using FHIR Release 2 to meet 2015 Edition certification requirements. ONC\u2019s assessment is that the United States \u201cmight be at a turning point\u201d when it comes to the adoption and implementation of FHIR.

Also See<\/b>: FHIR standard adoption in the U.S. is at a turning point<\/a>

\u201cONC should safely feel like they can now say to the industry that it\u2019s time to use a FHIR API,\u201d adds Tripathi.

Nonetheless, the agency is not willing to discuss any hypotheticals on the regulatory front or any potential plans it might have for the interoperability standard.

\u201cONC supports the use of FHIR, but it\u2019s not going to comment on making it a requirement,\u201d said an agency spokesman. \u201cWith respect to the standard\u2019s maturity, FHIR Release 2\u2014on which the Argonaut specifications are built\u2014progressed to a point where this version was stable and specified enough to be deployed in production to support certain uses.\u201d

At the same time, the ONC spokesman emphasized that it\u2019s \u201cimportant to remember that FHIR Release 3 was published over a year ago, and FHIR Release 4 is expected in the coming months\u2014so, like the WiFi standard, we expect FHIR to keep being refined and improved so that it will address new business needs as well as the overall complexity of healthcare.\u201d

Regarding this point, Chuck Jaffe, MD, CEO of HL7, observes that it\u2019s precisely because of the fact that FHIR continues to evolve that makes any potential effort on the part of the federal government to codify the standard so difficult.

\u201cIf they mandate FHIR, they\u2019ll have to mandate it at a certain point in time,\u201d says Jaffe. \u201cI don\u2019t know how the government could word the regulatory language without specifying a version of FHIR. What version they require is important so it doesn\u2019t put the brakes on the really good stuff that\u2019s coming down the pike. And I don\u2019t know how they get it into regulation without stifling the advancements.\u201d

Yet, Huff maintains that \u201cpeople need to expect and plan for continued evolution and improvement in the FHIR standard\u2014it is pretty stable, but it continues to change, and that is a good thing.\u201d

Josh Mandel, MD, chief architect for Microsoft Healthcare and a strong supporter of FHIR, points out that ONC has sent a proposed rule to the Office of Management and Budget for review <\/i>that seeks to implement certain provisions of the 21st Century Cures Act, including requirements for health IT developers under the agency\u2019s certification program.

According to Mandel, ONC\u2019s proposed rule\u2014which has not yet been released for public comment\u2014could modify the 2015 Edition certification criteria to comply with the 21st Century Cures Act\u2019s interoperability provisions, among them a mandate from Congress requiring certified HIT to have an API that enables health information to be accessed, exchanged and used \u201cwithout special effort\u201d and to provide access to \u201call data elements of a patient\u2019s electronic health record,\u201d as permitted by law.

\u201cWe've seen great convergence, even from \u2018functional requirements\u2019 like the patient access provisions in the 2015 certification rule,\u201d comments Mandel. \u201cOver time, there's an opportunity to start layering on more specific technical requirements. But we need to keep in mind that there will always be a gap between well-standardized-and-growing \u2018core data\u2019 definitions and the long tail implied by the Cures provision for \u2018all data elements.\u2019 \u201d

He concluded that \u201cregulations will need to ensure that standards like FHIR can be used to capture core data with increasing specificity, while there\u2019s still a strong functional mandate to expose the entire record, beyond what is well standardized.\u201d
","order":0,"get_parent":{},"attributes":[],"attributesType":{"content":{"type":"string","source":"raw"},"lock":{"type":"object"}},"dynamicContent":""}]

FHIR supporters want feds to make the standard a requirement

More for you