Submission
The path from a validated draft to a payer, and the two things about the upstream API that shape every decision in it.
#The order
- Payer supportPrior-auth support varies by payer more than any other transaction. Check before assembling anything.
- Fetch rulesWhat this payer requires, with provenance. Abstains rather than guessing.
- ValidateAgainst the payer's rules. A draft that fails stops before the wire, not after a rejection - a rejected submission still consumed a payer's queue slot and a person's afternoon.
- Identity reconciliationThe member id and the patient must describe the same person. A mismatch is refused before transmission, not flagged after.
- Duplicate checkSearch before submitting. This is the safe pattern when the upstream has no idempotency key.
- Human releaseAlways. See The release gate.
- Transmit
POST /v2/service-reviewsanswers 202 with aLocationheader and no body.
#Two upstream facts that shape everything
There is no idempotency key
Availity's Service Reviews API accepts no client-supplied idempotency key. A retry after an ambiguous failure can therefore reach the payer twice, and a duplicate authorization is a real operational problem. So: search before submitting, and treat a 5xx on an unsafe method as AMBIGUOUS rather than failed.
The adapter distinguishes them explicitly. A 500 on a read is unavailable and retryable. A 500 on a submit is ambiguous - the submission may or may not have reached the payer, and the correct response is to search, not to resend.
202 means two different things
On a POST, 202 means accepted. On a poll of an existing review, 202 means still pending - never success. Confusing the two turns "the payer has not decided" into "the payer approved it".
#Idempotency on our side
The gateway holds a durable idempotency ledger keyed by a canonical hash of the request. It survives a process restart, because a ledger that resets on deploy means a resubmitted authorization reaches the payer twice.