MANSOQ NPHIES
Classify platform errors, payer errors and denials
Choose the correct recovery path before correcting or appealing a payer transaction.
Current source · source reviewed · 6 min read
Before you begin
- Original exchange and response reference.
- Claim and adjudication details for the response.
1. Identify the response surface
Determine whether the platform rejected validation before payer delivery, the payer returned an unadjudicated business error, or the payer completed adjudication unfavorably.
2. Keep a platform validation error out of denial analytics
Correct the payload through the supported validation/retry path. Preserve message identity where the protocol and persisted exchange require it; do not manually mint a replacement transport identity.
3. Handle a payer business error as a new request
Review the returned business defect and the required new request/identifier semantics. Do not use the identical-transport-retry rule as a universal correction mechanism.
4. Route adjudication rejection to the denial workflow
Read the reason, responsibility, owner and deadline. An unfavorable adjudication is a completed business decision, not necessarily a transport error.
Why the distinction matters
Treating a validation failure as a denial inflates denial analytics. Retrying the wrong identity can create a duplicate or a repeating rejection. The remedy and its payload are selected from the actual response surface.
Operational evidence
The claim workbench exposes classify-response. Retain the raw payload in the protected transaction system and use identifiers in support notes rather than copying sensitive payloads.
Troubleshooting
A response has HTTP success but the claim is unpaid
Inspect business processing and adjudication, then bank settlement. HTTP success, acceptance, adjudication and cash receipt are separate states.
Source evidence
References are pinned to the private MANSOQ source repository. Repository access is required to open these links.