Skip to content

Concept explainer

Insurers and claims

Describes how Vault files eligibility checks, pre-authorisations and claims over the National Health Claims Exchange and applies the responses and settlements that return.

A claim leaves Vault for its payer by one of two routes: the National Health Claims Exchange, or a direct connection to an insurer or TPA that works outside it. This page lists what flows on each route, follows a claim over the National Health Claims Exchange, and sets out how the hospital switches that route on.

What flows

Each claim is one record in Vault, whichever route it takes, and the route changes only how that record reaches the payer.

ExchangeDirectionStandardOwning tool
Coverage eligibilityOut to the exchange, with the payer's response read backA FHIR R4 bundle carrying a CoverageEligibilityRequestVault
Pre-authorisationOut to the exchange, with the payer's decision read backA FHIR R4 bundle carrying a Claim for pre-authorisation, answered by a ClaimResponseVault
Final claimOut to the exchange, with the adjudication read backA FHIR R4 bundle carrying the Claim, answered by a ClaimResponseVault
Settlement adviceIn, read back from the payerA FHIR R4 PaymentReconciliationVault
Pre-authorisation statusFrom the claim to the order waiting on itThe approval state, relayed inside PensieveVault
Claims outside the exchangeOut to an insurer or TPA, with its responses backFHIR R4 over HTTPS to the endpoint registered on a direct connectionVault

A claim over the exchange

Vault builds each bundle in FHIR R4 from the encounter's claim, and every resource in it is checked against its schema before it leaves. The patient is named by ABHA number, and each amount is written as an exact rupee value with two decimals. A submission for a patient with no ABHA on the record is refused before any bundle is built.

Figure 1.Diagram showing Vault sending an eligibility check, a pre-authorisation and a final claim to the claims exchange, relaying the pre-authorisation decision to Forge, and reading back each decision and the settlement advice.

Each bundle is signed with JWS under the hospital's signing key, and JWE then encrypts it for the receiving participant on the exchange. Every bundle leaves from the platform itself, and none passes through the bridge.

The submission carries the claim's own identifier as its correlation identifier, so a decision that returns later is applied to the claim that asked for it. A decision on a mid-stay enhancement, the request to raise an approved ceiling, returns the same way.

The coding gate

Vault checks a claim's coding before it leaves. It needs a primary diagnosis held in ICD-11 with at least one ICD-10 code derived from it on the platform. A claim to a government scheme also needs the scheme's package code, and Vault refuses a claim that lacks what its payer requires.

The diagnosis is coded once, in ICD-11, as clinical vocabulary explains. Once the payer approves the pre-authorisation, the claim's coding is locked.

The pre-authorisation and the order

Vault relays the claim's pre-authorisation state to the order that waits on it in Forge, and Forge writes that state on its own order. Only a full approval clears the order to move from submitted into work; a query or a partial approval keeps it waiting, and a refusal marks its pre-authorisation denied.

How an order waits at submitted is set out in the order lifecycle.

Decisions and settlement

A payer's decision returns as a FHIR R4 ClaimResponse. Vault applies it to its claim through the same checked transitions a biller's entry would take. It writes the approved amount and records the co-payment and deductible the payer applied.

Vault refuses a decision the claim is not awaiting, and a repeat of one already applied leaves the claim where it stands. A decision that reaches the hospital another way, such as through a payer's own portal, is entered on the claim by a biller and passes the same checks.

Settlement advice returns as a PaymentReconciliation. Vault posts each line to its claim, records a short payment where the payer paid less than claimed, and enters the money as an insurance settlement beside the patient's own payments. The same advice can also be imported, as bulk loads describes.

Settlement feeds the discharge check

A posted settlement is what the discharge finance gate reads when it checks for a payer's settlement. A cashless stay with no claim filed holds the gate until the claim goes in.

Insurers, TPAs and schemes

A participant code identifies a hospital or a payer on the exchange. Each payer in Vault carries its own, and every bundle meant for that payer is addressed with it.

An insurer or TPA that works outside the exchange is set up in Westron as a direct connection, holding its endpoint and the hospital's credential for it. The platform exchanges FHIR R4 with that endpoint over HTTPS, and its claims run on the same record and lifecycle.

Government schemes, PM-JAY among them, are payers in Vault with their own rates and package codes. The payer types and schemes Vault recognises are listed in payers.

Switching the exchange on

The exchange route is switched on for each site by two people. A finance administrator proposes the hospital's participant code, and a different person holding the approval permission approves it. Connecting a cashless claims channel is one of the actions that wait on a second person, as approval and second signature lists.

The participant code, the signing key and the decryption key are the hospital's own, kept as authentication between systems sets out. Until the route is on for a site, Vault shows that the exchange is not set up there, and claims are filed by hand or on paper against the same record.

Common confusions

Can a claim go to the exchange before the patient's ABHA is recorded?

Vault refuses the submission and reports the missing ABHA, because every bundle identifies the patient by ABHA number. The biller sends the claim once the desk has recorded the ABHA, as national digital health describes.

Is a decision applied twice if the exchange sends it twice?

A repeated ClaimResponse finds the claim already in the state it names and leaves it there. A remittance that arrives a second time is recognised by its remittance identifier and skipped.

Does a short settlement move the claim to a new state?

The settlement posts the money and the shortfall. The claim's state follows the payer's ClaimResponse, and a hospital that contests the outcome takes the claim on through dispute, resubmission or appeal.

Read how a claim is assembled and the states it passes through in insurance claims, and how the patient's ABHA is captured in national digital health.