Terminology servers solve specific problems in FHIR-based systems. Understanding scope prevents over-investment and under-investment.
What they do
1. **`$expand` — Turn ValueSet into constituent codes. 2. $validate-code — Verify code is valid in ValueSet. 3. $translate — Map codes via ConceptMap. 4. $lookup — Fetch code metadata. 5. Code system loading** — SNOMED, LOINC, RxNorm distributions.
What they don't do
1. Store clinical resources. 2. Handle authentication. 3. Terminology governance workflow (that's admin tooling). 4. Cross-map to non-standard vocabularies without ConceptMap.
Deployment options
1. Bundled in FHIR server. HAPI, Aidbox. Simpler ops. 2. Standalone. Ontoserver. More capable. 3. Managed service. NIH UMLS terminology server. Zero ops.
License requirements
| Terminology | License |
|---|---|
| SNOMED CT US | Free with UMLS |
| LOINC | Free |
| RxNorm | Free with UMLS |
| ICD-10-CM | Free |
| CPT | Paid, AMA |
Update cadence
| Terminology | Release |
|---|---|
| SNOMED CT | Twice yearly |
| LOINC | Twice yearly |
| RxNorm | Weekly |
| ICD-10-CM | Annually |
Common integration mistakes
1. Terminology as afterthought. 2. Manual updates. 3. Runtime $expand. 4. Missing version pinning. 5. Cross-mapping in code.
Cost profile
| Server | Cost |
|---|---|
| Ontoserver license | ~$80k/year |
| HAPI (open) | Dev + ops |
| Aidbox terminology | Bundled |
Terminology servers are production infrastructure. Sites treating them as subsystems ship reliable FHIR deployments; sites treating them as afterthought accumulate drift.
