Identify the relevant US Core profile for the resource type (e.g., US Core Patient, US Core Observation Lab) from the US Core Implementation Guide at hl7.org/fhir/us/core.
Invoke the server's $validate operation: POST [base]/[ResourceType]/$validate with the resource as the body and profile parameter set to the US Core profile canonical URL.
Review the returned OperationOutcome for issues with severity 'error' (profile violations) vs. 'warning' (recommendations); must-support fields that are absent generate warnings, not errors, unless populated with a value.
Check that must-support fields are present when data is available; must-support means senders must populate the field if the data exists, and receivers must handle it if present.
For US Core Patient, verify that at minimum identifier, name, gender, and birthDate are present; for US Core Observation Lab, check status, category, code, subject, and effective[x] are present.
Use a FHIR validator tool (e.g., the HL7 FHIR Validator JAR) locally to pre-validate before submitting to production servers, reducing rejected resource errors.
Known gotchas
US Core profile URLs are version-specific; using the wrong version URL (e.g., US Core 3.x vs. 6.x) will validate against different constraints and may produce misleading results.
Must-support is a conformance obligation, not a cardinality constraint; a resource can be valid FHIR R4 but non-compliant with US Core if must-support fields are missing when the data is known.
The $validate operation may not be implemented on all production servers; validate externally during development and do not depend on server-side validation in runtime pipelines.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp