Preauthorisation response

The payer's answer, on the provider's /v1/preauth/on_submit callback. A collection bundle whose spine is a ClaimResponse carrying the request's case number. The same shape carries an acknowledgement, an approval, a query and a rejection.

Sent on /v1/preauth/on_submit.

The bundle​

Elements​

1. ClaimResponse​

NRCeS profile: ClaimResponse.

2. Patient​

NRCeS profile: Patient.

3. Organization (pay)​

NRCeS profile: Organization.

4. Organization (prov)​

NRCeS profile: Organization.

5. Coverage​

NRCeS profile: Coverage.

The answers​

The same bundle, told apart by the workflow code, outcome and the claim-level adjudication reason.

Rules​

1. Read outcome with the reason​

outcome complete covers approval and rejection alike. Read it with adjudication[].reason at claim level.

2. Answer early, decide later​

Acknowledge at once on 20 as response.partial, then decide on 21 or 23 as response.complete, or the exchange retires the correlation before the adjudicator gets to it.

3. The case number​

preAuthRef carries the payer's own case number. Store it on arrival; later requests on the case name it.

4. Items by sequence​

Read item adjudication by itemSequence, never by array position. A reduced amount does not force outcome to partial; reconcile the amounts yourself.

5. Totals​

total[] carries benefit, submitted and eligible. The eligible total names the member and the plan in its id; key on the category and the id together.

6. disposition is prose​

For a human. Route on outcome and the adjudication codes.

7. Match on the case number​

Join the response to the request on identifier and preAuthRef, never on the provider identifier or name, which can change shape between request and response.

8. Adjudication systems​

Some senders bind adjudication categories to a documentation URL. Match on the code.

PMJAY​

The generic bundle above is what every payer takes, IRDAI-regulated insurers and TPAs included. PMJAY takes it with the changes and requirements below.

What changes in the bundle​

PMJAY sends this exchange in the generic shape.

What PMJAY specifies​

• A rejection is outcome error with reason rejected and benefit 0. Generic payers send complete with cancelled or rejected. Handle both.
• A query is outcome partial with reason queried, the question as free text in the item adjudication; see the query chapter.
• preAuthRef carries the scheme's case id. It is what the payer service uses to address the case.

What PMJAY requires​

• Store the case reference the moment it arrives. Enhancements, claims and the payer service address the case by it.

Use cases, APIs and data elements​

C5 Respond to pre-authorisation (payer)​

The adjudicated pre-authorisation. The acknowledgement on 20 travels as response.partial and carries the payer's own case number; the decisions travel as response.complete. Read outcome and the adjudication amounts together: complete covers approval and denial alike. Under PMJAY a query is this ClaimResponse on 24 or 241, on the case's own thread.

Request headers

Workflow codes

Data elements

NRCeS profiles: ClaimResponse.