Building Evidence-Based Clinical Pathways with SNOMED CT, LOINC, CQL, and HL7 FHIR R5
Abstract
The computerization of evidence-based clinical pathways requires more than translating narrative recommendations into simple “if–then” statements. A reliable implementation must preserve the meaning of clinical observations, diagnoses, interventions, timing constraints, exceptions, and evidence provenance while integrating with Electronic Health Record (EHR) and Laboratory Information System (LIS) workflows. SNOMED CT and LOINC aprovide complementary semantic foundations for this work. LOINC is commonly used to identify laboratory tests, clinical measurements, and other observations, whereas SNOMED CT represents clinical findings, disorders, organisms, procedures, and many qualitative result values. HL7 FHIR R5 provides the structural resources for representing knowledge artifacts, while Clinical Quality Language (CQL) supplies executable patient-level logic.
This essay proposes a reference architecture consisting of a terminology server, a clinical pathway or knowledge-artifact server, and an EHR/LIS interoperability layer. It explains the roles of PlanDefinition, ActivityDefinition, Library, and RequestOrchestration; describes the correct semantics of the HL7 FHIR R5 PlanDefinition/$apply operation; and presents a sample CQL expression using LOINC and SNOMED CT. Particular attention is paid to terminology versioning, (legacy) local-code mapping, unit normalization, clinical governance, validation, and the distinction between generating a proposed action and authorizing or persisting an order.
Automating
evidence-based clinical pathways should be a clinical impact- and risk-driven exercise.
Designing systems that try to "automate everything but the kitchen
sink" leads to alert fatigue, rigid cookbook medicine, and frustration for clinicians and nurses. Instead, pathways should focus on targeted, high-value/high-risk areas where
digital intervention tangibly improves patient safety and clinically relevant
outcomes.
Keywords: SNOMED CT, LOINC, HL7 FHIR R5, CQL, ELM, clinical pathways, clinical decision support, terminology server, LIS, EHR, EBM, ELM, evidence-based medicine
1. Introduction
Structured data should not be regarded primarily as material for the discharge summary, billing, medical coding, research, or retrospective quality reporting. During active care, structured data is the machine-readable representation of the patient’s current clinical state, the decisions already made, and the actions still required.
An evidence-based clinical pathway must continuously answer questions such as:
- What is happening to the patient now?
- When did it start?
- How certain is the diagnosis?
- Which inclusion and exclusion criteria are satisfied?
- Which intervention has already been performed?
- Did the patient respond?
- Which deadline or escalation point is approaching?
A discharge letter usually answers a different question: What happened during the admission? Administrative coding answers another: How should the completed episode be classified for reimbursement, statistics, or reporting? Those retrospective functions remain important, but they occur too late and are too compressed to operate a pathway during care. Data must become available when it can still change the patient’s care and not only when the episode has already ended.
One should capture the pathway-critical clinically relevant facts ergonomically as standardized structured data and generate or support the narrative from those facts, while allowing clinicians to add explanatory context. The same well-designed point-of-care data can later populate the discharge summary, support medical coding, calculate quality indicators, and enable research. The sequence should not be reversed. Clinical data should be structured first for safe and effective patient care, with administrative and analytical reuse as important secondary benefits.
A clinical pathway is a structured, multidisciplinary plan that translates clinical evidence and clinical-practice recommendations into a sequence of patient-management activities. Computerization can make pathways more consistent and measurable, but only when the underlying clinical concepts and decision logic are represented unambiguously. A literal conversion of prose into software rules is insufficient because narrative guidelines frequently contain implicit assumptions, exceptions, temporal relationships, and terms that are interpreted differently by different institutions (Kinsman et al., 2010; Shivers et al., 2021).
Semantic interoperability is therefore a prerequisite for computable evidence-based medicine. An EHR, pathway engine, and LIS must interpret a test, result, diagnosis, or proposed intervention consistently even when the originating systems use different local identifiers. Research on clinical-pathway standardization demonstrates that terminology normalization, including the use of SNOMED CT, can reduce lexical variation and improve machine processing of pathway content (Alahmar et al., 2022; Brandt et al., 2020).
FHIR provides the exchange and knowledge-artifact structures, but FHIR alone does not define the clinical meaning of every data element or the executable logic of a guideline. In a mature implementation:
SNOMED CT and LOINC provide controlled clinical meaning.
Unified Code for Units of Measure (UCUM) provides computable units of measure.
FHIR resources provide the information and workflow structures.
CQL represents executable inclusion, exclusion, calculation, and decision logic.
A terminology service validates and expands the codes used by both patient data and pathway artifacts.
Clinical governance determines whether the encoded pathway remains faithful to the evidence and safe for local use.
The result is not merely an alerting system. It is a versioned, traceable, testable, and interoperable clinical knowledge system.
2. Complementary Roles of LOINC and SNOMED CT
2.1 LOINC as the identifier of an observation or test
LOINC (Logical Observation Identifiers Names and Codes) is designed primarily to identify observations, measurements, laboratory analyses, clinical documents, and related orderable concepts. In laboratory exchange, it answers the semantic question: “What was measured, observed, or requested?” Examples include glycated hemoglobin (HbA1c), serum potassium concentration, blood pressure, a microbiology culture, and a molecular-genetics observation.
The familiar “LOINC question, SNOMED CT answer” formulation is useful but should be treated as an implementation heuristic rather than an absolute rule. LOINC also contains answer lists and document concepts, while SNOMED CT includes observable entities and procedures. Code-system selection should therefore be based on the semantic role of the element, the applicable implementation guide, and jurisdictional policy, not on a rigid assertion that every question must be LOINC and every answer must be SNOMED CT (SNOMED International, n.d.-a).
In legacy HL7 version 2 laboratory messages, LOINC commonly appears in OBR-4 or OBX-3, identifying the ordered panel or reported observation. A coded qualitative result may appear in OBX-5 using SNOMED CT. The equivalent FHIR pattern normally places the LOINC code in ServiceRequest.code for an order or in Observation.code for a result (Regenstrief Institute, n.d.-a).
2.2 SNOMED CT as the representation of clinical meaning
SNOMED CT (Systematized Nomenclature of Medicine – Clinical Terms) provides a logically defined clinical terminology for findings, disorders, symptoms, organisms, body structures, procedures, situations with explicit context, and other clinical concepts. Its description-logic foundation supports hierarchy and subsumption operations, allowing a pathway to test membership in clinically meaningful categories rather than maintaining a flat list of every possible descendant code.
For example, a pathway may determine whether a patient has a subtype of diabetes by testing a SNOMED CT value set, or whether an organism reported by microbiology belongs to a clinically relevant taxonomic category. This is more maintainable than embedding display strings or local database identifiers in decision logic. SNOMED CT codes should be evaluated through a terminology service using a declared edition, module, extension, and effective version (SNOMED International, n.d.-b).
2.3 Units and contextual attributes remain essential
A terminology code does not by itself make a result clinically comparable. Numeric observations also require a computable unit, normally represented using Unified Code for Units of Measure (UCUM). Specimen type, measurement method, timing, fasting state, reference range, interpretation, and analytical context may materially affect the meaning of a laboratory result.
For example, a rule comparing an HbA1c result with a percentage threshold must not inadvertently evaluate a result expressed using a different reporting convention. The code, unit, method, and applicable guideline threshold must be validated together. FHIR represents the numeric result in Observation.valueQuantity, with the UCUM system URI and code used for machine comparison.
2.4 The LOINC Ontology collaboration
The collaborative LOINC Ontology represents defined LOINC content in the SNOMED CT logical model and distribution format. It can strengthen subsumption queries and semantic analytics by making relationships between laboratory concepts computable within a SNOMED CT-oriented terminology environment. However, it should not be interpreted as eliminating ordinary LOINC identifiers or as merging every part of both terminologies into a single undifferentiated code system.
Original LOINC codes used in FHIR continue to use http://loinc.org. Concepts distributed through the SNOMED CT–LOINC Ontology use SNOMED CT URI conventions and must be resolved against the appropriate module and version. An implementation must therefore distinguish the original LOINC identifier from ontology concepts derived or distributed through the collaboration (SNOMED International, n.d.-c).
3. Transforming an Evidence-Based Guideline into a Computable Pathway
3.1 Establish the evidence and governance baseline
The first artifact should not be CQL. It should be a governed clinical specification that identifies:
The authoritative guideline, publication date, version, and jurisdiction.
The strength of each recommendation and quality of supporting evidence.
The intended population and care setting.
Inclusion and exclusion criteria.
Required observations and their permitted temporal windows.
Actions, alternatives, contraindications, and escalation rules.
Responsible clinical roles.
Expected outcomes and monitoring intervals.
Known areas of ambiguity requiring local policy.
Approval, review, and retirement dates.
Each computable recommendation should retain traceability to its source paragraph, evidence statement, and local approval decision. In FHIR, this provenance can be represented partly through knowledge-artifact metadata and relatedArtifact elements, while organizational governance should also maintain review records and change-control documentation. HL7 FHIR R5 provides metadata such as canonical URL, business version, publisher, approval date, last-review date, and effective period for this purpose.
3.2 Decompose narrative recommendations
The narrative guideline should then be decomposed into explicit logical components:
Trigger: The event that causes evaluation, such as receipt of a laboratory result, opening a patient record, placing an order, admission, or scheduled reassessment.
Population: Demographic and clinical inclusion criteria.
Exclusions: Contraindications, previous procedures, comorbidities, patient preferences, or missing prerequisites.
Data requirements: The observations, conditions, medications, procedures, encounters, and temporal relationships needed by the rule.
Decision logic: Boolean expressions, calculations, thresholds, and uncertainty handling.
Actions: Proposed orders, assessments, referrals, communications, or documentation.
Exit criteria: Conditions under which the pathway is completed, suspended, or escalated.
Explanation: Human-readable rationale and evidence shown to the clinician.
This intermediate specification is critical because the terminology expert, informatician, software engineer, and clinical subject-matter expert must agree on the same interpretation before the recommendation is executed against real patient data. WHO guideline-computerization work has similarly emphasized an intermediate, structured representation between narrative guidance and executable FHIR artifacts (Shivers et al., 2021).
3.3 Define the terminology bindings
A terminology binding is a rule connecting a coded data element in an information model, such as a FHIR resource or profile, to a defined ValueSet. It specifies: For this field, which clinical concepts may or should be used, and how strictly must the system follow that selection? A code system is the complete vocabulary or dictionary that defines codes and their meanings. A valueset selects the concepts permitted or recommended for a particular purpose. It can contain codes from one or several code systems. The binding connects that valueset to a specific field. In practical terms, a terminology binding is a semantic contract as it tells data producers, receivers, terminology servers, and clinical pathway engines which coded meanings are acceptable in a particular clinical-data element.
For every data element, an implementation should produce a terminology binding worksheet containing:
Clinical meaning and intended use.
FHIR resource and element.
Preferred (open international) code system.
Code or intensional value set.
Code-system version.
Required or permitted units.
Specimen and method constraints.
Local-to-standard mapping.
Handling of absent, unknown, indeterminate, or invalid results.
Test cases demonstrating accepted and rejected data.
Single codes may be sufficient for tightly defined observations, but diagnosis and eligibility logic often requires versioned value sets. Intensional SNOMED CT value sets, expressed using the terminology’s hierarchy or Expression Constraint Language (ECL), are generally more maintainable than manually enumerated descendants. LOINC value sets may likewise be needed when several methods or specimen-specific observations are clinically equivalent for the pathway.
4. HL7 FHIR R5 Knowledge-Artifact Model
HL7 FHIR R5’s Clinical Reasoning module supports the representation, distribution, and evaluation of clinical decision-support rules, protocols, order sets, and related knowledge artifacts. The central resources are PlanDefinition, ActivityDefinition, and Library. These resources are designated Trial Use in HL7 FHIR R5, which makes explicit profiling, conformance testing, and bilateral implementation agreements especially important for production deployment (HL7, 2023a).
Note: HL7 FHIR (Fast Healthcare Interoperability Resources) and openEHR are complementary health informatics standards. HL7 FHIR is designed for data exchange across disparate health systems using web APIs, while openEHR governs the storage and modeling of complex, longitudinal clinical data. In a modern hybrid architecture openEHR is used as the foundational clinical repository to store deep, complex medical data securely and independently of any single software vendor. HL7 FHIR APIs act as a translator or facade on top of the openEHR repository. This allows external apps, patient portals, or third-party tools to request and exchange the stored data using universally accepted HL7 FHIR resources.
4.1 PlanDefinition
PlanDefinition is the patient-independent blueprint of the pathway. It describes the action hierarchy, workflow relationships, triggers, applicability conditions, selection behavior, timing, and references to reusable activity definitions.
A PlanDefinition.action.condition may be designated as an applicability, start, or stop condition. An applicability condition is evaluated when the plan is applied to a patient. Its expression can refer to a named expression in a Clinical Quality Language (CQL) library referenced through PlanDefinition.library. Multiple conditions of the same kind are combined using logical AND semantics in the base specification (HL7, 2025).
A typical link is conceptually equivalent to:
{
"library": [
"https://example.org/fhir/Library/diabetes-hba1c-logic|1.0.0"
],
"action": [
{
"title": "Propose guideline-defined follow-up",
"condition": [
{
"kind": "applicability",
"expression": {
"language": "text/cql",
"expression": "Pathway Applicability"
}
}
],
"definitionCanonical":
"https://example.org/fhir/ActivityDefinition/diabetes-follow-up|1.0.0"
}
]
}
HL7 clinical-guideline examples use this pattern to connect an applicability expression with an ActivityDefinition.
4.2 ActivityDefinition
ActivityDefinition represents a reusable definition of an action that can create a request resource. Depending on the pathway, this could be a ServiceRequest, MedicationRequest, Task, CommunicationRequest, Appointment, or another request-type resource permitted by the R5 model.
For laboratory pathways, an ActivityDefinition may define the common characteristics of a proposed ServiceRequest, including the LOINC-coded service, intent, priority, timing, specimen expectations, and supporting information. Patient-specific values can be supplied through dynamic expressions during application.
Medication identification should not automatically be assigned to SNOMED CT merely because SNOMED CT is used elsewhere in the pathway. A production implementation should use the mandated medication terminology for its jurisdiction, for example, RxNorm (United States) or the relevant national medicinal-product terminology, and retain SNOMED CT where it is semantically appropriate. There is no single direct equivalent to RxNorm in Europe. European medication normalization is divided across clinical care, regulatory frameworks, and regional coding.
4.3 Library and Clinical Quality Language (CQL)
The FHIR Library resource is a general-purpose container for logic and other knowledge content. It may contain or reference CQL source, compiled Expression Logical Model representations, parameters, and data requirements. When embedded content and an external URL are both present, the R5 specification instructs implementations to give precedence to the embedded content, making content integrity and version governance important (HL7, 2023b).
The Clinical Quality Language (CQL) should contain the substantive patient-level logic rather than embedding extensive expressions directly in PlanDefinition. This separation supports independent review, testing, reuse, and translation of the CQL into Expression Logical Model (ELM) for execution. Official HL7 clinical-guideline examples demonstrate retrievals using LOINC and SNOMED CT, FHIR status filtering, terminology equivalence, and named expressions referenced by plan definitions.
Note: Translating Clinical Quality Language (CQL) into Expression Logical Model (ELM) is the mandatory first step before executing clinical logic against data sources like HL7 FHIR or OHDSI OMOP (Observational Medical Outcomes Partnership). It converts human-readable syntax into a machine-readable JavaScript Object Notation (JSON) or XML Abstract Syntax Tree (AST) that engines can process (CQL-to-ELM Translator Reference Implementation, CQL to ELM Translation Service) (Wile, 1997).
5. Reference Architecture
A robust implementation should preserve the separation of responsibilities shown below.
┌───────────────────────────┐
│ Evidence and governance │
│ guideline, approval, │
│ versioning, review dates │
└─────────────┬─────────────┘
│
▼
┌─────────────────┐ ┌────────────────────────────┐
│ Terminology │◄───────►│ Clinical Pathway Server │
│ Server │ │ │
│ │ │ PlanDefinition │
│ SNOMED CT │ │ ActivityDefinition │
│ LOINC │ │ Library: CQL + ELM │
│ UCUM │ │ ValueSet dependencies │
│ ConceptMap │ │ $apply/CQL evaluation │
└───────┬─────────┘ └──────────────┬─────────────┘
│ │
│ validation, expansion, │ proposed patient-specific
│ subsumption, translation │ RequestOrchestration Bundle
▼ ▼
┌────────────────────────────────────────────────────────┐
│ EHR clinical-data and workflow platform │
│ Patient, Encounter, Condition, Observation, │
│ DiagnosticReport, ServiceRequest, MedicationRequest │
│ clinician review, authorization, persistence, audit │
└───────────────────────┬────────────────────────────────┘
│ orders and results
▼
┌──────────────────┐
│ LIS / analyzers │
│ local codes │
│ LOINC mappings │
└──────────────────┘
5.1 Terminology-server responsibilities
The terminology server should load and expose explicitly versioned content for:
The required SNOMED CT international or national edition and extensions.
The approved LOINC release.
Unified Code for Units of Measure (UCUM).
Controlled organization-specific code systems.
Governed
ValueSetandConceptMapresources.The relevant SNOMED CT–LOINC Ontology module, where used.
At minimum, the service should support the FHIR terminology operations required by the pathway and integration environment, commonly including:
$lookupfor concept metadata.$validate-codefor validating a code against a code system or value set.$expandfor generating value-set membership.$subsumesfor hierarchy relationships.$translatefor applying aConceptMap.
FHIR terminology services also support code-system, value-set, concept-map, and capability-management functions. The required subset should be declared through a TerminologyCapabilities resource and verified during deployment.
Terminology versions must be pinned for reproducibility. A pathway that was validated against one SNOMED CT or LOINC release should not silently begin using a later release without regression testing. Canonical references can include a business version, and SNOMED CT version Uniform Resource Identifiers (URI) can identify the module and effective date. It prevents ambiguity when the same clinical concept (SNOMED CT code) is updated or revised in a newer terminology release.
As of 24 February 2026, the public LOINC FHIR terminology service is described by LOINC as an R4 beta service and is explicitly not recommended for production use. Consequently, a production HL7 FHIR R5 architecture should not assume that this public beta endpoint is its operational terminology backend. A production-grade terminology server should instead load the licensed LOINC release locally or use another supported service with declared availability, versioning, and R5 compatibility (Regenstrief Institute, 2026).
5.2 Clinical-pathway server responsibilities
The clinical pathway server should:
Store immutable or properly versioned
PlanDefinition,ActivityDefinition,Library,ValueSet, and related artifacts.Resolve canonical dependencies by URL and version.
Compile Clinical Quality Language (CQL) into Expression Logical Model (ELM) using a translator compatible with the selected HL7 FHIR R5 model information.
Validate every terminology reference through the terminology server.
Retrieve patient data through the EHR’s authorized FHIR API.
Evaluate CQL with a defined handling policy for missing, null, uncertain, or conflicting data.
Execute
PlanDefinition/$apply.Return proposed resources without automatically authorizing clinical actions.
Produce logs sufficient to reproduce the evaluated artifact version, terminology versions, input data, and outcome.
Expose health, capability, and dependency information for operational monitoring.
The knowledge repository and runtime engine may be deployed as one product, but their logical responsibilities should remain distinct. Published artifacts should be immutable for a given canonical URL and version; modifications should result in a new version rather than an undocumented replacement.
6. Correct HL7 FHIR R5 $apply Semantics
In HL7 FHIR R5, applying a PlanDefinition does not ordinarily return a persisted CarePlan, nor does it independently authorize or place orders.
A client invokes the operation at the type or instance level, for example:
POST https://pathway.example.org/fhir/PlanDefinition/diabetes-hba1c/$apply
with parameters such as the patient subject and, where applicable, encounter or practitioner context.
For each returned result, the R5 operation produces a Bundle. The first entry is the patient-specific RequestOrchestration that represents the direct realization of the plan. Subsequent bundle entries are resources created or updated as part of applying applicable actions, such as proposed ServiceRequest or other request resources. During application, applicability conditions are evaluated, and referenced ActivityDefinition resources are applied for the actions that remain applicable (HL7, 2023c).
Critically, the result is transient. The FHIR specification states that the generated resources are not automatically persisted. They represent proposed activities, and the caller determines whether and how those resources enter the clinical workflow.
A safe EHR workflow is therefore:
The EHR or CDS integration invokes
$apply.The pathway engine evaluates the versioned CQL and terminology dependencies.
The engine returns a
Bundlebeginning with aRequestOrchestration.The EHR renders the recommendation, rationale, evidence, and proposed requests.
An authorized, competent and capable clinician and nurse review, modify, accept, or reject each proposal.
Accepted proposals are converted into resources with the locally appropriate authorization intent, status, requester, encounter, and other mandatory fields.
The EHR persists the authorized resources, preferably through a controlled FHIR transaction.
The EHR sends laboratory orders to the LIS.
ProvenanceandAuditEventrecords capture the pathway version, clinician decision, and resulting clinical transaction.
RequestOrchestration.intent expresses the degree of authority associated with the request orchestration. The pathway-generated result should remain distinguishable from a clinician-authorized order.
7. Integration with the EHR and LIS
7.1 Laboratory ordering
The EHR should persist a ServiceRequest representing the authorized laboratory order. Its code should contain the agreed LOINC orderable code when a suitable code exists. The order also needs the patient, requester, encounter, timing, priority, specimen requirements, clinical indication, and supporting information required by the local workflow.
Where the LIS still uses a local catalog identifier, the interface should transmit both the standard and local coding where possible:
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "4548-4",
"display": "Hemoglobin A1c/Hemoglobin.total in Blood"
},
{
"system": "https://hospital.example.org/codes/lab-catalog",
"code": "HBA1C"
}
]
}
The local code should not be discarded because it may be necessary for analyzer routing and operational reconciliation. Conversely, downstream CDS should not depend solely on the local code. The mapping should be governed in a ConceptMap or equivalent terminology-management repository and validated when the LIS catalog changes.
7.2 Laboratory results
FHIR laboratory results are normally represented through Observation resources, grouped and interpreted by a DiagnosticReport where appropriate. Specimen represents the collected material. The recommended semantic pattern is:
Observation.code: LOINC observation identifier.Observation.valueQuantity: numeric result with UCUM units.Observation.valueCodeableConcept: coded qualitative result, commonly SNOMED CT where appropriate.Observation.interpretation: high, low, positive, negative, or other interpretation code.Observation.referenceRange: laboratory-supplied reference interval.Observation.method: measurement method when clinically material.DiagnosticReport.result: references to component observations.DiagnosticReport.conclusionCode: coded diagnostic conclusion where appropriate.
This pattern supports numeric laboratory medicine as well as microbiology, in which LOINC may identify the culture or susceptibility observation and SNOMED CT may identify the organism or qualitative finding.
7.3 Triggering pathway evaluation
A pathway can be evaluated through several integration patterns:
A synchronous Computable Clinical Decision Support (CDS) Hooks invocation at an EHR workflow point.
An EHR-native event invoking the pathway API.
A FHIR Subscription or event-processing layer responding to a new result.
A scheduled population or patient-level evaluation.
A SMART-on-FHIR application launched in the clinical context.
CDS Hooks provides a standard pattern for synchronous, workflow-triggered CDS, including context, optional prefetch, FHIR access, and returned cards or suggested actions. SMART App Launch supplies OAuth-based authorization (Open Authorization) patterns for user-facing and backend applications. These integration mechanisms are complementary to the HL7 FHIR R5 knowledge artifacts: they determine when and under whose authorization the pathway server is called, whereas PlanDefinition, CQL, and $apply determine what is evaluated and returned (HL7, n.d.; HL7, 2024).
Clinical-decision-support (CDS) standards should be selected as an integrated stack rather than as isolated specifications. Published reviews of contemporary HL7 standards emphasize the complementary roles of FHIR data exchange, CQL, knowledge artifacts, CDS Hooks, and SMART applications in delivering interoperable CDS (Strasberg et al., 2021).
8. Illustrative CQL Using LOINC and SNOMED CT
The following Clinical Quality Language (CQL) illustrates how a pathway might identify a patient with confirmed active type 2 diabetes mellitus and a recent final HbA1c result above a configurable threshold. It uses LOINC 4548-4 for the HbA1c observation and SNOMED CT 44054006 for type 2 diabetes mellitus. FHIR provides the patient data and pathway structures; terminology supplies the clinical meanings; CQL expresses the logic that evaluates those data.
The threshold of 8.0 '%' is an illustrative parameter, not a clinical recommendation. A real implementation must obtain its threshold, measurement constraints, exclusions, and action from a current, jurisdictionally applicable guideline. The acceptable HbA1c LOINC value set may also need to include method-specific codes. LOINC confirms 4548-4 as an HbA1c observation, while the SNOMED CT diagnosis code should be validated against the licensed edition installed in the terminology server.
library DiabetesHbA1cPathway version '1.0.0'
using FHIR version '5.0.0'
/*
Resolve and pin the FHIRHelpers version supplied by the selected
R5 CQL execution environment before production publication.
*/
include FHIRHelpers called FHIRHelpers
codesystem "LOINC":
'http://loinc.org'
codesystem "SNOMED CT":
'http://snomed.info/sct'
codesystem "Condition Clinical Status":
'http://terminology.hl7.org/CodeSystem/condition-clinical'
codesystem "Condition Verification Status":
'http://terminology.hl7.org/CodeSystem/condition-ver-status'
code "HbA1c":
'4548-4' from "LOINC"
display 'Hemoglobin A1c/Hemoglobin.total in Blood'
code "Type 2 diabetes mellitus":
'44054006' from "SNOMED CT"
display 'Type 2 diabetes mellitus'
code "Active condition":
'active' from "Condition Clinical Status"
code "Confirmed condition":
'confirmed' from "Condition Verification Status"
/*
Illustrative only. In production this parameter should be supplied
by the governed guideline artifact rather than changed in source code.
*/
parameter "HbA1c Threshold"
System.Quantity default 8.0 '%'
context Patient
define "Has Confirmed Active Type 2 Diabetes":
exists (
[Condition: "Type 2 diabetes mellitus"] C
where C.clinicalStatus ~ "Active condition"
and C.verificationStatus ~ "Confirmed condition"
)
define "Final HbA1c Observations":
[Observation: "HbA1c"] O
where O.status in { 'final', 'amended', 'corrected' }
and O.value is FHIR.Quantity
define "Latest HbA1c Observation":
First(
"Final HbA1c Observations" O
sort by issued descending
)
define "Latest HbA1c Quantity":
FHIRHelpers.ToQuantity(
"Latest HbA1c Observation".value as FHIR.Quantity
)
define "Pathway Applicability":
"Has Confirmed Active Type 2 Diabetes"
and "Latest HbA1c Quantity" is not null
and "Latest HbA1c Quantity" > "HbA1c Threshold"
This fragment follows the general CQL/FHIR retrieval pattern used in HL7 clinical-guideline examples, including terminology declarations, FHIR resource retrievals, status filtering, terminology equivalence, and named eligibility expressions.
Before deployment, the implementation must define at least the following details:
What “latest” means when
issuedis absent or differs fromeffective[x].The maximum acceptable age of the result.
Whether point-of-care and laboratory HbA1c methods are interchangeable.
Permitted UCUM units and conversion policy.
Handling of entered-in-error, preliminary, cancelled, or corrected results.
Handling of multiple concurrent results.
Required exclusions and contraindications.
The exact action associated with a true applicability expression.
Whether missing data means false, unknown, or a request for additional information.
The Clinical Quality Language (CQL) should be compiled to an Expression Logical Model (ELM) and tested with the same HL7 FHIR R5 model-info and helper-library packages used by the production engine. A syntactically valid CQL library is not necessarily clinically correct, and a clinically correct library may still fail against unexpected FHIR profiles or terminology versions.
9. Validation and Safety Assurance
A production pathway should pass several independent validation layers.
9.1 Terminology validation
Every code must pass $validate-code against its declared code system or value set and version. Value-set expansions should be reproducible and cached or versioned where necessary. Local-to-standard mappings require clinical review; automatic lexical matching alone is not sufficient for high-risk decisions.
9.2 HL7 FHIR conformance validation
All knowledge artifacts, patient data, and generated proposal resources should be validated against HL7 FHIR R5 and the applicable implementation-guide profiles. Canonical dependencies must resolve to the intended versions, and the pathway package should be tested as a complete dependency graph rather than as isolated JavaScript Object Notation (JSON) files.
9.3 Clinical Quality Language (CQL) validation
The source should compile without errors to ELM. Unit tests should cover true, false, null, missing-data, boundary, unit-conversion, duplicate-result, corrected-result, and temporal cases. Test fixtures should include expected RequestOrchestration and proposed-resource outputs.
9.4 Clinical validation
Clinicians and nurses are two vital pillars of the healthcare system, working as a collaborative team to ensure optimal patient outcomes. While clinicians (like doctors and physician assistants) focus on diagnosis and prescribing treatment, nurses execute care plans, monitor patient vitals, and provide continuous bedside support.
Independent clinicians and nurses should compare pathway outputs against the narrative guideline and representative patient scenarios. The review must examine not only whether the recommendation fires, but also whether it does not fire in excluded or ambiguous cases.
International and national professional organizations of clinicians and nurses should take the lead in preparing evidence-based clinical pathways for automation. Medical societies and specialized bodies serve as the definitive authorities on medical consensus, guidelines, and quality control. Their involvement ensures that automated workflows and digital algorithms prioritize patient safety and clinical efficacy over administrative bottlenecks or rigid technological limitations.
Professional organizations are critical to the successful automation of clinical pathways for several reasons:
- Translating Guidelines into Actionable Logic: Clinical practice guidelines are frequently broad and textual, making them difficult to integrate directly into Electronic Health Record (EHR) systems. Medical specialty societies are best positioned to translate these standards into precise, computer-consumable algorithms using frameworks like BPM+ Health (De Ramon Fernandez, et al., 2020).
- Preventing Automation Bias and Ensuring Oversight: The automation of care can introduce risks like automation bias, where clinicians might over-rely on system suggestions, or obscure unique patient nuances. Professional oversight ensures that Artificial Intelligence (AI) and automated Clinical Decision Support Systems (CDSS) act as tools that complement clinical judgment rather than replace it.
- Standardizing Medical Terminology: Automated clinical pathways require precise data standardization (e.g., mapping treatments to standardized terminologies like SNOMED CT) to prevent misinterpretation and support interoperability. Professional bodies ensure consistent, specialty-wide vocabulary usage.
- Continuous Updates and Vetting: Medical innovation moves too fast for static guidelines. Organizations can establish transparent, systematic review protocols to audit and update automated pathways as new treatments and technologies emerge.
9.5 Workflow and human-factors validation
Workflow and human-factors validation involves iteratively designing digital systems so that they complement human cognition, operate transparently, and are rigorously tested for safety against automation bias. It integrates continuous algorithmic performance validation with human-in-the-loop (HITL) usability metrics to ensure teams perform more safely and efficiently than humans or digital systems alone.
The EHR interface should make clear that the output is a recommendation or proposal, identify the evidence and data used, expose missing information, and permit an authorized clinician to accept, modify, or reject the action. Alert frequency, override reasons, acceptance rates, and unintended consequences should be monitored after deployment.
9.6 Lifecycle governance
A new guideline, terminology release, laboratory method, EHR profile, or Clinical Quality Language (CQL)-engine version may change pathway behavior. Each change should trigger impact analysis and regression testing. Retired artifacts must remain available for audit, while the operational environment prevents their use for new decisions.
Proper impact analysis and regression testing are vital when clinical pathway behavior changes due to updates, and retired artifacts must be archived for audits while blocked from active use.
The core message is that every modification must be carefully tested to prevent errors for patients, and that older versions must be retained for legal review.
10. Added value of computable evidence-based clinical pathways
10.1 Computable evidence-based clinical pathways during routine operations
- Clinical: more timely, consistent and patient-specific decisions.
- Organizational: clearer allocation and sequencing of multidisciplinary work.
- Information: interoperable, reusable and semantically precise clinical data.
- Governance: auditable implementation of evidence, measurable quality and systematic pathway revision.
| Component | Principal function |
|---|---|
| Evidence-based pathway | Defines the recommended care process |
| SNOMED CT | Represents diagnoses, findings, procedures and clinical meaning |
| LOINC | Identifies tests, measurements, assessments and documents |
| CQL | Expresses eligibility, decision, calculation and quality logic |
| HL7 FHIR R5 | Represents data, pathways, requests, workflow and results |
10.2 Computable evidence-based clinical pathways and the First Hour Quintet
The First Hour Quintet (FHQ) refers to five critical, time-sensitive medical emergencies prioritized by Emergency Medical Services (EMS). Defined initially by the European Resuscitation Council (ERC), the acronym encompasses: stroke, severe trauma, cardiac chest pain, severe respiratory failure/difficulty, and cardiac arrest. The FHQ concept emerged from presentations and discussions at the Sixth European Resuscitation Council Congress in Florence in 2002 and was subsequently incorporated into the European Emergency Data Project. The five conditions were selected because rapid evaluation, prehospital treatment, and transport to an appropriate definitive-care service can materially affect outcomes (Krafft et al., 2003; Krafft et al., 2021).
Evidence-based clinical pathways for the First Hour Quintet (FHQ) would convert the FHQ from a broad EMS classification into a coordinated, measurable system of care covering the entire patient journey, from the emergency call to definitive treatment and outcome review.
Evidence-based clinical pathways for the First Hour Quintet would mean transforming five time-critical presentation groups into a coordinated dispatch-to-definitive-care system.The central objective is not simply to make ambulances arrive faster. It is to ensure that the correct emergency is recognized, the correct treatment begins, the correct destination is selected, the correct team is activated, and definitive care occurs with the least avoidable delay.
The FHQ should therefore be implemented as a common time-critical-care framework with five specialized branches, shared terminology, computable decision rules, structured handovers, and outcome-based quality measurement. This would make the FHQ useful not only for EMS benchmarking but also for real-time clinical decision support (CDS), regional network design, quality improvement, and comparative emergency-care research.
10.3 Computable evidence-based clinical pathways during health crises
An international health crisis or Public Health Emergency of International Concern (PHEIC) (e.g. pandemic), a Seveso incident, and a CBRN incident are three distinct types of high-stakes emergencies that pose severe threats to human life, public health, and the environment. While they all require immediate, highly coordinated emergency responses, they differ by their root causes, legal frameworks, and specific hazards (EUR-Lex, 2012, Wilder-Smith et al., 2020).
SNOMED CT defines the clinical meaning; LOINC defines what is measured or reported; CQL defines the decision logic; and FHIR R5 distributes the pathway, supplies the patient data, coordinates the actions and reports the outcomes. During an international health crisis, this architecture can accelerate guideline updates, standardized treatment and real-time surveillance. In a Seveso accident, it can connect information about a dangerous substance and exposure zone to decontamination, toxicological treatment, reporting and long-term follow-up. In a CBRNe incident, it can support common mass-casualty processes while activating hazard- and agent-specific modules.
The principal added value of combining evidence-based clinical pathways with SNOMED CT, LOINC, Clinical Quality Language and HL7 FHIR R5 is that a written guideline can be transformed into a standardized, machine-interpretable and operational care process.
The greatest value of a computable evidence-based clinical pathways during health crises is not digitization alone. It is the creation of a versioned, auditable and interoperable learning system connecting evidence, bedside care, emergency operations and public-health surveillance. That value depends on clinical validation, common implementation profiles, human oversight, cybersecurity, lawful data governance and the availability of non-digital fallback procedures.
Instead of distributing a PDF that clinicians must interpret manually during a crisis, the system can represent:
- what clinical (crisis)situation activates the clinical pathway;
- which patient and exposure data are required;
- which tests, treatments and precautions should be considered;
- which exceptions or contraindications apply;
- when escalation or referral is required;
- what must be reported to public-health or emergency authorities; and
- which outcomes should be measured.
HL7 FHIR’s Clinical Reasoning module is expressly designed to represent and evaluate knowledge artifacts such as decision-support rules, quality measures, public-health indicators, order sets and clinical protocols. CQL provides the executable clinical logic, while SNOMED CT and LOINC give standardized meanings to the clinical concepts and observations used by that logic.
The purpose of SNOMED CT is semantic interoperability: “respiratory distress,” “chemical exposure,” “decontamination performed” or “suspected viral pneumonia” should retain the same clinical meaning when transmitted between emergency medical services, hospitals, laboratories, poison centres and (inter)national public-health authorities (e.g. ECDC). SNOMED CT’s formal relationships also permit systems to identify broader classes, for example, recognizing that several separately coded findings belong to a respiratory or neurological syndrome.
LOINC answers the question “what was measured or reported?” The numerical result, coded answer and unit are then transmitted separately. In a crisis this is essential because apparently identical local test names may otherwise refer to different specimens, methods or measurements.
CQL as a clinical domain-specific language for expressing clinical decision-support and quality-measure logic. It can encode rules such as "Where a patient has a documented organophosphate exposure and clinically relevant cholinergic findings, activate the organophosphate pathway and evaluate the indications for atropine and oxime treatment." or "Where oxygen saturation is below a defined threshold, respiratory rate is elevated and the patient has specified risk factors, recommend escalation to a higher level of monitoring unless an exclusion applies." CQL has both a human-readable expression and a machine-readable representation, facilitating review by clinical experts while allowing implementation in different technical systems.
11. Conclusion
The greatest added value of computable evidence-based clinical pathways is the creation of a continuous connection between evidence, the individual patient record, clinical action, continuity of care and quality evaluation. That value is achieved only where the pathways are clinically validated, locally adapted, interoperably implemented, transparent to clinicians, nurses and patients, and designed to support rather than displace professional judgment.
LOINC, SNOMED CT, CQL, and HL7 FHIR R5 address different but interdependent layers of computable clinical pathways. LOINC primarily identifies the observation or laboratory service; SNOMED CT represents diagnoses, findings, procedures, organisms, and many qualitative answers; UCUM ensures computable units; CQL expresses patient-level logic; and HL7 FHIR knowledge resources package the pathway as versioned, shareable artifacts.
The recommended architecture separates terminology management, knowledge-artifact authoring and execution, and EHR/LIS clinical workflow. The terminology server supplies validation, expansion, subsumption, and translation. The pathway server stores PlanDefinition, ActivityDefinition, and Library resources, compiles and executes CQL, and applies plans to patient context. The EHR remains responsible for presenting the recommendation, obtaining clinician authorization, persisting accepted requests, and communicating laboratory orders.
Most importantly, HL7 FHIR R5 PlanDefinition/$apply should be implemented according to its actual normative behavior: it returns transient proposal artifacts in a Bundle, whose first entry is a patient-specific RequestOrchestration, followed by generated or updated resources. It does not independently persist orders and does not necessarily return a CarePlan. This boundary protects clinical accountability and separates computable recommendation generation from legally and operationally authorized care.
References
Alahmar, A., AlMousa, M., & Benlamri, R. (2022). Automated clinical pathway standardization using SNOMED CT-based semantic relatedness. Digital Health, 8, 20552076221089796. https://doi.org/10.1177/20552076221089796
Brandt, P. S., Kiefer, R. C., Pacheco, J. A., Adekkanattu, P., Sholle, E. T., Ahmad, F. S., ... & Rasmussen, L. V. (2020). Toward cross‐platform electronic health record‐driven phenotyping using Clinical Quality Language. Learning Health Systems, 4(4), e10233.
De Ramon Fernandez, A., Ruiz Fernandez, D., & Sabuco Garcia, Y. (2020). Business Process Management for optimizing clinical processes: A systematic literature review. Health informatics journal, 26(2), 1305-1320.
EUR-Lex. (2012). Directive 2012/18/EU of the European Parliament and of the Council of 4 July 2012 on the control of major-accident hazards involving dangerous substances, amending and subsequently repealing Council Directive 96/82/EC Text with EEA relevance.
Health Level Seven International. (2025). Clinical Quality Language Specification. https://cql.hl7.org/
Health Level Seven International. (2023a). FHIR Release 5: Clinical reasoning module. https://hl7.org/fhir/R5/clinicalreasoning-module.html
Health Level Seven International. (2023b). FHIR Release 5: Library resource. https://hl7.org/fhir/R5/library.html
Health Level Seven International. (2023c). FHIR Release 5: PlanDefinition $apply operation. https://hl7.org/fhir/R5/plandefinition-operation-apply.html
Health Level Seven International. (2023d). FHIR Release 5: Terminology module. https://hl7.org/fhir/R5/terminology-module.html
Health Level Seven International. (2024). SMART App Launch Implementation Guide, version 2.2.0. https://hl7.org/fhir/smart-app-launch/
Health Level Seven International. (n.d.). CDS Hooks, version 2.0. Retrieved July 12, 2026, from https://cds-hooks.hl7.org/
Kinsman, L., Rotter, T., James, E., Snow, P., & Willis, J. (2010). What is a clinical pathway? Development of a definition to inform the debate. BMC Medicine, 8, Article 31. https://doi.org/10.1186/1741-7015-8-31
Krafft, T., Castrillo-Riesgo, L. G., Edwards, S., Fischer, M., Overton, J., Robertson-Steel, I., & König, A. (2003). European emergency data project (EED Project) EMS data-based health surveillance system. The European Journal of Public Health, 13(suppl_1), 85-90.
Krafft, T., Riesgo, L. G. C., Fischer, M., Robertson-Steel, I., & Lippert, F. (2021). European Emergency Data Project. EMS Data-based Health Surveillance System.(Abruf: 12.
OHDSI. Standardized Data: The OMOP Common Data Model.
Regenstrief Institute. (2026). LOINC terminology service using HL7 FHIR. https://loinc.org/fhir/
Regenstrief Institute. (n.d.-a). Using LOINC with SNOMED CT in HL7 messages. Retrieved July 12, 2026, from https://loinc.org/kb/faq/usage/
Regenstrief Institute. (n.d.-b). LOINC 4548-4: Hemoglobin A1c/Hemoglobin.total in blood. Retrieved July 12, 2026, from https://loinc.org/4548-4/
Shivers, J., Amlung, J., Ratanaprayul, N., Rhodes, B., & Biondich, P. (2021). Enhancing narrative clinical guidance with computer-readable artifacts: Authoring FHIR implementation guides based on WHO recommendations. Journal of Biomedical Informatics, 122, 103891. https://doi.org/10.1016/j.jbi.2021.103891
SNOMED International. (n.d.-a). LOINC implementation guide: Clinical workflow. Retrieved July 12, 2026, from https://docs.snomed.org/implementation-guides/loinc-implementation-guide/use-case/3.1-clinical-workflow
SNOMED International. (n.d.-b). SNOMED CT URI standard. Retrieved July 12, 2026, from https://docs.snomed.org/snomed-ct-specifications/snomed-ct-uri-standard
SNOMED International. (n.d.-c). Accessing the LOINC Ontology using FHIR terminology services. Retrieved July 12, 2026, from https://docs.snomed.org/implementation-guides/loinc-implementation-guide
Strasberg, H. R., Rhodes, B., Del Fiol, G., Jenders, R. A., Haug, P. J., & Kawamoto, K. (2021). Contemporary clinical decision support standards using Health Level Seven International Fast Healthcare Interoperability Resources. Journal of the American Medical Informatics Association, 28(8), 1796–1806. https://doi.org/10.1093/jamia/ocab070
U.S. National Library of Medicine. (2022). Value Set Authority Center: SNOMED CT code 44054006—Type 2 diabetes mellitus. https://vsac.nlm.nih.gov/
Wile, D. S. (1997, May). Abstract syntax from concrete syntax. In Proceedings of the 19th international conference on Software engineering (pp. 472-480).
Wilder-Smith, A., & Osman, S. (2020). Public health emergencies of international concern: a historic overview. Journal of travel medicine, 27(8), taaa227.
Peter Van Osta. An essay concerning a new healthcare.