Start Visit Process Guide: Get Beneficiary Valid Contact
Start Visit Process Guide: Get Beneficiary Valid Contact Workflow
1. Overview: Retrieve and Validate the Beneficiaryʼs Contact Details
This guide focuses on the Get Beneficiary's Valid Contact Workflow, a foundational step in our broader Start Visit Process. This workflow's primary role is to retrieve and validate the crucial contact information associated with a patient's beneficiary. It confirms if the beneficiary is an active SHA member and possesses a valid phone number, which is an essential prerequisite for sending consent One-Time Passwords (OTPs). For cases involving deceased beneficiaries, it prioritises displaying next-of-kin contacts, and for minors, it ensures the provision of valid parent or guardian contact details.
1.1. What This Workflow Does
The Get Beneficiary's Valid Contact Workflow's primary function is to securely obtain and validate the accurate contact details of a specific beneficiary. It achieves this by:
- Identifying the Beneficiary: Using the provided beneficiary_cr_id (Client Registry ID) linked to the patient seeking services, it can identify the beneficiary from data from the Client Registry (CR)
- Determining Relevant Contacts: For patients who are minors or dependents of a deceased beneficiary, it identifies and prioritises the contact information of the designated parent/guardian or next of kin, respectively.
- Retrieving Comprehensive Details: Accessing all registered information for that beneficiary, including their active membership status with SHA.
1.2. Why This Workflow Is Critical
Getting the beneficiary's contact information precisely correct from the start is important for initiating a valid and compliant patient visit claim. This workflow is critical because it:
- Enables Secure Consent: Ensures that consent OTPs, which are vital for verifying a patient's presence and agreement to services, are sent to the correct and authorised individual (the beneficiary, parent/guardian, or next of kin). This prevents unauthorised consent and potential fraud.
- Confirms Valid Membership: Verifies that the beneficiary is a valid, active member registered under SHA. This is a foundational check for all subsequent financial and service-related processes.
- Facilitates Crucial Communication: Provides reliable contact points for any necessary follow-up or emergency communication related to the patient's visit.
- Supports Compliant Claiming: By confirming the accuracy of beneficiary contacts, it strengthens the position for healthcare facilities to make legitimate claims for services provided to SHA.
This workflow ensures that all subsequent steps of the Start Visit Process, especially consent and communication, are built upon accurate and verified information.
2. Workflow Details: Get Beneficiary Valid Contact
2.1. Workflow Description
When eligibility checks are completed and a patient is ready to receive a medical intervention, triggering the start of a visit, here's the internal process that unfolds for contact retrieval:
-
Input Received: The system receives the patient's client_registry_id, which is either the beneficiary's beneficiary_cr_id or, if the patient is a dependent, it gets the beneficiary_cr_id, which is that of the primary contributor.
-
Beneficiary Data Fetching: Using the provided beneficiary_cr_id, it securely fetches the comprehensive profile and all registered contact details of that specific beneficiary from the central client registry.
-
Phone Number Validation: From the retrieved contact details, it checks for the presence of at least one valid and active phone number associated with the beneficiary. This number is flagged for OTP delivery.
-
Output: The validated contact details of the beneficiary are provided.
2.2. Key Validations: Our System's Essential Checks
There are some essential checks our system performs behind the scenes to ensure a successful and accurate execution of this workflow. Understanding these helps you provide the correct information from your end, preventing errors.
Valid Beneficiary Client Registry ID:
- The beneficiary_cr_id provided must be a valid, existing, and correctly formatted identifier recognised by the Client Registry.
- This ID is the absolute foundation for accessing any beneficiary information. It serves as the single source of truth for accurate and up-to-date client data.
- Without a valid CR ID, the system cannot uniquely identify the beneficiary, making it impossible to retrieve their details or check their SHA membership.
Presence of at Least One Valid Phone Number:
- After fetching beneficiary details, the system verifies that at least one functional phone number is registered and available for communication.
- A valid phone number is critical for the subsequent Send OTP Workflow, which relies on sending an OTP to this number for explicit patient/beneficiary consent. Without it, the consent process cannot be completed, preventing the start of a visit.
Correct Contact Identified for Minors/Deceased Dependents:
- For patients identified as minors or dependents of deceased beneficiaries, the system must accurately identify and provide the contact information of their registered parent/guardian or next of kin, respectively.
- This ensures that consent for the visit is sought from the appropriate and authorised individual, which makes it compliant for a valid healthcare encounter.
2.3. Workflow Data Dictionary
This table helps you understand the key pieces of information this workflow uses, whether they're required, and the conceptual format our system expects.
| Field Name (Conceptual) | Description | Data Type (Conceptual) | Required | Purpose / What it Means (to the Business) |
|---|---|---|---|---|
| Beneficiary Client Registry ID | The unique identifier of the beneficiary associated with the patient. This could be the patient's own CR ID if they are the primary beneficiary, or the CR ID of their parent/guardian. | String | Yes | This is the identity key that tells our system which beneficiary we need to retrieve details for. It's the primary input to pull all their registered information, including contact details and membership status. |
2.4. Expected Outcomes from this Workflow
When you query this workflow, here's what you can expect in return:
Success: Beneficiary Found & Valid Contact Retrieved:
- One successfully identifies the beneficiary, retrieves their contact details (including a valid phone number), and identifies relevant next-of-kin/parent/guardian contacts if applicable. This sets the stage for the next step in the Start Visit Process.
Failure: Beneficiary Not Found:
- The provided beneficiary_cr_id does not correspond to any valid beneficiary record in the system. The visit cannot be initiated under this beneficiary. The user may need to re-verify the identification details.
Failure: No Valid Phone Number Found:
- The beneficiary record is found, but no valid or active phone number is registered for them (or their next of kin/guardian for minors/deceased dependents). The OTP consent workflow, therefore, cannot proceed.
3. Critical Success Factors for Get Beneficiary Valid Contact Integration
For your integration with the Get Beneficiary Valid Contact Workflow to be successful, keep these key points firmly in mind:
- Provide Valid Client Registry ID: Always ensure you provide a correct and validated beneficiary_cr_id. This is the single most critical input; any error here will halt the process.
- Plan for Missing Contacts: Design your system to handle scenarios where a beneficiary might not have a registered phone number.