Migrate a FHIR server implementation from US Core 6.1.0 to US Core 7.0.0 by identifying breaking must-support and profile changes
domain: hl7.org · 6 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
In-depth guide
FHIR Bulk Data $export gotchas — the full failure-mode walkthrough related to hl7.org, checked against official docs, with linked verified routes.
Steps
Review the US Core 7.0.0 change log and the STU Update notes; focus on new profiles (Screening and Assessment Observation, Average Blood Pressure Observation), removed profiles, and must-support obligation changes
For each existing US Core profile your system implements, diff the 7.0.0 profile against the 6.1.0 version using the FHIR profile comparison tool or manual review of StructureDefinition differential elements
Identify elements that changed from optional to must-support in 7.0.0 and update your resource creation logic to populate them; identify elements removed or renamed
Update CapabilityStatement supportedProfile canonical URLs to reference 7.0.0 profile versions and update any locally stored profile snapshots used for validation
Run $validate against a representative sample of existing resources using the 7.0.0 profile canonical URLs to surface validation errors before live deployment
Update FHIR search parameter support for any new or modified search parameters introduced in US Core 7.0.0
Known gotchas
US Core 7.0.0 aligns with USCDI v4, which includes new data classes not present in USCDI v3 (the basis for US Core 6.x); failing to implement new USCDI v4 data elements will result in non-conformance for systems subject to ONC certification
The must-support obligation model in US Core 7.0.0 uses explicit obligation codes (SHALL, SHOULD) defined per actor (Responder, Requester); the meaning of must-support is now actor-specific and differs from the general US Core 6.x interpretation
Profile canonical URL versioning matters for $validate: validating against a 6.x canonical when you intend 7.0.0 conformance produces incorrect results — always specify the full versioned canonical URL in validation requests
Give your agent this knowledge — and 15,600+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?