Skip to main content
FHIR CapabilityStatement and terminology metadata

Overview

Returns a FHIR CapabilityStatement describing what operations and resources OMOPHub exposes at a given FHIR version endpoint. This is the first endpoint every conformant FHIR client hits - HAPI FHIR, Firely, Postman collections, and the inspectors built into most FHIR tooling all probe GET /metadata before making any other call.

Path Parameters

string
default:"r4"
string
OMOP vocabulary release; defaults to the active release.
string
Header alternative to vocab_release; the header takes precedence.
FHIR wire version: r4, r4b, r5, or r6. Omit the segment to use R4.

Request

Version variants

The response shape is version-adapted - field names follow the conventions of the requested FHIR version.

Response

Response Fields

string
Always CapabilityStatement.
string
Publication status.
string
Capability statement kind.
string
FHIR release represented by this endpoint.
array
Supported FHIR media types.
string
Capability statement publication date.
string
Capability publisher.
object
Server software name and version.
object
Deployment description and canonical URL.
array
REST resources, interactions, and operations exposed by the server. Extended operations appear under each resource’s operation list. FHIR batch Bundle processing is a system interaction and appears as interaction.code: batch.
$diff is an OMOPHub-specific CodeSystem operation. Batch processing is not a $batch operation: it is the standard FHIR system-level batch interaction, invoked by posting a Bundle to the FHIR base URL. See FHIR Batch Bundle for the supported entry types. The advertised format array includes application/fhir+xml because the server accepts XML requests via content negotiation. Most operations return clean XML; the three Bundle-shaped endpoints (CodeSystem search, ValueSet search, batch) are best-effort in XML and should be called with JSON in practice. See the XML support matrix in the overview for the per-endpoint breakdown.

Response headers

Every response from the FHIR Terminology Service - /metadata included - carries two OMOPHub-specific headers that tell you which OMOP vocabulary release served the request: Use these headers to confirm which release your client is actually hitting, especially when pinning a specific version via the X-Vocab-Release request header or vocab_release query parameter. See Vocabulary Versions for the full release history.

Content negotiation

GET /metadata respects the same Accept header rules as every other FHIR endpoint - JSON is returned by default; XML is served only when the client strictly prefers it. See the Content Type section of the overview for the q-value semantics.

Errors

See Also

  • Overview - full list of operations, supported vocabularies, and extension properties
  • CodeSystem search - discovery for the supported system URIs advertised in this CapabilityStatement