FHIR® (HL7 Fast Healthcare Interoperability Resources)

The Baader-Meinhof Phenomenon?

The HL7 FHIR data platform might be a great example of the Baader-Meinhof Phenomenon: With Baader-Meinhof, one stumbles upon some obscure piece of information⁠—often an unfamiliar word or name⁠—and soon afterwards encounters the same subject again, often repeatedly. Commonly, no one knows what it is. At the 2022 HIMSS conference in a social setting, someone remarked about FHIR: "Everyone is talking about it, but only five people in the world know anything about it." Although an obvious exaggeration, many experienced healthcare IT professionals have limited, if any knowledge of it. With the entire "Intersect on FHIR" digital health platform having been created on the FHIR data set, Intersect would like to provide you with an idea of what that means.

For context, the first thing to note is that the full title of what is known as the Cures Act, is the "21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program". The legislation implements provisions that include "Conditions and Maintenance of Certification requirements for health information technology developers under the ONC Health IT Certification Program, the voluntary certification of health IT for use by healthcare providers, and reasonable and necessary activities that do not constitute information blocking. The implementation of these provisions will advance interoperability and support the access, exchange, and use of electronic health information. The rule also finalizes certain modifications to the 2015 Edition health IT certification criteria and Program in additional ways to advance interoperability, enhance health IT certification criteria, and reduce burden and costs".

The Cures Act, as you might imagine has several Major Provisions and Clarifications. One is titled "Adoption of the United States Core Data for Interoperability (USCDI) as a Standard" It states: "We noted in the Proposed Rule that, as a part of continued efforts to ensure the availability of a minimum baseline of data classes that could be commonly available for interoperable exchange, ONC adopted the 2015 Edition "Common Clinical Data Set" (CCDS) definition and use the CCDS shorthand in several certification criteria. However, the CCDS definition also began to be used colloquially for many different purposes. As the CCDS definition's relevance grew outside of its regulatory context, it was often viewed as a ceiling to the industry's collective data set for access, exchange, and use. In addition, we noted in the NPRM that as we continue to move toward value-based care, the inclusion of additional data classes beyond the CCDS would be necessary. In order to advance interoperability, we proposed to remove the CCDS definition and its references from the 2015 edition and replace it with the "United States Core Data for Interoperability (USCDI). We proposed to adopt the USCDI as a standard naming USCDI Version 1 (USCDI v1) in 170.213 and incorporating it by reference in 170.299. The USDI standard would establish a set of data classes and constituent data elements required to support interoperability nationwide. To achieve the goals set forth in the Cures Act, we indicated that we intended to establish and follow a predictable, transparent, and collaborative process to expand the USCDI, including providing stakeholders with the opportunity to comment on the USCDI's expansion. We also noted that once the USCDI is adopted by the Secretary in regulation, health IT developers would be allowed to take advantage of a new proposed flexibility we called the "Standards Version Advancement Process" (SVAP). In order to advance interoperability, we have finalized the adoption of the USCDI standard. Because the USCDI is adopted as a standard and the SVAP is finalized, the SVAP will allow a developer to voluntarily have their products certified to newer, National Coordinator approved versions of the USCDI in the future without waiting for rulemaking to update the versions of the USCDI listed in the regulations"

In a following Provision titled: Application Programing Interfaces (APIS), it states: "We have adopted a new API certification criteria in 170.315(g)(10) to replace the "application access - data category request" certification criterion (170.315(g)(8)), and added it to the 2015 Edition Base EHR definition. "The new standardized API for patient and population services" certification criterion focuses on supporting two types of API-enabled services: (1) Services for which a single patient's data is the focus and (2) services for which multiple patient's data are the focus. The API certification requires the use of the Health Level 7 (HL7®) Fast Healthcare Interoperability Resources (FHIR®) standard Release 4 and references several standards and implementation specifics adopted in 170.213 and 170.215 to support standardization and interoperability This certification criterion will align industry efforts around FHIR Release 4 and advance interoperability of API-enabled "read" services for single and multiple patients" Within this context, Intersect's decision to adopt the FHIR data set creates a transformational opportunity for healthcare organizations.

From their website: "Founded in 1987, Health Level Seven International is a not-for-profit, ANSI accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services." Several standards have been developed by HL7 v2.x which was also used to exchange messages between systems. HL7 Clinical Document Architecture (CDA) is a part of HL7 v3 is a standard to describe clinical documents. FHIR is a platform specification that defines a set of "resources." FHIR resources are a collection of information models that define the data elements of their role in healthcare.

The Patient API

Each resource can contain multiple levels of information.