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

Claim Submission

Overview

This use case enables healthcare providers (HCPs) to submit claims on behalf of patients to their insurer(s) to permit the insurer, or TPA, to adjudicate the claim 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 real-time submission of an individual, a single, claim to the insurer or TPA. For the submission of a batch of claims see the Claim Batch use case.

Workflow

1. Provider sends a Claim Request Message to the nphies system.
2. nphies validates the request and, if valid, proceeds to Step 3. Otherwise, it generates an error response.
3. nphies forwards the request to the designated insurer or TPA.
4. The insurer or TPA adjudicates the request and returns a Claim Response Message.
5. nphies validates the response and, if valid, proceeds to Step 6; otherwise, an Error Notice Message is generated.
6. nphies returns the Claim Response Message with approval, denial, or additional information requests, or errors, to the provider.

Claims can be processed as real-time transactions or non-real-time transactions, depending on the insurer's adjudication capabilities:

• Real-Time Transactions: When automatic adjudication is possible, the insurer immediately processes the Claim request and returns an approval, denial, or request for additional documentation within the same session.
• Non-Real-Time Transactions: If manual review is required, the insurer validates the request, returning errors (outcome=’error’) if invalid, or places the request in the insurer’s queue and responds with an Claim Response Message indicating that the request is queued (outcome=’queued’). The insurer may respond later with partial adjudication results (outcome=’partial’) but generally will only respond with the final response (outcome=’complete’) once the adjudication is completed.
• If nphies is unable to deliver the request to the insurer, or TPA, then nphies will pend the request for later delivery to the insurer, or TPA, and generate a response to the provider indicating that the request was received without errors, as far as nphies could detect, and that nphies will deliver the Claim Request to the insurer once the exchange issue is resolved.

• In the event that nphies is not able to successfully deliver the Claim Request Message to the HIC within less than one minute, or nphies generates a ‘pended’ message or an error message as documented above, then nphies will generate a response message, with a bundle.meta.tag to identifiy that the message has been issued by nphies, see Meta Tag: nphies-generated.

• Delayed responses, those not issued directly in the same session as the request, are stored on nphies and, if not containing errors detected by nphies, are stored (pended) for the provider. The provider can retrieve the valid response via Polling.

Message Structures

Claim 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 = claim-request)
  One of the following Claim profiles:
     Nphies Claim Institutional
     Nphies Claim Oral
     Nphies Claim Pharmacy
     Nphies Claim Professional
     Nphies Claim Vision
  Nphies Coverage
  Nphies Patient
  Nphies Organization (Provider)
  Nphies Organization (Insurer)
  Nphies Practitioner
  One of the following Encounter profiles based on the Claim profile selected above: 
     Nphies Encounter Claim AMB (Ambulatory)
     Nphies Encounter Claim EMER (Emergency)
     Nphies Encounter Claim HH (Home Healthcare)
     Nphies Encounter Claim IMP (In-Patient)
     Nphies Encounter Claim SS (Day Case)
     Nphies Encounter Claim VR (Telemedicine)
  [any additional resources]

Claim 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 = priorauth-response)
  Nphies Claim Response
  Nphies Coverage
  Nphies Patient
  Nphies Organization (Provider)
  Nphies Organization (Insurer)
  [Nphies CommunicationRequest]
  [any additional resources]

Guidance

There are five types of claim handled within the nphies system:

1. Institutional Claim – Used for hospital-based services such as inpatient admissions and surgical procedures.
2. Professional Claim – Required for outpatient physician services, consultations, and diagnostic procedures.
3. Pharmacy AClaim – Necessary for prescription medications that require approval before dispensing.
4. Dental Claim – Required for major dental procedures, such as orthodontics or surgeries.
5. Vision Claim – Used for optical services, including corrective lenses and eye surgeries.

Each type of claim follows a similar request-response pattern but may have specific extensions or required data elements.

Claims are immutable packages of information, they cannot be changed to alter, amend or add content. If the content of the claim needs to be changed then the provider SHALL first cancel the claim, see the Cancellation use case, then once cancelled submit a new claim with the amended information.

In order to supply additional supporting information for a claim when the contents of the claim itself do not need to be altered the provider may send a separate Information Submission message.

• Providing Eligibility: Providers SHALL provide information about the Eligibility Check if one was performed prior to the authorization or claim. This information is provided through the Eligibility Response extension if the check was performed online via the Eligibility use case or if eligibility checking was done manually, for example on a portal or over the phone, via the Eligibility Offline Reference extension and the Eligibility Offline Date extension.

• 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.

• Providing Authorization: Providers SHALL provide information about the authorization if one was performed prior to the claim. This information is provided through the Authorization Response extension if the check was performed online via the Authorization use case or if authorization was done manually, for example on a portal or over the phone, via the Authorization Offline Date extension.

• Episode of Care: All claims related to the same patient episode (e.g., admission, discharge, follow-up) must use the same episode identifier using a defined FHIR extension.

• Patient Invoice: Each claim item SHALL include an invoice number extension to support deduplication and traceability.

• Partial Adjudication: If the payer partially approves or rejects (pays zero) a service due to insufficient information, then the provider may send to the payer an Information Submission(TODO add link) which references the authorization or claim and includes the supporting information. The payer may then issue a new adjudication response message, ClaimResponse, with their revised adjudication and with an extension containing a reissue-reason code.

• Prior Authorization Reference: Providers must include one or more .preAuthRef references under Claim.insurance when applicable.

• SupportingInfo – Days Supply: Required for outpatient medications using the 'days-supply' category code (see the days-supply slice on supportingInfo). Not required for inpatient items.

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

Cancelling the Claim

A provider may need to cancel a claim if, for example, some information is missing, such as services rendered during the same treatment session, or some of the information is determined to be incorrect such as wrong eye or tooth or product or service code. As long as it does not contain errors the provider SHALL issue a cancel-request for the previously sent claim, regardless of whether it has been completely adjudicated, with the identifier of the claim in the Task.focus element.

Resubmitting Claims

To resubmit a Partially Approved or Rejected Claim: Submit a new claim request where:

• Claim.related.claim = Business Identifier of the original claim

• Claim.related.relationship = 'prior'

Also include all services to be adjudicated (even previously approved ones) and send any additional supporting information to justify medical necessity.

This process will initiate re-evaluation of the full set of services under a new claim referencing the original.

Episode of Care

From a business perspective, the HIC requires the episode of care identifier from the provider in order to identify multiple claims for the same episode of care. If the patient has multiple visits for different services within the same episode of care, the rendered services can be claimed separately sharing the same episode of care identifier. For example:

• The patient was admitted on 20th of November. A claim is issued at the end of the month.
• The patient was discharged on 15th of December. Another claim is sent after the discharge.
• A follow-up visit with the physician was on December 19th and a claim issued for the service.

All three claims will report the same episode of care identifier, so the payer will be able to link all the claims within the same episode of care. The below extension SHALL be added and applied as mandatory to all types of claims at the Claim level:

{ 
  “extension”: { 
    “url”: “http://nphies.sa/fhir/ksa/nphies-fs/StructureDefinition/extension-episode”, 
    “valueIdentifier”: { 
         “system”: “[BaseURL]/extension-episode”, 
         “value”: “episode123ABC” 
    } 
  } 
}

Patient Invoice

The HIC & HCP need to identify the patient invoice number for line item to detect duplication and for other purposes. The below extension will be added and applied as mandatory to all types of claims at the Claim.item level. For example:

{ 
  “extension”: { 
    “url”: “http://nphies.sa/fhir/ksa/nphies-fs/StructureDefinition/extension-patientInvoice”, 
    “valueIdentifier”: { 
        “system”: “[BaseURL]/patientInvoice”, 
        “value”: “ABC123” 
    } 
  }
}

Full Message Examples

Key Extensions

Error Handling

If nphies or the Insurer, or TPA on behalf of an insurer, 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 response message.

Similarly, if the nphies system times-out on passing the request message to the Insurer/TPA or times-out on receiving a valid response from the Insurer/TPA or receives an invalid response from the Insurer/TPA then the nphies system will return either a business message with errors or a message with an OperationOutcome to indicate the nature of the error. If the response message is issued by nphies rather than the Insurer/TPA then a Bundle.meta.tag will be included to document that.

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. These queued messages may be retrieved by the provider at their convenience, see Polling for guidance on Polling and Pended Message retrieval.