Support OID-based CodeSystem and ValueSet resolution - #8188
Open
gM4n-sys wants to merge 6 commits into
Open
Conversation
gM4n-sys
marked this pull request as ready for review
July 24, 2026 16:13
GL-8718: Generalise patient SP Patient compartment membership beyond …
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #8176
Summary
This PR adds identifier-based fallback resolution for canonical terminology resources referenced by OID URNs.
It supports ValueSet expansion when:
ValueSet.compose.include.systemreferences a CodeSystem by OIDValueSet.compose.include.valueSetreferences another ValueSet by OIDThe installed CodeSystem or ValueSet may continue to use its HTTP canonical URL in
urlwhile exposing the OID through:{ "identifier": [ { "system": "urn:ietf:rfc:3986", "value": "urn:oid:1.2.3.4" } ] }Previously, HAPI FHIR attempted to resolve these references only through the resource's canonical
url. An OID reference therefore failed whenever the installed resource used a different HTTP canonical URL.Companion PR
The corresponding HAPI FHIR JPA Server Starter compatibility changes are provided by:
The companion PR updates the starter for the
DaoRegistryregistration flow and was used for the end-to-end runtime verification described below.Resolution behavior
Canonical resource resolution now uses two distinct phases:
urn:oid:, search by identifier.The identifier fallback requires:
When the reference includes a version, the resource version must also match exactly.
For example:
matches only a resource with:
Canonical URL resolution retains priority across the complete validation-support chain. An identifier match from an earlier support cannot override an exact canonical match from a later support.
Nested
ValidationSupportChaininstances preserve the same canonical-first ordering.Changes
This PR:
Adds
CanonicalResourceIdentifierRequest.Adds the FHIR-version-independent
CanonicalResourceIdentifierMatcher.Adds
IValidationSupport.fetchCanonicalResourceByIdentifier(...).Generalizes identifier fallback beyond CodeSystem-specific resolution.
Adds canonical-first, identifier-second resolution for:
CodeSystemValueSetAdds backend-specific identifier resolution for:
PrePopulatedValidationSupportUses indexed identifier and version searches for persisted JPA resources.
Restricts in-memory and package lookups to candidates of the requested resource type.
Requires exact identifier-system and identifier-value matches.
Requires an exact version match when a version is requested.
Collapses duplicate representations of the same canonical URL and version.
Rejects ambiguous identifier mappings to different canonical targets.
Preserves validation-support ordering during identifier fallback.
Preserves the original OID from
ValueSet.compose.include.systeminValueSet.expansion.contains.system.The default
IValidationSupportimplementation returns no identifier result. Each backend therefore controls how it performs an optimized lookup instead of falling back to an unrestricted scan of all conformance resources.Supported examples
CodeSystem referenced by OID
A ValueSet may contain:
{ "compose": { "include": [ { "system": "urn:oid:1.3.6.1.4.1.19376.3.276.1.5.9", "version": "4.0.0" } ] } }while the installed CodeSystem contains:
{ "url": "https://example.org/CodeSystem/example", "identifier": [ { "system": "urn:ietf:rfc:3986", "value": "urn:oid:1.3.6.1.4.1.19376.3.276.1.5.9" } ], "version": "4.0.0" }The CodeSystem is resolved by its identifier, and the expansion continues to use the requested OID as
expansion.contains.system.ValueSet imported by OID
A ValueSet may import another ValueSet using:
{ "compose": { "include": [ { "valueSet": [ "urn:oid:1.2.3.4|4.0.0" ] } ] } }The imported ValueSet can use an HTTP canonical URL while exposing
urn:oid:1.2.3.4throughValueSet.identifier.Verification
The change is covered at multiple levels.
Matcher tests
Tests verify:
Validation-support chain tests
Tests verify:
Backend tests
Tests cover:
Expansion tests
End-to-end R4 expansion tests verify:
ValueSet.compose.include.systemis resolved by its OID identifier.ValueSet.compose.include.valueSetis resolved by its OID identifier and imported successfully.The relevant validation, JPA, NPM-JPA and expansion tests pass together in the Maven reactor.
Runtime verification
The change was also verified using a complete HAPI FHIR JPA Server Starter build from hapifhir/hapi-fhir-jpaserver-starter#985 against this PR.
The resulting Java 21 server was run against PostgreSQL with an existing R4 terminology repository.
The following checks completed successfully:
ValueSet/$expandresolved CodeSystems referenced through OID identifiers.ValueSet/$expandresolved imported ValueSets referenced through OID identifiers.ValueSet.expansion.contains.system.The tested runtime combination was:
Dockerfile
Non-goals
This change does not alter REST search semantics such as:
It also does not treat arbitrary identifiers as canonical aliases. Identifier fallback is currently restricted to OID URNs represented as: