POST the resource to {base}/{ResourceType}/$validate with the resource as the request body (or wrapped in a Parameters resource with a 'resource' parameter); include ?profile={profile-canonical-URL} to validate against a specific profile.
Parse the returned OperationOutcome resource: check issue[].severity for 'error' and 'warning' entries; 'error' issues indicate non-conformance that must be fixed.
For offline or CI validation, use the HL7 FHIR Validator CLI (validator_cli.jar) with the -ig flag pointing to US Core or other implementation guide packages from the FHIR package registry (packages.fhir.org).
Download US Core profiles as an npm-style FHIR package (e.g. hl7.fhir.us.core) and supply them to the validator so it can resolve profile URLs and value set bindings.
Address common US Core violations: missing must-support elements, unbound or incorrectly bound code values, and missing required identifiers or category codings.
Integrate $validate calls into your data ingestion pipeline to catch non-conformant resources at the boundary rather than letting invalid data propagate into your store.
Known gotchas
The $validate operation's behavior varies by server; some servers validate only against the base FHIR spec unless a profile URL is explicitly supplied, so always pass the profile parameter explicitly.
Value set expansion for validation requires a terminology server; the HL7 validator uses tx.fhir.org by default, which requires network access and may time out—configure a local terminology server for offline or high-volume validation.
Validation warnings (as opposed to errors) may indicate real clinical data quality issues even if the resource is technically conformant; review warnings rather than silently suppressing them.
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