US Core keeps Must Support separate from data availability

Must Support is a capability contract

The direct answer in US Core is that Must Support tells implementers what their systems must be capable of handling; it is not a promise that each marked element will contain a value in every returned resource. For responders, the guide describes capability to populate the element when the data are present and supported. For requestors, it requires capability to process the element without failing. Those two sides should be tested independently.

This differs from minimum cardinality. An element with a minimum of one is generally expected to be present subject to the guide's missing-data rules, while a Must Support marker can appear on an element whose minimum is zero. A conformance screen that reduces both concepts to one required-field icon loses the distinction. The profile version, element path, cardinality, Must Support flag, actor role, supported search or operation, and applicable guidance all belong in the test record.

Absence has a defined but limited meaning

US Core's missing-data guidance addresses cases where required or supported information cannot be represented as an ordinary value. The correct representation can depend on whether the reason is known, the data are suppressed, the element is required, and the underlying FHIR data type and profile permit an absent-data mechanism. Implementations should follow the exact profile and guide rule rather than placing a generic unknown code in every empty field.

Where a responder has no data for an optional Must Support element and the reason is unknown, omission can be the appropriate response. The requestor can interpret that absence as the data not being present in the responder's system; it should not expand that into a clinical conclusion that the condition, observation, or fact does not exist anywhere. Provenance, access rules, source-system scope, and known suppression remain material to the interpretation.

Conformance testing must include present and absent cases

A credible test set pairs a populated case with cases where the element is unavailable, known absent, suppressed, malformed, repeated, or present through an allowed choice or extension. The responder should produce the correct structure and preserve policy boundaries. The requestor should render, store, transform, and forward supported data without discarding it or failing when it appears. It should also handle valid absence without inventing a value.

Historical versioning matters. US Core 9.0.0 is based on FHIR R4, and implementations may be contractually tied to another US Core release or to a regulatory program that names a specific version. A product's statement that it supports US Core should therefore be decomposed into the exact release, profiles, actors, interactions, terminology, search behavior, security context, and tested edge cases. Passing one validator example is evidence for that example, not proof of complete production interoperability.

What an interoperability buyer should require

Choose one profile and trace several Must Support elements end to end from source data through the responder, network, requestor, user display, downstream export, and audit record. Change one value, remove another, suppress a third, and send an element the receiving system did not populate in its own test data. Reviewers should inspect profile and terminology versions, validation results, transformations, warnings, error handling, data loss, provenance, authorization, and the behavior of the consuming workflow.

HL7 publishes the implementation guide but does not certify a vendor through the page linked below or establish clinical completeness. Applicable regulations, certification criteria, contracts, other implementation guides, network rules, consent and privacy controls, and local clinical-safety governance can add or narrow requirements. Software capability must be demonstrated with representative data and partners; qualified standards, clinical, privacy, security, compliance, and legal owners still determine whether the implemented exchange is acceptable.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.