Preauthorizations

Copy page

Preauths Process Guide: Renal Preauth Workflow

1. Overview: Authorising Renal Treatments and Dialysis Sessions

This guide details the Renal 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 renal interventions, which often involve a series of sessions, such as dialysis, that require prior approval from the Social Health Authority (SHA) for payment.

A renal preauth is a type of multisession preauth because, given its nature of treatment, it often involves multiple sessions. At its core, this workflow ensures that patients requiring ongoing renal treatments receive necessary prior approval, providing financial assurance and enabling continuous, compliant care.

2. Workflow Details: Submitting a Renal Preauth

This section details the step-by-step process for submitting a renal 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 renal procedure, start_date, number_of_sessions_required, frequency_of_sessions, clinical_indications, is_co_insured, and arrays of items, diagnoses, doctors, and attachments. The preauth_type will be "Renal Preauthorization".

2. Authorisation 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. Renal 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 renal procedures. Most checks and validations are based on the multisession validations.

4. Submit Renal Preauth Request to SHA: If all validations pass, the system compiles the complete renal 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 an oncology pre-authorisation request. Most of these checks stem from the specific multisession validations.

2.3. Workflow Data Dictionary

This table outlines the key information used and produced by this workflow:

Field Name	Description	Required (Input)	Type	Options (if applicable)
consent_token	The consent token for the patient visit.	Yes	string
intervention_code	The unique identifier for the renal intervention you want to do a preauth request. You should only select the intervention that needs_a_preauth. You can know this from the previous intervention coverage response.	Yes	string
start_date	Expected Date of 1st Session.	Yes	An ISO 8601 timestamp of the date for the
number_of_sessions_required	Number of Sessions Required.	Yes	integer
frequency_of_sessions	Frequency of sessions.	True	string	Twice a week, Once a week, One time every 2 weeks, One time every 3 weeks, One a month
clinical_indications	The clinical indications.	True	string	End-Stage renal disease, Acute kidney failure, Other
is_co_insured	Is the patient co-insured?	False	boolean
doctors	The Attending Doctors/Clinical Officers consent. This is an array of the doctors you need approval from.	Yes	array
items	This will be an array of items in the preauth request.	Yes	array
diagnoses	This will be an array of diagnoses in the preauth request.	Yes	array
attachments	This will be an array of attachments in the request.	False	array

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

2.3.1. Preauth Doctor

This defines the structure for doctors associated with a preauth request.

Field Name	Info	Options (if applicable)	Is required?	Type
identification_number	The unique id to the doctor.		True	file
identification_type	The type of ID being used.	registration_number, National ID, Alien ID, Refugee ID	True	string
regulation_body	The licensing body's choices. Defaults to KMPDC.	KMPDC, COC, NCK	True	string
intervention_code	The intervention code.		True	string
name	The client registry ID from the previous eligibility call.		True	string

2.3.2. Preauth Items

This defines the structure for individual items included in a preauth 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 to the item. Defaults to today.		False	An ISO 8601 timestamp of the date for the
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 defines the structure for diagnoses associated with a preauth request.

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

2.3.4. Preauth Attachments

This defines the structure for attachments included in a preauth request.

Field Name	Info	Options (if applicable)	Is required?	Type
file_blob	The file blob.		True	file
document_title	Title to 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