Process letter of authorisation requests

Workflow purpose

This guide demonstrates how to use Proto's platform to process incoming letter of authorisation (LOA) requests on the insurer or HMO side. Where "Letter of authorisation requests" covers a patient or provider submitting a request, this workflow covers what happens next – checking coverage, auto-approving straightforward cases, and routing anything ambiguous to a human reviewer. Manual LOA processing is one of the slowest points in the patient journey; this workflow is designed to clear the routine cases in seconds and leave reviewers free for the ones that actually need judgement.

Who can benefit from this guide:

Insurers and HMOs receiving LOA requests from partner hospitals
Hospital billing teams waiting on authorisation before a procedure can proceed
Claims teams wanting a consistent, auditable approval trail
Operations teams trying to cut authorisation turnaround time

Process a letter of authorisation request

This workflow checks coverage against the policy engine, auto-approves straightforward cases, and escalates anything ambiguous to a human reviewer. See how to process letter of authorisation requests.

Just starting with the platform?

For initial setup of your AI agent – including workspace setup, agent training, and channel deployment – please start here. This workflow guide assumes your AI agent is set up and ready for more advanced configurations.

1. Create a trigger

Purpose: Start the flow when an LOA request arrives from a partner hospital or provider portal.

Navigate to the Actions tab in the AI agent settings.
Click “+ Add Trigger” and select the Message Received trigger type (or a Send API request webhook trigger if requests arrive from a partner system).
Name the trigger “Process LOA request”.
Add a description such as “Triggers when a letter of authorisation request is submitted for review.”

2. Set chat variables – capture request details

Purpose: Store the request’s key fields once, so every downstream action reuses them.

Add Set chat variable actions for plan_number, procedure_code, and provider_name, populated from the incoming submission.

3. Send API request – eligibility check

Purpose: Confirm coverage against the actual policy engine rather than a static rule list.

Add a Send API request action to your eligibility engine with {plan_number} and {procedure_code}. Map the response to eligibility_result.

4. Branch – auto-approve or escalate

Purpose: Clear the routine cases automatically and route the rest to a reviewer.

Add a Branch action.
Condition: eligibility_result["covered"] == true and eligibility_result["requires_review"] == false → auto-approve.
Else → AI Agent Network handoff to the claims reviewer’s AI agent, passing {plan_number}, {procedure_code}, and {eligibility_result} in the transferred context.

5. Send the outcome

Purpose: Give the provider a clear, referenceable answer either way.

Add a Send message action for the approved branch: “LOA approved for {procedure_code} under plan {plan_number}. Reference: {authorisation_id}.”
Add a Send message action for the reviewed branch: “Your request has been sent for manual review. We’ll confirm the outcome within [SLA].”

6. Test the flow

Purpose: Confirm the auto-approval boundary is set correctly before go-live.

Test a plan and procedure combination that should auto-approve, and confirm the reference number is generated correctly.
Test a plan that is out of coverage, and confirm it escalates rather than auto-approving.
Test with a malformed plan number to confirm the eligibility check fails gracefully rather than approving by default.

550K