Preauthorizations

Copy page

Preauths Process Guide: Optical Preauth Workflow

1. Overview: Authorising Optical Interventions and Items

This guide details the Optical Preauth Workflow, a specialised preauth form which is part of the broader Preauths Process. This workflow is specifically designed to facilitate the submission of pre-authorisation requests for Optical interventions (such as eye examinations, corrective lenses, frames, and other optical aids) that require prior approval from the Social Health Authority (SHA) for payment.

An optical preauth is a type of elective preauth, and therefore, this workflow ensures that patients needing optical services receive necessary prior approval, providing financial assurance and enabling the appropriate and compliant utilisation of these services.

2. Workflow Details: Submitting an Optical Preauth

This section details the step-by-step process for submitting an optical pre-authorisation request.

2.1. Step-by-Step System Behavior

1. Input Reception: The system receives the consent_token for the patient's active visit, the intervention_code for the optical procedure, clinical_indications, new_or_replacement, lens_prescription, consultation_amount, consultation_description, eye_examination_amount, eye_examination_description, frame_amount, frame_description, lens_amount, lens_description, necessity_of_service, arrays of doctors, items, diagnoses, and attachments.

2. Authorization and Visit Context Check: The system uses the provided consent_token to validate that the patient has a valid, active visit and that consent is still active. This also includes confirming the patient is in an active state.

3. Optical Preauth Request Validation: The system performs comprehensive and specific checks on the incoming data and the context of the request, as per SHA's rules for optical procedures (which fall under Elective Preauths). Therefore, elective preauth validations are considered. However, Optical Specific Mandatory Fields are checked, such as clinical_indications and necessity_of_service.

4. Submit Optical Preauth Request to SHA: If all validations pass, the system compiles the complete optical pre-authorisation request payload and submits it to SHA's preauth service.

5. Receive SHA Response: The system receives and processes the response from SHA, which indicates the submission status (e.g., success, failure, pending review).

2.2. Key Validations

These are the critical checks performed during this workflow to ensure the accurate and compliant submission of a surgical pre-authorisation request. Optical preauths align with the validation rules for elective procedures, hence the validations remain the same.

2.3. Workflow Data Dictionary

This table outlines the key information used and produced by this workflow for an Optical preauth.

Field Name	Info	Options (if applicable)	Is required?	Type
consent_token	The consent token for the patient visit.		True	string
intervention_code	This should be the unique identifier for the intervention we want to do a preauth request for. You should only select the intervention that needs_a_preauth. You can know this from the previous intervention coverage response.		True	string
clinical_indications	The clinical indications.		True	string
new_or_replacement	Confirms if this is a new request or a replacement request	New, Replacement	False	string
lens_prescription		Framed, Contact	False	string
consultation_amount			False	string
consultation_description			False	string
eye_examination_amount			False	string
eye_examination_description			False	string
frame_amount			False	string
frame_description			False	string
lens_amount			False	string
lens_description			False	string
necessity_of_service	Brief Description of necessity for service.		True	string
doctors	The Attending Doctors/Clinical Officers' consent. This is an array of the doctors you need approval from.		True	array
items	This will be an array of items in the preauth request.		True	array
diagnoses	This will be an array of diagnoses in the preauth request.		True	array
attachments	This will be an array of attachments in the request.		False	array
status	The outcome of the preauth submission (e.g., "Success", "Failed").		Output	Indicates whether the optical preauth request was successfully submitted to SHA.
message	A descriptive message about the outcome, including any error details.		Output	Provides detailed feedback, especially in case of failure, to aid in troubleshooting.
preauth_id	A unique identifier for the submitted preauthorization request (if successful).		Output	A reference ID for tracking the optical preauthorization request within SHA's system.

Some items in the general workflow dictionary have their own specific workflow dictionaries. Below is the list that applies to this particular preauthorization.

2.3.1. Preauth Doctor

This component represents the details of a doctor or clinical officer whose consent is required for a pre-authorisation.

Field Name	Info	Options (if applicable)	Is required?	Type
identification_number	The unique ID for's choices. Defaults to KMPDC.	KMPDC, COC, NCK	True	string
intervention_code	The intervention code is associated with the doctor's consent.		True	string
name	The client registry ID from the previous eligibility call (This might be a generic description; in context of items, likely item name).		True	string

2.3.2. Preauth Items

This component represents the individual billable items or sub-services included within a pre-authorisation request.

Field Name	Info	Options (if applicable)	Is required?	Type
unit_price	The unit price charged for this item.		True	float (up-to 2dp)
quantity	The quantity of the item.		True	float (up-to 2dp)
charge_date	The charge date for the item. Defaults to today.		False	An ISO 8601 timestamp of the date
scheme_name	The name of the scheme you intend to bill to.	Universal Health Coverage, Public Medical Service Fund	True	string
scheme_code	The scheme code you intend to bill against.	UHC, PMF	True	string
consent_token	The consent token for the patient visit.		True	string

2.3.3. Preauth Diagnosis

This component represents the diagnostic information associated with a pre-authorisation request.

Field Name	Info	Options (if applicable)	Is required?	Type
icd_code	The ICD-11 code.		True	string

2.3.4. Preauth Attachments

This component represents the supporting documents or files that are attached to a pre-authorisation request.

Field Name	Info	Options (if applicable)	Is required?	Type
file_blob	The file blob.		True	file
document_title	Title of the document.		False	string
document_type		PRESCRIPTION, MEDICAL_REPORT, RADIOLOGY_REQUEST, LAB_ORDER, INTERIM_BILL, DISCHARGE_SUMMARY, FINAL_BILL, PROFORMA_INVOICE, THEATRE_LIST, CLINICAL_DOCUMENTATION, OTHER	True	string