For a solicited attachment, begin when the payer sends a request to the provider — this may arrive as a CDex Task (task-based) or via the $request-attachment operation; identify which mechanism your exchange partner supports by consulting their CDex CapabilityStatement.
For an unsolicited attachment, the provider proactively submits supporting documentation alongside or after a claim; structure the submission as defined by the CDex unsolicited attachment profile, attaching clinical documents to the relevant claim or prior authorization.
In either flow, package clinical documents as FHIR DocumentReference resources pointing to Binary resources (base64-encoded content) or as inline base64 within DocumentReference.content.attachment.data.
Use the $submit-attachment operation on the payer's endpoint to deliver the attachment bundle, including the TrackingId that links the submission back to the original claim or authorization request.
Confirm receipt by checking the OperationOutcome or Task status returned by the payer system.
Retain correlation identifiers (TrackingId, claim reference, Task id) for audit and resubmission purposes.
Known gotchas
Solicited vs. unsolicited flows have distinct profile requirements in the CDex IG — mixing them will cause conformance failures; verify which profile applies to each direction.
The TrackingId linking an attachment to a claim is critical — a missing or incorrect TrackingId means the payer cannot associate the document with the correct claim.
Document MIME types must be supported by the receiving system; confirm accepted formats (PDF, CDA, FHIR JSON) with the payer before submitting.
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