Start Visit Consent

Copy page

Start Visit Process Guide: Pre-Start Visit Workflow

Start Visit Process Guide: Pre-Start Visit Workflow

1. Overview: Preparing for a Valid Patient Encounter

This guide focuses on the Pre-Start Visit Workflow, a crucial step in the broader Start Visit Process. This workflow acts as a start-visit checklist, verifying that all conditions are met before a patient's visit can officially commence. Its primary role is to conduct a series of internal checks, validating that a proposed visit contains all necessary information and strictly adheres to the rules set by the Social Health Authority (SHA) for a valid encounter between the patient and the healthcare facility.

1.1. What This Workflow Does

The Pre-Start Visit Workflow's primary function is to perform required validations that determine if a visit is ready to be initiated. It accomplishes this through the following core actions:

• Reviewing Visit Information: The workflow meticulously examines the complete data intended for the visit, checking it for both completeness and accuracy of format.
• Preventing Resource Wastage: By conducting these critical upfront checks, the workflow actively prevents wasted resources, such as the unnecessary sending of One-Time Passwords (OTPs), if the visit conditions are not met. If checks fail, it prevents progression to the Send OTP Workflow.
• Checking for Parallel Active Visits: The workflow ensures that no conflicting or concurrent active visits exist for the same patient, upholding SHA's "one active visit" rule.
• Applying SHA Rules: It cross-references all proposed visit details against the specific, detailed rules set by the Social Health Authority (SHA) for initiating valid healthcare encounters. This includes vital checks like ensuring only one active visit per patient and preventing the mixing of inpatient and outpatient interventions within the same visit.

1.2. Why This Workflow Is Critical

This workflow is vital because it acts as a critical quality check for every patient visit. Without these essential preliminary checks, healthcare facilities could accidentally initiate invalid visits, leading to significant problems downstream:

• Reduces number of Invalid Claims: By ensuring visits meet SHA standards upfront, this workflow is key to helping facilities avoid rejected claims for services rendered.
• Ensures Compliance: It strictly enforces adherence to regulatory requirements and SHA guidelines, significantly reducing the risk of non-compliance.
• Optimises Workflow and Process Efficiency: By catching errors or conflicts early in the process, it prevents wasted effort, time, and resources in later stages for visits that were essentially invalid from the start.
• Improves Data Accuracy: It plays a crucial role in maintaining the integrity and reliability of visit claims by actively preventing duplicate, improperly formatted, or non-compliant encounters from being created in the system.

In short, this workflow ensures that every patient encounter begins on a solid, compliant, and accurate foundation, paving the way for smooth and successful service delivery and efficient claims processing.

2. Workflow Details: Pre-Start Visit

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

Once beneficiary contact information is validated (from the Get Beneficiary's Valid Contact Workflow) and the patient is ready to proceed with a visit, here's where the pre-visit checks come in:

1. Input Reception: The system receives the necessary preliminary data for the proposed visit. This includes the beneficiary_cr_id (Client Registry ID), the beneficiary_contact_id, the service_type (e.g., "INPATIENT"), the list of interventions to be provided, and other relevant information that will constitute the visit's complete "payload."

2. Payload Completeness & Format Check: The system first verifies that all mandatory fields within the proposed visit's payload are present and that their formats align with the expected data types and structures.

3. SHA Rule Compliance Check: The system then applies various specific rules set by the Social Health Authority (SHA) for visit initiation. This might include:

• Active Visit Duplication Check: Querying claims to ensure that the patient does not currently have another similar active visit already in progress at the same or a conflicting facility.
• Intervention Combination Check: Verifying that the proposed interventions are an acceptable combination according to SHA rules (e.g., ensuring inpatient and outpatient interventions are not mixed within the same visit).
• Capitation rule Check: For interventions using capitation as their payment mechanism, the system confirms that the patient is involved in only one such visit per day, preventing over-utilisation of capitation funds.

4. Outcome: Based on the results of all these rigorous checks, the system determines the pre-visit check has passed or explains any issues found.

2.2. Key Validations: Our System's Essential Checks

These are the critical checks our internal 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.

Complete and Valid Visit Payload Data:

• All the information required to initiate a visit (e.g., beneficiary_cr_id, service_type, interventions, and other relevant details) must be provided, correctly formatted, and non-empty where required. This workflow relies on a complete and valid dataset to conduct proper and comprehensive checks. Missing or malformed data will inevitably lead to failed validations, preventing the progression to the Send OTP Workflow and ultimately preventing a valid visit from being created.

No Similar Active Visit for the Patient:

• The system checks that the patient does not currently have another active visit that would conflict with the newly proposed visit. This rule is key in preventing duplicate visit claims, which can cause significant billing errors and lead to compliance issues with SHA.

Acceptable Intervention Combinations:

• The system verifies that the specific combination of interventions selected for the visit adheres to the rules and guidelines set by SHA. Non-compliant combinations can lead to rejected claims and operational inefficiencies. For example, it is not allowed for an inpatient and outpatient intervention to be recorded under the same visit.

One Visit per Day for Capitation Interventions:

• For interventions whose payment mechanism is capitation, the system checks to ensure that the specific patient is involved in only one such visit per day. This validation is critical for compliance with SHA's capitation rules. It prevents over-claiming or overstretching the pool of funds available through capitation for providing Universal Healthcare (UHC) schemes, ensuring fair and sustainable resource allocation.

2.3. Workflow Data Dictionary (Conceptual): What Information We Work With

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	Description	Data Type	Options	Required	Purpose
Beneficiary Client Registry ID	The unique identifier of the beneficiary associated with the patient. This ID is carried forward from the Get Beneficiary's Valid Contact Workflow.	String	N/A	Yes	This is the identity key for the beneficiary whose visit is being prepared. It allows the system to link the proposed visit to the correct beneficiary's record for all subsequent checks.
Service Type	The broad classification of the healthcare service for the visit (e.g., "INPATIENT").	String	INPATIENT, OUTPATIENT, CAPITATION, EMERGENCY	Yes	This provides the context for the visit. Different SHA rules and active visit checks apply based on the general type of service being sought.
Interventions	A list of all the specific interventions selected to start the visit.	Array	N/A	Yes	This shows the specific services to be offered under the visit. It's critical to check them against the rules for a valid visit as set by SHA, especially concerning acceptable combinations and capitation visit limits.
Beneficiary contact ID	This is the identifier of the beneficiaryʼs contact chosen. If not selected, it selects the default contact from the client registry	String	N/A	No	It helps identify the contact that will be used for OTP

2.4. Expected Outcomes from this Workflow

When you query this workflow, here's what you can expect in return:

Success: Visit Ready for Initiation:

• The system confirms that the proposed visit passed all preliminary checks, including data completeness, no active visit conflicts, acceptable intervention combinations, and compliance with all SHA rules. The visit can now proceed to the next stage in the Start Visit Process (specifically, the Send OTP Workflow), as it has been validated as compliant.

Failure: Duplicate Active Visit Detected:

• The system identified that a similar active visit for the same patient is already in progress, violating SHA's rules. The new visit cannot be initiated. The user needs to investigate and address the existing active visit (e.g., by completing it) before re-attempting the new visit.

Failure: Missing or Invalid Payload Data:

• Essential information required for the visit (e.g., service_type, missing beneficiary_cr_id, or malformed interventions list) was either missing or provided in an incorrect format. The visit cannot be initiated due to incomplete or malformed data. The user must correct and resubmit the complete and accurate visit payload.

Failure: Unacceptable Intervention Combination:

• The system detected that the selected list of interventions for the visit is not allowed under SHA's rules (e.g., mixing INPATIENT and OUTPATIENT services in one visit). The visit cannot be initiated as it violates SHA's service combination guidelines. The user must adjust the selected interventions to comply.

Failure: Capitation Visit Limit Exceeded:

• The system found that initiating this visit would exceed the "one visit per day" rule for interventions under the capitation payment mechanism for this specific patient. The visit cannot be initiated under capitation for this day. The user may need to seek alternative payment methods or re-evaluate the timing of the visit.

3. Critical Success Factors for Pre-Start Visit Integration

For your integration with the Pre-Start Visit Workflow to be successful (and by extension, the entire Start Visit Process), keep these key points firmly in mind:

• Provide Complete and Valid Payload: Always ensure that all the data elements required for the proposed visit (beneficiary_cr_id, service_type, and the interventions list) are fully populated and strictly conform to expected formats and data types. Incomplete or malformed data will inevitably lead to validation failures.
• Understand SHA Visit Rules Deeply: Familiarise yourself conceptually with the Social Health Authority's (SHA) specific rules regarding valid visits. Pay close attention to nuances like active visit conflicts, permissible intervention combinations within a single visit, and any capitation-specific limits. Your system should pre-validate against these rules, where possible, to minimise rejections.
• Design for Proactive Error Handling: Your system must be designed to gracefully receive and interpret error messages from this workflow. If a check fails, clearly inform the end-user about the specific reason (e.g., "Duplicate active visit detected," "Incompatible intervention mix") so they can understand and correct the input or take alternative action before attempting to proceed.