Overview#
The Caller Enrichment module builds a comprehensive context profile for each incoming emergency call before the AI dispatcher speaks its first word. Within a 450-millisecond window at call start, the system runs five independent lookups in parallel: caller identity and medical history, prior call activity, premise hazards at known addresses, active incidents at those locations, and linked utility account details. The results are injected directly into the AI dispatcher's context, enabling immediate informed responses rather than having to ask callers to repeat basic information they may have already provided in previous calls.
Caller enrichment is particularly valuable for repeat callers, vulnerable individuals with known medical conditions, and addresses with documented hazards, where prior knowledge directly affects triage priority and responder safety briefings.
Key Features#
- Parallel Five-Way Lookup: Caller profile, prior calls, premise hazards, open incidents, and utility accounts are fetched concurrently within a hard 450ms budget, ensuring enrichment never delays call answer time
- Caller Profile Resolution: Looks up registered name, known addresses, medical flags (conditions, medications, mobility restrictions), and emergency contact details for callers who have opted in to pre-registration
- 30-Day Prior Call History: Retrieves the count of calls from the same number and a summary of the most recent call, giving dispatchers immediate awareness of frequent callers or evolving situations
- Premise Hazard Loading: For any address associated with the caller, retrieves active hazard records sorted by severity, including structural hazards, chemical storage, violent history flags, and access restrictions relevant to responding units
- Active Incident Correlation: Checks whether any open incidents are already linked to the caller's known addresses, enabling dispatchers to connect a new call to an ongoing operation rather than creating a duplicate incident
- Utility Account Context: For utility service calls, retrieves account number, customer name, service address, account status, and outstanding balance, eliminating the need for callers to repeat account details during emergencies
- System Prompt Injection: All enriched data is formatted as a structured KNOWN CALLER CONTEXT block appended to the AI dispatcher's initial prompt, ensuring the information is available from the opening exchange
- Opt-In Enforcement: Medical flags and emergency contacts are only surfaced when the caller has explicitly opted in to data sharing; all other enrichment uses operationally registered data only
- Graceful Degradation: Each of the five lookups is independently fault-tolerant; a timeout or database error on one lookup does not block or delay the others
Use Cases#
Repeat Caller Recognition#
A caller who has contacted emergency services multiple times about an ongoing domestic situation is immediately recognised. The dispatcher sees the prior call count, a summary of the last interaction, and any open incidents at the address, enabling continuity without interrogating the caller.
Medical Emergency Pre-Brief#
For a caller registered with known cardiac history, the enrichment block surfaces their medical flags and emergency contacts before the dispatcher has asked a single question, allowing medically relevant questions to begin immediately.
Hazardous Premises Awareness#
When a call originates from an address with a known chemical storage flag or violent history record, the hazard data is surfaced to the dispatcher and can be included in the responder brief before units are deployed.
Utility Service Emergencies#
A customer calling about a gas leak is automatically matched to their utility account. The dispatcher can confirm service address and account status without diverting the conversation, keeping focus on the safety assessment.
Duplicate Incident Prevention#
If an active incident is already logged at the caller's known address, the dispatcher is immediately aware and can assess whether the new call relates to the same event or represents an escalation, reducing duplicate incident creation.
How It Works#
The Voice AI session handler invokes caller enrichment automatically at call start. All five database lookups run in parallel and must complete within 450ms. Results are assembled into a structured context block and injected into the AI dispatcher's system prompt before the call is answered. Each individual lookup fails independently without blocking the others, so partial enrichment is always better than delayed enrichment.
Integration#
Caller Enrichment is invoked automatically at call start by the Voice AI session handler. It reads from the caller profiles, prior calls, premise hazards, incidents, and utility accounts tables, all of which are populated through their respective domain modules (PSAP Profile Management, Premises Intelligence, Incident Management, and Utility Customer Management). No enrichment data is persisted to the call record at this stage; the injected context is live at call start and is reflected in the AI's transcribed conversation. Post-call summaries and incident records capture the outcome independently.
Open Standards#
- NENA i3 / NENA-STA-012: The seven standard Additional Data block types (SubscriberInfo, DeviceInfo, CommsInfo, ServiceInfo, OwnerInfo, ProviderInfo, ComponentInfo) defined in NENA-STA-012 are the data shapes populated and injected into the dispatcher context during caller enrichment.
- IETF RFC 7852 (Additional Data Related to an Emergency Call): The Additional Data Repository layer fetches, caches, and serves RFC 7852 compliant data blocks in parallel during the 450 ms enrichment window, with each block identified by its standard block type.
- PIDF-LO (RFC 4119 + RFC 5491): Presence Information Data Format Location Object is used to represent and exchange caller and premise location data, including both geodetic and civic-address forms, when resolving known addresses during enrichment.
- LoST / RFC 5222 (Location-to-Service Translation): The ECRF/LVF layer uses RFC 5222 LoST queries to correlate caller addresses with service boundaries, confirming that open incidents and premise hazards retrieved during enrichment are scoped to the correct PSAP jurisdiction.
- EN 17128:2020 (Advanced Mobile Location): Handset-transmitted AML SMS bodies conforming to the European EN 17128 standard are parsed to supply a precise caller position before the AI dispatcher answers, complementing registered-address lookups.
- ITU-T E.164: All caller telephone numbers are stored and matched in ITU E.164 format, ensuring consistent lookup across the caller profile, prior call history, incident correlation, and utility account queries.
- W3C Verifiable Credentials v2 (Ed25519Signature2020): Additional Data blocks retrieved and cached by the ADR service are optionally wrapped in a W3C VC v2 envelope signed with Ed25519, providing tamper-evident provenance for enrichment data delivered to the dispatcher prompt.
- RFC 5031 / RFC 6443 (Service URNs): Emergency service URNs (e.g. urn:service:sos.ambulance) drawn from these IETF registries are attached to call sessions and used during enrichment to select the appropriate data providers and prioritise the hazard and incident lookups surfaced to the dispatcher.
Compliance#
- Caller profile data is accessed only for numbers with active opt-in consent records
- Medical and emergency contact information is gated behind explicit data-sharing consent
- All enrichment lookups are scoped to the answering organisation's tenant, preventing cross-agency data access
- Audit events are recorded for each enriched field accessed, supporting post-incident review and data access transparency requirements
Last Reviewed: 2026-04-14 Last Updated: 2026-04-14