FHIR Terminology Services Architecture: Managing SNOMED CT, LOINC, ICD-10, and RxNorm At Scale
A FHIR resource can be structurally valid while still carrying a code that is inactive, outside an approved value set, interpreted against the wrong terminology version, or mapped without sufficient clinical context.
For example, an Observation may contain a correctly structured LOINC code that does not represent the test performed. A Condition may use a valid SNOMED CT concept that is not permitted by the implementation guide governing the workflow. An ICD-10-CM code may be valid for one date of service but unavailable in the release applicable to another.
A terminology service addresses these semantic requirements through standardized lookup, validation, expansion, subsumption, and translation operations.
Technical Scope of This Guide
This guide describes terminology services using FHIR R4, version 4.0.1.
FHIR R4, R4B, and R5 are not identical. Operation parameters, capability declarations, and resource structures must always be checked against the FHIR version implemented by the client and terminology server.
The architecture sections below are divided into:
- FHIR-defined behavior: Resources, operations, parameters, and terminology semantics defined by HL7.
- Recommended architecture patterns: Deployment, caching, release management, observability, and governance practices that HL7 does not mandate.
What Is a FHIR Terminology Service?
FHIR R4 describes a terminology service as a set of functions built around:
CodeSystem
A CodeSystem declares the existence of a code system, identifies its key properties, and may define part or all of its content.
Large external terminologies such as SNOMED CT, LOINC, and RxNorm are distributed in their own official formats. A FHIR terminology server may expose its capabilities without publishing its complete contents as ordinary FHIR CodeSystem resources.
ValueSet
A ValueSet defines a selection of codes from one or more code systems for a particular context.
A value set may contain:
- Explicitly listed codes
- Codes selected by terminology properties
- Imported value sets
- Inclusion rules
- Exclusion rules
The ValueSet definition contains the selection logic. A ValueSet expansion contains the concepts produced by evaluating that logic against specified terminology content.
ConceptMap
A ConceptMap represents directional relationships from source concepts to one or more target concepts.
It is not a universal equivalence table. A mapping is created for a particular purpose, direction, terminology version, and business context.
How Terminology Is Represented in FHIR
FHIR commonly carries terminology identifiers through the Coding datatype.
{ Â "system": "http://loinc.org", Â "version": "<LOINC_VERSION>", Â "code": "<LOINC_CODE>", Â "display": "<RECOMMENDED_DISPLAY>" }
The elements have distinct purposes:
- system identifies the terminology system.
- code is the symbol defined by that system.
- version identifies the terminology version, when relevant.
- display provides a human-readable representation.
The meaning of a code is defined by the code interpreted through its code system and, where applicable, its version. The display text is not intended for computation.
A CodeableConcept may contain multiple Coding entries and optional text. Multiple codings can represent the same clinical concept using local and standard terminologies, but their ordering has no defined semantic meaning.
Roles of SNOMED CT, LOINC, ICD-10-CM, and RxNorm
| Terminology | Primary purpose | Common implementation use |
| SNOMED CT | Comprehensive representation of clinical healthcare concepts and relationships | Clinical problems, findings, procedures, body structures, organisms, substances, and clinical situations |
| LOINC | Identification of health measurements, observations, surveys, panels, and documents | Laboratory tests, vital signs, clinical measurements, assessment questions, and clinical documents |
| ICD-10-CM | U.S. classification for coding and classifying medical diagnoses | Diagnosis coding, morbidity reporting, reimbursement-related workflows, and administrative classification |
| RxNorm | Normalized names and identifiers for clinical drugs, with links to source drug vocabularies | Medication normalization, clinical drug identification, ingredient representation, and medication exchange |
These terminologies should not be used as interchangeable code lists.
SNOMED CT is designed to represent detailed clinical meaning. ICD-10-CM is designed to classify diagnoses in the United States. A SNOMED CT concept does not necessarily determine one final ICD-10-CM code without additional clinical information and applicable coding rules.
Recommended Enterprise Terminology Architecture
The following topology is a recommended implementation pattern. It is not a deployment structure required by HL7.
1. Terminology Consumers
Consumers may include:
- EHR and clinical applications
- Laboratory information systems
- Pharmacy and medication applications
- FHIR servers
- Integration engines
- Clinical decision-support services
- Quality-measure systems
- Analytics and population-health platforms
2. Access and Security Layer
An API gateway or equivalent access layer can provide:
- TLS termination
- Authentication
- Authorization
- Request routing
- Usage controls
- Audit correlation
- Licensing enforcement
Terminology requests can expose clinically meaningful information even when they do not contain a complete patient record. Production terminology traffic should therefore use encrypted transport.
3. FHIR Terminology API Layer
The API layer exposes the operations supported by the server.
An FHIR R4 server describes its API through a CapabilityStatement. It can describe terminology-specific behavior through TerminologyCapabilities, retrievable through:
GET [base]/metadata?mode=terminology
CapabilityStatement describes the API. TerminologyCapabilities describes terminology-server behavior, such as supported code-system versions, lookup properties, subsumption support, expansion behavior, validation, and translation.
Clients should not assume that every terminology server supports every optional parameter or behavior.
4. Terminology Content Layer
The terminology content layer provides access to the authorized editions and releases loaded into the service.
The internal implementation may use:
- One multi-terminology engine
- Separate terminology-specific services
- Native terminology stores
- Search indexes
- FHIR resource repositories
FHIR does not prescribe the internal storage engine. The external results must accurately represent the selected terminology content and the capabilities declared by the server.
5. Governed Artifact Repository
Locally maintained ValueSet and ConceptMap resources should be managed as governed artifacts.
Recommended metadata includes:
- Canonical URL
- Business version
- Publication status
- Owner or publisher
- Intended purpose
- Usage context
- Jurisdiction
- Source and target terminology versions
- Approval and effective dates
Draft content should not become available to production validation or translation workflows without an explicit publication process.
Core FHIR R4 Terminology Operations
Code Lookup
CodeSystem/$lookup retrieves information about a code.
GET [base]/CodeSystem/$lookup  ?system=http%3A%2F%2Floinc.org  &code=<LOINC_CODE>  &property=display  &property=designation
Depending on the code system and declared server capabilities, the result may include:
- Recommended display
- Code-system version
- Definitions
- Designations
- Code properties
- Parent or child relationships
When no properties are requested, the server determines which properties to return. If the code system has a version, the lookup response returns the version used.
Value-Set Validation
ValueSet/$validate-code determines whether a code or coded concept is valid within a specified value set.
GET [base]/ValueSet/$validate-code  ?url=https%3A%2F%2Fexample.org%2Ffhir%2FValueSet%2Fapproved-lab-tests  &system=http%3A%2F%2Floinc.org  &systemVersion=<LOINC_VERSION>  &code=<LOINC_CODE>
A successful operation returns a Parameters resource containing a Boolean result and may include a message, recommended display, system, and version.
A valid code-system concept is not automatically valid in every value set. Code recognition and contextual value-set membership are separate questions.
Value-Set Expansion
ValueSet/$expand evaluates a ValueSet definition against available terminology content.
GET [base]/ValueSet/$expand  ?url=https%3A%2F%2Fexample.org%2Ffhir%2FValueSet%2Fapproved-lab-tests  &filter=hemoglobin  &activeOnly=true  &offset=0  &count=20
FHIR R4 supports filtered expansion and paging for flat expansions. Paging does not apply to hierarchical expansions.
The server determines how a text filter is applied. Search behavior can therefore differ between terminology servers.
If an expansion is too large or too expensive, the server may return an OperationOutcome with the too-costly issue code.
Subsumption Testing
CodeSystem/$subsumes evaluates the hierarchical relationship between two concepts in a code system that supports subsumption.
The possible outcomes are:
- equivalent
- subsumes
- subsumed-by
- not-subsumed
For SNOMED CT, the requested edition and version determine the terminology substrate used for the operation.
Concept Translation
ConceptMap/$translate uses a ConceptMap, or sufficient source and target context, to evaluate a directional mapping.
A translation result does not automatically establish full semantic equivalence. The response may contain more than one candidate and can include dependencies or relationship information that the client must evaluate.
Version Management by Terminology
SNOMED CT
SNOMED CT is distributed through editions. Every edition contains the International Edition and may include extension content for a country, region, specialty, or organization.
Each update creates a versioned edition. A version can add, modify, or inactivate components and reference-set members. A service supporting multiple editions or versions must allow the appropriate terminology substrate to be selected.
LOINC
LOINC uses the statuses:
- Active
- Trial
- Discouraged
- Deprecated
Deprecated LOINC concepts are retained for historical use but should not be selected for new use. Discouraged concepts are not recommended for new mappings, although existing mappings may remain valid in context.
LOINC codes are not reused or deleted.
ICD-10-CM
ICD-10-CM is used to code and classify medical diagnoses in the United States.
The applicable release must be selected using the relevant date of service. NCHS publishes fiscal-year updates effective October 1 and may publish additional updates effective April 1.
Using only the latest release for historical validation can produce incorrect results.
RxNorm
NLM publishes full monthly RxNorm releases and weekly updates.
RXCUIs for normalized RxNorm concepts are not reused. In exceptional cases, identifiers may be remapped, split, archived, or retired. RxNorm history files support investigation of identifiers that are no longer present in the current release.
Governing Mapping as a Clinical and Administrative Artifact
FHIR ConceptMap mappings are directional and business-context dependent.
A map should identify:
- Mapping direction
- Source and target systems
- Source and target versions
- Intended use
- Jurisdiction
- Relationship or equivalence
- Dependencies
- Unmapped behavior
- Review and publication status
A SNOMED CT-to-ICD-10-CM map designed for analytics may differ from a map designed for billing. Billing may require greater specificity, additional documentation, or multiple candidate codes.
An application should not represent an ambiguous mapping as one definitive equivalent target.
Scaling Without Changing Semantic Results
Caching, search indexing, horizontal API scaling, and precomputed expansions are recommended performance patterns, not FHIR requirements.
At scale, organizations should:
- Pin requests to explicit terminology versions where reproducibility is required.
- Prevent different serving nodes from using unintended release combinations.
- Invalidate affected caches when terminology, ValueSet, or ConceptMap content changes.
- Separate search optimization from authoritative validation.
- Retain releases needed for historical validation.
- Test critical value sets and maps before production activation.
- Monitor latency, validation failures, expansion errors, translation failures, and the terminology versions used.
Performance optimizations must not change the semantic result of the terminology operation.
Build a Governed FHIR Terminology Service With CapMinds
CapMinds helps healthcare organizations design, integrate, and operate terminology infrastructure across clinical, laboratory, medication, administrative, and analytics workflows.
Our FHIR terminology services include:
- FHIR terminology architecture assessment
- FHIR R4, R4B, and R5 integration
- SNOMED CT, LOINC, ICD-10-CM, and RxNorm integration
- ValueSet and ConceptMap implementation
- Terminology version and release governance
- EHR, LIS, pharmacy, payer, and analytics connectivity
- Search, validation, expansion, and translation workflows
- Performance engineering and observability
- Terminology migration and managed interoperability services
Build a terminology platform that preserves clinical meaning across applications, releases, mappings, and downstream workflows.
