The Language of Interoperability and Digital Quality Measurement

Get familiar with common interoperability terms and how they relate to digital quality.

Introduction to Interoperability in Quality Measurement

“Interoperability” refers to the ability of different information systems, devices and applications to access, exchange and use data seamlessly across organizational, regional and technological boundaries.

In a health care setting, “semantic” interoperability ensures that clinicians, payers and other stakeholders can access, exchange and understand standardized data, regardless of the software or technology platform of origin, enabling systems to interpret and use data consistently.

With respect to quality measurement, this capability is crucial for aggregating and uniformly analyzing data from sources such as EHRs, claims databases and patient-reported outcomes. Semantic interoperability ensures that diverse data sources adhere to common definitions and standards, supporting accurate and consistent measurement across settings. Without standardization, quality measurement is challenging and can lead to inconsistent or incomplete data, hindering efforts to derive meaningful insights from aggregated datasets.

An Overview of Essential Terms

API (Application Programming Interface)

Definition	A common interface that tells disconnected systems how to communicate. APIs allow a system to request and exchange data without needing to know the underlying code or architecture of the other system.
How It Works	Health care data are often stored in different systems that may not communicate with each other. APIs allow systems to share information in real time or near real time. By providing structured information exchange, APIs ensure that data flow seamlessly between systems, making the health care ecosystem more connected.
Example	An EHR system can use an API to send patient health data to a payer's system for quality measurement or billing purposes.

FHIR^® (Fast Healthcare Interoperability Resources)

Definition

A standard that defines how health care information can be exchanged between systems. Developed by Health Level 7 (HL7^®), it is designed to facilitate interoperability between health care systems and make it easier to share, retrieve and manage clinical data.

How It Works

The following components are essential to understanding how FHIR works:

Resources. FHIR organizes health care data into units called “resources.” Each resource represents a health care concept, such as a patient, observation or medication. Resources can be used individually or collectively, depending on the use case.
Profiles and Extensions. Resources can be customized, using profiles that define required or non-required elements of a resource. Profiles can be extended to add data elements not covered in the core resource.
APIs. FHIR uses widely adopted web technologies, making it flexible and accessible to developers familiar with these technologies.

Example

FHIR Patient Resource.

A fundamental resource in the FHIR standard, designed to represent core patient information used in health care applications: patient identifiers, demographic details, personal information (such as patient name, gender, birthdate, address).

Profiles for Patient Resource. FHIR profiles allow organizations to standardize data by customizing FHIR resources according to need. A patient profile typically defines mandatory, optional or prohibited fields in the patient resource, based on an organization's requirements.

API Context. The patient resource is accessible through RESTful API calls, and supports common interactions such as:

GET: Retrieve patient data. For example, GET /Patient/{id} retrieves a specific patient's data by their unique FHIR ID.
SEARCH: Allows filtered queries. For example, SEARCH /Patient?name=Smith finds patients with the name Smith.

JSON (JavaScript Object Notation File)

Definition	A text-based data interchange format that is both human-readable and machine-parsable. Commonly used to read data from a web server and display the data in a web page.
How It Works	JSON files store data in a structured format—as objects or arrays—using key-value pairs that represent information. This format allows different types of data to be structured in a way that ensures both systems can interpret the data correctly. When data are transmitted in this format, the receiving system can easily interpret and process the information, allowing smooth integration across applications.
Example	This JSON file highlights how a patient's blood pressure observation is formatted and exchanged in a standardized manner between systems. View Sample Code

XML (eXtensible Markup Language)

Definition	A text-based data format (like JSON) designed to store and transport data in a structured and self-descriptive way. It is both human-readable and machine-parsable, and is widely used in web services, document storage and data exchange between systems.
How It Works	XML stores data using a tree-like structure where elements are defined by opening and closing tags. Each element can have attributes, nested elements or text content to represent data hierarchies and relationships. XML is highly flexible, allowing developers to define custom tags and schemas to suit specific use cases. Systems use the tags and structure to interpret data transmitted in XML, enabling interoperability across diverse applications and platforms.
Example	This is an example of an XML file illustrating how a patient's blood pressure observation can be formatted and exchanged in a standardized manner between systems. View Sample Code

CQL (Clinical Quality Language)

Definition	An open-source, standards-based logic published by HL7, designed to express clinical rules and quality measures in a clear, consistent and human-readable format. It is a high-level, domain-specific language that enables specification of complex health care concepts, including decision support and quality measurement criteria, and is both human-readable and machine-parsable.
How It Works	In digital quality measurement, CQL helps harmonize how logic is written across systems and drives performance calculations, such as determining if certain clinical actions or outcomes meet measure requirements. Logic written in CQL can be executed by software systems to automatically compute whether patients or populations meet quality metrics, reducing the need for manual review and enabling real-time or near real-time quality reporting.
Example	This is an excerpt from a CQL code example for the Controlling High Blood Pressure (CBP) measure, which calculates whether a patient's most recent blood pressure reading meets the target thresholds. View Sample Code

ELM (Expression Logical Model)

Definition	A machine-readable data model derived from CQL. It provides structured instructions that systems can ingest, ensuring that clinical logic authored in CQL can be consistently understood and reliably executed by machines.
How It Works	ELM is a computer-interpretable representation of CQL that enables systems to execute the defined logic. CQL logic is translated into ELM, typically in formats like JSON or XML, which are optimized for machine parsing and ingestion. While CQL focuses on creation, ELM facilitates execution of logic across diverse systems.
Example	This is an example of CQL to ELM transformation. View Sample Code

Clinical Quality Engine

Definition	In the health care interoperability domain, the system responsible for executing clinical logic, processing data and delivering results for use in health care applications like quality measurement and clinical decision support.
How It Works	A clinical quality engine collects health care data, such as patient records stored in a FHIR-based system, and applies standardized quality measures to assess whether clinical guidelines and best practices are met, calculating scores or results based on these metrics. The engine generates reports that help providers and health care organizations understand their performance, identify areas for improvement and ensure compliance with quality standards.
Example	CQL Engine. A software system designed to understand and follow instructions written in CQL. Clinical and administrative data are input into the CQL engine, which uses instructions in the CQL script to compute quality measures, apply clinical decision rules and derive outcomes.

Interoperability and Digital Quality Measurement

Digital quality measurement relies on seamless data exchange, accurate processing and reliable testing to ensure that data accurately reflect care quality. Multiple technologies and standards come together to enable accurate and efficient reporting.

A “clinical quality engine” is the core processing unit that takes clinical data in FHIR format, applies CQL logic (via ELM) and processes the data so results can be delivered through an API in formats like JSON. Together, these components form an ecosystem where clinical data can be automatically shared, processed and validated across systems.

Key Components of a Clinical Quality Engine in This Context

FHIR (Data Format): Provides the structure and standard for clinical data.
CQL (Logic Language): Defines the clinical rules and logic in human-readable form.
ELM (Executable Model): Converts CQL into machine-readable format (JSON/XML) for execution.
JSON (Data Interchange Format): Used to format both FHIR resources and ELM, allowing easy data exchange.
API (Integration): Exposes runtime engine functionality, allowing systems to submit FHIR data and retrieve processed results.

Sample Communication: HEDIS Blood Pressure Control Measure

Input Data (FHIR + JSON)

The engine receives clinical data in FHIR format, often structured as JSON files. For example, the data might include blood pressure observations, diagnoses and encounters.

Clinical Logic (CQL)

The runtime engine has CQL logic that defines criteria for controlling blood pressure (systolic ≤140, diastolic ≤90).

Translation (ELM)

The CQL logic is translated into ELM, a machine-readable, structured format like JSON or XML.

Processing and Execution (Runtime Engine)

The runtime engine processes the FHIR data, evaluating whether blood pressure readings meet thresholds defined in the CQL. It uses ELM to retrieve the necessary patient data, apply logical conditions and determine if the patient qualifies for the measure.

Integration, Output and Results (APIs)

The runtime engine calculates results (whether the patient's blood pressure is controlled or not), which are returned as a JSON response through an API, which can be used for reporting or sent to another system for further action.

Related Resources

Articles

The Language of Interoperability and Digital Quality Measurement

Introduction to Interoperability in Quality Measurement

An Overview of Essential Terms

API (Application Programming Interface)

FHIR® (Fast Healthcare Interoperability Resources)

JSON (JavaScript Object Notation File)

XML (eXtensible Markup Language)

CQL (Clinical Quality Language)

ELM (Expression Logical Model)

Clinical Quality Engine

Interoperability and Digital Quality Measurement

Sample Communication: HEDIS Blood Pressure Control Measure

Input Data (FHIR + JSON)

Clinical Logic (CQL)

Translation (ELM)

Processing and Execution (Runtime Engine)

Integration, Output and Results (APIs)

Related Resources

CQL Engines for Technical Teams

HEDIS Volume 2 Is Getting a Makeover!

Advancing Digital Quality: Addressing Data Challenges to Improve Performance

Introducing the First Cohort of the Bulk FHIR Quality Coalition

NCQA Shares New Guidance for Digital HEDIS Reporting

NCQA’s Proposed Timeline for Retiring and Replacing HEDIS Hybrid Measures

Lessons Learned From Leading Health Plans Implementing Digital Quality

NCQA Fireside Chat: Charting the Future of Health Care Interoperability

FHIR^® (Fast Healthcare Interoperability Resources)