Stedi's real-time eligibility integration for Amazon Connect Health

Amazon Connect Health is a managed service for building AI agents that handle common healthcare tasks, like scheduling or scribing clinical notes.

One of the things Connect Health's AI agents can do is take calls from patients. The agents can answer the call, verify the caller's identity against the provider's EHR, and book an appointment.

If you use an integration to connect Connect Health's agents to a real-time eligibility vendor – like Stedi – the agents can also check the patient's insurance coverage and quote the patient a co-pay.

We recently published a reference implementation of a real-time eligibility integration between Stedi and Amazon Connect Health on GitHub.

The repo covers setup, testing, and deployment. This guide walks you through what Amazon Connect Health is, how the integration works, and the things worth knowing before you start.

You can also watch this video for a full walkthrough:

Amazon Connect Health agents

Amazon Connect Health offers two types of agents:

Patient engagement agents handle inbound and outbound voice calls with patients.
Point of care agents support clinicians during a visit with ambient documentation and pre-visit summaries, the latter currently in preview.

This guide – and our reference implementation – focuses on patient engagement agents.

Patient engagement agents

Say a patient calls their doctor's office to schedule an appointment. Before scheduling, the provider needs to verify the caller's identity. Connect Health splits those tasks between two subtypes:

The Patient verification agent confirms a caller's identity at the start of the call by matching what they say against EHR records.
The Appointment management agent helps patients schedule, reschedule, and cancel appointments.

Real-time eligibility integrations for Connect Health

Insurance verification is an optional feature of Appointment management agents. When a patient schedules or reschedules, the agent can check their coverage and quote a co-pay before it confirms the appointment.

The verification itself runs through a vendor integration that performs real-time eligibility checks.

To help developers build real-time eligibility integrations, Amazon provides a vendor-neutral sample implementation. Our reference implementation is adapted from that sample, customized to use our Real-Time Eligibility Check API.

How the integration works

The integration is an AWS Lambda function – serverless code that runs on demand – and it sits between the voice agent and Stedi:

On the call, the agent collects the information needed for the eligibility check, such as the patient's name, member ID, and date of birth.
The Lambda maps those fields to a Stedi Real-Time Eligibility Check API request. The appointment dates become the dates of service on the request, so the payer answers for the appointment rather than for today.
Stedi returns the patient's coverage and benefits.
The Lambda maps the response back to the schema Amazon Connect Health expects, and the agent reads the answer to the caller.

From the patient's point of view, they're just talking to the agent. They never know that Stedi is involved, or that an eligibility check is happening at all.

How the response is mapped

The integration's function/mapper.py converts Stedi's eligibility response into the response schema Amazon Connect Health expects.

An example of that response, including a coverage status, a coverage period, and a co-pay:

{
  "status": "ACTIVE",
  "eligibilityPeriodStart": "2026-04-01",
  "eligibilityPeriodEnd": "2026-12-31",
  "paymentInformation": {
    "expectedServiceCost": 25.0 // Co-pay amount
  }
}

The mapper populates each field from Stedi's eligibility response as follows.

Eligibility status

status comes from the code on each benefitsInformation entry. Codes 1-5 mean ACTIVE status; codes 6-8 mean INACTIVE status. Anything else – such as a payer that returns no benefits or a code of V (Cannot Process) – returns an UNKNOWN status.

Eligibility coverage dates

The dates come from planDateInformation, using:

Start date: planBegin, falling back to plan
End date: planEnd, falling back to plan

If the payer reports no date, the field falls back to the service date the agent asked about – requestPeriodStart or requestPeriodEnd from the request, matching the AWS sample's response schema.

The coverage date logic is simplified for demonstration purposes. See our full guidance on when a patient is eligible for benefits.

Expected service cost

expectedServiceCost is the benefitAmount from the first in-network co-pay for a service type code the reference implementation hard-codes – more on that below.

What to know before you start

Testing without PHI

Our reference implementation includes a test event that uses one of Stedi's mock eligibility requests.

Mock requests are predefined eligibility checks that return realistic – but fake – responses, so there's no PHI to leak. You can send mock requests using a test API key and Stedi's production Real-Time Eligibility Check API endpoint.

Service type codes are hard-coded

Most medical eligibility requests include a Service Type Code (STC) – a broad benefit category like behavioral health or chiropractic.

The STC you use in an eligibility request determines the type of benefits – like co-pays – you'll get back in the response.

Amazon Connect Health's eligibility request and response schemas have no field for an STC, so our reference implementation hard-codes both ends. The request asks for STC 30 (Health Benefit Plan Coverage), which returns benefits across service types. The response mapper then pulls the first in-network co-pay for STC 33 (Chiropractic).

When you're ready, upgrade to production on our pay-as-you-go plan. There are no monthly minimums or setup fees. You only pay for the transactions you use.

Twitter LinkedIn