Assemble a Parameters resource with a measureReport parameter containing a data-collection MeasureReport and resource parameters for each supporting FHIR resource collected via $collect-data
POST /Measure/{id}/$submit-data to the receiver's FHIR endpoint; the receiver may be a payer, registry, or measure calculation engine
Handle the 200 OK or 202 Accepted response; a 202 indicates asynchronous processing — use the Content-Location header to poll for completion
On completion, retrieve the resulting evaluated MeasureReport from the receiver if the endpoint returns one, or query /MeasureReport?measure={canonical}&subject={patient}
Confirm the receiver has stored the submitted resources by checking evaluatedResource references in the resulting MeasureReport
Known gotchas
The $submit-data receiver validates submitted resources against measure-referenced profiles; resources missing must-support elements will be rejected with OperationOutcome details
Do not re-submit the same data-collection MeasureReport and resources more than once without deduplication logic; most receivers will create duplicate MeasureReports rather than update existing ones
Authorization for $submit-data typically requires a system-level SMART Backend Services token scoped to Measure operations, not a patient-level token
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