Overview
Returns a single CodeSystem resource by its FHIR id. OMOPHub recognizes two ID shapes:
- Per-vocabulary stub IDs - short lowercase slugs (
loinc, snomed, rxnorm, icd-10-cm, …) that map 1:1 to canonical FHIR system URIs. These return content: "not-present" stubs with metadata only.
- Unified OMOP release IDs - the release-specific FHIR id (e.g.
omop-v20250827) for the omnibus OMOP CodeSystem that covers every supported vocabulary under one URL. These return the full CodeSystem resource with all OMOP property definitions.
Request
Per-vocabulary stub
curl "https://fhir.omophub.com/fhir/r4/CodeSystem/loinc" \
-H "Authorization: Bearer YOUR_API_KEY"
Unified OMOP release
curl "https://fhir.omophub.com/fhir/r4/CodeSystem/omop-v20250827" \
-H "Authorization: Bearer YOUR_API_KEY"
Use the metadata endpoint to discover the current release ID, or call CodeSystem search with url=https://fhir-terminology.ohdsi.org to fetch the unified resource via the canonical URL.
Response (per-vocabulary stub)
{
"resourceType": "CodeSystem",
"id": "loinc",
"url": "http://loinc.org",
"name": "LOINC",
"title": "Logical Observation Identifiers Names and Codes",
"status": "active",
"experimental": false,
"publisher": "Regenstrief Institute",
"description": "Logical Observation Identifiers Names and Codes - served by OMOPHub. Use $lookup and $validate-code operations to query concepts; the full concept list is not served inline (content: not-present).",
"content": "not-present"
}
Instance reads return a bare CodeSystem resource, not a Bundle. Only search-type queries wrap results in a Bundle.
Response (unified OMOP release)
{
"resourceType": "CodeSystem",
"id": "omop-v20250827",
"url": "https://fhir-terminology.ohdsi.org",
"version": "2025.2",
"name": "OMOPConcepts",
"title": "OMOP Standardized Vocabularies",
"status": "active",
"date": "2025-08-27",
"publisher": "OHDSI / OMOPHub",
"description": "OMOP Standardized Vocabularies (release 2025.2). Served by OMOPHub at https://fhir.omophub.com. Content is identical to the OHDSI ATHENA vocabulary release.",
"content": "not-present",
"property": [
{
"code": "concept-id",
"description": "The OMOP concept_id value for the concept.",
"type": "integer"
},
{
"code": "source-concept-code",
"description": "The OMOP concept_code value as a FHIR Coding (includes system URI + code).",
"type": "Coding"
}
]
}
The full response lists every OMOP property and relationship type the server supports - see $lookup properties in the overview for the complete set.
Why two shapes?
OMOPHub serves all 130+ vocabularies from a single unified backend. The per-vocab stubs are thin FHIR-conformant views over that backend, added so clients like HAPI and EHRbase can discover http://loinc.org as a first-class CodeSystem instead of having to know the OMOP omnibus URL. Both shapes resolve to the same concept data; pick whichever matches your client’s expectations.
| Use the stub when | Use the unified CodeSystem when |
|---|
| A FHIR client is probing support by canonical URI (HAPI, EHRbase) | You need release-specific metadata (version, release date, property definitions) |
| You want concise metadata for UI pickers | You’re building a client that walks OMOP properties directly |
Round-tripping url: http://loinc.org from a search result | Round-tripping url: https://fhir-terminology.ohdsi.org |
Errors
| HTTP | Issue Code | Cause |
|---|
| 401 | login | Missing or invalid API key |
| 404 | not-found | id does not match any known stub or released vocabulary version |
See Also