Scenario 3: SHIF - Inpatient - Fee for Service - Elective Preauth

On the day of the actual visit, you do not need to call POST /api/v1/claims/authorize again. The system checks that:

• The same patient_id is used
• The same intervention_code is used
• An existing authorization in AUTHORIZED status exists
• An approved preauth exists for this patient and intervention

For OTP: send a fresh OTP and pass it directly in POST /api/v1/claims/visit. For biometrics: pass the auth_guid from the pre-visit authorization directly in POST /api/v1/claims/visit.

For elective preauths, the doctor must approve before the preauth proceeds. The status flow is:

1. PENDING_DOCTOR_APPROVAL - created; awaiting doctor confirmation
2. ACTIVE - doctor approved; sent to payer for review
3. FINALISED - payer approved; preauth is now valid for claim creation

The POST /api/v1/claims/doctor-consent endpoint is available as a fallback to resend the consent request if the doctor reports they did not receive it.

When you call POST /api/v1/claims/authorize during the pre-visit phase, the authorization is created in AUTHORIZED_PENDING_VISIT status. This is correct and expected - it means the patient has consented but no claim exists yet.

Once the preauth is approved (FINALISED), the authorization transitions to AUTHORIZED status, signaling that a claim can now be created for this patient and intervention.

The system automatically links the approved preauth to the new claim. For this to work, use the same patient_id and the same intervention_code that were used during the pre-visit phase.