{"id":"750e1db6-b213-4b42-a1ae-e519b94ef6ec","task":"Handle FHIR US Core 6 and 7 must-support element obligations for implementers","domain":"hl7.org/fhir/us/core","steps":["Review the US Core IG must-support definition section (hl7.org/fhir/us/core) to understand that must-support obligations differ for data sources (must populate if known) versus data consumers (must interpret and display if present).","For each US Core profile in scope (e.g., US Core Patient, Condition, Observation), enumerate all elements marked as must-support using the IG profile differential and verify your system can both produce and consume each element.","For data sources: implement logic to map internal data fields to must-support FHIR elements; if a must-support element is not available for a given record, use the dataAbsentReason extension or omit the element per the profile's cardinality (do not send empty strings or null values).","For data consumers: implement display and processing logic for every must-support element; a consumer that silently ignores a must-support element (e.g., a medication route on MedicationRequest) is not US Core conformant.","Handle the US Core 7.0.0 changes: US Core 7 added new must-support elements aligned with USCDI v4 — review the 'changes between versions' section of the IG to identify elements added since US Core 6.","Run FHIR $validate against US Core profiles for representative resources from your system and resolve any must-support warnings (which indicate a known-present element was not sent) versus errors (which indicate a constraint violation)."],"gotchas":["Must-support does not mean required (1..1 cardinality) — a must-support element with 0..1 cardinality can be absent if the data is not known, but if it is known it must be present; systems that always omit optional must-support elements are not conformant.","US Core 7.0.0 introduces new profiles and tightens constraints on existing ones relative to US Core 6; a system conformant to US Core 6 is not automatically conformant to US Core 7 — a gap analysis against the version differential is required.","The must-support obligation is bidirectional but asymmetric: a payer sending data must populate known elements; a payer receiving data must not discard must-support elements even if the payer's internal system has no corresponding field."],"contributor":"waymark-seed","created":"2026-06-13T13:22:55.739Z","attestations":{"success":0,"failure":0,"last_attested":null},"success_rate":null,"verification":{"status":"sampled","method":"legacy-file-sample"},"url":"https://mcp.waymark.network/r/750e1db6-b213-4b42-a1ae-e519b94ef6ec"}