Health Care Industry Data Model Series: FHIR, CDISC, OMOP, and OpenEHR — Part 1

NEERAJ SHRIVASTAVA
7 min readJul 16, 2023

The healthcare industry relies heavily on data models to manage and exchange patient information efficiently and to perform data analytics. Several prominent data models play crucial roles in this domain, these are the leading and widely adopted data models in US and EU region: -

FHIR, OMOP, CDISC and OpenEHR.

Fast Healthcare Interoperability Resources (FHIR) is used for healthcare data exchange such as Electronic Health Records. This is the most important model for US Healthcare industry since The ONC Cures Act Final Rule mandated certified health IT developers to provide FHIR-based APIs for providers and patients by December 31, 2022

FHIR provides a framework for the exchange, integration, sharing, and retrieval of healthcare information across systems. FHIR’s modular and flexible design enables interoperability, making it easier for different healthcare applications to communicate and share data seamlessly.

Reference : Index — FHIR v5.0.0 (hl7.org)

CDISC Data Model: The CDISC (Clinical Data Interchange Standards Consortium) data model is a comprehensive set of standards that facilitates the collection, exchange, and submission of clinical trial data.

The CDISC data model consists of various standard domains, including Demographics, Adverse Events, Medical History, and Laboratory Results, which capture specific types of data relevant to clinical trials.

By promoting data sharing, reusability, and traceability throughout the clinical trial lifecycle, from protocol development to analysis and reporting, the CDISC data model plays a crucial role in improving data quality, accelerating drug development, and enhancing patient safety in the pharmaceutical and healthcare industries.

Reference : Standards | CDISC

OMOP Data Model: The OMOP (Observational Medical Outcomes Partnership) data model is an open-source, standardized framework designed to support large-scale data analytics of observational healthcare data.

By organizing diverse healthcare data into a set of standardized tables, such as Person, Visit, Condition, Drug Exposure, Measurement, Procedure, and Observation, the OMOP data model ensures a consistent format for analysis and research purposes.

Researchers can define cohorts and conduct various analyses, including comparative effectiveness studies and population-level analyses, using the OMOP data model. Supported by the collaborative efforts of the OHDSI community, the OMOP data model empowers researchers worldwide to generate real-world evidence and gain valuable insights into patient outcomes, safety, and healthcare effectiveness.

Reference : OMOP Common Data Model (ohdsi.github.io)

OpenEHR Data Model: The OpenEHR data model is an open-source approach to capturing, storing, and exchanging electronic health records (EHRs) and other health-related data. It focuses on separating clinical content from technical implementation, allowing for flexibility and adaptability across different healthcare settings and systems.

The openEHR data model adopts a dual-model architecture, distinguishing between the archetype (representing clinical content) and the template (defining presentation and implementation details).

Archetypes enable semantic interoperability by representing clinical concepts in a standardized manner, facilitating the exchange and sharing of health information. Its modular and flexible design promotes interoperability and future-proofing of healthcare systems, fostering innovation and collaboration in the field of health informatics.

Reference : openEHR Home

In this article I will be explaining FHIR in more detail and in subsequent posts will cover OMOP, CDISC and OpenEHR so stay tuned and please follow me.

What is FHIR:

The HL7® FHIR® (Fast Healthcare Interoperability Resources ) standard defines how healthcare information can be exchanged between different computer systems regardless of how it is stored in those
systems. It allows healthcare information, including clinical and administrative data, to be available securely to those who have a need to access it, and to those who have the right to do so for the benefit
of a patient receiving care. The standards development organization HL7® (Health Level Seven®3) uses a collaborative approach to develop and upgrade FHIR.

Additionally, the FHIR standard provides the following advantages to software developers

  1. A strong focus on fast and easy implementation; developers have reported they experienced simple interfaces being implementable in a single day
  2. Support from major vendors including Apple, Microsoft, Google, Epic, Cerner, and most other EHR vendors.
  3. Many free, online, and downloadable tools, including reference servers and implementation libraries like Synthea
  4. Interoperability out-of-the-box — base resources can be used as is, but can also be adapted for local requirements (the process of Profiling).

What is a FHIR Resource

In FHIR, health care data is broken down into categories such as patients, laboratory results, and insurance claims, among many others. Each of these categories is represented by a FHIR Resource,
which defines the component data elements, constraints on data, and data relationships that together make up an exchangeable patient record.

To see the list of all FHIR resource click on the link : Resourcelist — FHIR v4.3.0 (hl7.org)

Resourcelist — FHIR v5.0.0 (hl7.org)

What’s the numbering on each FHIR resource indicates.

You can notice in the above screen shot, against each resource there is a number 0 to 6 (N) indicates maturity level in terms of testing, usage & adoption, 0 or 1 indicates resource is ready for adoption and 6 is the highest indicating widespread adoption and normalization of the resource data structure. For more details, please visit Versions — FHIR v5.0.0 (hl7.org)

How does a FHIR Resource Looks like:Fro

From the list of resources as mentioned above select any of the resource, for example Patient resource: Patient — FHIR v4.3.0 (hl7.org)

Here is the Patient resource data structure: -

Patient — FHIR v5.0.0 (hl7.org)

HL7 has done a great job in providing examples of data actually looks like, for that navigate to examples tab:-

Are there any Publicly available FHIR servers to experiment with?

Yes HL7 provides a Publicly available and free FHIR server http://fhirserver.hl7fundamentals.org/fhir/Patient/

In order to test the API you will have to install PostMan tool or any other tool that can help with API testing Download Postman | Get Started for Free

To retrieve Patient data, select Direct Read (GET) Request, this is an example on how to get data from Patient resource:-

Provide the following header parameter : Accept : application/fhir+json

To get data from any other resource just replace Patient with that resource name, for example, Observation and click on Get.

Default output will be in JSON format.

Similarly you can POST a new patient record, you can pick any of the example JSON files provided by HL7 site, please refere the above screenshot that shows how to get to example files.

How do I setup my own FHIR Server

Many cloud provides like Azure, AWS, Google are now offering FHIR API server configuration, I have beenn using Azure Health Data Services and found it to be very helpful, Here are the steps you need to follow to setup your own Azure API for FHIR

Considering a patient walks into a clinic and for a blood test and receives an assessment from the Doctor, which FHIR resources will be involved in this process:-

In the scenario where a patient walks into a clinic, undergoes a blood test, receives a report, and later receives an assessment from the doctor, several FHIR resources can be involved to capture and represent this process. The following FHIR resources could be relevant in this scenario:

  1. Patient: The Patient resource represents the individual receiving healthcare services. It contains demographic information, such as the patient’s name, gender, date of birth, and contact details.
  2. Encounter: The Encounter resource captures the interaction between the patient and the healthcare system. It would represent the visit or encounter at the clinic, including details such as the encounter type, date, and location.
  3. Observation: The Observation resource represents the blood test results. It contains the specific details of the blood test, such as the observation code (e.g., blood glucose, cholesterol levels), the result value, and relevant reference ranges.
  4. DiagnosticReport: The DiagnosticReport resource would contain the formal report generated by the laboratory or testing facility. It provides structured information about the blood test results, including the observation references, the issuing organization, and any interpretations or conclusions.
  5. Practitioner: The Practitioner resource represents the healthcare professional, such as the doctor, who performs the assessment. It contains information about the practitioner’s name, specialty, contact details, and qualifications.
  6. CarePlan: The CarePlan resource could be used to capture any ongoing or future care plans or interventions based on the assessment. It may include details about recommended treatments, medications, or follow-up visits.
  7. Claims processing related resources will also get involved as hospital, clinic will certainly charge the fees, hence the following resources will also get involved: Coverage, Claim Eligibility Request and Response, Claim,ExplanationOfBenefit & PaymentNotice

--

--