DEV Community

anusha
anusha

Posted on

I Built a Durable Insurance Verification Caller with Telnyx Edge

#telnyx #ai #devrel

Insurance verification is one of those workflows that looks simple from the outside and messy from the inside.

A patient is scheduled. The clinic needs to know whether the patient's coverage is active. Someone calls the carrier, waits through the IVR, enters a member ID, listens to a spoken eligibility result, and turns that result into a front desk note.

That process is repetitive, but it is not trivial. Phone calls fail. IVRs loop. Voicemail happens. Spoken answers are inconsistent. And if the result is missed, the cost can land on the clinic or the patient.

I built a Telnyx code example that models the workflow as a durable voice actor.

The code example:
https://github.com/team-telnyx/telnyx-code-examples/tree/main/insurance-verification-caller

The Flow

A front desk system opens a verification job with a member ID, plan, and provider.

From there, a Telnyx Edge actor owns the job. It dials the carrier IVR, sends DTMF digits to move through the menu, captures the spoken eligibility response, asks Jev Decision Models to score the transcript, and sends a concise SMS verdict to the front desk.

The actor also handles the unglamorous parts:

  • voicemail
  • dropped calls
  • long holds
  • retry backoff
  • attempt logging
  • duplicate SMS prevention
  • pod restarts in the middle of the workflow

That is the reason I like this sample. It treats the phone call as a stateful job, not a fragile one-off request.

Why Telnyx Fits This Pattern

The example uses Telnyx for the communication primitives:

  • Voice and Call Control to place the outbound call
  • send_dtmf to drive the carrier IVR
  • transcription to capture the spoken answer
  • Jev Decision Models to structure the carrier response
  • Messaging to notify the front desk
  • Telnyx Edge Agent SDK for durable actors, scheduled retries, and state

The important move is putting those pieces inside an actor. The actor is the verification job. It knows whether it has already tried once, whether it has a transcript, what verdict came back, and whether the SMS has already been sent.

That means the app can survive normal telecom messiness without losing the thread.

What the Decision Model Does

Carrier IVR language is not guaranteed to be tidy. One system might say:

The member is active and eligible for coverage.
Enter fullscreen mode Exit fullscreen mode

Another might say:

We are unable to verify eligibility at this time.
Enter fullscreen mode Exit fullscreen mode

The sample sends the transcript to Jev Decision Models and asks for a structured result:

choice: covered | not_covered | needs_verification
score: 0-100 confidence
noul: 0-1 confidence this is a hard no-coverage result
Enter fullscreen mode Exit fullscreen mode

The app then turns that into a front desk notification:

  • Coverage confirmed
  • Not covered, verify before visit
  • Needs verification

This is deliberately not a clinical agent. It does not diagnose, approve care, deny care, or replace billing staff. It automates a phone-based eligibility check and routes uncertain cases back to humans.

Run It Locally 

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/insurance-verification-caller
npm install
cp .env.example .env
npx tsx smoke_test.ts
Enter fullscreen mode Exit fullscreen mode

The sample defaults to demo mode:

DEMO_MODE=true
Enter fullscreen mode Exit fullscreen mode

That lets you inspect the actor flow without placing real calls or sending live SMS messages.

For live mode, configure the Telnyx API key, carrier number, outbound caller ID, front desk SMS destination, and deploy:

telnyx-edge ship
Enter fullscreen mode Exit fullscreen mode

Where to Take It Next

The production version should connect the verification result to the systems staff already use: a PMS, EHR, billing queue, or prior authorization workflow.

I would also add payer-specific IVR profiles, richer webhook routing, audit views for the attempt ledger, and operational dashboards for retry rates. If one payer's IVR starts failing every morning, that should be visible to staff.

The core boundary should stay the same: the system handles the communications loop and produces a structured eligibility signal. Humans still own the final administrative and patient-facing decisions.

Resources

Top comments (0)