Ontoserver: urn:ietf:bcp:13 codesystem (MIME types) not available

[niccoreyes]

Description

The urn:ietf:bcp:13 codesystem (MIME types, per BCP 13 / RFC 6838) is not loaded in Ontoserver. This causes validation failures for any FHIR resource that uses codes from this system.

Affected Elements

• Provenance.signature.sigFormat — uses MimeType type bound to urn:ietf:bcp:13
  • Example value: application/signature+xml
  • Without the BCP 13 codesystem, Ontoserver cannot validate this field and throws a codesystem-not-found error

Impact

• IG Publisher validation fails with codesystem resolution errors during QA
• Any transaction bundle containing a Provenance with sigFormat will fail server-side validation
• The use of urn:ietf:bcp:13 has been temporarily removed from the PH eReferral IG — sigFormat was stripped from the provenance example as a workaround (see PR #145)

Resolution Needed

• Load the urn:ietf:bcp:13 codesystem into Ontoserver, OR
• Configure Ontoserver to recognize it as an external codesystem that can be validated without loading (if supported)
• Once resolved, the sigFormat field can be restored in the PH eReferral examples

Related

Discovered while building the PH eReferral Implementation Guide (ph-ereferral). The sigFormat field was removed from the provenance example in PR #145 as a temporary workaround.

[jgsuess]

Diagnosis

Confirmed on tx.fhirlab.net (Ontoserver 6.25.2) today:

• urn:ietf:bcp:13 — not present (0 results)
• http://www.iana.org/assignments/media-types — 1 copy exists but is marked retired

Uploading a content: not-present stub at urn:ietf:bcp:13 doesn't help — Ontoserver still returns x-caused-by-unknown-system on $validate-code and refuses to resolve the system. This is expected Ontoserver behaviour: not-present tells the server the system exists but doesn't give it anything to validate against.

Why this is hard

urn:ietf:bcp:13 is an open-ended, externally-maintained system (IANA MIME type registry). Ontoserver can't validate arbitrary MIME type strings by looking them up in a database the way it handles HL7 code systems — the valid values are "whatever IANA has registered," which is a moving target.

Correct fix path: Ontoserver implicit code system configuration

Ontoserver supports configuring certain code systems as implicit — the server accepts any code without checking against a loaded list. This is the right approach for MIME types (and similarly for other open-ended systems like regex-validated URIs, ISO language codes etc.).

The configuration lives in Ontoserver's application.yaml (server-side, not a FHIR resource upload). The relevant setting is in the ontoserver.yaml or Ontoserver deployment config — specifically a property along the lines of:

ontoserver:
  fhir:
    implicit:
      codesystems:
        - url: urn:ietf:bcp:13
          version: "2.0.0"

(Exact key name varies by Ontoserver version — the CSIRO Ontoserver Confluence has the authoritative reference for 6.25.2.)

This change goes in the Kubernetes deployment (the Ontoserver ConfigMap or Helm values in open-shared-clouds), not in a FHIR resource upload to the server. A config repo ticket has been raised to track this: configuration#42 — I'll add this as a sub-task there.

Short-term

The sigFormat removal workaround (PR #145) stands until the configuration change is deployed. Once the implicit system config is in place, sigFormat can be restored in the PH eReferral provenance examples.

[jgsuess]

Proposed fix: route BCP-13 to tx.fhir.org as a remote terminology service

What we tried

Uploading a content: not-present CodeSystem stub at urn:ietf:bcp:13 does not resolve this on Ontoserver. The server still returns x-caused-by-unknown-system on $validate-code — Ontoserver requires either a server-side implicit code system configuration or actual content, neither of which is possible via FHIR resource upload alone.

The proper fix (Ontoserver implicit.codesystems configuration) requires a Kubernetes config change and is tracked in configuration#42.

Short-term fix: tx.fhir.org as BCP-13 remote terminology service

HL7's public reference server at https://tx.fhir.org/r4 correctly validates BCP-13 codes:

GET https://tx.fhir.org/r4/CodeSystem/$validate-code?url=urn:ietf:bcp:13&code=application/fhir+json
→ result: true, display: application/fhir+json

It handles this as an implicit system — no content needs to be loaded; any properly-formed IANA MIME type string is accepted. This is the correct behaviour for an open-ended registry like MIME types.

Implementation

Adding a specific bcp13 entry to the remote_terminology_service configuration in both HAPI CDR instances, routing BCP-13 validation to tx.fhir.org/r4 rather than tx.fhirlab.net:

remote_terminology_service:
  bcp13:
    system: "urn:ietf:bcp:13"
    url: "https://tx.fhir.org/r4"

This is being implemented now in open-shared-clouds/hapi-fhir/flux (apps/red/hapifhir-phcore and hapifhir-pheref app-config-configmaps). Once deployed, server-side validation of Provenance.signature.sigFormat will pass, and the sigFormat field can be restored in the PH eReferral examples (PR #145 workaround can be reverted).