Healthcare Financial Services IG Edition 1 - Local Development build (v0.3.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Batch Claims

Overview

This use case enables healthcare providers (HCPs) to submit a batch of claims for a single insurer to permit the insurer, or TPA, to adjudicate the claims under the patient’s policy and to return the results of that adjudication to the provider which may in turn provide that information to the patient. This use case supports a non-real-time submission of a group of claims where nphies will validate the claims and return a batch of Claim response messages indicating errors or acknowledgement of receipt. The claims are later send to the insurer for processing where the insurer will respond individually with deferred claim responses which the provider can retrieve the valid response via Polling. For the real-time submission of an individual, single, claim to the insurer or TPA see the Claim use case.

Workflow

1. Provider sends an Batch Request Message to the nphies system.
2. nphies validates the message and if valid proceeds to Step 3 and return errors, otherwise proceeds to Step 2.
   • nphies extracts the claims from the batch;
   • validates each claim message;
   • constructs a Claim Response Message; and.
   • if for each valid Claim Request Message stores the request in the queue for delivery to the insurer ro TPA.
3. nphies returns a Batch Response Message with a bundle containing the requested messages, or errors to the provider.

This is a REAL TIME use case in that nphies will burst the batch, extract and validate all message bundles within the batch and respond with a batch of Claim Response Messages in real-time, however, the valid claims within the batch will be queued for later transmission to the insurer or TPA.

Message Structures

Batch Request Message

The key resources for the message are provided below and all require nphies-profiled resources as provided in the Artifacts. Note: the MessageHeader resource must be the first .entry in the bundle and any other resources may follow in any order.

Nphies Bundle (.type = message )
  Nphies MessageHeader (.eventCoding = batch-request)
  Nphies Claim Request Bundle (Claim Request #1)
  [Nphies Claim Request Bundle (Claim Request #2)]
  ...  

Batch Response Message

The key resources for the message are provided below and all require nphies-profiled resources as provided in the Artifacts. Note: the MessageHeader resource must be the first .entry in the bundle and any other resources may follow in any order.

Nphies Bundle (.type = message )
  Nphies MessageHeader (.eventCoding = batch-response)
  Nphies Claim Response Bundle (Claim Response #1)
  [Nphies Claim Response Bundle (Claim Response #2)]
  ...  

Guidance

• Batch Target:All claims within a Claim batch SHALL be intended for the same insurer and/or TPA.

• Batch Size: The Batch SHALL not contain more than 200 individual claims and SHALL not exceed the maximum message size.

• Batch Claim Submission: Claims may be submitted individually or as part of a batch (see Batch Claim use case). While providers may group multiple claims into a single batch for submission, each claim is adjudicated independently by the insurer. Claims submitted in batches are not processed by insurers in real-time, nphies validates and responds in real-time with validation ClaimResponses but transmits these claims in the background to the insurers and TPAs. The payer issues separate deferred ClaimResponse messages for each claim in the batch.

• Batch Claims Extensions: Each claim in a batch SHALL supply the extensions: Claim Batch Identifier; Claim Batch Number; and, Claim Batch Period. ClaimResponses to claims submitted in batches SHALL also include the claim batch extensions submitted on the respective Claim to assist the provider in aligning the response to the request.

• Individually submitted Claims: Claims submitted individually, that is not submitted as part of a batch, will be processed by nphies as a real-time message. They SHALL be forwarded by nphies to the insurer or TPA in real-time when possible and the insurer’s or TPA’s response, should it be: errors, acknowledgement of receipt, partial or complete adjudiction SHALL be returned in real-time to the provider, if possible.

See the Claim Submission Guidance for guidance on the requirements for the individual claims messages contained within a Claim Batch.

See also the general Authorization and Claims guidance in the Usecase Overview.

Full Message Examples

Error Handling

If nphies detects errors in the request message such that the request cannot be processed then the response message will contain an OperationOutcome resource rather than a business-level Poll Response resource. Otherwise if nphies detects errors within the request it will return a Poll Response with errors (Task.output.type = ‘error’) and an extension indicating where the error occurred.

Like all other response messages the provider receives from nphies, if there are other messages queued at nphies which have not been delivered to the provider then this will be reflected in the presence of a MessageHeader.meta.tag.