Skip to content
MK CDN
Menu
  • Terminology server
  • Medical form builder
  • Ehr development
  • Emr development
Menu
Editorial illustration in neubrutalism-shadow style depicting US Core Patient with race, ethnicity, birthsex, and gender-identity extensions annotated

Finding US Core Extensions Your Data Has to Carry

Posted on July 15, 2026July 13, 2026 by Mei Lin

US Core is the implementation guide most US-based FHIR integrations follow, and its extensions are the ones most producers have to carry and most consumers have to handle. Knowing which extensions US Core actually requires — not the full set it defines — is the difference between compliant payloads and rejected ones. The site's Extension registry audit matches US Core extensions specifically. For the wider FHIR framing, the FHIR fundamentals hub has more.

The Patient Extensions You Have To Carry

  • us-core-race — mustSupport on US Core Patient
  • us-core-ethnicity — mustSupport on US Core Patient
  • us-core-birthsex — mustSupport on US Core Patient
  • us-core-genderIdentity — mustSupport on US Core Patient
  • us-core-tribal-affiliation — optional but common
  • us-core-birthplace — optional

The first four are the ones that appear on nearly every conforming Patient. Missing one on a mustSupport-marked profile is the fast path to validation failure.

For the base pattern of reading an IG for its extensions, reading an IG for the extensions you actually need is the entry.

The Race And Ethnicity Structure

us-core-race is a complex extension with three sub-extensions:

  • ombCategory — one or more OMB race category Codings
  • detailed — one or more finer-grained race Codings
  • text — a required plain-text race statement

us-core-ethnicity mirrors that structure. Producers that send only the top-level extension without the nested sub-extensions fail validation.

The Practitioner Extensions

  • us-core-ethnicity on Practitioner — mustSupport if provided
  • us-core-race on Practitioner — mustSupport if provided

The demographics extensions apply on Practitioner as well as Patient. Consumers that handle them only on Patient miss the Practitioner case.

The Encounter Extensions

  • us-core-condition-encounter-diagnosis — links Condition to Encounter
  • us-core-encounter-suicide-risk-assessment — encounter-scoped assessment

Encounter extensions are less commonly required than Patient ones, but they show up on specific care-provision workflows.

The Coverage Extensions

  • us-core-coverage-plan-classification — classifies the Coverage plan
  • us-core-insurance-plan-identifier — insurance identity

Coverage extensions carry the payer-side information that revenue-cycle systems depend on. Handling them well is worth the specific effort.

The Provenance Extension

us-core-provenance-participant-role on Provenance carries the participant role in a data lineage record. Compliance and audit workflows depend on this being populated correctly. For the pattern of documenting what your custom extensions do so they can be maintained, documenting extensions so the next team can maintain them covers it.

The Version Question

US Core versions matter. 3.1.1, 5.0.1, 6.1.0, 7.0.0 — each version adjusts the extension set. A producer targeting 3.1.1 sends a slightly different set than one targeting 7.0.0.

Pin your target version explicitly. Do not assume the latest version is what your consumer expects. Ask.

Value Set Bindings

us-core-race.ombCategory binds to the OMB race categories. us-core-ethnicity.ombCategory binds to the OMB ethnicity categories. us-core-birthsex binds to a small enumerated set of codes.

Payloads with codes outside the bound value sets fail validation. The tool at /lint-lab/audit-extension-urls/ checks the URLs; validating the bound codes is a separate check. For the registry-problem side of the same question, the extension URL registry problem is the entry.

What The Audit Catches

The extension audit tool matches every URL in a paste-in resource against US Core's published set. Extensions matched are highlighted with their profile of origin. Extensions unmatched are flagged for review.

That single readout is often the fastest way to know "does my Patient carry the US Core extensions it needs?"

The Short Version

US Core's mustSupport extensions on Patient are the ones every US integration must carry — race, ethnicity, birthsex, gender identity. Complex extensions have nested sub-extensions. Version matters. The audit tool catches missing ones fast.

Neubrutalism-shadow diagram of US Core Patient with race, ethnicity, birthsex, and gender-identity extension slots and their sub-extension anatomy annotated, with heavy black borders and hard shadows on ivory

Sources

  • HL7 US Core Patient profile canonical page with extension - HL7 US Core Patient profile canonical page with extension slots

Dev utility

Dev utility

Wondering whether that Extension URL matches a known registry? an extension URL auditor lives in the toolbox pages nearby.

Recent Posts

  • FHIR Questionnaire vs REDCap for US Clinical Research
  • Self-Hosted vs Cloud FHIR Terminology Servers for US Hospitals
  • Open-Source vs Commercial FHIR Servers for US Hospital IT
  • SDC Forms vs JotForm for US Clinical Intake
  • LOINC vs ICD-10 FHIR Bindings for US Lab Workflows

Categories

  • Ehr development
  • Emr development
  • Extension Registry
  • Medical form builder
  • Terminology server
© Copyright 2025.
imunify-bot-check