Claim Dispatch

Copy page

Claim Dispatch / Visit End Process Guide: Outpatient Claim Dispatch Workflow

1. Overview: Finalising an Outpatient's Visit and Claim

This guide outlines the Outpatient claim dispatch workflow, which is the final step in our comprehensive Claim Dispatch/Visit End process. It serves as a final verification and checkout for a patient's outpatient visit. The primary purpose of this workflow is to ensure that a patient's visit is officially closed and that the claim is ready for dispatch. To obtain explicit patient consent for the end of the visit, we utilise a One-Time Password (OTP).

1.1. What This Workflow Does

The Outpatient claim dispatch workflow's main function is to formalise an outpatient's visit conclusion. It does this by:

• Retrieving the beneficiary's contact details
• Sending an OTP to that contact
• Verifying the OTP
• Performing the "Outpatient Visit End" action

1.2. Why This Workflow Is Critical (The "Why It Matters")

Finalising an outpatient visit correctly is essential for claim integrity and patient trust. Without a precise, patient-verified process, several risks arise:

• Unverified Claims: Claims submitted without patient confirmation may be disputed or rejected.
• Billing Discrepancies: Incomplete visit closures can cause inaccuracies in patient records.
• Lack of Patient Trust: Verifying the visit end with an OTP increases trust and transparency.

This workflow ensures every outpatient claim is backed by patient-verified consent.

---

2. Workflow Details: Outpatient Claim Dispatch

2.1. Workflow Description: Step-by-Step System Behavior

1. Get Beneficiary's Valid Contacts
   The system retrieves the patient's valid contact info using:

   • consent_token
   • is_alive flag (to determine which contact to use)

2. Send OTP
   The system sends a unique OTP to the contact using:

   • beneficiary_cr_id
   • beneficiary_contact_id
   • consent_token
   • otp_type = discharge

3. Outpatient Visit End
   Once the patient provides the correct otp_code, the system finalises the visit and prepares the claim for dispatch.

---

2.2. Key Validations: Our System's Essential Checks

• Valid Beneficiary Contacts
  The system must retrieve a valid contact (phone/email). Without one, it cannot send the OTP.

• OTP Match
  The provided otp_code must match what was sent. This confirms the patient's consent to end the visit.

• Valid consent_token
  It must correspond to an active outpatient visit.

---

2.3. Workflow Data Dictionary: What Information We Work With

Field Name	Description	Data Type	Required	Purpose
consent_token	The consent token for the patient visit.	string	Yes	Authorises and links action to a specific visit.
is_alive	Whether the patient is alive.	boolean	Yes	Determines which contacts to use for OTP.
beneficiary_cr_id	Client registry ID from eligibility check.	string	Yes	Identifies the patient in the client registry.
beneficiary_contact_id	ID of the contact (defaults to main contact).	string	No	Indicates which contact receives the OTP.
otp_type	OTP context – should be "discharge"	string	Yes	Defines the purpose of the OTP.
otp_code	The OTP provided by the beneficiary.	string	Yes	Confirms patient consent to end the visit.

---

2.4. Expected Outcomes from this Workflow

• Success: Visit Ended with OTP
  The OTP is verified and the outpatient visit is officially ended.

• Failure: No Valid Contacts
  The system cannot send the OTP due to missing contact info.

• Failure: Incorrect OTP
  The provided OTP does not match what was sent.

• Failure: Missing Required Data
  Any required field (consent_token, otp_code, etc.) is missing or malformed.