Logo
Search
API Docs

Medical Triage & Scheduling Squad

Guides

Medical Triage & Scheduling: A Squad Walkthrough

Overview

This is a full worked example of building a clinic triage-and-scheduling system as a Squad, using the same handoff-tool mechanics covered in Squad Routing: Handoff Destinations & Context Engineering and the knowledge-base approach covered in Query Tool Setup. A modern Squad-based approach like this one has superseded the older Workflow-based way of building multi-step call flows, so this walkthrough only covers the Squad approach.

Important: every patient, provider, and appointment record used below is fictional, for configuration purposes only. Nothing in this walkthrough is medical advice, and none of the example prompts should be read as real triage or clinical guidance — it is a walkthrough of how to configure the assistants and tools, not a description of correct clinical practice. If you handle real patient data in production, read the HIPAA & PCI page first: real PHI requires HIPAA mode, a signed BAA, and HIPAA-compliant providers before it ever touches a live call.


Step 1: Upload the Knowledge Base Files

Upload four CSV files through the Files API (fictional/training data only):

  • patients.csv — columns: patient_id, name, phone, dob, primary_provider
  • providers.csv — provider names, specialties, and availability
  • triage_protocols.csv — symptom categories and their associated urgency level
  • appointments.csv — existing appointment slots and booking status
curl --location 'https://api.sulus.ai/file' \
--header 'Authorization: Bearer <YOUR_API_KEY>' \
--form 'file=@"patients.csv"'

# repeat for providers.csv, triage_protocols.csv, and appointments.csv

Save each returned file id for use in the tools below. See Query Tool Setup for how these files get attached to a knowledge base tool.


Step 2: Create the Three Tools

ToolPurposeNote
lookup_patientRetrieves the caller's patient recordIn this walkthrough it's backed by patients.csv; in a real production deployment it would instead call your actual EHR system's API rather than a static file
conduct_triageCaptures reported symptoms, onset, and severityBacked by triage_protocols.csv to classify urgency
schedule_appointmentBooks an appointmentCaptures patient_id, appointment_type, and urgency_level
curl -X POST "https://api.sulus.ai/tool" \
  -H "Authorization: Bearer $CORE_SYSTEM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "function",
    "name": "schedule_appointment",
    "description": "Book a clinic appointment for a patient",
    "parameters": {
      "type": "object",
      "properties": {
        "patient_id": { "type": "string" },
        "appointment_type": { "type": "string" },
        "urgency_level": { "type": "string", "enum": ["routine", "urgent", "emergency"] }
      },
      "required": ["patient_id", "appointment_type", "urgency_level"]
    },
    "server": {
      "url": "https://your-scheduling-system.example.com/appointments"
    }
  }'

Step 3: Build the Three-Assistant Squad

The Triage assistant is the entry point for every call, and routes to Emergency or Scheduler using handoff tools that also pass the patient's name forward as a variable:

{
  "type": "handoff",
  "function": {
    "name": "handoff_to_Emergency",
    "description": "Use when the caller describes a red-flag symptom requiring immediate attention.",
    "parameters": {
      "type": "object",
      "properties": {
        "destination": { "type": "string", "enum": ["<emergency_assistant_id>"] },
        "patientName": { "type": "string", "description": "Full name of the patient" }
      },
      "required": ["destination", "patientName"]
    }
  },
  "destinations": [
    {
      "type": "assistant",
      "assistantId": "<emergency_assistant_id>",
      "contextEngineeringPlan": { "type": "all" }
    }
  ]
}

The Emergency assistant receives the {{patientName}} variable and opens with it directly:

{
  "name": "Emergency",
  "firstMessage": "Hello {{patientName}}, I understand this may be urgent. I'm connecting you with our emergency protocol right away.",
  "model": {
    "provider": "openai",
    "model": "gpt-4o",
    "messages": [
      {
        "role": "system",
        "content": "Emergency protocol assistant. Patient name: {{patientName}}. For any life-threatening symptom, instruct the caller to hang up and dial emergency services immediately."
      }
    ]
  }
}

The Scheduler assistant is used the same way for routine care, using the schedule_appointment and lookup_patient tools once handed the call.


Context Preservation & Handoff Routing

Every handoff above uses contextEngineeringPlan: { "type": "all" }, so the full conversation the patient already had with Triage — symptoms described, onset, severity — transfers forward rather than making them repeat themselves. In addition to the conversation history, the patient's name is passed explicitly as a {{patientName}} variable captured by the handoff tool itself, so the receiving assistant can open personally rather than asking for the name again. See Squad Routing: Handoff Destinations & Context Engineering for the full set of contextEngineeringPlan options if a given handoff needs a more restricted context (for example, excluding tool call results on a handoff involving sensitive data).


Testing Scenarios

  • Routine appointment request: call in describing a non-urgent reason for a visit, and confirm Triage routes to Scheduler with the conversation and patient name intact.
  • Emergency symptom scenario: call in describing a red-flag symptom from triage_protocols.csv, and confirm Triage routes to Emergency immediately, with the Emergency assistant opening by name and pointing the caller to emergency services for anything life-threatening.

Remember that every scenario here is a fictional test case for configuration purposes — use only synthetic patient data in testing, never a real caller's actual health information, until HIPAA mode and a signed BAA are in place per HIPAA & PCI.