FHIR Clinical Reasoning

A domain-specific, human-readable language for expressing clinical logic in FHIR artifacts. CQL provides:

• Authoring-level syntax that clinicians can review and validate
• ELM (Expression Logical Model) for machine processing
• Built-in clinical operators for age calculations, medication periods, and lab value comparisons
• Seamless integration with FHIRPath for data traversal CQL separates logic from data models, allowing the same rule to execute against FHIR DSTU2, STU3, or R4 without modification.

The $apply operation is the primary execution mechanism for PlanDefinition and ActivityDefinition resources. The execution flow:

• Data Requirements: Library resources declare what patient data is needed
• Expression Evaluation: CQL logic evaluates against retrieved FHIR data
• Action Generation: PlanDefinition actions produce RequestGroup resources with proposed clinical activities
• Care Plan Integration: Generated requests can be incorporated into the patient's CarePlan This enables CDS Hooks services to return actionable recommendations.

The $evaluate-measure operation processes Measure resources to calculate quality metrics. Core components:

• Population Criteria: Initial population, denominator, denominator exclusion, numerator, numerator exclusion
• Stratifiers: Break down results by age, gender, or clinical factors
• MeasureReport: The output resource containing calculated scores and patient-level results
• Continuous Variable Measures: Support for measures that produce a calculated score rather than a proportion Supports both individual patient-level and summary-level reporting.

FHIR Clinical Reasoning artifacts serve as the knowledge backbone for CDS Hooks services. The integration pattern:

• A CDS Hooks service receives a hook (e.g., patient-view, order-select)
• The service executes relevant PlanDefinition or Library resources via the $apply operation
• Generated RequestGroup resources are translated into CDS Hooks suggestion cards
• Cards include actions like create, update, or delete with FHIR resource payloads This decouples knowledge authoring from EHR-specific integration logic.

Clinical reasoning artifacts depend on robust terminology services for value set expansion and code validation. Key capabilities:

• ValueSet $expand: Resolves a value set definition to its member codes at runtime
• ConceptMap $translate: Maps codes between different code systems (e.g., SNOMED CT to ICD-10-CM)
• CodeSystem $lookup: Retrieves display names and properties for specific codes
• FHIR Terminology Service: Provides a standardized RESTful API for all terminology operations CQL expressions reference value sets by canonical URL, enabling late-binding to the latest code versions.

The FHIR Clinical Reasoning module defines a set of resources to represent structured clinical knowledge as discrete, shareable artifacts.

• PlanDefinition: Represents computable clinical protocols, order sets, and guidelines as a sequence of actions with decision logic.
• ActivityDefinition: Defines a single clinical activity, such as ordering a lab panel or administering a medication, with associated timing and dosage.
• Measure: Represents a clinical quality measure (eQM) with defined populations (initial, denominator, numerator) and stratification criteria.
• Library: A container for logic libraries, including CQL or FHIRPath expressions, that can be referenced by other knowledge artifacts.

A lightweight, path-based navigation and extraction language used to traverse and compute values from FHIR resources.

• XPath-inspired syntax: Uses a familiar dot-notation to navigate resource elements, e.g., Patient.name.where(use = 'official').given.
• Invocation model: Supports functions like exists(), count(), aggregate(), and today() for temporal comparisons.
• Complementary to CQL: Often used for simpler data extraction within Questionnaire and PlanDefinition resources where full CQL is unnecessary.
• Canonical URL: Defined at http://hl7.org/fhirpath/, ensuring consistent implementation across FHIR servers.

A software service that evaluates CQL or FHIRPath expressions against a FHIR server's data to generate patient-specific recommendations, quality measure reports, or care gap analyses.

• $apply operation: The core FHIR operation that executes a PlanDefinition against a specific patient context, returning a CarePlan or RequestGroup.
• $evaluate-measure operation: Executes a Measure resource to calculate quality metrics for an individual patient or a population cohort.
• Data requirements discovery: The $data-requirements operation introspects a knowledge artifact to declare all necessary FHIR resources, enabling prefetch optimization.
• Stateless execution: Engines typically operate as stateless microservices, fetching all required data at invocation time to ensure deterministic, auditable results.

The electronic Clinical Quality Measure (eCQM) framework uses FHIR Clinical Reasoning to standardize the calculation and reporting of healthcare quality metrics.

• MeasureReport resource: Captures the results of an eCQM evaluation, including population counts, stratification, and individual patient-level results.
• Data-of-type evaluation: The evaluate-measure operation can process data for a single patient, a practitioner's panel, or an entire hospital census.
• Value set binding: Measures reference ValueSet resources to define terminological constraints, such as a specific set of LOINC codes for HbA1c lab results.
• Attestation and submission: MeasureReports can be digitally signed and submitted to regulatory bodies like CMS for programs such as MIPS and APMs.