The payer creates a Task resource on the provider's FHIR server (or sends a Task via a push mechanism) requesting additional clinical documentation; the Task must include the requester (payer), owner (provider), intent: order, code (referencing the CDex attachment request code), and a focus linking to the Claim or prior auth.
The provider's system polls for new Tasks via GET [base]/Task?owner={provider-NPI}&status=requested or subscribes to a FHIR Subscription for Task creation events.
Upon receiving a Task, the provider fulfills it by attaching DocumentReference resources (the clinical documents) as Task.output elements and updating the Task status to completed via PUT or PATCH on the Task resource.
The payer retrieves the completed Task to collect the output references and then fetches the referenced DocumentReference resources (and their Binary attachments) from the provider server.
If the provider cannot fulfill the request, update the Task status to rejected and set Task.statusReason with a coded or text explanation.
Known gotchas
The CDex Task-based exchange is distinct from the $submit-attachment operation — Task exchange is a solicited pull model where the payer initiates; $submit-attachment is an unsolicited push model where the provider initiates.
FHIR server authorization for cross-organization Task read/write requires SMART on FHIR backend services auth or a mutually agreed security model — check the current CDex IG's security section for compliant options.
Task polling intervals should be coordinated with the payer's SLA expectations; polling too infrequently risks missing response deadlines; always check the current CDex IG for recommended polling and subscription patterns.
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