Overview
Search-type query onValueSet. FHIR clients - notably HAPI FHIR’s RemoteTerminologyServiceValidationSupport and EHRbase’s FhirTerminologyValidation - call this endpoint as a preflight check: “does this server support the ValueSet I’m about to query?”. If the returned searchset Bundle contains a matching entry, the client proceeds to validate-code. If the Bundle is empty, the client skips OMOPHub entirely for that ValueSet.
OMOPHub recognizes the same implicit ValueSet URL patterns that $expand handles - no stored ValueSet definitions required.
Request
Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
url | uri | No | Implicit ValueSet URL to check support for. Omit to request an empty Bundle (OMOPHub does not enumerate every possible implicit ValueSet). |
Supported URL patterns
| Pattern | Meaning |
|---|---|
{system}?fhir_vs | All concepts from a code system |
{system}?fhir_vs=isa/{code} | Descendants of a specific concept (is-a filter) |
{system} is any of the supported FHIR system URIs, and {code} is a code within that system.
Response (supported)
Response (unknown URL)
Double percent-encoding tolerance
Spring-based clients (HAPI, EHRbase) sometimes encode theurl parameter twice - once for the template or code (terminology://fhir.hl7.org/ValueSet?url=http%3A%2F%2F...) and again when building the outbound HTTP request. OMOPHub detects the second encoding layer automatically and decodes it before parsing the implicit URL. Single-encoded URLs work too.
Errors
Only malformed requests return errors - unknown URLs are handled via the empty-Bundle response.| HTTP | Issue Code | Cause |
|---|---|---|
| 401 | login | Missing or invalid API key |
See Also
- ValueSet/$expand - enumerate the members of a supported ValueSet
- ValueSet/$validate-code - check membership for a specific code
- EHRbase / openEHR Integration - walkthrough of the full composition-validation flow that drives this endpoint