FHIR

Fast Healthcare Interoperability Resources (FHIR) is a healthcare data standard with an application programming interface (API) for representing and exchanging electronic health records (EHR). FHIR is an information network that lets you link data across systems and a communication network that lets you exchange data between systems.

FHIR includes the following:

An HTTP-based RESTful protocol
Data representation that uses JSON, XML, and RDF

For more details about FHIR, see the most recently published version of the FHIR specification.

Importance of FHIR in healthcare information technology

Healthcare IT systems often don't share the same data models. As healthcare data becomes more digitized, solving incompatibilities between different systems becomes expensive and time-consuming.

FHIR defines a common data model and REST architecture so that different healthcare systems can share and integrate data. FHIR is designed to be flexible and adaptable, so that it can be used in a wide range of settings and with different health care information systems.

FHIR uses resources to represent discrete medical, administrative, infrastructural, or financial data elements. Each resource is linked to a unique identifier, making it simpler for applications to access and modify the same data. Resources can be compiled and distributed to different healthcare providers in formats that comply with their respective data models.

FHIR is a valuable tool for improving the interoperability of healthcare IT systems. It can help to reduce costs, improve efficiency, and improve the quality of care.

Benefits of FHIR

Interoperability across devices and platforms

FHIR accommodates the exchange of healthcare data from monolithic data silos to open APIs. FHIR is the primary healthcare data standard with open APIs for accessing, searching, and modifying electronic health records (EHR) and exchanging data between healthcare IT systems.

FHIR lets EHR to be exchanged between healthcare providers and consumers on platforms such as the following:

EHR-based data sharing
Mobile apps
Cloud-based applications
Wearable devices

The FHIR API also lets third-party apps integrate with existing systems.

Compatibility with legacy standards

FHIR evolved from HL7 Version 2 messaging and HL7 Version 3 Clinical Document Architecture (HL7 CDA). FHIR can be used in partnership with HL7v2 and HL7 CDA.

For more information on the relationship between FHIR and other HL7 standards, see Appendix: The Relationship between FHIR and other HL7 Standards.

Decipherable and useful data

Because FHIR is implemented on top of the HTTPS protocol, you can retrieve and dissect FHIR resources to support machine learning, AI, and other forms of data analytics. These capabilities let you generate a deeper and more versatile understanding of your healthcare data.

Efficient data exchange

FHIR's resource-based approach facilitates more efficient and accurate data exchange. Because FHIR uses a uniform standard for health information, it lets you build custom templates from the shared base resources, and it eliminates inconsistency in data templates. This uniformity improves the accuracy and readability of data in data exchanges across health systems.

FHIR eliminates the need to individually modify the data template of every health IT system by exchanging data as resources. FHIR exposes resources such as patients, admissions, and medications as services. Therefore, consumer mobile apps can use GET and POST requests to retrieve and manipulate only the relevant data.

FHIR architecture

FHIR stores

A FHIR store is a data store in the Cloud Healthcare API that holds FHIR resources. FHIR stores exist inside datasets.

The FhirStore resource provides a representation of a FHIR store's attributes. For each FHIR store, you can choose options such as:

Enabling the updateCreate capability (DSTU2, STU3, R4).
Publishing changes to the FHIR store to a Pub/Sub topic.
Requiring referential integrity.
Enabling resource versioning (DSTU2, STU3, R4).

The state of these configuration options is shown in the FHIR store's capability statement (STU3 or R4) or conformance statement (DSTU2).

FHIR resources

FHIR uses resources to organize data formats and elements. Each resource has the following properties:

A shared method for defining and representing data, built upon data types consisting of reusable clusters of elements.
A common set of metadata, providing technical and structural context.
A human-readable text representation that uses HTML as a fallback display option for clinical safety.

FHIR specifies a base set of resources that can be combined in various ways to meet the data model demands of healthcare providers. It also provides representations of clinical observations and documents. FHIR does not aim to encompass every possible document or data type. Instead, FHIR first supports most clinical and billing use cases. You can then extend your FHIR implementation to meet additional clinical or organizational needs.

FHIR profiles

Using extensions, applications can customize the existing resources and describe their specifications with profiles. Profiles are a set of instructions in addition to the existing core specification for resources that fall under a specific use and context. The Cloud Healthcare API enforces profiles by validating resources against the constraints in the relevant profile.

For instance, recording a patient's ethnicity is not allowed in certain regions, but required in others. Using profiles, the FHIR base specification can define and require an "ethnicity" extension in accordance with the regional policies. Therefore, profiles help countries, regions, districts, and organizations customize data in accordance with their healthcare data regulations and needs.

You can use profiles to do the following:

Extend and restrict the FHIR API by defining additional operations, specify required pre-existing search parameters, and add new search parameters.
Extend and restrict resources by defining extensions of resources and changing the cardinality of fields.

A collection of profiles can be published as an implementation guide. Implementation guides are both machine- and human-readable. They can be exchanged and searched using REST and used to generate code and user interfaces.

For more information on FHIR extensions, see FHIR extensions.

FHIR base URL implementation

As shown in the official FHIR documentation (DSTU2, STU3, and R4), a FHIR Service Base URL uses the format http(s)://server/PATH. For example, https://server/path/Observation.

The Cloud Healthcare API uses a base URL that aligns with this standard. The Cloud Healthcare API base URL contains the following parts:

The endpoint for the Cloud Healthcare API
The version of the Cloud Healthcare API
The project ID
The name of a dataset
The dataset's location
The name of a FHIR store
The /fhir suffix

The following table shows the format of a FHIR Service Base URL and its equivalent base URL in the Cloud Healthcare API:

FHIR Service Base URL	Cloud Healthcare API equivalent URL
`http(s)://server/PATH`	`https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/fhirStores/FHIR_STORE_ID/fhir`

To get information about a patient using the FHIR RESTful API, make an HTTP GET request. The following table shows the format to use to get this information using the FHIR Service Base URL and its equivalent base URL in the Cloud Healthcare API:

FHIR Service Base URL	Cloud Healthcare API equivalent URL
`http(s)://server/path/Patient/PATIENT_ID`	`https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/fhirStores/FHIR_STORE_ID/fhir/Patient/PATIENT_ID`

FHIR conformance

For more information on the FHIR DSTU2, STU3, and R4 implementations in the Cloud Healthcare API, see the FHIR conformance statement.

Integrating with OMOP

OMOP Common Data Model (OMOP CDM) is a standard developed by Observational Health Data Sciences and Informatics (OHDSI). It is primarily used for observational clinical data. The OHDSI tool suite can assist common analytics use cases such as cohort definition, cohort generation, and population effect estimation. It is a commonly used data model in genomics and pharmaceutical research due to its expansive terminology and genetics support.

See the following resources for more details about OMOP:

By integrating FHIR and OMOP, clinical data from EHRs and other sources in the FHIR format can be used as research data in the OMOP standard. Specific fields and data elements in OMOP can also be integrated into existing data in FHIR.

You can use the open-sourced Cloud Healthcare API Data Harmonization mapping engine to perform the following tasks:

Harmonizing data to the OMOP CDM and others.
Configuring data mapping for FHIR-to-OMOP data conversion.