CodeSystem

Each CodeSystem defines a discrete set of codes where each code is a unique string identifier within that system. The combination of the system URI and code creates a globally unique identifier for a concept.

• code: The machine-readable identifier (e.g., 8480-6 for systolic blood pressure in LOINC)
• display: The human-readable name (e.g., Systolic blood pressure)
• definition: A formal description of the concept's meaning
• system: A canonical URL that globally identifies the code system (e.g., http://loinc.org)

This design ensures unambiguous semantic exchange between disparate clinical systems.

CodeSystems can model is-a hierarchies through the concept.property element, enabling parent-child relationships between codes. This supports both simple taxonomies and complex polyhierarchies where a concept may have multiple parents.

• parent: Indicates a direct ancestor concept
• child: Indicates a direct descendant concept
• abstract: A concept that is not selectable but serves as a grouping mechanism

For example, in SNOMED CT, 73211009 |Diabetes mellitus| has children like 44054006 |Type 2 diabetes mellitus|, enabling clinical decision support systems to reason about disease subtypes.

Beyond basic codes, a CodeSystem can define a rich set of properties that describe additional characteristics of each concept. These properties are declared at the system level and assigned values at the concept level.

• code: The property name (e.g., status, inactive, deprecated)
• type: The data type of the property value (e.g., code, Coding, string, boolean)
• uri: An optional formal identifier for the property
• description: Human-readable explanation of the property's purpose

Common properties include status (active/inactive), deprecated (true/false), and designation for alternative display names or translations.

CodeSystems support explicit version tracking through the version and versionNeeded elements, enabling deterministic referencing of specific terminology releases in clinical data.

• version: A string identifier for the current version (e.g., 2.78 for LOINC)
• experimental: Indicates if the CodeSystem is for testing purposes
• status: The lifecycle state (draft, active, retired, unknown)
• publisher: The organization responsible for maintaining the terminology

This versioning is critical for regulatory compliance, ensuring that clinical decision support rules and quality measures reference the exact terminology version used at the time of data capture.

The designation element allows a single concept to have multiple display representations, supporting multilingual terminology and context-specific labels without duplicating the underlying code.

• language: The language code for the designation (e.g., es for Spanish)
• use: A context for the designation (e.g., display, patient-friendly, abbreviation)
• value: The actual display string in the specified language or context

For instance, a SNOMED CT concept can have a clinical display name, a patient-friendly synonym, and translations in multiple languages, all linked to the same immutable code.

FHIR distinguishes between complete CodeSystems that define all their codes authoritatively and supplement CodeSystems that add properties or designations to concepts defined in another system.

• Complete: Contains the full definition of codes (e.g., a local terminology)
• Supplement: References an external CodeSystem and adds local properties without redefining the codes themselves
• content: Declares the completeness (complete, fragment, supplement, not-present)

This pattern allows organizations to enrich standard terminologies like SNOMED CT with local mappings or workflow-specific metadata without forking the standard.