Editorial illustration in editorial-gouache style depicting a meta.profile claim processed by four receiver modes — trust, verify, ignore, combine
by: Daniel Friedman

meta.profile: What It Claims and What It Costs to Enforce

Resource.meta.profile is the sender's assertion of conformance. It says "this resource conforms to these profiles." That claim is powerful and unenforced by the spec — receivers may honor it, ignore it, or dispute it. Deciding how your validator treats it is a design choice with real trade-offs. The site's R4 resource vetter records claims but does not silently trust them. For the wider FHIR framing, deeper coverage of CMS interop rules has more.

What The Claim Looks Like

`` "meta": { "profile": [ "http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient|7.0.0" ] } ``

Every URL in the array is a canonical profile identifier. The version suffix is optional. Multiple profiles can be claimed simultaneously — the resource asserts conformance to all of them.

What The Sender Is Promising

  • The resource satisfies the profile's structural rules
  • The resource satisfies the profile's cardinality rules
  • The resource satisfies the profile's invariant expressions
  • The resource satisfies terminology bindings (if the sender validated them)

The sender is not promising the receiver will verify. They are promising the resource passes.

Receiver Options

  • Trust — accept the claim, validate only if structural rules also fail
  • Verify — run the claimed profile's rules against the payload
  • Ignore — treat every resource as if unclaimed, use the receiver's configured profiles
  • Combine — verify against both the claim and the configured profile

Verify is the safe default. Trust is the fast default. Ignore is defensible in environments where meta.profile is unreliable. Combine is what most CMS-relevant workflows do.

The Cost Of Verify

Verifying every claim means loading and running every claimed profile per request. For high-throughput workloads, that is expensive. Two mitigations:

  • Cache parsed profiles indefinitely (invalidate on version bump)
  • Batch validation runs to amortize profile-load overhead

For the wider question of what a profile package needs to contain, profile-based validation without a full IG deploy is the entry.

The Cost Of Trust

Trusting the claim means the receiver has no ground truth. If the sender got it wrong — a payload claiming US Core conformance but missing mustSupport extensions — the receiver has no signal.

The trust default is safe only if the sender is trusted separately. For open endpoints, verify.

The Cost Of Ignore

Ignoring meta.profile means the receiver validates against its own configured profile, which may not match the sender's intent. A US Core producer sending to a receiver configured for CARIN Blue Button gets rejected by a validator that never read the claim.

Ignore is defensible only when the receiver is highly opinionated about which profile applies.

Cross-Reference With Configured Profile

The safest pattern is combine: run both the sender's claim and the receiver's configured profile. Divergences are surfaced separately:

  • Payload passes claim, fails configured — sender chose wrong profile for this endpoint
  • Payload fails claim, passes configured — sender misdeclared, but data works
  • Payload fails both — real validation failure

Each is a different fix. For the response shape, OperationOutcome design for validator responses is the entry.

Version Handling In Claims

http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient|7.0.0 claims version 7.0.0. http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient claims any version.

Validators that ignore the version suffix run against whichever version they have loaded. That is safe when versions match, quietly wrong when they do not.

Pin your validator's version. Log mismatches for review.

The Short Version

meta.profile is an assertion, not a guarantee. Receivers choose whether to trust, verify, ignore, or combine. Verify with a cached profile package is the safe default for open endpoints. Log claim-vs-configured divergences separately. For the boundary case, single-resource validation vs Bundle validation: knowing the boundary covers when profile validation is even in scope.

Editorial-gouache diagram of a meta.profile claim being processed by a receiver in four modes — trust, verify, ignore, combine — with per-mode outcomes annotated, in soft coral gouache tones on cream paper

Sources