4 ways SMS patient engagement platforms can automate insurance checks with Stedi
Patient engagement platforms keep providers connected to patients between visits. They handle the routine work that drives revenue but might otherwise require more staff. Think things like scheduling appointments, handling intake, and sending payment reminders.
Many patient engagement platforms now offer SMS text messages as a patient communication channel.
Unlike phone calls, a text message doesn't need the patient to pick up the phone at a specific time. Text messages also give the patient a written record of things like appointment dates and amounts due. And because texting is two-way, patient replies can trigger actions, like insurance verification checks, that run in the background.
Much of the work a patient engagement platform does depends on the patient's insurance. Many providers want to verify coverage before a visit and know what a patient owes before asking for payment.
If you're building a patient engagement platform that uses SMS, this guide shows you how to use Stedi to get those answers – from thousands of payers in a format your platform can easily parse and surface to patients over text messages.
1. Use real-time eligibility checks to verify insurance
Before a visit, most providers want to confirm the patient's insurance coverage is active. Coverage lapses and plans change, and a claim against an inactive plan gets denied.
Stedi's Real-Time Eligibility Check API returns a patient's coverage status in 1-3 seconds. You only need the patient's first name, last name, date of birth, member ID, and their payer's name.
To collect this information, your platform can text the patient a secure link to a form where they enter their insurance details or upload a photo of their card. You can extract patient information from an uploaded card using Optical Character Recognition (OCR) or an AI agent.
You can use the payer's name to get a payer ID through Stedi's Search Payers API. Then use our Real-Time Eligibility Check API to send an eligibility check:
curl --request POST \
--url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3" \
--header "Authorization: <api_key>" \
--header "Content-Type: application/json" \
--data '{
"tradingPartnerServiceId": "87726", // Payer ID
"encounter": {
"serviceTypeCodes": ["30"] // Health Benefit Plan Coverage
},
"provider": {
"organizationName": "ACME Health",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "19850315",
"memberId": "UHC123456"
}
}'
The response's benefitsInformation object array contains an entry that confirms whether the patient has active coverage:
{
"benefitsInformation": [
{
"code": "1", // Active coverage
"serviceTypeCodes": ["30"] // Health Benefit Plan Coverage
}
// ...
]
}
Unlike other verification methods like payer portals, eligibility checks are standardized healthcare transactions. You run an eligibility check the same way for each payer. That makes eligibility checks easy to automate and scale.
To learn more, see our eligibility checks docs.
2. Use eligibility benefits to estimate what a patient owes
In addition to coverage, an eligibility check also returns the patient's insurance benefits, including cost-sharing amounts like co-pays and deductibles, as benefitsInformation objects:
{
"benefitsInformation": [
{
"code": "B", // Co-pay
"serviceTypeCodes": ["98"], // Office visit
"benefitAmount": "20", // $20 co-pay
"inPlanNetworkIndicatorCode": "Y" // In-network
},
{
"code": "C", // Deductible
"serviceTypeCodes": ["30"], // Health Benefit Plan Coverage (General Medical)
"benefitAmount": "1000", // $1000 deductible
"timeQualifier": "Calendar Year"
}
// ...
]
}
You can extract and combine the amounts for use in a patient-facing text message. For example:
Your estimated co-pay for Tuesday's visit is $20. You have $1,000 remaining on your deductible.
For more tips, see How to estimate patient responsibility using a 271 eligibility response and our patient responsibility docs.
3. Use insurance discovery to find missing coverage
Most patients don't know their member ID by heart – and they may not have their card handy when your text arrives. Other patients may have lost their card or provide information for an old plan that no longer covers them.
In these cases, you can run an insurance discovery check instead.
Insurance discovery searches across payers for active coverage using only demographic data the patient already knows: name, date of birth, ZIP code, and optionally Social Security Number (SSN). Those are details a patient can provide on the spot.
In most cases, the Insurance Discovery API returns a synchronous response within 120 seconds, often faster.
If the check finds active coverage, the response contains the same data as an eligibility check:
{
"status": "COMPLETE",
"coveragesFound": 1,
"discoveryId": "12345678-abcd-4321-efgh-987654321abc",
"items": [
{
"payer": {
"name": "Aetna",
"payorIdentification": "100003"
},
"subscriber": {
"memberId": "J9606211996",
"firstName": "JOHN",
"lastName": "DOE"
},
"benefitsInformation": [
{
"code": "1", // Active coverage
"serviceTypes": ["Health Benefit Plan Coverage"],
"planCoverage": "Aetna Choice POS II"
}
]
// ...
}
]
}
Tips for interpreting the response:
- Treat each item in the
itemsarray as a candidate for coverage, not a confirmed match. Verify it against other known patient details, like gender, ZIP code, or state. benefitsInformationobjects follow the same structure as those in a JSON eligibility response.
Insurance discovery is a useful fallback, but results aren't guaranteed. Run an eligibility check first when you can.
For more, see our insurance discovery docs.
Discovery for Medicare-eligible patients
For patients likely covered by Medicare, such as those 65 or older, an MBI lookup is a targeted alternative to insurance discovery.
It returns the patient's Medicare Beneficiary Identifier (MBI) and, if found, their complete Medicare eligibility response. You can run an MBI lookup using only the patient's demographics and, optionally, their Social Security Number (SSN).
4. Use batch eligibility checks to refresh coverage between visits
Many patient engagement platforms run on a loop: ingest a patient file, then send a message per patient. Batch eligibility checks feed that loop.
But a patient's insurance can change after intake or between visits. Catching the change early lets the platform reach out before the appointment. That heads off rejected and denied claims later.
Stedi's batch eligibility checks re-verify coverage and benefits for all your patients, or a subset, in one batch. Platforms can run these refreshes weekly, monthly, or annually by uploading a CSV in the Stedi portal or using Stedi's Batch Eligibility Check API endpoint.
Refresh the entire patient panel, then text only the patients whose coverage changed.
For more tips, see How to optimize monthly eligibility refresh checks and our batch eligibility checks docs.
Get started with Stedi
To get started with Stedi, sign up for a free sandbox account. It takes less than two minutes. No credit card is required.
Sandbox accounts give you access to mock eligibility checks you can use for testing or integration.
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.