TerminologyService

Requests the server to resolve a ValueSet into a flat list of its constituent codes. This is essential for populating user interface drop-down lists or performing code lookups.

• Key Parameters: url (the canonical ValueSet URL), filter (text search), count (pagination limit).
• Hierarchical Expansion: Supports includeDesignations to fetch display names and synonyms.
• Use Case: A clinician types 'diabetes' into a diagnosis field; the client calls $expand with a filter to return matching SNOMED CT codes.

Validates whether a specific code exists within a defined ValueSet. This operation ensures data integrity before persisting a coded clinical concept.

• Input: A code and system (e.g., http://loinc.org), or a Coding datatype.
• Output: Returns true/false with an optional error message.
• Display Validation: Can optionally verify that the supplied display text matches the official term for the code.
• Use Case: An EHR checks if '718-7' is a valid LOINC code for hemoglobin before saving a lab result.

Retrieves the full details and properties for a specific concept from a CodeSystem. Unlike $expand, this operates on the terminology definition itself.

• Returns: display name, designations (synonyms), and property values (e.g., parent/child relationships, SNOMED CT 'is-a' hierarchy).
• Parameter: Requires system and code.
• Use Case: A clinical decision support engine fetches the parent concepts of a specific bacteria code to infer broader antibiotic resistance patterns.

Translates a code from one CodeSystem to an equivalent code in another, using a ConceptMap resource. This bridges semantic gaps between different standards.

• Dependencies: Relies on a pre-defined ConceptMap instance.
• Direction: Can map from source to target or reverse.
• Equivalence: Returns a grade (e.g., equivalent, wider, narrower) indicating mapping precision.
• Use Case: Converting an internal billing code to a standard SNOMED CT concept for a national registry submission.

Tests the subsumption relationship between two codes within the same CodeSystem. It determines if one concept is an ancestor or descendant of another.

• Logic: Returns subsumes, subsumed-by, equivalent, or not-subsumed.
• Requirement: The CodeSystem must define hierarchical relationships.
• Use Case: A quality measure checks if a documented 'Type II Diabetes Mellitus' diagnosis is subsumed by the broader inclusion criterion 'Diabetes Mellitus'.

Manages a client-side transitive closure table for a CodeSystem. This stateful operation helps clients efficiently navigate complex hierarchies without re-downloading the entire terminology.

• Mechanism: The client sends an initial request and receives a version identifier. Subsequent calls with that version return only new or changed concepts.
• Use Case: A terminology server maintains a live, local cache of the SNOMED CT hierarchy for a high-performance clinical decision support app.

The foundational resource that declares the existence of a controlled terminology. A TerminologyService relies on CodeSystem definitions to understand the canonical set of concepts, their display names, and hierarchical relationships. Without a CodeSystem resource, the service has no source of truth to validate against. Key properties include content completeness (complete, partial, or not-present) and hierarchy meaning (is-a, part-of, etc.).

A curated, intensional or extensional set of codes drawn from one or more CodeSystems. The TerminologyService's $expand and $validate-code operations are primarily driven by ValueSet definitions. A ValueSet answers the question: 'Which codes are allowed in this specific clinical context?' It is the mechanism that constrains a general terminology like SNOMED CT to a specific use case, such as a drop-down list for 'Diabetes Types'.

Defines a semantic translation between concepts in one CodeSystem and another. The TerminologyService's $translate operation directly consumes ConceptMap resources to map, for example, a local proprietary billing code to a standard SNOMED CT concept. This resource is essential for cross-institutional data harmonization, enabling federated analytics where different sites use different local terminologies but must contribute to a unified research query.

A conformance tool that checks resources against the base specification and defined profiles. It uses the TerminologyService internally to validate that coded elements in a resource instance are members of the bound ValueSet. Key capabilities include:

• StructureDefinition validation: Ensuring cardinality and type constraints
• Terminology binding strength: Checking if a code matches a required or extensible binding
• Invariant evaluation: Running FHIRPath expressions to enforce complex rules

A domain-specific language for defining FHIR artifacts concisely. When authoring a TerminologyService-dependent ImplementationGuide, FSH allows you to define CodeSystems, ValueSets, and ConceptMaps in a human-readable text format that compiles to FHIR JSON. This dramatically reduces the complexity of maintaining large terminology assets. A single FSH file can define hundreds of concepts with hierarchical relationships using minimal syntax.

A path-based navigation language used to evaluate expressions against FHIR data. In the context of a TerminologyService, FHIRPath is used to define complex validation invariants that go beyond simple code membership. For example, a rule might state: 'If the observation code is from LOINC, the value must be a Quantity with a UCUM unit.' The TerminologyService resolves the coded concepts while FHIRPath enforces the structural logic.