Claim Dispatch

Copy page

Claim Dispatch / Visit End Process Guide: In-patient Claim Dispatch Workflow

1. Overview: Finalising an Inpatient's Discharge and Claim

This guide focuses on the inpatient claim dispatch workflow, which is part of the final stages of the broader claim dispatch and visit end process. The workflow ensures a formal finalisation and checkout for a patient's inpatient stay. Its primary purpose is to guarantee that the patient is officially discharged and that all claim-related data, including special case information, is accurately captured and linked to the final claim.

1.1. What This Workflow Does

The Inpatient claim dispatch workflow's primary function is to formalise an inpatient's discharge from a facility. It achieves this by:

• Confirming the patient's identity via an OTP,
• Processing the discharge itself, and
• Executing a conditional step of collecting next-of-kin contact information if the discharge reason is "DECEASED".

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

Getting an inpatient's discharge process right is key for both clinical accuracy and financial compliance. Without a precise process, several serious issues can arise:

• Inaccurate Records: An incomplete discharge can leave a patient's record in an "open" state.
• Non-Compliant Claims: Claims for deceased patients require next-of-kin documentation, or they risk rejection.
• Audit Scrutiny: Improper discharges may lead to issues during audit reviews.
• Financial Errors: Incomplete claims can lead to payment delays and reconciliation errors.

This workflow ensures compliant inpatient billing with accurate discharge data and procedural integrity.

---

2. Workflow Details: Inpatient Claim Dispatch

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

1. Get Beneficiary's Valid Contacts
   The system retrieves patient contact info using consent_token and is_alive flag.

2. Send OTP
   An OTP is sent to the retrieved contact using:

   • beneficiary_cr_id
   • beneficiary_contact_id
   • consent_token
   • otp_type = discharge

3. Inpatient Discharge
   After OTP verification, the discharge action is performed using:

   • consent_token
   • discharge_date
   • invoice_number
   • discharge_reason

4. Conditional Check
   The system checks whether discharge_reason == DECEASED.

5. Set Next-of-Kin Contacts (if deceased)
   If is_alive = false, the system requires:

   • next_of_kin_full_name
   • next_of_kin_id_number
   • next_of_kin_id_number_type
   • contact_value

6. Confirmation
   The system confirms successful discharge and the completion of required steps.

---

2.2. Key Validations: Our System's Essential Checks

• Valid Discharge Date
  discharge_date cannot be before admission date or in the future.

• Conditional next_of_kin Data
  If discharge_reason == DECEASED, next-of-kin data is required.

• Valid consent_token
  Must correspond to an active inpatient visit.

---

2.3. Workflow Data Dictionary: What Information We Work With

Field Name	Description	Data Type	Required	Purpose
consent_token	Token for patient visit	string	Yes	Authorises finalisation and links to patient encounter
is_alive	Patient alive status	boolean	Yes	Determines contact retrieval logic for OTP
beneficiary_cr_id	Client registry ID	string	Yes	Identifies the beneficiary
beneficiary_contact_id	ID of the patient’s contact	string	No	Specifies the contact for OTP
otp_type	Should be set to discharge	string	Yes	Defines OTP context
discharge_date	Date of discharge (not before admission or in future)	ISO 8601	Yes	Sets the patient’s discharge timestamp
invoice_number	Invoice reference from provider	string	Yes	Links the discharge to a specific claim
discharge_reason	Reason for discharge: RECOVERED, REFERRED, DECEASED, etc.	string	Yes	Used for logic branching and compliance
next_of_kin_full_name	Full name of next-of-kin	string	Conditional	Required if discharge_reason == DECEASED
next_of_kin_id_number	ID number of next-of-kin	string	Conditional	Required if discharge_reason == DECEASED
next_of_kin_id_number_type	ID type (e.g. National ID, Alien ID)	string	Conditional	Required if discharge_reason == DECEASED
contact_value	Active phone number of next-of-kin	string	Conditional	Required if discharge_reason == DECEASED

---

2.4. Expected Outcomes from this Workflow

• Success:
  Patient is successfully discharged; all required steps completed.

• Failure: Incorrect OTP
  OTP verification failed.

• Failure: Missing Conditional Data
  discharge_reason == DECEASED but next-of-kin info not provided.

• Failure: Invalid Discharge Date
  Discharge date is before admission or in the future.

• Failure: Missing Required Data
  Any required field (e.g., consent_token, discharge_reason) is missing or malformed.