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, two methods are supported: a One-Time Password (OTP) sent to the patient's registered contact, or a biometrics authorization via fingerprint matching.

1.1. What This Workflow Does

The Outpatient claim dispatch workflow's main function is to formalise an outpatient's visit conclusion. It supports two consent methods:

OTP path:

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

Biometrics path:

• Calling POST /api/v1/claims/authorize with biometrics fields to create a PENDING authorization
• Rendering the iframe so the patient can match their fingerprint, transitioning the authorization to AUTHORIZED
• Performing the "Outpatient Visit End" action using auth_guid instead of otp_code

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. Obtain Visit-End Consent

   Option A: OTP The system sends a unique OTP to the contact using:

   • beneficiary_cr_id
   • beneficiary_contact_id
   • consent_token
   • otp_type = discharge

   Option B: Biometrics As an alternative to OTP, consent can be obtained via biometrics:

   • Call POST /api/v1/claims/authorize with biometrics-specific fields, including the workstationID from the biometrics hardware server and the biometrics agent's National ID. The authorization is created in PENDING status and the response includes an iframe link.
   • Render the iframe so the patient can match their fingerprint. On a successful match, the authorization transitions from PENDING to AUTHORIZED.
   • In the visit-end call (step 3), include auth_guid (the GUID of the AUTHORIZED authorization) instead of otp_code.

3. Outpatient Visit End The system finalises the visit and prepares the claim for dispatch using otp_code (OTP path) or auth_guid (biometrics path).

---

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.

• Biometrics Authorization Status (biometrics path) The auth_guid must correspond to an AUTHORIZED authorization. PENDING or expired authorizations will be rejected.

• 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	Conditional	Confirms patient consent to end the visit (OTP path).
auth_guid	GUID of an AUTHORIZED biometrics authorization.	string	Conditional	Used instead of otp_code when biometrics consent was used for visit end.

---

2.4. Expected Outcomes from this Workflow

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

• Success: Visit Ended with Biometrics The biometrics authorization is confirmed as AUTHORIZED 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: Invalid or Pending Biometrics Authorization The auth_guid does not correspond to an AUTHORIZED authorization.

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

---

3. Related Guides and Scenarios

• Scenario 4: SHIF OP FFS Elective Preauth
• Scenario 5: SHIF OP FFS Normal Preauth
• Scenario 6: UHC OP Capitation