Terminology servers sit at the intersection of clinical vocabularies and FHIR resources. Understanding their scope prevents overinvestment and under-investment.
What terminology servers do
1. **`$expand` — Turn a ValueSet reference into its constituent codes. Used for choice-list population and validation. 2. $validate-code — Verify a code is valid in a ValueSet. Used at write time. 3. $translate — Map a code from one system to another via ConceptMap. Used for cross-terminology. 4. $lookup — Fetch metadata about a specific code (display, definition, properties). 5. Code system loading** — Ingest SNOMED CT, LOINC, RxNorm, ICD-10 distributions.
What they don't do
1. Store clinical resources (Patient, Observation) — that's the FHIR server's job. 2. Handle authentication — separate auth layer. 3. Handle terminology governance workflow — that's admin tooling on top. 4. Cross-map to non-standard terminologies without configured ConceptMaps.
Deployment patterns
1. Bundled in FHIR server — HAPI, Aidbox have in-process terminology modules. Simpler ops. 2. Standalone service — Ontoserver as separate deployment. Cleaner separation, higher latency. 3. Managed service — NIH's UMLS terminology server, others. Zero ops.
License requirements
| Terminology | License |
|---|---|
| SNOMED CT (US) | Free with UMLS registration |
| LOINC | Free |
| RxNorm | Free with UMLS registration |
| ICD-10-CM | Free |
| CPT | Paid, AMA |
| Some commercial ValueSets | Paid |
Update cadence
| Terminology | Release |
|---|---|
| SNOMED CT US Edition | Twice yearly |
| LOINC | Twice yearly |
| RxNorm | Weekly |
| ICD-10-CM | Annually |
Terminology servers are a subsystem, not an afterthought. Treat them as such and CMS-0057 attestation gets easier every quarter.