Service Reviews (278)

The prior authorization transaction. Five operations, and three behaviours that shape every design decision above it.

#Operations

Operation	Notes
`POST /v2/service-reviews`	Submit. Answers 202 with a `Location` header and no body.
`GET /v2/service-reviews/{id}`	Poll. 202 means still pending, never success.
`GET /v2/service-reviews`	Search. 36 query parameters.
`PUT /v2/service-reviews`	Update an existing review.
`DELETE /v2/service-reviews/{id}`	Void.

#Three traps

1 · No idempotency key

The API accepts no client-supplied idempotency key. A retry after an ambiguous failure can reach the payer twice. The safe pattern is to search before submitting, and to treat a 5xx on a POST as AMBIGUOUS rather than failed - the submission may or may not have arrived.

2 · 202 is overloaded

On a POST it means accepted. On a poll it means still pending. Reading a poll 202 as success turns "the payer has not decided" into "the payer approved it".

3 · The declared scope may not exist

The published Swagger names a security scope that does not appear in the product's scope list. The contract module reads the spec and reports the discrepancy rather than papering over it - see PHANTOM_SCOPE.

#Decision codes

Code	Meaning	What the platform does
`A1`	Certified in total	Write back, gated.
`A2`	Certified in part	Write back, gated. The partial scope matters clinically.
`A3`	Not certified	Routed to a licensed human. Never written back, never communicated by software.
`A4`	Pending	Keep chasing on the backoff schedule.
`A6`	Modified	Treated as consequential; a human reviews what changed.