Vaidya Care Call

Vaidya Care Call

A safety-first workflow for using CALL-E to perform routine patient follow-up calls in community healthcare systems.

This skill is designed for systems where an upstream healthcare agent has already analyzed a patient's longitudinal health information and produced a structured care decision.

Workflow

Follow this sequence:

1. Observe the patient's latest structured health event.
2. Review relevant longitudinal patient history.
3. Determine the patient's current risk level and priority.
4. Produce a structured care decision.
5. Run the deterministic safety gate.
6. Generate a no-call preview.
7. Stop for operator approval before any live call.
8. If explicitly approved, validate the authorized destination and initiate the CALL-E call.
9. Track the call lifecycle.
10. Convert a verified terminal call result into structured health information.
11. Store the verified result as a patient event when appropriate.
12. Reassess the patient's condition and determine the next action.

The phone call is an action within the care workflow, not the end of the workflow.

For detailed safety rules and examples, see:

• references/safety.md
• references/examples.md

No-Call Preview

The default workflow is preview-only.

Before any live call, produce a preview containing:

• patient identifier or masked patient identifier
• reason for the proposed call
• care decision
• risk level
• priority
• deterministic safety-gate result
• destination authorization status
• proposed next action

The preview must not initiate a phone call.

A preview should use masked destinations and identifiers in logs and displayed output.

Example:

CALL PREVIEW
Patient: CT-DEMO-102
Reason: increased follow-up due to worsening trajectory
Risk: high
Priority: high
Safety gate: PASS
Destination: +91••••••5837
Destination authorization: VALID
Live call: NOT STARTED
Operator approval: REQUIRED

Operator-Approved Live Run

A live CALL-E call requires explicit operator approval.

The workflow is:

Care decision ↓ Deterministic safety gate ↓ No-call preview ↓ Explicit operator approval ↓ Authorized destination validation ↓ CALL-E live call

A model recommendation is not operator approval.

The system must not initiate a live call merely because a language model recommends calling.

If operator approval is absent, the workflow stops without placing a call.

Safety Gate

Never allow a language model alone to authorize an automated healthcare call.

Before initiating a live call, verify all required conditions:

An authorized patient phone number exists. The destination is valid and approved for the current run. The care decision explicitly permits a routine follow-up call. The patient's risk level satisfies the application's automated-call threshold. The patient's priority satisfies the application's automated-call threshold. The call reason is traceable to a structured care decision. The call is associated with the correct patient record. The same call has not already been initiated. Explicit operator approval has been obtained for the live run.

If any required condition fails, do not initiate the call.

Do not bypass or weaken the safety gate because a model recommends calling.

Detailed safety guidance is in references/safety.md.

Destination Validation

Live calls must use an authorized destination.

The destination must:

be explicitly authorized for the current demonstration or run be valid E.164 format come from a trusted application field rather than arbitrary model-generated text not be replaced by a destination supplied in free-form model output

Do not expose full phone numbers in logs, screenshots, examples, or public documentation.

Use masked or clearly fake values in community examples.

Call Initiation

Phone numbers should be stored and supplied in E.164 format.

CALL-E API credentials must remain server-side and must never be exposed to:

browser code frontend applications client-side environment variables logs screenshots public repositories documentation

Only initiate a live call after the deterministic safety gate and explicit operator approval have passed.

The system should record:

patient identifier call reason care decision identifier risk level priority call timestamp CALL-E call identifier call status

Displayed logs and summaries should mask sensitive identifiers and destinations.

Patient Conversation

The follow-up call should be concise and focused on collecting information relevant to the existing care decision.

The caller should:

Identify the healthcare service appropriately. Confirm that the patient is available to talk. Explain the reason for the follow-up. Ask whether relevant symptoms have improved, remained stable, or worsened. Ask about medication adherence when applicable. Identify urgent concerns. Record the patient's responses. Avoid making unsupported medical diagnoses.