ValueSet

A ValueSet is defined by a set of rules, not just a static list. It can be intensionally defined using logical filters (e.g., 'all codes that are descendants of a specific SNOMED CT concept') or extensionally defined by explicitly enumerating every allowed code. This compositional approach allows a single ValueSet to dynamically include hundreds of codes from a large terminology like SNOMED CT without manual curation.

A single ValueSet can draw codes from multiple, disparate code systems to represent a single clinical concept. For example, a ValueSet for 'Diabetes Mellitus' might include:

• SNOMED CT code 73211009 for clinical diagnosis
• ICD-10-CM code E11.9 for billing classification
• LOINC code 4548-4 for a lab result like Hemoglobin A1c This aggregation bridges the gap between clinical, administrative, and laboratory terminologies within one data element.

When a ValueSet is linked to a FHIR element, the binding strength dictates how strictly the code must match. The four levels are:

• required: The element MUST use a code from the ValueSet.
• extensible: The element SHOULD use a code from the ValueSet, but a local code is allowed if a suitable one doesn't exist.
• preferred: A code from the ValueSet is encouraged, but any valid code is acceptable.
• example: The ValueSet is just a suggestion for implementers.

ValueSets are not static; they require a lifecycle. Tools like FHIR Shorthand (FSH) allow authors to define ValueSets as code, which is then compiled into the formal FHIR resource. Governance workflows manage versioning, deprecation, and the periodic synchronization of ValueSets with the underlying code systems, such as when a new ICD-10 code is released annually.

A ValueSet's primary purpose is to constrain a generic terminology for a specific use case. The code system for SNOMED CT contains over 350,000 concepts, but a ValueSet for 'Chief Complaint' in an emergency department EHR might only contain 50 relevant codes. This curation prevents data entry errors and ensures that downstream analytics and decision support rules operate on a predictable, clean data set.

The source of truth that formally defines all valid concepts and their associated codes within a terminology. A CodeSystem resource enumerates every code—such as 195967001 for 'Asthma' in SNOMED CT—along with its display name, definition, and hierarchical relationships. ValueSets draw their codes from one or more CodeSystems, making the CodeSystem the foundational vocabulary that ValueSets curate and constrain for specific use cases.

The mechanism that links a coded FHIR element to a ValueSet, defining precisely which codes are allowed for that element. A binding specifies:

• Strength: required, extensible, preferred, or example
• ValueSet URI: the canonical reference to the constraining ValueSet

For example, the MedicationRequest.status element is required-bound to a ValueSet containing only active, on-hold, cancelled, and other defined status codes. This ensures every system sending a medication order uses identical status values.

A resource that defines a semantic mapping between concepts in different code systems, enabling terminology translation. Unlike a ValueSet which simply enumerates codes, a ConceptMap specifies equivalences:

• equal: identical meaning
• wider: target is broader
• narrower: target is more specific
• unmatched: no equivalent exists

This is critical when converting data from a legacy system using ICD-9 to a FHIR system requiring SNOMED CT, ensuring clinical meaning is preserved across terminology boundaries.

A published set of rules, profiles, and ValueSets that defines how FHIR must be used to solve a specific interoperability problem. Implementation Guides—such as US Core or Da Vinci PDex—define the exact ValueSets that must be used for particular clinical data elements. For instance, the US Core Implementation Guide mandates a specific ValueSet for Observation.code when exchanging vital signs, ensuring every EHR system uses the same LOINC codes for blood pressure, heart rate, and temperature.

A software tool that checks FHIR resources against profiles and terminology bindings to ensure conformance. When validating a resource, the validator:

• Confirms coded elements contain codes from the bound ValueSet
• Checks binding strength: required bindings must match exactly
• Flags invalid codes with detailed error messages

This is the enforcement mechanism that ensures ValueSets are not merely documentation but active constraints that prevent non-conformant data from entering the healthcare ecosystem.