The US Core IG

Without US Core, every EHR could expose a slightly different Patient. One might omit race; another might use a custom coding system for gender. Apps would need per-vendor adapters.

US Core says: if you implement these profiles, with these Must Support elements and these value sets, an external app can read and write the core US clinical data set without surprises.

It is published by HL7 as an Implementation Guide (IG) — a bundle of:

• StructureDefinitions (the profiles)
• ValueSets and CodeSystems (the terminology bindings)
• SearchParameters (which queries servers must answer)
• CapabilityStatements (what a conformant server looks like)
• Worked examples

USCDI (United States Core Data for Interoperability) is a list maintained by ONC of clinical data classes and elements that certified EHRs must exchange — things like Patient Demographics, Problems, Medications, Lab Results, Clinical Notes, etc.

US Core is the FHIR representation of USCDI. Each USCDI data element maps to one or more US Core profile elements.

The current build (build.fhir.org) tracks the next USCDI version. Most production EHRs today are still on US Core 3.1.1 or 6.0.0 because that's what their certification edition required.

This trips everyone up. In US Core:

• `min: 1` (Required) — the element MUST be present in every instance. If it's missing, the instance is non-conformant.
• Must Support — the element MAY be absent (often because the data genuinely isn't known), but:
• Producers must be *able* to populate it when the data exists.
• Consumers must be *able* to process it meaningfully when it's present (not just ignore it).

So Must Support is about implementation capability, not instance content. A Must Support element with no data should typically be sent with a data absent reason extension instead of being silently omitted, e.g.:

"_birthDate": {
  "extension": [{
    "url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
    "valueCode": "unknown"
  }]
}

US Core's general guidance for missing Must Support data is one of: unknown, asked-unknown, temp-unknown, not-asked, asked-declined, masked, not-applicable.

Server conformance — the server's CapabilityStatement declares which US Core profiles it supports, which interactions (read, search-type, create…) and which search parameters. Servers MUST support the search parameters listed as required for each profile.

Client conformance — clients must be able to process every Must Support element, follow references, and handle the listed search parameters.

Instance conformance — a single resource instance conforms if it satisfies the profile's invariants, cardinalities, and bindings. Tools like the official HL7 FHIR Validator check this.

You'll see all three terms in real conversations — don't confuse a server claiming US Core support with an individual resource being valid US Core.