I need to build a telephone attendant,
and do it fast!

1. I need to build a telephone attendant, and do it fast!

“I need to build a telephone attendant, and do it fast!” That was the practical urgency: people were calling during medical emergencies, and there were not enough people available to answer every call immediately. In São Paulo in 2012, the challenge was to help people reach the appropriate response, not to imitate unrestricted human conversation. The system had to gather useful information, preserve the caller's place in the process and direct the case toward the appropriate response.

The scale matters. The 2010 census counted 11,253,503 residents in the municipality of São Paulo. This supports the description of a city with roughly eleven million people near the period under discussion; it is not a count of callers, a 2012 call-volume estimate or the population of the entire metropolitan region. [1]

A large population does not by itself determine staffing requirements. The missing operational quantities are calls per interval, arrival bursts, handling-time distributions, repeat calls, abandonment and resource availability. The shortage of answering capacity was the motivating problem. This record focuses on techniques and design decisions; operational staffing and patient records are outside its scope.

Our objective is narrower and testable: reduce repeated administrative questions and misdirected information while preserving a timely path to clinical personnel. “Where should this person go?” includes the hospital, service, ward or entrance, but also whether transport or on-scene assistance is required. Geographic proximity alone cannot answer that question.

Research questions

1. Which information can be collected automatically without blocking a human response?
2. How should uncertainty in speech and location prevent an incorrect branch?
3. Which operational constraints must be satisfied before a facility becomes a candidate?
4. How do we evaluate reduced workload without hiding delayed or inappropriate care?

2. Method: separate intake, clinical regulation and destination information

The design separates three decisions. Intake records caller information and recognition uncertainty. Clinical regulation determines the appropriate response and required care pathway. Resource coordination identifies an eligible destination and verifies its acceptance and access instructions. These decisions communicate through explicit states rather than a chain of unchecked keyword matches.

This boundary is consistent with the historical regulatory context. Brazil's Portaria GM/MS 2,048 of 2002 describes regionalized emergency systems under medical regulation, including a medical regulator who determines an appropriate response. It provides a period-appropriate reference for the distinction between receiving a call and deciding its medical disposition. [2] Institutional identities and implementation details are outside the scope of this record.

For the 2012 implementation problem, available components included telephone audio capture and playback, keypad fallback, grammar-constrained recognition, keyword spotting and finite-state dialogue. PocketSphinx had been documented in 2006; Kaldi's original project paper appeared in 2011. VoiceXML 2.0 and SRGS supplied established prompt, grammar and event concepts from 2004. Flite was a compact local synthesis option described in 2001. [3] [4] [5] [6] [7]

The first engineering choice is not the most impressive recognizer. It is the recognizer that performs acceptably for the actual channel, language, vocabulary, budget and failure cost. A Portuguese telephone service needs appropriate acoustic resources, pronunciation dictionaries and evaluation across speakers and accents; an English desktop demonstration does not establish that capability.

The proposed contribution is the coordination of these components around provisional information and accountable gates. A recognition result remains a hypothesis. A location remains unconfirmed until checked. A resource remains a candidate until the appropriate clinical and operational decisions authorize its use. This is a description of the engineering approach, not disclosure of proprietary implementation details.

3. Conditional gates for a caller who may not be able to wait

The automated exchange should be short and transparent: identify it as automated assistance and explain that it is collecting information for the attending team. It must not impersonate a clinician, promise that help has been dispatched or make a caller believe a queue is equivalent to a completed response.

Collect location early when possible: municipality, street or landmark, and a means for an authorized operator to reconnect. Preserve the original utterance alongside the normalized address. A geocoder's first result is not confirmation; similar street names, incomplete numbers and cross-municipality ambiguity must remain visible.

Speech mentioning a concerning condition may justify immediate review under an approved protocol; its absence does not justify downgrading the caller. A keyword system cannot establish that a situation is safe because a trigger word was not heard. Likewise, silence may mean line failure, inability to speak or other problems. It should not be classified as a low-priority case.

A repair budget limits repeated failed prompts, but any human connection becoming available should supersede the automated sequence. Collection can occur while connection is pending; completing an automated questionnaire must not be a prerequisite for reaching an attending professional. Queue identity and recorded context should survive a transfer so the caller does not start again.

Naturalness in this setting is a usability property, not a theatrical goal. Use one question per turn, familiar terms, consistent recordings and intelligible pacing. Barge-in requires coordinated playback interruption and echo handling. Long apologies, variable delays and repeated confirmations can increase the burden; their effect must be measured rather than assumed beneficial.

4. The appropriate hospital may not be the nearest one

Let r be the service or pathway selected by clinical regulation, and let h be a potential resource. A directory record needs an identity, location, available services, accepting status, status timestamp, and verified ward/entrance instructions. A record should distinguish “emergency department,” “specialty service” and “physical entrance” rather than collapsing them into one free-text field.

Filter first, rank second. A nearby facility that cannot provide the authorized service, is not accepting, or has stale status should not win a distance comparison. Travel time depends on the road network, traffic and the authorized transport mode; straight-line distance is only a coarse geographic aid. A ward name or entrance can change independently of the hospital's street address.

In a larger system, the objective can include transfer risk and uncertainty, but weights and eligibility rules must be established with the responsible clinical and operational services. A hospital capacity estimate is not a guaranteed bed. A timestamp does not authenticate a source. Directory updates need provenance, service agreements, expiry and a procedure for confirmation when live status is unavailable.

The candidate list is decision support, not an instruction to travel independently. The authorized team must determine whether dispatch, on-scene care, transport or another response is appropriate. Before spoken information is released, the destination and entrance should be reviewed and associated with the case. If the required data are missing, the system should retain the case for human coordination rather than improvise a destination.

5. Evaluation: workload, queue stability and incorrect pathways

For a first capacity approximation, let λ be the arrival rate, c the number of answering staff and μ their mean service rate. Under a simplified stationary queueing model, utilization is ρ = λ/(cμ). When ρ approaches one, waiting becomes increasingly sensitive to variation. This is a planning model, not a measurement of São Paulo's historical emergency service.

Automation helps only if the removed work exceeds its extra repair burden and it does not delay necessary intervention. The main outcomes should include time to qualified human contact, abandonment, repeated information, unverified locations, inappropriate destination candidates, stale-resource usage and complete transfers. Report distributions and adverse cases, not only mean call duration.

Recognition evaluation needs recorded, consented, channel-matched data; policy evaluation needs annotated states and expected transitions. Clinical evaluation requires a separately governed protocol and appropriate oversight. These are different studies. No claims of reduced mortality, clinical sensitivity, staffing savings or citywide deployment accuracy are made from the software examples below.

Inspectable software results

The accompanying Python lab passes nine deterministic tests: no service candidates without a supplied clinical pathway; exclusion of closed and stale resources; ranking by combined travel and handover estimate; withholding unreviewed destination information; requiring a review reference; accepting location correction; handling repeated silence; preserving uncertainty when an unconfirmed address is handed off; and allowing immediate operator transfer.

In the worked example, DEMO A has a 12-minute travel estimate and an 8-minute handover estimate. DEMO B has 18 and 1 minutes, respectively. Both meet the declared service/status filters, so B ranks ahead on the illustrative 19-versus-20-minute total. DEMO C is closer but closed; DEMO D is closer but stale. These values make the eligibility and ranking calculations inspectable; the operational directory and full implementation are not disclosed.

The tests show that the published rules behave as specified on supplied examples. They do not demonstrate medical safety or real speech recognition performance. A realistic pilot would also test network failure, queue persistence, interruption, incorrect geocoding, inconsistent resource updates, handoff failure and the effect of automation on callers unable to complete the prompts.

6. Python lab: emergency-call intake and resource-filtering techniques

Download the medical-intake Python lab ↓

The companion code targets current Python 3.9+ with no pip dependencies. It provides text-based intake, optional local spoken prompts, example directory records, a review-release gate and nine tests. It does not operate a telephone service, record a microphone, determine diagnosis, dispatch an ambulance or recommend an actual hospital.

For the dialogue, type an example location, answer “no” to correct it, then confirm the revised location. Type operator or 0 to hand off immediately. The final packet always records that a clinician is needed; an operator request does not magically confirm an address that the caller has not confirmed.

The --demo command prints eligible example records and their illustrative totals. The required service is supplied by a fixture representing the clinical-regulation interface. It is never inferred from symptoms typed by the caller. The --speak option uses an already-installed local speech engine; if none exists, prompts remain text-only.

Core algorithm: filter, rank, then require review

def resource_candidates(service,resources,now,max_age=300):
 """service is supplied by a clinician/regulation adapter, never inferred from caller words."""
 if not service:return []
 eligible=[]
 for row in resources:
  age=now-row['status_at']
  if not row['accepting'] or not 0<=age<=max_age or service not in row['services']:continue
  r=dict(row);r['estimated_minutes']=r['travel_minutes']+r['handover_minutes'];eligible.append(r)
 return sorted(eligible,key=lambda r:r['estimated_minutes'])
def release_information(candidate,review):
 """In this teaching example review is a fixture. Production must verify operator identity,
 patient/session binding, authority, transport decision and an audit reference server-side."""
 if not candidate or not review or not review.get('reviewed_by_clinician') or not review.get('reference'):return None
 return {'resource':candidate['name'],'entrance':candidate['ward'],'review_reference':review['reference'],'kind':'educational_example'}

The review object in this teaching example is an explicit fixture. A production system must authenticate the responsible professional, check their authority, bind the review to the correct call and patient, and write an auditable reference. A Boolean field in a local JSON object is not an authentication mechanism.

Download Python source · Read the lab instructions

Conclusion

The engineering problem was to make scarce human attention available sooner and connect people to the appropriate care pathway. Speech automation can assist by collecting and checking information, keeping uncertain data provisional and exposing eligible resources. Its value depends on preserving the clinical decision boundary, maintaining the call through handoff and communicating verified instructions—not merely answering more calls with a synthetic voice.