Clinical Quality Language (CQL)

CQL is designed to be both human-readable and computable, bridging the gap between clinical domain experts and software engineers. Its syntax is inspired by common programming languages but uses clinical terminology, allowing non-programmers to review and validate the logic. This dual nature ensures that a quality measure's intent is transparent and auditable, reducing the risk of misinterpretation during implementation.

CQL is fundamentally designed to operate on the FHIR (Fast Healthcare Interoperability Resources) data model. It uses a domain-specific data model called QUICK (Quality Improvement Core) as a logical view, which maps directly to FHIR resources. This tight coupling allows CQL expressions to natively traverse FHIR profiles, retrieve specific resources like Patient, Observation, or MedicationRequest, and access their elements using a path-based syntax, ensuring seamless integration with modern healthcare APIs.

CQL provides a rich set of operators for defining complex clinical logic:

• Comparison and Logical Operators: =, >, and, or, not for building conditional rules.
• Timing and Interval Operators: Operators like before, after, during, and within allow precise temporal reasoning, such as checking if a lab test occurred within 30 days of a diagnosis.
• List and Aggregate Functions: exists, forall, count, sum, and avg enable population-level analysis and cohort identification.

CQL has first-class support for value set membership testing. Authors can define expressions that check if a clinical concept belongs to a specific value set (e.g., 'Diabetes' value set) without hardcoding individual codes. The language includes a valueset keyword and an in operator, allowing the expression "Diabetes" in "Diabetes Value Set". This decouples the clinical logic from the specific code systems like SNOMED CT, LOINC, or ICD-10, making measures resilient to terminology updates.

CQL promotes modularity and reuse through a library model. Logic can be packaged into named libraries, versioned, and shared across multiple measures or decision support artifacts. A library can declare:

• Parameters: Input values provided at runtime.
• Expressions: Named reusable logic fragments.
• Functions: Parameterized, callable blocks of logic. This component-based architecture prevents duplication and ensures consistent implementation of common clinical definitions across an organization.

For machine execution, CQL is translated into a canonical, XML-based representation called Expression Logical Model (ELM). The CQL-to-ELM translator produces a deterministic, unambiguous abstract syntax tree that calculation engines consume directly. This two-layer approach—human-readable CQL for authoring and machine-optimized ELM for execution—ensures that the original clinical intent is preserved while enabling high-performance, deterministic computation in clinical decision support and quality reporting systems.