Terminology Binding for Drug Content

Introduction

Terminology bindings for drug content must align with both the data element and the clinical or operational workflow in which it is used. The selected SNOMED CT concept level should provide sufficient detail to support safe and accurate use of medications, while also enabling interoperability, aggregation, and traceability across systems.

A key aspect of terminology binding is that drug concepts are not used in isolation; they are always bound to structured data elements within an information model. The meaning of the data element determines the appropriate level of abstraction in the SNOMED CT drug model.

Terminology binding ensures that:

• the appropriate drug model concept level is used for each data element

• medication data is represented consistently across systems

• clinical and administrative workflows are supported safely and effectively

• data can be aggregated and reused for analytics, reporting, and research

More information on Terminology Bindings can be found in Context Representation Implementation Guide

Overall Binding Principles

Use the Appropriate Level of Abstraction

Use the highest level of abstraction that safely supports the use case:

• MP (Medicinal Product) for ingredient-level use, such as clinical decision support and analytics

• MPF (Medicinal Product Form) for ingredient and dose form

• CD (Clinical Drug) for prescribing and other clinically precise definitions

• RCD (Real Clinical Drug) for dispensing and administration of a specific product

• RPCD (Real Clinical Drug Package) for inventory, supply, and packaged products

Different healthcare systems operate at different levels of detail within the SNOMED CT drug model. Some workflows require abstract representations (e.g. ingredient-level analysis), while others require precise identification of specific authorized products or packages.

Maintain Semantic Consistency Across Workflows

Terminology bindings should preserve meaning as medication data moves between systems and workflow stages.

This includes:

• traceability from prescribing to dispensing and administration

• consistent interpretation across clinical and administrative systems

• aggregation across concept levels for reporting and analytics

The hierarchical structure of the SNOMED CT drug model supports this by linking abstract and concrete representations of medicinal products.

Bind Concepts to Structured Data Elements

SNOMED CT drug concepts should be bound to clearly defined coded fields within an information model. The meaning of the field determines the appropriate concept level.

Common examples include:

• medication prescribed

• medication dispensed

• medication administered

• medication held in inventory

• medication recorded in an adverse event report

It is essential to distinguish between:

• the clinical intent (what is prescribed)

• the supply or administration event (what product is actually used)

• the analytical or reporting context (how data is aggregated)

Each of these requires a different level of representation in the drug model.

Overview of Terminology Binding by Data Element

Data Element	Recommended Concept Class	Role	Example
Medication (general)	MP	Ingredient-level representation	Product containing amoxicillin (medicinal product)
Medication (with form)	MPF	Ingredient and dose form	Product containing amoxicillin in oral capsule dose form (medicinal product form)
Medication prescribed	CD	Clinical specification of intended medication	Product containing precisely amoxicillin 500 mg oral capsule (clinical drug)
Medication dispensed	RCD	Actual product supplied	BrandX amoxicillin 500 mg oral capsule (real clinical drug)
Medication administered	RCD	Actual product given	Morphine sulfate 10 mg/mL solution for injection (real clinical drug)
Medication package	RPCD	Specific packaged product	Brand X amoxicillin 500 mg oral capsule box of 24 (real clinical drug package)
Medication package (generic)	CDP	Generic packaged clinical drug	Amoxicillin 500 mg oral capsule box of 24 (clinical drug package)

Example Information Models with Bindings

Structured data entry ensures that medication information is captured in a consistent and computable way. This is achieved by binding SNOMED CT drug concepts to specific data elements that reflect the role of the medication within a workflow.

The following abstract models illustrate how terminology binding aligns with structured data elements.

Model 1: Prescribing

• Purpose: Capture clinical intent

• Context: MedicationRequest

• Data Element: medicationCode

  • The prescribed medication is represented using a Clinical Drug (CD) to define ingredient, strength, and dose form.

MedicationRequest
 ├── medicationCode
 │     └── SNOMED CT Clinical Drug (CD)
 ├── dosageInstruction
 ├── route
 ├── indication
 └── substitution

Additional data elements in example model:

• dosageInstruction – dose, frequency, duration (essential for safe prescribing)

• route – route of administration (SNOMED CT qualifier values)

• indication – reason for prescribing (SNOMED CT clinical findings)

• substitution – whether generic substitution is allowed

Model 2: Dispensing

• Purpose: Capture actual supplied product

• Context: MedicationDispense

• Data Element: .medicationCode

  • The dispensed medication is a specific product, requiring a Real Clinical Drug (RCD).

MedicationDispense
 ├── medicationCode (CodeableConcept)
 │     └── SNOMED CT Real Clinical Drug (RCD)
 ├── quantity
 ├── substitution
 ├── daysSupply
 └── performer

Additional data elements in example model:

• quantity – amount dispensed

• daysSupply – expected duration of supply

• substitution – indicates if substitution occurred

• performer – dispensing organization or pharmacist

Model 3: Administration

• Purpose: Capture actual administered product

• Context: MedicationAdministration

• Data Element: .medicationCode

  • The administered medication must reflect the exact product given to the patient.

MedicationAdministration
 ├── medicationCode (CodeableConcept)
 │     └── SNOMED CT Real Clinical Drug (RCD)
 ├── dose
 └── route
       └── << 284009009 |Route of administration value (qualifier value)|
 ├── site
 └── effectiveDateTime

Additional data elements in example model:

• dose – actual dose administered

• route – route of administration (SNOMED CT)

• site – anatomical site (SNOMED CT body structure)

• effectiveDateTime – when administration occurred

Model 4: Inventory and Supply

• Purpose: Manage stock and logistics

• Context: InventoryItem

• Data Element: .product

  • Inventory systems manage packaged products, requiring representation at the RPCD level to include pack size and packaging details.

InventoryItem
 └── product
       └── SNOMED CT Real Clinical Drug Package (RPCD)
 ├── quantity
 ├── batchNumber
 ├── expiryDate
 └── storageCondition

Additional data elements in example model:

• quantity – number of packages in stock

• batchNumber – batch/lot tracking

• expiryDate – product expiration

• storageCondition – storage requirements

Model 5: Analytics and Reporting

• Purpose: Reporting and population analysis

• Context: Analytics Dataset

• Data Element: .medication

  • For analytics, medications are often aggregated at the ingredient level (MP) to support population-level analysis and reporting.

Analytics Dataset
 └── medication
       └── SNOMED CT Medicinal Product (MP)
 ├── indication
 ├── outcome
 ├── patientContext
 └── timePeriod

Additional data elements in example model:

• indication – condition being treated (SNOMED CT)

• outcome – clinical outcomes or adverse events (SNOMED CT / MedDRA)

• patientContext – demographics, population group

• timePeriod – time-based analysis

Provide Feedback