Blog

The big takeaway: Manually entered payer names are often wrong. Use Stedi's Search Payers endpoint to find the closest matching payer ID. Then verify it's the right payer with an eligibility check.

Healthcare runs on forms. People often fill them out wrong.

One thing we commonly see is the plan name entered as the payer name. A tired nurse sees "UHC Open Access Plus" on an insurance card and enters it as the payer name. But that's actually the plan name. The payer is UnitedHealthcare.

It’s an honest mistake. But if you’re building on top of that data, it can break your workflow.

Clearinghouse transactions – like claims – need a payer ID. It’s like a routing number for the payer. Use the wrong ID, and your claims are likely to be rejected. And that may mean delayed payments for the provider.

When payer names are clean and trustworthy, finding their IDs is easy. You can just use the top result from Stedi’s Search Payers endpoint.

But when the data is dirty, you need a verification workflow. This guide lays out our recommended flow. It’s based on what we’ve seen work with customers.

Step 1. Run a payer search

Use the Search Payers endpoint to search for the payer name:

curl --request GET \
  --url "https://healthcare.us.stedi.com/2024-04-01/payers/search?query=uhc+open+access+plus" \
  --header "Authorization: <api_key>"

Results are sorted by relevance. Store the top result's primaryPayerId as the payer ID:

{
  "items": [
    {
      "payer": {
        "stediId": "KMQTZ",
        "displayName": "UnitedHealthcare",
        "primaryPayerId": "87726",            // Payer ID
        ...
      }
    },
    ...
  ],
  ...
}

The Search Payers endpoint’s search algorithm is greedy. It’ll almost always return something, even for an unmappable payer name like BCBS out of state.

It’s important to verify the patient has coverage with the payer before using the payer ID in a workflow.

Step 2. Verify the payer ID using an eligibility check

Eligibility checks are fast, inexpensive, and easy to automate. This makes them a good choice to verify a patient’s payer.

Run an eligibility check to verify the payer ID. For example, using the Real-Time Eligibility Check JSON endpoint:

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"]
  },
  "provider": {                                  // Provider data
    "organizationName": "ACME Health Services",
    "npi": "2528442009"
  },
  "subscriber": {                                // Patient data
    "memberId": "1234567890",
    "firstName": "Jane",
    "lastName": "Doe",
    "dateOfBirth": "19850101"
  }
}'

The results will tell you if the patient has active coverage with the payer. If so, you can use the payer ID in other workflows for the patient. For tips on interpreting the results, see Active and inactive coverage in the Stedi docs.

If the check returns AAA error 75 (Subscriber/Insured Not Found) or a similar error, it means the payer search likely matched the wrong payer. Move on to step 3.

Step 3. Manually check the rest

Some raw payer names can't be mapped automatically. They need human judgment to pick the right ID.

Many payers use separate payer names and payer IDs for different lines of business, states, or coverage types.

For example, searching "Aetna" returns their main commercial ID first, but they also have separate IDs for each state's Medicaid plan. Without more context, you can't pick the right one.

Other payer name strings can’t be mapped to a valid payer ID at all:

• BCBS out of state (which state?)

• Insurance pending (not a payer)

• Typos that match nothing

Mark these for review or flag them with the provider. Don't guess.

Things to watch out for

Don’t send Medicare Advantage checks to CMS

Medicare Advantage isn't Medicare. It's commercial insurance that Medicare has approved.

Medicare Advantage plans and payers often have “Medicare” in their names. With typos, it’s easy to run a search for these payers that returns the National Centers for Medicare & Medicaid Services (CMS) – the government payer for Medicare – instead of the commercial payer you need.

CMS forbids using its system for Medicare Advantage checks. To avoid doing that, filter anything with "Medicare" in the name. Make sure it’s not a Medicare Advantage check before sending it to CMS.

Blue Cross Blue Shield eligibility responses

Blue Cross Blue Shield (BCBS) isn't one payer. It's a collection of 30+ separate entities. However, a BCBS payer can verify any other BCBS member through the BlueCard network.

For example, if you send an eligibility check to BCBS Texas for a BCBS Alabama member, you'll get benefits back. It may not be obvious that BCBS Alabama is the home payer.

To get the home payer, check the response's benefitsRelatedEntities for an entry with entityIdentifier = "Party Performing Verification". The entityIdentificationValue is the home payer’s ID. Use that payer ID for claims and other workflows.

{
  ...
  "benefitsInformation": [
    {
      "code": "1",
      "serviceTypeCodes": ["30"],
      ...
      "benefitsRelatedEntities": [
        {
          "entityIdentifier": "Party Performing Verification",
          "entityType": "Non-Person Entity",
          "entityName": "Blue Cross Blue Shield of Alabama",
          "entityIdentification": "PI",
          "entityIdentificationValue": "00510BC"
        }
      ]
    },
    ...
  ],
  ...
}

Get help when you need it

We’ve seen the workflow above work about 80% of the time. For the remaining 20%, patterns often emerge.

If there’s a raw payer name string that’s giving you trouble, reach out. Our team can help with payer ID matching.

Big takeaway: Duplicate benefits often aren’t duplicates. They cover different scenarios, like in-network vs. out-of-network care.

Imagine you run an eligibility check. A second or two later, you get back the response. It lists three different co-pays – $15, $30, and $0 – each for a physician office visit.

Which one is right?

They all are. Each co-pay applies to a different situation:

• $15 for in-network providers – providers who have a contract with the patient’s payer for their health plan.
  
  

• $30 for out-of-network providers – providers without a contract.
  
  

• $0 for specific services, like preventive care or maternity visits, with in-network providers.

If you don't know which fields to check in the response, it’s hard to tell them apart. This guide shows you what to look for with real-life examples.

Where to find benefits

If you’re using Stedi’s JSON eligibility APIs, most of a patient’s benefit information is in the response’s benefitsInformation object array.

Each benefitsInformation object – or benefit entry – tells you about one aspect of the patient’s coverage. One entry indicates active coverage. Another contains a co-pay.

For tips on reading the objects, see How to read a 271 eligibility response in plain English.

{
  ...
  "benefitsInformation": [
    {
      "serviceTypeCodes": ["30"],         // General medical
      "code": "1",                        // Active coverage
      "timeQualifierCode": "23",          // Calendar year
      "inPlanNetworkIndicatorCode": "Y",  // Applies to in-network providers
      "additionalInformation": [
        {
          "description": "Preauthorization required for imaging services."
        }
      ]
    },
    {
      "serviceTypeCodes": ["30"],         // General medical
      "code": "C",                        // Deductible
      "benefitAmount": "1000",            // $1000 annual deductible
      "timeQualifierCode": "23",          // Calendar year
      "inPlanNetworkIndicatorCode": "N"   // Applies to out-of-network providers
    },
    {
      "serviceTypeCodes": ["30"],
      "code": "D",                        // Benefit Description
      "additionalInformation": [
        {
          "description": "EXCLUSIONS: COSMETIC SURGERY, EXPERIMENTAL TREATMENTS"
        }
      ]
    },
    {
      "serviceTypeCodes": ["88"],         // Pharmacy
      "code": "B",                        // Co-pay
      "benefitAmount": "10",              // $10 co-pay
      "inPlanNetworkIndicatorCode": "Y"   // Applies to in-network providers
    },
  ],
  ...
}

Fields to check

Benefit entries often look identical except for one or two fields. Check these fields first to spot the difference:

• serviceTypeCodes
The Service Type Code (STC) indicates what type of service the benefit applies to. If two benefitsInformation objects have different serviceTypeCodes values, they apply to different services – like pharmacy and mental health services.
  
  You’ll often see the same serviceTypeCodes in more than one benefitsInformation object. That’s expected. To get the full picture for a service, look at all entries that include the same STC.

  
  

• coverageLevelCode
  Whether the benefit applies to the plan’s subscriber, their family, etc. A $20 individual deductible and $50 family deductible aren't duplicates. They're separate buckets that apply to different members of the patient’s plan.

  
  If coverageLevelCode is missing, assume the benefit entry applies to individual coverage.
  
  

• inPlanNetworkIndicatorCode
  Whether the benefit applies to in-network providers, out-of-network providers, or both. This often explains the biggest price differences in what the patient pays.
  
  

• timeQualifierCode
  The time period for the benefits, such as calendar year, remaining year, or visit. A $500 calendar year maximum is different from a $500 per-visit limit.
  
  

• additionalInformation.description
Free-text notes – these act as fine print. Payers often use these to include specific procedure codes, exclusions, carve outs, or special rules. As a rule of thumb, more specific descriptions override less specific ones.
  
  In many cases, these descriptions will be in a separate entry for the STC. These entries typically have a code of 1 (Active Coverage) or  D (Benefit Description).
  
  

• eligibilityAdditionalInformation.industryCode
  When eligibilityAdditionalInformation.codeListQualifierCode is set to ZZ (Mutually Defined), this field contains a code for where the service takes place. Some payers offer reduced co-pays or coinsurance for telehealth visits.

  
  See Place of Service Code Set on CMS.gov for a list of these codes and their descriptions.

Other fields

The above list isn’t exhaustive. If you’ve checked these fields and still can’t spot differences between similar benefit entries, try diffing the entries in a code editor or a similar tool.

Examples

Here are a few examples of near-identical benefit entries we’ve helped customers interpret.

Multiple co-pays for the same service
The following benefits cover mental health outpatient visits (STC CF).

The difference is in the additionalInformation.description field. Primary care providers (PCPs) have a $25 co-pay. Specialists and other providers have a $75 co-pay.

// PCP co-pay
{
  "serviceTypeCodes": ["CF"],              // Mental health outpatient
  "code": "B",                             // Co-pay
  "coverageLevelCode": "IND",              // Individual coverage
  "inPlanNetworkIndicatorCode": "Y",       // In-network
  ...
  "benefitAmount": "25",                   // $25 co-pay
  "additionalInformation": [
    {
      "description": "Provider Role PCP"    // Primary care provider only
    }
  ]
}

// Specialist co-pay
{
  "serviceTypeCodes": ["CF"],
  "code": "B",
  "coverageLevelCode": "IND",
  "inPlanNetworkIndicatorCode": "Y",
  ...
  "benefitAmount": "75",                   // $75 co-pay
  "additionalInformation": [
    {
      "description": "Provider Role OTHER"  // All other providers
    }
  ]
}

Different provider network status, different deductibles
The benefits below both cover general medical care (STC 30). Both have an annual deductible.

The only difference is the provider’s network status. In-network providers have a $1000 deductible. Out-of-network providers have a $2500 deductible.

// In-network deductible
{
  "serviceTypeCodes": ["30"],              // General medical
  "code": "C",                             // Deductible
  "coverageLevelCode": "IND",              // Individual coverage
  "timeQualifierCode": "23",               // Calendar year
  ...
  "benefitAmount": "1000",                 // **$1000 deductible**
  "inPlanNetworkIndicatorCode": "Y",       // **In-network only**
}


// Out-of-network deductible
{
  "serviceTypeCodes": ["30"],
  "code": "C",
  "coverageLevelCode": "IND",
  "timeQualifierCode": "23",
  ...
  "benefitAmount": "2500",                 // **$2500 deductible**
  "inPlanNetworkIndicatorCode": "N",       // **Out-of-network only**
}

Co-insurance for different procedures
These dental benefits all cover adjunctive dental services (STC 28). The coinsurance percentage depends on which procedure codes are billed.

In this case, the procedure codes are CDT (Current Dental Terminology) codes, which are used for dental services.

The codes for each coinsurance are listed in the additionalInformation.description field.

// Fully covered procedures
{
  "serviceTypeCodes": ["28"],              // Adjunctive dental services
  "code": "A",                             // Co-insurance
  "coverageLevelCode": "IND",              // Individual coverage
  "inPlanNetworkIndicatorCode": "W",       // Not applicable
  "benefitPercent": "0",                   // Patient pays 0% (fully covered)
  "additionalInformation": [
    {
	// CDT codes for palliative treatment
      "description": "D9110 D9912"
    }
  ]
}

// 20% coinsurance procedures
{
  "serviceTypeCodes": ["28"],
  "code": "A",
  "coverageLevelCode": "IND",
  "inPlanNetworkIndicatorCode": "W",
  "benefitPercent": "0.2",                 // Patient pays 20%
  "additionalInformation": [
    {
	// CDT codes for consultation and diagnostic procedures
      "description": "D9910 D9911 D9930 D9942 D9943 D9950 D9951 D9952"
    }
  ]
}

// 50% coinsurance procedures
{
  "serviceTypeCodes": ["28"],
  "code": "A",
  "coverageLevelCode": "IND",
  "inPlanNetworkIndicatorCode": "W",
  "benefitPercent": "0.5",                 // Patient pays 50%
  "additionalInformation": [
    {
	// CDT codes for hospital/facility services and anesthesia
      "description": "D9938 D9939 D9940 D9944 D9945 D9946 D9947 D9948 D9949 D9954 D9955 D9956 D9957 D9959"
    }
  ]
}

Get help from eligibility experts

Sometimes, payers do return conflicting benefit entries. We've seen it. In other cases, descriptions aren’t clear about when a benefit applies.

If you need help, reach out. We offer real-time support and answer questions in minutes. Our experts have helped hundreds of teams interpret confusing eligibility responses.

Big takeaway: Use patient control numbers to track a claim from submission to remit.

A patient control number is a tracking ID for a claim.

You create a patient control number when you submit a claim. The payer sends the ID back in follow-up transactions: claim acknowledgments, Electronic Remittance Advice (ERAs), and claim status checks.

This guide gives you best practices for creating patient control numbers and where to find them in each transaction.

Patient control number locations

This table shows the location of patient control numbers across claim-related transactions in Stedi’s JSON API requests and responses.

Best practices for creating patient control numbers

Here's what we found works best in practice:

• Stick to 17 characters.
  X12 states patient control numbers can be up to 20 characters. But some payers cut off values longer than 17 characters in ERAs and claim acknowledgments.
  
  

• Use a unique patient control number for each claim.
  If multiple claims have the same patient control number, you may match the claim to the wrong ERA or acknowledgment.
  
  

• Use alphanumeric characters only.
  Patient control numbers can contain both letters and numbers. Avoid special characters. Many payers don’t handle them properly.
  
  

• Use random strings.
  Predictable formats, like {patientInitials}-{DOS}, can create duplicates.

Our recommendation: Use nanoid or a similar library to create a strong, unique 17-character patient control number for each claim.

Claim submission

You set the patient control number when you submit the claim.

For JSON-based claims submission endpoints, pass the patient control number in the patientControlNumber field. For example, using the Professional Claims (837P) JSON endpoint:

curl --request POST \
  --url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
  ...
  "claimInformation": {
    "patientControlNumber": "ABCDEF12345267890",  // Patient control number 
    "claimChargeAmount": "109.20",
    ...
  }
  ...
}'

Claim acknowledgments

A 277CA claim acknowledgment indicates whether the claim was accepted or rejected. Payers send claim acknowledgments to the clearinghouse that submitted the claim.

Listen for claim acknowledgments
Use a webhook or the Poll Transactions endpoint to listen for incoming 277 transactions. When a claim acknowledgment arrives, use the transaction ID to fetch the acknowledgment using Stedi’s Claims acknowledgment endpoint.

Retrieve claim acknowledgments
The claim’s claimStatus.patientAccountNumber and claimStatus.referencedTransactionTraceNumber fields contain the claim’s patient control number. You can use either of these fields in your application logic.

{
  "claims": [
    {
      "claimStatus": {
        "claimServiceBeginDate": "20250101",
        "claimServiceEndDate": "20250101",
        "clearinghouseTraceNumber": "01J1SNT1FQC8ABWD44MAMBDYKA",
        "patientAccountNumber": "ABCDEF12345267890", // Patient control number
        "referencedTransactionTraceNumber": "ABCDEF12345267890", // Patient control number
        ...
      },
      ...
    },
    ...
  ]
}

ERAs

An 835 ERA contains details about payments for a claim, including explanations for any adjustments or denials.

ERAs require transaction enrollment
Payers send ERAs to the provider's designated clearinghouse. The provider designates this clearinghouse through transaction enrollment. Providers can receive ERAs at one clearinghouse per payer.

Listen for ERAs
Use a webhook or the Poll Transactions endpoint to listen for incoming 835 transactions. When an ERA arrives, you can use the transaction ID to fetch the ERA using Stedi’s 835 ERA endpoint.

Retrieve ERAs
The endpoint’s response contains the patient control number in the claimPaymentInfo.patientControlNumber field.

{
  ...
  "transactions": [
    {
      ...
      "detailInfo": [
        {
          "assignedNumber": "1",
          "paymentInfo": [
            {
              "claimPaymentInfo": {
                "patientControlNumber": "ABCDEF12345267890", // Patient control number
                "patientResponsibilityAmount": "30",
                ...
              },
              ...
            },
            ...
          ]
        }
      ],
      ...
    }
  ]
}

Claim status checks

Unlike claim acknowledgments or ERAs, you run 276/277 claim status checks in real time.

Claim status requests
The Real-Time Claim Status JSON endpoint doesn’t accept a patient control number as a request parameter. Instead, you pass in information for the payer, provider, patient, and date of service. For detailed guidance, see our recommended base JSON request.

Claim status responses
If the payer has multiple claims on file that match the information you provided, the response may include multiple claims. Each claim’s claimStatus.patientAccountNumber field contains the claim’s patient control number.

{
  "claims": [
    {
      "claimStatus": {
        "patientAccountNumber": "ABCDEF12345267890",  // Patient control number
        "amountPaid": "95.55",
        ...
      },
      ...
    }
  ],
  ...
}

Other tracking IDs

Tracking service line items

This guide covers tracking at the claims level. However, you can also track service line items from a claim in claim acknowledgments and ERAs. For details, check our docs:

• Service lines in 277CA claim acknowledgments

• Service lines in 835 ERAs

Payer claim control numbers

Don’t use payer claim control numbers for tracking.
Payers use payer claim control numbers to internally track claims. You can use them when talking to a payer, but they can’t easily be matched to a claim submission.

Payer claim control numbers are returned in the following fields:

• claimStatus.tradingPartnerClaimNumber of claim acknowledgment responses

• claimPaymentInfo.payerClaimControlNumber of ERA responses

X12 control numbers

If you’re using Stedi’s JSON APIs, you can safely ignore X12 control numbers.
X12 control numbers are used by Stedi and payers for general EDI file processing. If you’re using our JSON APIs, Stedi manages them for you. They’re not useful for tracking claims or individual transactions.

Process claims with Stedi

Stedi’s JSON Claims APIs are available on all paid Stedi developer plans.

To try it out, request a free trial. We get most teams up and running in less than a day.

You can now submit 837I institutional claims as X12 EDI using the new Institutional Claims X12 API endpoint.

Most Stedi customers submit 837I claims using our JSON-based Institutional Claims endpoint. JSON is familiar and easy to work with. You can build an integration faster.

But if you already work with X12, converting to JSON wastes time. The new endpoint accepts X12 directly. 

Previously, X12 submissions of 837I claims required SFTP. With SFTP, you have to wait for files to get errors or validation. With the API, you get instant responses. Development is faster, and debugging is easier.

Use the Institutional Claims X12 endpoint

To use the endpoint, send a POST request to the https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/institutionalclaims/v1/raw-x12-submission endpoint. Include an 837I X12 payload in the request body’s x12 field:

curl --request POST \
  --url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/institutionalclaims/v1/raw-x12-submission" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "x12": "ISA*00*          *00*          *ZZ*001690149382   *ZZ*STEDITEST      *240630*0847*^*00501*000000001*0*T*>~GS*HC*001690149382*STEDITEST*20240630*084744*000000001*X*005010X223A2~ST*837*3456*005010X223A2~BHT*0019*00*0123*20061123*1023*CH~NM1*41*2*PREMIER BILLING SERVICE*****46*TGJ23~PER*IC*JERRY*TE*7176149999~NM1*40*2*AETNA*****46*AETNA~HL*1**20*1~NM1*85*2*TEST HOSPITAL*****XX*1234567890~N3*123 HOSPITAL ST~N4*NEW YORK*NY*10001~REF*EI*123456789~HL*2*1*22*1~SBR*P********CI~NM1*IL*1*DOE*JOHN****MI*123456789~NM1*PR*2*AETNA*****PI*AETNA~HL*3*2*23*0~PAT*19~NM1*QC*1*DOE*JOHN~N3*123 MAIN ST~N4*NEW YORK*NY*10001~DMG*D8*19800101*M~CLM*26403774*150***11>B>1*Y*A*Y*I~DTP*472*D8*20240101~REF*D9*17312345600006351~NM1*82*1*SMITH*JANE****XX*1234567890~PRV*AT*PXC*207Q00000X~LX*1~SV2*0450*HC>99213*150****1~DTP*472*D8*20240101~SE*29*3456~GE*1*000000001~IEA*1*000000001~"
  }'

Stedi validates the EDI and sends the claim to the payer.

The endpoint returns a response from Stedi in JSON. The JSON contains information about the claim you submitted and whether the submission was successful:

{
  "claimReference": {
    "correlationId": "01J1M588QT2TAV2N093GNJ998T",
    "formatVersion": "5010",
    "patientControlNumber": "26403774",
    "payerID": "AETNA",
    "rhclaimNumber": "01J1M588QT2TAV2N093GNJ998T",
    "serviceLines": [
      {
        "lineItemControlNumber": "1"
      }
    ],
    "timeOfResponse": "2024-07-10T22:05:32.203Z"
  },
  "controlNumber": "000000001",
  "httpStatusCode": "200 OK",
  "meta": {
    "traceId": "b727b8e7-1f00-4011-bc6e-e41444d406d8"
  },
  "payer": {
    "payerID": "AETNA",
    "payerName": "Aetna"
  },
  "status": "SUCCESS",
  "tradingPartnerServiceId": "AETNA"
}

For complete details, check out the Institutional Claims (837I) Raw X12 API reference.

Try it free

The Institutional Claims X12 endpoint is available for all paid Stedi developer accounts.

To try it out, request a free trial. Most teams are up and running in under a day.

Big takeaway: Most payers omit carveout benefits from eligibility responses, but many include the carveout administrator's information. Run a second eligibility check with the carveout admin for full benefits details.

Carveout benefits can leave gaps in your eligibility workflows.

For example, many Blue Cross Blue Shield (BCBS) plans carve out mental (behavioral) health benefits to Magellan, a mental health payer.

A BCBS eligibility check may confirm the patient has mental health coverage. But the response doesn’t contain details about mental health benefits. No co-pays, deductibles, or limitations – just basic information for Magellan.

To get the full benefit details, you need to run a separate check with Magellan. This guide shows you how and what to look for in the eligibility response.

What’s a carveout?

A carveout is when the primary payer for a plan lets another entity handle certain benefits.

Often, carveout administrators specialize in benefits for a particular service, such as mental health services or pharmacy benefits.

Carveouts in eligibility responses

Payers aren’t required to return carveout benefits in eligibility checks.
Most don't. If they do, Stedi passes along what the payer provides.

Many payers return the carveout admin’s information.
However, it’s not guaranteed. If you’re using Stedi’s JSON Eligibility API, the carveout admin’s information is typically included in a related benefitsInformation entry in the response. Look for:

• code = U (Contact Following Entity for Eligibility or Benefit Information)
  OR
  code = 1 (Active coverage)

• serviceTypeCodes containing a related Service Type Code (STC) 

• benefitsRelatedEntities object containing contact information for the carveout admin.

• If present, benefitsRelatedEntities.entityIdentificationValue contains the patient’s member ID for the carveout admin.

Also look for key phrases in additionalInformation.description. These may be in a separate benefitsInformation entry with code = D (Benefit Description).

For example:

{
  "benefitsInformation": [
    {
      "code": "U",	// Contact Following Entity for Eligibility or Benefit Information
      "serviceTypeCodes": [
        "MH"		// Mental Health
      ],
      ...
      "benefitsRelatedEntities": [
      {
        "entityIdentifier": "Third-Party Administrator",
        "entityType": "Non-Person Entity",
        "entityName": "Acme Health Payer",
        "entityIdentificationValue": "123456789", // Member ID for the carveout admin
        "contactInformation": {
          "contacts": [
            {
              "communicationMode": "Telephone",
              "communicationNumber": "1234567890"
            }
          ]
        }
      },
      ...
    },
    {
      "code": "D",                        // Benefit Description
      "serviceTypeCodes": ["MH"],
      "additionalInformation": [
        {
          "description": "BEHAVIORAL HEALTH MANAGED SEPARATELY"
        }
      ]
    }
  ],
  ...
}

Tip: Don’t rely on benefitsRelatedEntities.entityIdentifier to identify carveout admins. The value can vary between payers.

The carveout benefits runbook

Payers don’t consistently return carveout admin information. But when they do, you follow these steps to get the full carveout benefits:

1. Run an eligibility check for the primary payer.
   Use a related STC. For tips, see our STC testing docs.
   
   

2. Look for the carveout admin’s information.
   Check for benefitsInformation entries with a related STC in serviceTypeCodes and a benefitsRelatedEntities section.
   
   The benefitsRelatedEntities.entityName field will contain the carveout admin’s name. If present, benefitsRelatedEntities.entityIdentificationValue contains the patient’s member ID for the carveout admin. See the above example.
   
   

3. Get the carveout admin’s ID.
   Use Stedi's Payer Search API or Payer Network to get the payer ID for the carveout admin’s name.
   
   

4. Run an eligibility check for the carveout admin.
   Use the patient’s member ID for the carveout admin. If you use the right STC, many carveout admins will return the missing carveout benefits.
   
   The STC may differ from the primary payer. See our STC testing docs for tips.

Other ways to get carveout benefit details

If checks alone can’t get you the carveout benefits you need, try one of these methods:

Check the member ID card.
The back often lists information for carveout benefits and payers. The card may provide enough information on its own. If not, it may give you enough to run an eligibility check for the carveout admin.

Make a telephone call to the primary payer.
Use an AI voice agent to do this programmatically.

Check the primary payer’s website or portal.
Some payers post plan coverage documents with carveout details on their public website. Others may require you to log in to their portal. For programmatic access, create a scraper or use a scraping vendor.

Claims for carveout benefits

Claims for carveout benefits are often a form of crossover claim.

Submit the claim to the primary payer first. If the primary payer supports crossover, they’ll automatically forward the claim to the carveout admin. If not, you’ll need to submit a separate claim directly to the carveout admin.

You may need to complete a separate transaction enrollment for the carveout admin. For more guidance, see our crossover claims docs.

Carveouts vs. secondary or tertiary insurance

Carveouts are different from secondary or tertiary insurance:

• Carveouts are part of a single health plan.
  Secondary and tertiary insurance is when a patient has multiple, separate health plans.
  
  

• Carveouts don’t show up in coordination of benefits (COB) checks.
  COB checks are intended for cases where a patient has multiple health plans.
  
  

• You can have both carveout benefits and a secondary (or tertiary) plan.
  After the primary payer or carveout admin adjudicates a claim for carveout benefits, you can submit a claim for the remaining balance to the secondary health plan. Sometimes, the primary payer will automatically forward the claim to the secondary payer.
  
  If you’re unsure which plan is the primary or secondary, use a COB check to find out.

Get expert support

Carveouts – and how they show up in eligibility responses – vary widely by payer and plan. Knowledgeable support can make a difference.

Stedi offers real-time support from experts over Slack or Teams. Request a free trial and try it out.

Big takeaway: For Medicare Advantage plans, send eligibility checks to the commercial payer, not CMS.

Verification and billing for Medicare Advantage plans can be confusing. It’s easy to send a request to the wrong payer or miss an important detail.

This guide aims to make it simple. It covers how to spot Medicare Advantage plans, where to send eligibility checks, and how to submit claims.

What is Medicare Advantage?

A Medicare Advantage plan – also called Medicare Part C – is a health plan from a private payer that’s approved by Medicare. It serves as an alternative to Original Medicare. 

Medicare Advantage plans cover benefits included in Medicare Part A (hospital benefits) and Part B (medical benefits). Along with those benefits, Medicare Advantage plans often provide extra coverage like prescription drugs, vision, dental, and hearing. 

Eligibility checks for Medicare Advantage plans

When running eligibility checks for Medicare Advantage plans:

• Send the check to the plan’s commercial payer.
  Don’t send the check to the National Centers for Medicare & Medicaid Services (CMS) – the government payer for Medicare.
  
  

• Check the payer ID.
  Some payers have separate payer IDs for Medicare Advantage plans and other lines of business, like employer-sponsored plans. For example, CareFirst Medicare Advantage vs CareFirst Blue Cross Blue Shield Maryland.
  
  Use the payer ID for the Medicare Advantage payer. You can get the ID using the Stedi Payer Network or Payers API.
  
  

• Transaction enrollment isn’t typically required.
  Most Medicare Advantage payers don’t require transaction enrollment for eligibility checks. You can check for transaction enrollment requirements using the Stedi Payer Network or Payers API.
  
  

• Use the commercial plan’s member ID – if required.
  Many Medicare Advantage plans allow eligibility checks with just the patient’s first name, last name, and date of birth.
  
  If a member ID is required, use the commercial plan’s member ID, not the patient’s Medicare Beneficiary Identifier (MBI) used for Medicare.

How to spot a Medicare Advantage plan in an eligibility response

Providers often want to know if a plan is a Medicare Advantage plan. These plans often have different prior authorization requirements and reimbursement rates than traditional Medicare.

To spot a Medicare Advantage plan in a commercial payer’s eligibility response, look for either of the following indicators in the JSON Eligibility API's response:

• benefitsInformation.insuranceTypeCode = MA (Medicare Part A) or MB (Medicare Part B)
  
  

• planInformation.hicNumber or benefitsInformation.benefitsAdditionalInformation.hicNumber, which contains the patient’s MBI.

{
  "benefitsInformation": [
    {
      "code": "1",                 // Active Coverage
      "serviceTypeCodes": ["30"],  // Health Benefit Plan Coverage
      "insuranceTypeCode": "MA",   // Medicare Part A
      ...
      "benefitsAdditionalInformation": {
        "hicNumber": "1AA2CC3DD45" // Patient's MBI
      },
      ...
    },
    ...
  ],
  ...
}

What is a HIC number?
The hicNumber property name refers to a Health Insurance Claim (HIC) Number, the old member ID system for Medicare. HIC numbers were usually a Social Security Number plus a letter, such as 123-45-6789A.

CMS now uses MBIs for member IDs – and that’s usually what fills these properties when present. MBIs are 11 characters: numbers and capital letters, no spaces. For MBI formatting rules, see CMS’s Understanding the MBI doc.

Medicare Advantage plans in CMS eligibility responses

Sometimes, a patient may be confused about whether they’re covered by Original Medicare or Medicare Advantage.

You may run an eligibility check with CMS (the Medicare government payer) or an MBI lookup (which returns a CMS eligibility response on a match), only to discover through the response that the patient actually has Medicare Advantage coverage.

If the patient has Medicare Advantage, the eligibility response from CMS will include a benefitsInformation object with the following:

• code = U (Contact Following Entity for Eligibility or Benefit Information)

• serviceTypeCodes = 30 (Health Benefit Plan Coverage)
  OR
  serviceTypeCodes = 30 AND CQ (Case Management

• insuranceTypeCode = HM (HMO), HN (HMO - Medicare Risk), IN (Indemnity), PR (PPO), or PS (POS)

• benefitsInformation.benefitsRelatedEntities.entityIdentifier = Primary Payer

The name of the Medicare Advantage payer is usually in the object’s benefitsRelatedEntities.entityName property. For example:

{
  "benefitsInformation": [
    {
      "code": "U",	// Contact Following Entity for Eligibility or Benefit Information
      "serviceTypeCodes": ["30"],	 // Health Benefit Plan Coverage
      "insuranceTypeCode": "HM",	 // HMO
      "benefitsRelatedEntities": [
        {
          "entityIdentifier": "Primary Payer",
          "entityName": "BLUE CROSS MEDICARE ADVANTAGE",
          ...
        }
      ],
      ...
    },
    ...
  ],
  ...
}

Note: Don’t use CMS eligibility checks to verify Medicare Advantage coverage. CMS prohibits this.

Coordination of benefits (COB) checks for Medicare Advantage

Medicare Advantage patients often have supplemental insurance or employer-sponsored coverage that could be primary or secondary.

A COB check can help you determine the correct billing order. Most Medicare Advantage plans are supported.

Medicare vs. Medigap

Although Medicare Advantage patients often have supplemental insurance, they won’t have Medigap.

Medigap – also called Medicare Supplement Insurance – is supplemental insurance that helps pay out-of-pocket costs (like deductibles and coinsurance) for people with Original Medicare. 

• Medigap is completely separate from Medicare Advantage.
  
  

• You can’t have Medigap and Medicare Advantage at the same time.
  Payers can’t sell someone Medigap if they’re on a Medicare Advantage plan.
  
  

• Medigap only works with Original Medicare, not Medicare Advantage. 

Medicare Advantage claims

Submit claims for Medicare Advantage plans to the commercial payer – just as you would for any commercial health plan. Don’t send Medicare Advantage claims to CMS.

Get started

You can run eligibility checks, MBI lookups, and COB checks – and submit claims – using any paid Stedi developer plan.

If you don't have a paid developer plan, request a free trial. We get most teams up and running in under a day.

A spotlight is a short-form interview with a leader in health tech. In this spotlight, you'll hear from Federico Ruiz, Founder and CEO of Puppeteer AI.

What does Puppeteer do?

Puppeteer builds AI agents that handle the patient work that clogs your day: calls, follow-ups, symptom checks, scheduling, and routine questions, so clinicians can focus on care. Our agents hold natural phone conversations, ask clinically relevant questions, summarize to the chart, and keep checking in after the visit. Think continuous, proactive navigation of each patient’s journey, with humans in the loop for anything sensitive or complex. The outcome is less admin, fewer missed appointments, and more capacity without more headcount.

How did you end up working in health tech?

I was working at Meta at the time, but my head was already in the space of building something of my own. I had just launched LangAI, and I was really interested in how agents could evolve beyond the narrow use cases we were seeing then. Back in those days, “agents” weren’t a mainstream concept – it still felt like an open frontier.

I stayed close with Alan and the founders of Light-it, and through those conversations, the opportunity came up to work on a project together. Their background in healthcare and my focus on agents fit naturally, and that collaboration turned into the starting point for Puppeteer, a company built around the idea that agents could actually support clinicians and patients in meaningful ways.

So the path wasn’t a grand plan. It was Meta giving me exposure to big-scale problems, LangAI showing me the potential of agents, and trusted friendships that created the right conditions to start something new in healthcare.

How does your role intersect with revenue cycle management (RCM)?

When you think about RCM, a lot of the problems trace back to the same operational gaps: missed appointments, incomplete paperwork, delays in follow-up, or patients not having the right information at the right time. My role is to make sure our agents close those gaps.

For example, if someone misses an appointment, the agent can call right away to reschedule. If benefits need to be confirmed, the agent can collect and structure that information before the visit. And in value-based programs, our agents can keep nudging patients on adherence and preventive care, which not only improves outcomes but also makes sure organizations meet their quality metrics.

So my intersection with RCM isn’t on the billing side, it’s on the upstream side: making sure the right things happen with patients, consistently, so that revenue capture becomes a natural outcome of smoother operations.

What do you think RCM will look like two years from now?

I think we’ll see a shift from RCM being a back-office function to something that’s much closer to the point of care. Conversations with patients, whether over the phone, in the waiting room, or through an AI agent, will generate structured data that flows directly into eligibility checks, claims, and follow-ups. The gap between “talking to a patient” and “having everything ready for billing” will keep getting smaller.

At the same time, value-based care is going to push revenue away from just transactions and more toward outcomes. That means systems will need to stay connected to patients long after the visit, reminding them about meds, nudging them to book labs, checking in on recovery. The financial side will depend on how well organizations can keep patients engaged and adherent, not just how fast they code a claim.

In short, RCM will still be about dollars, but it will feel less like accounting and more like care continuity, because that’s where the revenue will come from.

You can turn payer names into payer IDs (or the reverse) in Google Sheets using the Search Payers API endpoint. This guide tells you how.

Tip: If you just want a full list of Stedi’s payers in a spreadsheet-friendly format, you can download the latest payer CSV from the Stedi Payer Network or use the List Payers CSV endpoint.

Requirements

To use the Search Payers API endpoint, you need a paid Stedi developer account. To try it out free, request a trial.

Step 1. Create a production API key

1. Log in to Stedi.

2. Click your account name at the top right of the screen.

3. Select API Keys.

4. Click Generate new API Key.

5. Enter a name for your API key.

6. Select Production mode.

7. Click Generate. Stedi generates an API key and allows you to copy it.

If you lose the API key, delete it and create a new one.

Step 2. Open Google Sheets

In your Google Sheet spreadsheet, place your payer names or payer IDs in column A. You can mix them if desired. For example:

How this may look in your spreadsheet:

Step 3. Create the script

1. In the Google Sheets menu, click Extensions > Apps Script.

2. Delete what’s in the editor.

3. Paste in the following code. Replace YOUR_STEDI_API_KEY with your Stedi API key.

   /**
    * Returns the payer name and primary payer ID from Stedi's Payer Search API.
    * Usage: =STEDI_PAYER_INFO(A2)
    * Output: [[payer name, primary payer ID]]
    */
   function STEDI_PAYER_INFO(query) {
     if (!query) return [["", ""]];
     const apiKey = "YOUR_STEDI_API_KEY"; // Replace with your Stedi API key
     const encodedQuery = encodeURIComponent(query);
     const url = "https://healthcare.us.stedi.com/2024-04-01/payers/search?query=" + encodedQuery;
     const options = {
       "method": "get",
       "headers": { "Authorization": apiKey },
       "muteHttpExceptions": true
     };
     try {
       const response = UrlFetchApp.fetch(url, options);
       const status = response.getResponseCode();
       if (status === 403) {
         return [["Error: Invalid or missing API key", ""]];
       }
       const result = JSON.parse(response.getContentText());
       if (
         result.items &&
         result.items.length > 0 &&
         result.items[0].payer &&
         result.items[0].payer.displayName &&
         result.items[0].payer.primaryPayerId
       ) {
         return [[
           result.items[0].payer.displayName,
           result.items[0].payer.primaryPayerId
         ]];
       } else {
         return [["No match found", ""]];
       }
     } catch (e) {
       return [["Error: " + e.message, ""]];
     }
   }

4. Click the Save project to Drive icon or press Ctrl + S.

The script creates an =STEDI_PAYER_INFO() formula that outputs the payer name and primary payer ID from the Search Payers API endpoint.

Step 4. Use the Google Sheets formula

In your Google Sheets spreadsheet, use the =STEDI_PAYER_INFO() formula to get the payer name and primary payer ID for each value in column A. For example:

The search supports fuzzy matching. The formula returns the closest match available.

Note: The payer names returned by the Search Payers API endpoint are intended for routing transactions – not for display in patient-facing UIs. If you need a patient-facing name, build your own list and map the names to Stedi payer IDs.

Get started

The Payers API is available on Stedi’s paid developer plan.

To try it out, request a free trial. Most teams are up and running in less than a day.

Today, we’re announcing Stedi integrated accounts and Stedi apps – a new set of capabilities that allows end customers of Stedi’s Platform Partners to have Stedi accounts of their own.

Integrated accounts drastically reduce the amount of clearinghouse functionality that partners need to build themselves.

Instead of partners having to replicate Stedi’s user interfaces within their own applications, providers can use their own dedicated Stedi accounts that are pre-integrated into partner platforms, such as Revenue Cycle Management (RCM) systems, Practice Management Systems (PMS), and Electronic Healthcare Record (EHR) systems. 

Making integrations easier

Platform Partners have used Stedi’s clearinghouse APIs to incorporate healthcare claims and eligibility functionality into their own systems. To build this functionality, a partner typically maintains a single Stedi account that powers all of the transactions for their provider customers. 

For example, an RCM system would submit claims to a single Stedi account using Stedi’s Claims API or SFTP, and would create transaction enrollment requests for each provider’s required ERA enrollments. In other words, the RCM system would use a single Stedi account in a multitenant fashion – that is, with multiple end provider customers (such as an independent practitioner, group practice, or health system) operating within a single Stedi account.

This multitenant pattern has meant that each Stedi partner needed to replicate much of Stedi’s functionality within their own platform, since providers needed the ability to perform all necessary actions within the partner’s system. For example:

• Any partner that offered functionality related to ERAs needed to build out a complex set of user interfaces and email notifications for transaction enrollment.
  
  

• Any partner that offered the ability to submit claims needed to also have the ability to manually modify and resubmit claims that are rejected or denied.
  
  

• Any partner that offered eligibility checks needed to build out functionality for troubleshooting failed attempts and functionality for batch uploads. These partners were also on the hook for support, even if Stedi was better positioned to help fix the issue.

This functionality is complex and time-consuming to build, and each time Stedi launched a new feature like delegated signature authority or the Stedi Agent, it meant that our partners needed to dedicate engineering, product, and design resources to incorporate Stedi’s latest functionality. 

For these reasons, the number one feature request we’ve heard from our partners is that they want to allow their providers to have Stedi accounts of their own. This way, providers can use Stedi’s functionality directly, rather than partners needing to replicate it.

Integrated Stedi accounts give providers that access. Stedi apps connect integrated accounts to one or more partner platforms.

Integrated accounts

Integrated accounts are simplified Stedi accounts that are designed to be friendly to non-technical users. The more complex developer-focused functionality – such as configuring API access and webhooks, and viewing raw JSON payloads – has been removed. 

The interfaces for common tasks such as running and troubleshooting eligibility checks, modifying and resubmitting claims, and managing transaction enrollments have been streamlined, so platforms can direct providers to their Stedi accounts for this functionality rather than building and maintaining UIs for those workflows themselves. Integrated accounts also include other standard Stedi account features, including member access, role-based access control (RBAC), and multi-factor authentication (MFA).

Create an integrated account

Providers can create integrated accounts using a self-service signup flow:

1. Create a Stedi sandbox account.

2. In the sandbox, click Upgrade. 

3. Select Integrated Account and follow the prompts.

Stedi apps

Integrated accounts can install Stedi apps, which are Stedi’s pre-built integrations to a growing list of third-party RCM, PMS, EHR, and other platforms.

Stedi apps allow providers to quickly connect their Stedi account to these external systems using preconfigured SFTP credentials and API keys.

They can also grant Stedi portal access for external support and implementation teams to assist with setup and ongoing support.

Transaction enrollment registers a provider to exchange specific transaction types with a payer. For Electronic Remittance Advice (ERAs), enrollment is always required. For other types of transactions, enrollment requirements depend on the payer.

Most traditional clearinghouses treat transaction enrollment as a cost center. Because ERA revenue is small, they try to minimize their involvement and put the work on you. You end up filling out PDFs, chasing signatures, and checking portal statuses just to onboard a provider.

Many Stedi customers manage transaction enrollment for hundreds or thousands of providers. At that scale, enrollment can be an operational burden. One team told us that before switching to Stedi, their staff spent 25–30% of their time just managing enrollment requests.

At Stedi, we treat transaction enrollment as a core part of our product experience. We offer fully managed, API-based transaction enrollment designed to reduce operational overhead, eliminate manual steps, and improve visibility. So you can scale provider onboarding without scaling manual work.

This guide explains how transaction enrollment works at Stedi, how we designed it, and how to manage enrollments at scale. It incorporates practices we’ve seen high-scaling teams use to streamline provider onboarding.

Types of enrollment

Transaction enrollment is just one part of the broader enrollment process. It’s the final step – and the only one that involves working with your clearinghouse. Providers typically complete three types of enrollment to work with a payer:

• Credentialing – Verifies licenses, training, and qualifications.
  
  

• Payer enrollment – Registers the provider with specific insurance plans. This is typically when providers set rates with a payer.
  
  

• Transaction enrollment – Enables the provider to exchange transactions through a clearinghouse.

This guide focuses only on transaction enrollment. For help with credentialing or payer enrollment, contact the payer or a credentialing service, like CAQH, Assured, or Medallion.

Transaction enrollment as a product

At Stedi, we take on as much of the transaction enrollment process as possible and work constantly to automate the rest. If a manual step is required, it’s built into the product with clear next steps and full visibility.

Our goal is to eliminate back-and-forth. You shouldn’t need to track spreadsheets or email threads to onboard a provider.

Key parts of this approach include:

• API-first design – Submit and track enrollment requests programmatically using the Enrollments API. Built for automation at scale, with full visibility into status and next steps. We also support UI and bulk CSV upload.
  
  

• One-click enrollment – For payers that support one-click enrollment, just submitting an enrollment request is enough. You don’t need to take any additional steps. One-click enrollment is available for 850+ payers. You can check support using the Payers API or the Payer Network.
  
  

• Delegated signature authority – For payers that still require signed forms, you can authorize Stedi to sign on your behalf. It’s a one-time setup that can eliminate 90% of your enrollment paperwork.
  
  

• Streamlined timelines – Enrollment timelines vary by payer, but most enrollments through Stedi complete in 24-48 hours.

When enrollment is required

Before exchanging transactions with a payer, check whether enrollment is required for the transaction type. Common requirement patterns:

• 835 ERAs. Always require enrollment. Payers can only send a provider’s ERAs to one clearinghouse at a time, so they need to know where to route them.

• 270/271 eligibility checks. A few payers, including Medicare, require enrollment. Most major payers don’t.

• 837P/837D/837I claim submissions. Most major payers don’t require enrollment, but certain payers do – TRICARE West Region and TRICARE East are two examples that do.

Use the Stedi Payer Network or Payers API to see which payers require enrollment by transaction type.

For example, the following JSON payer record from the Payers API indicates enrollment is required for 835 ERAs (claimPayment):

{
  "displayName": "Blue Cross Blue Shield of North Carolina",
  "primaryPayerId": "BCSNC",
  ...
  "transactionSupport": {
    "claimPayment": "ENROLLMENT_REQUIRED",
   ...
  }
}

How to submit an enrollment request

If a transaction type requires enrollment, Stedi’s Enrollments API lets you automate related requests at scale. Here’s how it works:

Step 1. Create a provider record.
Use the Create Provider endpoint to submit the provider’s basic information:

• Name
  
  

• NPI
  
  

• Tax ID – Either an Employer Identification Number (EIN) or Social Security Number (SSN), depending on whether the provider is a corporate entity or not.
  
  

• Contacts – Information for one or more provider contacts.
  
  Ensure this contact information – excluding email and phone number – matches what the payer has on record for the provider. Some payers reject enrollment requests if the name or address doesn’t match what’s already on file.
  
  The payer may use the provided email and phone to reach out with enrollment steps. If you’re a vendor representing a provider, you can use your own email and phone to have the payer contact you instead.
  
  When creating an enrollment request in Stedi, you must select one of these contacts as the primary contact.

curl --request POST \
  --url "https://enrollments.us.stedi.com/2024-09-01/providers" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "Bob Dental Inc",
    "npi": "1999999992",
    "taxIdType": "EIN",
    "taxId": "555123456",
    "contacts": [
      {
        "firstName": "Bob",
        "lastName": "Dentist",
        "email": "bob@example.com",
        "phone": "555-123-2135",
        "streetAddress1": "123 Some Street",
        "city": "Chevy Chase",
        "zipCode": "20814",
        "state": "MD"
      },
    ]
  }'

The request returns an id for the provider. You can use this ID to reference the provider record across multiple enrollment requests.

{
  ...
  "id": "10334e76-f073-4b5d-8984-81d8e5107857",
  "name": "Bob Dental Inc",
  "npi": "1999999992",
  ...
}

Step 2. Submit the enrollment request.
Use the Create Enrollment endpoint to submit the actual transaction enrollment request.

In the request, specify:

• The provider ID, returned by the Create Provider endpoint or fetched using the List Providers endpoint.
  
  

• The payer ID. You can get this using the Payers API.
  
  

• The transaction types (for example,  claimPayment, eligibilityCheck) you want to enroll the provider for.
  
  

• A primary contact – One of the contacts from the provider record.
  
  

• A userEmail address. Stedi will send notifications for enrollment status updates to this email address. If you’re a vendor representing a provider, you can use your own email address here.
  
  

• A status for the request. Set the status to DRAFT if you plan to work on the request later or want to wait to submit the request. Otherwise, set the status to SUBMITTED to submit the request.

curl --request POST \
  --url "https://enrollments.us.stedi.com/2024-09-01/enrollments" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "provider": {
      "id": "db6665c5-7b97-4af9-8c68-a00a336c2998"
    },
    "payer": {
      "idOrAlias": "87726"
    },
    "transactions": {
      "claimPayment": {
        "enroll": true
      }
    },
    "primaryContact": {
      "firstName": "John",
      "lastName": "Doe",
      "email": "test@example.com",
      "phone": "555-123-4567",
      "streetAddress1": "123 Some Str.",
      "city": "A City",
      "state": "MD",
      "zipCode": "20814"
    },
    "userEmail": "test@example.com",
    "status": "SUBMITTED"
  }'

Step 3. Track enrollment status
Each enrollment request moves through a defined set of statuses.

You can track the status of enrollment requests using the List Enrollments endpoint or the Stedi portal.

The endpoint lets you pull the status of every request and filter by status or transaction type. This lets you build custom views into your own systems or dashboards. For example:

curl --request GET \
  --url "https://enrollments.us.stedi.com/2024-09-01/enrollments?status=LIVE" \
  --header "Authorization: <api_key>"

You’ll also get email notifications whenever an enrollment status changes, like when it moves from PROVISIONING to LIVE, or if it's rejected. If an enrollment requires action on your part, we’ll reach out to you using Slack, Teams, or email with clear next steps.

Get started

Fully managed transaction enrollment is available on all paid Stedi plans.

If you’re not yet a customer, request a free trial. We get most teams up and running in under a day.

A spotlight is a short-form interview with a leader in health tech. In this spotlight, you'll hear from Cassandra Bahre, Product Manager for Virtual Visit Revenue at Included Health.

What does Included Health do?

Included Health delivers personalized all-in-one healthcare to support members holistically – mind, body, and wallet. We offer a wide range of services, from care navigation to virtual care, including urgent care, primary care, and behavioral health to claims and member advocacy.

How did you end up working in health tech?

After several years in product consulting across numerous industries, I was personally struck by how insurance and benefits complexity directly influence the patient experience. I learned this firsthand when my child was diagnosed with cancer shortly after her first birthday (today she is cancer-free!). I faced numerous billing issues over the subsequent years, from a prior authorization being denied as not medically necessary to serious overbilling by the practice because prepaid funds weren't correctly applied to the claim balance.

My knowledge of revenue cycle management (RCM) granted me the ability to advocate for myself, but the billing process was still a source of unnecessary trauma during my family’s journey. My personal mission is to help others understand and navigate the healthcare system so they can advocate for themselves, too. Health tech is the perfect place to combine my skills and my goal!

How does your role intersect with revenue cycle management (RCM)?

As the Product Manager for Virtual Visit Revenue at Included Health, I'm the voice of our members and our RCM Operations team in our virtual care business.

For our members, I focus on the billing experience, advocating for cost transparency and reliable, secure payment processing. My goal is to help them focus on getting care without the stress of managing the financial side of their healthcare experience.

For our RCM Ops team, I support revenue realization for virtual visits. I collaborate with cross-functional teams across the entire revenue cycle – from eligibility and registration to coding, claims submission, denial management, and payment posting. By optimizing for an efficient claims experience, we reduce administrative overhead on the member, instilling trust that they can rely on us to effectively manage their benefits. 

When my team and I are successful, we provide high-quality, cost-transparent care to our members and recognize revenue for the business in ways that are scalable and sustainable for our operational and care delivery teams. 

What do you think RCM will look like two years from now?

I believe RCM operations are set for a deep evolution over the next couple of years. We're already seeing a rapid rise in AI usage to automate repetitive, manual tasks like data entry, eligibility verification, and payment posting. And AI is being used on the payer side by claims departments to review, approve, and deny claims, prior authorizations, and more.

This shift will allow RCM teams to focus on more complex, high-value work that requires critical thinking, such as managing complex denial appeals and analyzing data to find revenue leakages. The future of RCM will be a hybrid model where humans and AI work together, with humans providing the crucial oversight and strategic direction.

This shift will also require a renewed focus on data integrity for Health Tech teams. Healthcare data can no longer be managed in silos; it needs to be clean, accurate, and accessible across the entire revenue cycle to build effective AI agents and provide patients with a more efficient and transparent billing experience.

Lastly, I think members – as healthcare consumers – will increasingly expect cost transparency and accuracy for the care they receive. Included Health aims to make that the standard, and that’s always my north star.

A spotlight is a short-form interview with a leader in health tech. In this spotlight, you'll hear from Bruno Ferrari, Head of Innovation at Light-it.

What does Light-it do?

Light-it is a digital product studio specialized in healthcare. We help healthcare organizations ideate, design, develop, and launch custom software solutions, which range from patient-facing apps all the way to complex internal systems. Our focus is on combining product strategy, technical expertise, and deep knowledge of the healthcare ecosystem to create solutions that are innovative, compliant, and impactful.

How did you end up working in health tech?

I’ve always been passionate about building products that make a real difference – not just nice-to-have tools but solutions that truly impact people’s lives. When I joined Light-it, I quickly realized how uniquely complex and rewarding the healthcare industry is. Unlike many other sectors, the work you do here has a direct influence on people’s well-being, outcomes, and even quality of life. That combination of high stakes and high potential drew me in.

Healthcare comes with its own set of challenges: regulatory requirements, fragmented systems, and a huge diversity of stakeholders. But I’ve always seen those challenges as opportunities for innovation. Technology, when designed right, can unlock new ways of delivering care.

Today, I lead our Innovation and AI initiatives at Light-it. My focus is on exploring how cutting-edge technologies can be applied responsibly to solve some of the industry’s biggest problems. From reducing administrative overhead and clinician burnout to improving clinical documentation and enabling smarter use of data, I’m constantly looking for ways to push the boundaries of what’s possible while keeping compliance and patient trust at the center.

For me, health tech is the perfect intersection of purpose and innovation: you get to experiment with the future of technology, but you also know that every advancement has the potential to make healthcare more humane, efficient, and accessible.

What’s one thing you wish you could change about U.S. healthcare?

I’d love to see more interoperability and the adoption of open, flexible systems across U.S. healthcare. Today, too many providers and platforms operate in silos, which not only leads to inefficiencies but also creates a fragmented, frustrating experience for both patients and clinicians. Every time data is locked within a single system, valuable context is lost, whether it’s a physician missing part of a patient’s history or patients having to repeatedly provide the same information.

If health data could flow more seamlessly and securely across the ecosystem, it would unlock enormous benefits: better coordination of care, reduced administrative costs, improved clinical decision-making, and ultimately healthier, more empowered patients. True interoperability would also accelerate innovation, giving startups and health systems the ability to build on shared infrastructure rather than having to reinvent the wheel each time.

At the core, healthcare should put patients first, and that means enabling them and their providers to access the right information at the right time without unnecessary barriers.

What do you think U.S. healthcare will look like two years from now?

Two years from now, I think U.S. healthcare will look very different. We’ll see a major shift toward AI-enabled workflows and automation. Especially in administrative and clinical documentation, freeing clinicians from routine tasks so they can focus more on patients. Healthcare organizations will increasingly adopt tools that not only reduce the burden on providers but also improve patient engagement and unlock richer, more actionable insights from data. At the same time, trust, safety, and compliance will remain non-negotiable, meaning the solutions that thrive will be those that strike the right balance between innovation and responsibility.

AI is an incredibly powerful force, but its impact depends on how humans guide, test, and validate it before it touches patients' lives. At Light-it, we don’t just watch these trends; we anticipate them. Through our Innovation Lab, we dedicate a team fully focused on exploring, testing, and validating emerging technologies. We run experiments, build proofs of concept, and pressure-test new models so that when clients face new challenges, we’re already a step ahead with proven solutions.

At the end of the day, healthcare is about people. Technology should never replace the human connection; it should empower it. That’s the future we’re working towards: a healthcare system where innovation makes care more human, not less.

If you want to get benefits data, eligibility checks are usually the best place to start. They’re fast, accurate, inexpensive, and easy to automate. In most cases, eligibility responses give you everything you need.

But not always. While there is some required data, payers mostly decide what benefits to include in their eligibility responses. Benefits for some services – like medical nutrition therapy – might be hidden in free-text fields or missing entirely. If the payer leaves information you need out, it can create a gap in your workflow.

Stedi has worked with teams who have filled these gaps – for medical nutritional therapy and other services –  to keep their workflows running.

This guide covers how you can follow their practices to get the most out of eligibility responses and what to do when you need more information. It uses medical nutrition therapy benefits as a running example.

Eligibility responses

Eligibility responses organize benefits by Service Type Codes (STCs), which group services into broad categories like "office visit" or "surgery." You can get the full STC list in our docs.

If you use Stedi’s JSON-based Eligibility API, these benefit details are in the benefitsInformation object array. Each object in the array includes a serviceTypeCodes field with the related STC:

{
  ...
  "benefitsInformation": [
    {
      "code": "1",                        // Active coverage
      "serviceTypeCodes": ["30"],         // General medical
      "timeQualifierCode": "23",          // Calendar year
      "inPlanNetworkIndicatorCode": "Y",  // Applies to in-network services
      "additionalInformation": [
        {
          "description": "Preauthorization required for imaging services."
        }
      ]
    },
    {
      "code": "C",                        // Deductible
      "serviceTypeCodes": ["30"],         // General medical
      "benefitAmount": "1000",            // $1000 annual deductible
      "timeQualifierCode": "23",          // Calendar year
      "inPlanNetworkIndicatorCode": "N"   // Applies to out-of-network services
    },
    {
      "code": "D",                        // Benefit Description
      "serviceTypeCodes": ["30"],
      "additionalInformation": [
        {
          "description": "EXCLUSIONS: COSMETIC SURGERY, EXPERIMENTAL TREATMENTS"
        }
      ]
    }
  ],
  ...
}

For more information on interpreting eligibility responses, see How to read a 271 eligibility response in plain English.

Why gaps can happen

Though not a one-to-one mapping, the STC you send in the eligibility request determines the benefits you get back in the response.

The problem is that X12 5010 – the X12 version mandated by HIPAA –  doesn’t have a specific STC for medical nutrition therapy or some other healthcare services.

If a payer includes benefits for these services in their eligibility responses, it’s usually under a generic STC like 30 (Health Benefit Plan Coverage) or 98 (Professional Physician Visit - Office), often as a free-text description.

These descriptions appear in the additionalInformation.description field of benefitsInformation objects. Look for them with a code of 1 (Active Coverage), D (Benefit Description), or F (Limitations), but they can also show up in other entries too.

Example: Co-pay with free-text note
For example, the following entries relate to a generic STC – BZ (Physician Visit - Office: Well). The additionalInformation.description values indicate they relate to nutritional therapy.

{
  "code": "1",                               // Active coverage
  "serviceTypeCodes": ["BZ"],                // Physician Visit - Office: Well
  "inPlanNetworkIndicatorCode": "W",         // Both in and out-of-network
  "additionalInformation": [
    {
      "description": "NUTRITIONAL THERAPY AND COUNSELING"
  ]
},
{
  "code": "B",                               // Co-pay
  "serviceTypeCodes": ["BZ"],                // Physician Visit - Office: Well
  "benefitAmount": "20",                     // $20 co-pay amount
  "timeQualifierCode": "27",                 // Per visit
  "coverageLevelCode": "IND",                // Individual coverage
  "inPlanNetworkIndicatorCode": "Y",         // In-network benefits
  "additionalInformation": [
    {
      "description": "NUTRITIONAL THERAPY AND COUNSELING"
    }
  ]
},
{
  "code": "B",                               // Co-pay
  "serviceTypeCodes": ["BZ"],                // Physician Visit - Office: Well
  "benefitAmount": "30",                     // $30 co-pay
  "timeQualifierCode": "27",                 // Per visit
  "coverageLevelCode": "IND",                // Individual coverage
  "inPlanNetworkIndicatorCode": "N",         // Out-of-network benefits
  "additionalInformation": [
    {
      "description": "NUTRITIONAL THERAPY AND COUNSELING"
    }
  ]
}

Example: Service limitations using codes
The following example is a bit more complex. One entry (code = D) defines abbreviations like AQ and 086 for Nutritionist. Another entry (code = A) uses these codes to show that nutritionists and other services are excluded from co-insurance for emergency hospital coverage.

{
  "code": "D", // Benefit description. Contains details or notes about the coverage.
  "additionalInformation": [
    {
      // List of abbreviations and their definitions for various codes.
      "description": "BENEFIT ABBREVIATIONS - B0 = NAPRAPATH - IL1, BY = NAPRAPATH GRP - IL1, D0 = VIRTUAL VISITS VENDOR - IL1, D7 = TELEMEDICINE - IL1, MT1, NM1, OK1, TX1, 097 = NAPRAPATH - IL1, 0I = +NON-PLN FOREIGN CLMS - IL1, MT1, NM1, TX1,"
    },
    ...
    {
      // More abbreviations and definitions
      // Note `AQ` is used for nutritionist.
      "description": "AC = AMBULANCE SERV - IL1, MT1, TX1, AG = OPTICIAN (IND) - IL1, MT1, AH = HEARING AID SUPPLIER - IL1, MT1, AM = PHARMACY - IL1, AQ = NUTRITIONIST - IL1, MT1, AX = SKILLED NURSE GRP - IL1, MT1, BG = OPTICIAN GRP - IL1, MT1, 071 = AMBULANCE SERVICES - IL1, MT1, TX1,"
    },
    {
      // More abbreviations and definitions.
      // Note `086` is also used for nutritionist.
      "description": "076 = HEARING AID & SUPPLIES - IL1, MT1, 080 = REGISTERED NURSE (RN) - IL1, 081 = LICENSED PRACTICAL NURSE (LPN) - IL1, OK1, 086 = NUTRITIONIST - IL1, MT1, 094 = PHARMACY - IL1"
    }
  ]
},
{
  "code": "A",                         // Co-insurance
  "serviceTypeCodes": [
     "51",                             // Hospital - Emergency Accident
     "52"                              // Hospital - Emergency Medical
   ],    
  "benefitPercent": "0.2",             // 20% co-insurance
  "timeQualifierCode": "23",           // Calendar year
  "coverageLevelCode": "IND",          // Individual coverage
  "inPlanNetworkIndicatorCode": "N",   // Out-of-network benefits
  "additionalInformation": [
    ...
    {
      // These provider specialties are NOT covered under this benefit.
      // The list includes `086` (Nutritionist) from the prior entry.
      "description": "EXCLUDED PROVIDER SPECIALTIES - 071, 076, 080, 081, 086, 094, 097,"
    },
    {
      // More provider specialties NOT covered under this benefit.
      // The list includes `AQ` (Nutritionist) from the prior entry.
      "description": "EXCLUDED PROVIDER TYPES - 0I, 0N, 0Q, 0T, 0U, 0V, A9, AC, AG, AH, AM, AQ, AX, B0, BG, BY, D0, D7, D7,"
    }
  ],
  ...
}

Missing benefits
In some cases, eligibility responses like the ones above may provide everything you need. However, sometimes, the payer doesn’t include the benefit at all – even if it’s covered by the patient’s plan. This makes it hard to know what’s covered, which STC to check, or how to automate parsing.

How to get the most from eligibility responses

Eligibility responses vary by payer. The best way to check for the benefit details you need is to test likely STCs with each payer. For each payer:

1. Compile a list of STCs to test.
   Use our list of STCs for common services as a starting point. For example, for medical nutritional therapy, try 98 (Professional Physician Visit - Office), MH (Mental Health), 1 (Medical Care),  and BZ (Physician Visit - Office: Well).
   
   

2. Send a baseline eligibility request.
   Use STC 30 (Health Benefit Plan Coverage) for general medical benefits or 35 (Dental Care) for general dental benefits.
   
   

3. Compare the baseline response with the response to the specific STC.
   Save the benefitsInformation array for each STC and diff them. If they're different, the payer may include information about your service in the response.
   
   

4. Search the response.
   Look for keywords related to your service in free-text fields. For medical nutrition therapy, you can match on nutrition, dietitian, and MNT.

As a test, we checked recent responses from Stedi’s top eligibility payers to see which returned benefits related to medical nutrition therapy. Out of the 140 we checked, about 40% did. That group included several major payers – like UnitedHealthcare and Blue Shield of California – who make up about 82% of our transaction volume.

There are exceptions. For example, some major payers like Cigna and Blue Cross Blue Shield of Texas didn’t appear to include nutrition therapy benefits in their responses at all.

How to fill in gaps

If the eligibility response is missing benefits you need, you can still reliably get the information. Here’s what we’ve seen work with our most successful customers:

1. Contact the payer.
   Call or use the payer’s portal to get any missing benefits information you need. You can do this manually or use an AI voice agent or screen scraper to do it programmatically.
   
   

2. Record what you learn.
   Regardless of the method you use, create a system to track the information you get by payer and plan. Depending on your needs, this could just be a database, spreadsheet, or JSON file.
   
   

3. Use the collected data to enrich your eligibility responses.
   Plan benefits for the same payer and plan usually don’t vary from member to member. You can reuse the information you collect to enrich eligibility responses across patients for that plan.
   
   Even when plan benefits are the same, eligibility checks are still useful for things that change by member like active coverage or service history.

Get expert support

Eligibility checks are a good first line of defense for fetching benefits data. They work for most cases and help automate your workflow. But when gaps appear, you can still get answers.

Support often plays a key role in filling those gaps. Stedi has helped several companies, like Berry Street and others, interpret eligibility responses and optimize their workflows for medical nutrition therapy and more.

Request a free trial and see our support for yourself.

You can now correct and resubmit claims directly from the transaction detail page of any claim in the Stedi portal. 

We’ve also made other UI improvements that make the portal’s Claims section simpler and faster to use. Here’s what’s new:

• Streamlined list views and filters on the Transactions and Files pages help you find what you need, fast.

• Cleaner detail pages for transactions and files put the most important information front and center.

These changes cut the clutter and help anyone using the portal – developer or operator – resubmit claims quickly, which means faster payments for the provider.

Correct and resubmit claims

You can now correct and resubmit claims from the transaction details page in the Claims section of the Stedi Portal. Just open a claim from the Transactions page, and click Edit and resubmit.

The claim opens in an interactive inspector, with the X12 EDI on the left and the EDI specification on the right. Make your changes, and click Review and submit. You can review a diff of the updated X12 before resubmitting.

Improved list page views and filters

The Transactions and Files list pages now have a simplified layout. We’ve removed unneeded columns and simplified each page’s filter. For example, the Transactions page:

The Files page:

Improved detail pages

We’ve revamped the File detail page so that you can see the file’s X12 alongside the EDI specification. You can also view related transactions in the Transactions tab.

The Transaction detail page now includes tabs for X12 and JSON versions of the transaction, along with webhook deliveries, which are useful for 277CA and 835 transactions.

Get started

The improved claims UI is now available in the Stedi portal for all paid plans. If you’re not yet a Stedi customer, request a free trial. Most teams are up and running in less than a day.

You can now run 276/277 real-time claim status checks in the Stedi portal.

A real-time claim status check tells you if a claim was received, is in process, was denied, or has another status with the payer. You typically run claim status checks if you haven’t gotten a claim acknowledgment or an ERA for a claim within an expected timeframe – typically around 21 days.

Previously, you could only run these checks using Stedi’s Real-Time Claim Status API.

Now, you can send real-time claim status requests and view the responses right in the Stedi portal. This makes it easy for anyone – whether you’re an operator or a developer – to check on claims and debug issues. This can help speed up resubmissions and result in faster payments.

Submit a claim status request

You can submit a claim status check using the Stedi portal’s new Create claim status check page. You can access the page by clicking Claims > New claim status in the portal’s nav.

By default, the page shows fields from our recommended base request. Check our docs for best practices on filling out the request.

View claim status responses

Claim status checks run synchronously – so you get responses back quickly.

If the payer has multiple claims on file that match the information in the claim status request, the response may contain information about more than one claim. If so, you can use the dropdown to navigate between claims and quickly see each one’s status category code.

You’ll see claim-level statuses in the response, and when available from the payer, you’ll also see service-line level statuses.

Get started

Claim status checks are available in the Stedi portal for all paid plans. Check the Stedi Payer Network or Payers API to see which payers support 276/277 real-time claim status checks.

If you’re not a Stedi customer, request a free trial. Most teams are up and running in less than a day.

Figuring out the right steps for processing out-of-network claims can be confusing.

Some payers require provider registration. Others make you submit a claim before enrolling for Electronic Remittance Advice (ERAs). Some have few requirements at all.

If you’ve run into questions or hurdles, you’re not alone.

While requirements vary between payers, there are common patterns you can use to reliably submit out-of-network claims and – when possible – get back ERAs. 

This guide aims to answer your questions about out-of-network claims. It also covers patterns we’ve seen work.

Provider network status

A provider’s network status indicates whether a provider is in-network or out-of-network for a specific payer. If a provider is out-of-network, any claim they submit is also out-of-network.

Network status is determined by credentialing and payer enrollment, which are handled directly with the payer.

They’re separate from transaction enrollment, which determines what transactions you can exchange with a payer. Your clearinghouse only handles transaction enrollment.

For help with credentialing or payer enrollment, contact the payer or use a credentialing service like CAQH, Assured, or Medallion.

Checking a provider’s network status
You can’t reliably determine whether a provider is in-network or out-of-network using an eligibility check or other pre-claim clearinghouse transaction. However, there are options for checking this programmatically. For a rundown, see our Provider network status docs.

Out-of-network benefits
Even if a payer accepts out-of-network claims, not all patients have out-of-network benefits. You can determine if a patient has out-of-network benefits –and whether they’re eligible for reimbursement – using an eligibility check. See the In Plan Network Indicator docs

Requirements for out-of-network claims

Most payers accept out-of-network claims, but requirements can vary. The two main things to check are:

• Whether the payer requires registration for out-of-network providers

• Whether they require transaction enrollment for claims submission

Provider registration
Some payers require any out-of-network provider to register as a “non-participating” provider before they’ll accept claims. This registration is separate from transaction enrollment and happens outside of Stedi. 

You’ll need to contact the payer to confirm what’s needed and set up your provider if required.

Transaction enrollment for claims submission
Most payers don’t require transaction enrollment for claims submission – but some do. If a payer does and enrollment isn’t completed, the claim will be rejected.

Before submitting claims, check the payer’s enrollment requirements using the Payer API or Payer Network. You can filter payers by supported transaction type and enrollment requirements.

Once any needed provider registration or transaction enrollment is complete, the provider can submit out-of-network claims for the payer.

Submit an out-of-network claim

You submit out-of-network claims using the Claims API, the Stedi portal, or SFTP.

There are no special fields or requirements for out-of-network claims. Just submit them as you would an in-network claim. A provider doesn’t have to be enrolled for ERAs with a payer to submit claims.

You’ll receive claim acknowledgments for out-of-network claims. You can also run real-time status checks.

ERAs for out-of-network claims

Unlike claims, all payers require transaction enrollment for ERAs. Providers can only be enrolled for ERAs with one clearinghouse per payer at a time.

Transaction enrollment for ERAs
ERA enrollment requirements for out-of-network providers vary across payers.

Some payers treat ERA enrollment the same for all providers. Others require out-of-network providers to be "on-file" first. Some payers don’t allow out-of-network providers to enroll for ERAs at all.

“On-file” requirements
To become "on-file," out-of-network providers typically need to either:

• Submit a claim to the payer.

• Register as a “non-participating” provider with the payer.

Many payers require a submitted claim before ERA enrollment. However, claims submitted before or during enrollment won't generate ERAs. 

Many payers send Explanations of Benefits (EOBs) – typically snail mailed – for out-of-network claims or when no ERA enrollment is on file. EOBs contain the same information as ERAs, but if you and your providers rely on ERAs for reconciliation, this can create issues.

A straightforward workaround is to use Anatomy to convert your EOBs into ERAs. Anatomy sends the converted ERAs to Stedi. You can then use Stedi’s APIs or SFTP to fetch the ERAs as normal.

Set up Anatomy for EOB-to-ERA conversion

Setting up Anatomy is a one-time step. Once configured, you can use it for any EOBs sent to the provider from any payer.

Step 1. Create an Anatomy account
Contact Anatomy to get started. You can upload PDFs directly in Anatomy’s UI or redirect paper EOBs to a PO Box managed by Anatomy.

Step 2. Submit an ERA enrollment request for Anatomy in Stedi
Enroll the provider for ERAs using the Enrollments API or the Stedi portal, with ANAMY (Anatomy) as the payer ID. Enrollment typically takes 1-2 business days.

Step 3. Send EOBs to Anatomy
After enrollment completes, send any paper EOBs for the provider to Anatomy.

Step 4. Fetch the converted ERAs
You can fetch the converted ERAs as normal using our APIs or SFTP. See the ERA docs.

Pricing
Stedi doesn’t charge extra to receive ERAs from Anatomy. You pay the same as you would for any ERA. Contact Anatomy for pricing on their services.

The out-of-network claims runbook

There are several ways to handle out-of-network claims with Stedi. Here's practical steps you can follow based on what we’ve seen work.

Step 1. Set up Anatomy (optional).
Follow the instructions above. You only need to configure Anatomy once. You use the same Anatomy ERA enrollment across multiple payers.

Step 2. Check the payer’s requirements for out-of-network claims and ERAs.
Contact the payer to see if they require registration for “non-participating” for out-of-network claim submissions and ERAs. If so, complete any registration steps for the provider.

Step 3. Check if the payer requires transaction enrollment for claim submission.
Check the payer’s transaction enrollment requirements for claim submission using the Payer API or Payer Network.

If transaction enrollment is required, use the Enrollments API or the Stedi portal to submit a related enrollment request. Wait for enrollment to complete before submitting claims to the payer.

Step 4. Start submitting out-of-network claims.
Submit out-of-network claims using the Claims API, the Stedi portal, or SFTP.

Many payers require a claim on file before processing ERA enrollment. While these initial claims won't get ERAs, waiting risks cash flow delays and missed timely filing deadlines. We'll address this gap in step 6 below.

Step 5. Submit an ERA enrollment request for the payer.
Use the Enrollments API or the Stedi portal to submit an ERA enrollment request for the payer.

Most enrollment requests complete in 1-2 business days, but it varies by payer. You can monitor the enrollment status using the API or the portal.

Step 6. Monitor for ERAs from the payer.
Once enrollment completes, you can listen for and fetch ERAs using our APIs or SFTP.

ERA enrollment isn't retroactive. You'll only receive ERAs for claims submitted after enrollment completes. For claims submitted before or during the enrollment process, you have two options:

• If you're using Anatomy and the payer sends paper EOBs, Anatomy converts these EOBs into ERAs. You can then fetch the ERAs as normal using our APIs or SFTP.
  
  

• If the payer doesn’t send EOBs or you don’t use Anatomy, use real-time claim status checks and your provider’s actual payments for reconciliation.

Get started

We help teams set up claims processing workflows every day.

When you’re ready, start a free trial and see the workflow end-to-end.

You can now use the Stedi Agent in sandbox accounts and test mode.

In sandbox accounts and test mode, you run predefined mock eligibility requests that return realistic responses. The Stedi Agent is the Stedi portal’s built-in AI assistant. It helps you recover failed eligibility checks.

Previously, you could only use the Stedi Agent for failed eligibility checks in production. Now, you can try the agent out in sandbox accounts and test mode using a predefined mock check.

Try Stedi Agent in Eligibility Manager

The mock eligibility request is preloaded in the Stedi portal’s Eligibility Manager. To run the check:

1. Log in to your sandbox account. If you have a production account, switch to test mode.
   
   

2. Create a new eligibility check and select Stedi Agent as the Payer. Leave the Person as is.
   
   

3. Submit the check. It’s expected to fail.
   
   

4. After the check fails, click Resolve with Stedi Agent.

The agent runs in Debug view, where you can watch it work – step by step, in real time.

Run a mock API request

You can also run the mock request using the Real-Time Eligibility Check JSON endpoint and a test API key. Sandbox accounts can only create test API keys.

The following curl request uses the request body for the predefined mock request:

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 '{
    "provider": {
      "organizationName": "STEDI",
      "npi": "1447848577"
    },
    "tradingPartnerServiceId": "STEDI",
    "controlNumber": "112233445",
    "subscriber": {
      "memberId": "23051322",
      "lastName": "Prohas",
      "firstName": "Bernie"
    },
    "stediTest": true
  }'

Try it today

Stedi Agent is available now and is completely free for sandbox accounts and in test mode.

To get access, create a sandbox account. It’s free and takes less than two minutes.

Stedi provides fast, reliable infrastructure for healthcare billing. Anyone doing RCM work could benefit from running on it.

But not everyone should build on Stedi themselves.

Stedi is designed for teams with developers. Think software platforms, MSOs, DSOs, and health tech startups. These teams are often building custom RCM functionality and want full control over their RCM stack. If you have engineers, Stedi’s APIs give you everything you need to do that.

But many healthcare companies don't have developers. Even those with dev teams may not want to build everything from scratch. Some use solutions from our Platform Partners directory. Others need something more custom.

That's where firms like Light-it come in. Light-it is a software development firm that specializes in healthcare. They help teams build on Stedi without writing code. Light-it handles development and other implementation details for them.

Here's how one provider worked with Light-it to verify insurance coverage for nutrition therapy.

Verifying eligibility for nutrition therapy

The provider offers virtual-first medical nutrition therapy. They work with a nationwide network of registered dietitians. Most visits are fully covered by insurance – 95% of patients pay nothing out of pocket.

To deliver that kind of experience, the provider needs to verify coverage before a patient books. That’s harder than it sounds.

Most payers don’t clearly state whether nutrition therapy is covered in their eligibility responses. The X12 270/271 standard lacks a specific Service Type Code (STC) for medical nutrition therapy. This makes it hard to get consistent data across payers.

Most clearinghouses add more friction on top of this. You have to deal with unreliable connections, outdated – or poorly documented – APIs, and lossy responses where the clearinghouse drops data from the payer’s responses. When you do get an unclear response, it can take days to get help. Many teams end up just calling the payer themselves.

Instead of adding friction, Stedi makes the process easier. We offer easy integration, reliable payer connections, and lossless eligibility responses. And we provide real-time support. When you get a confusing eligibility response, we’ll help you interpret or debug it.

From proof of concept to production

Light-it and the provider started small. They ran a proof of concept with real patient data. They tested which payers returned usable coverage.

The results were clear. With Stedi, Light-it and the provider got clean, lossless eligibility responses. When they got errors, there were predictable failure modes. Light-it built reliable logic around those failures. When responses were unclear, they turned to Stedi for help in real time.

After validating the approach, Light-it built a simple frontend. Then they connected it to Stedi's Real-Time Eligibility Check API. It’s modern, JSON-based, and well-documented. Because of that, Light-it was able to move from proof of concept to production in weeks, not months.

The result

Today, the provider runs eligibility checks before every visit. Patients see coverage results immediately.

Stedi handles the transaction layer and APIs. Light-it handles the business logic and patient experience. They tailored the workflow to match how the provider operates. This includes fallback paths when data is unexpected or incomplete.

When to use an implementation partner

If you're evaluating Stedi and don’t have developers – or don’t want to build from scratch – partnering with a healthcare software development service like Light-it might be a good fit. They offer free consultation calls with no commitment.

You can start with a proof of concept to test your specific use case. Then work with the firm to build what's missing. Stedi's modern APIs and real-time support help implementation teams ship faster.

You can now filter results more precisely in the List Enrollments and List Providers API endpoints.

We’ve also updated the Enrollments page and Providers page in the Stedi portal to surface these filters.

Previously, you had to page through results and filter them in your client. These new options make it easier to find the data you want – faster, with less paging and smaller responses.

List Enrollments endpoint

We’ve added new query parameters to the List Enrollments endpoint. You can use the parameters to filter by:

• Partial term: filter lets you search across multiple fields at once.
  
  

• Status: Filter by one or more enrollment statuses—such as DRAFT, SUBMITTED, PROVISIONING, LIVE, CANCELED, or REJECTED.
  
  

• Provider details: Filter by NPI (providerNpis), tax ID (providerTaxIds), or name (providerNames).
  
  

• Payer: Filter by payer IDs (payerIds).
  
  

• Source: Limit results by how the enrollment was created: API, UI, or IMPORT.
  
  

• Transaction type: Filter by transaction types, like eligibilityCheck, claimStatus, or claimSubmission.
  
  

• Date: Filter enrollments by when they were created (createdFrom, createdTo) or when their status last changed (statusUpdatedFrom, statusUpdatedTo).
  
  

• Import ID: If an enrollment was created through CSV import, filter by the returned importId.

Several of these query parameters accept arrays. You can include an array parameter more than once in the URL to filter by multiple values.

For example, ?providerNames=John%20Doe&providerNames=Jane%20Doe&status=LIVE returns all enrollments in LIVE status that have either John Doe or Jane Doe as the provider:

https://enrollments.us.stedi.com/2024-09-01/enrollments?providerNames=John%20Doe&providerNames=Jane%20Doe&status=LIVE

List Providers endpoint

The List Providers endpoint now accepts a filter parameter for searching by provider name, NPI, or tax ID. Filtering is case-insensitive and supports partial matches.

For example, ?filter=2385442357 returns all providers whose name, NPI, or tax ID contains 2385442357:

https://enrollments.us.stedi.com/2024-09-01/providers?filter=2385442357

Updated filters in the Stedi portal

Alongside API improvements, we’ve updated the Stedi portal to surface these new filters on the Enrollments page and Providers page.

On the Enrollments page:

On the Providers page:

Try it out

The new filters are available on all paid Stedi plans. For full details, check out the API documentation.

In February of last year, I gathered our engineering team in a war room. Change Healthcare – the nation’s largest clearinghouse for healthcare claims processing – had been down for almost a full week due to a cyberattack that would ultimately render them unable to process many types of transactions for two months or longer. 

It’s hard to explain the magnitude of the Change Healthcare outage to people outside the healthcare industry. Nearly 40% of healthcare claims processed in the United States flowed through Change’s platform. They processed an aggregate $1.5 trillion of claims volume annually – 15 billion claims – and they were the exclusive designated clearinghouse for dozens of payers ranging from small regional payers to UnitedHealthcare, Change’s parent company. Healthcare spend in the US is $4.9 trillion annually – 18% of total GDP – which means that when Change went down, it was processing roughly 5.5% of US GDP. 

When the seriousness of Change’s situation became clear, we worked around the clock to accelerate the development of our own clearinghouse that we had planned to launch later that year. We announced a drop-in replacement for Change’s clearinghouse just a few days later, and the 7 weeks afterwards were unlike anything I had experienced in 20 years of business. We couldn’t leave our keyboards during any waking hour of the day for more than a few minutes at a time – 6 and 7 figure deals went from initial phone call or text message to signed terms in under an hour. 

Change Healthcare has long since come back online, but our growth trajectory has only steepened. In April 2025, we were named Ramp’s 3rd-fastest growing software vendor. Last month, we signed 5x the number of customers that we signed at the height of the Change outage. Stedi has become the de facto choice for virtually every new venture-backed health tech company – and as later-stage health tech companies and traditional institutions revisit their legacy clearinghouse dependencies in the wake of the Change outage, Stedi’s cloud-native, API-first platform has become the obvious choice. 

But more and more, our growth is driven by GenAI use cases from all segments of the market – from brand new startups to traditional companies coming to Stedi to build agentic functionality into their existing platform. One-third of our customer base is now made up of fully native GenAI companies, an extremely high-growth cohort that has collectively raised an astounding $5B in funding to date. 

Today, we’re announcing our own $70 million Series B fundraise, co-led by Stripe and Addition, with participation from USV, First Round, Bloomberg Beta, BoxGroup, Ribbit Capital, and other top investors, which includes a $50 million previously-unannounced round plus $20 million of new capital.

Our mission is to make healthcare transactions as reliable as running water. This new funding has allowed us to double down on rebuilding the backbone of healthcare transaction infrastructure as Revenue Cycle Management (RCM) undergoes an AI-driven transformation. In addition to our best-in-class APIs, we’ve made it even easier for development teams to integrate to our clearinghouse using the new MCP server launched last week. Yesterday, we launched the Stedi Agent to power AI functionality within our platform directly.

What’s driving the AI boom in RCM? 

RCM is practically designed to be automatable using AI. Every claim, remittance, and eligibility check is already transmitted in a well-structured transaction, giving AI models clean, labeled data to work with. RCM workflows are rule-bound – that is, every step is governed by explicit payer or regulatory logic. Eligibility follows coverage rules; claim submissions and resubmissions must meet payer-specific requirements; denial appeals hinge on predefined evidence thresholds and deadlines. Because each decision is effectively a yes/no test against a published rule set, accuracy can be measured objectively and improvements validated quickly – ideal conditions for AI agents to learn, iterate, and outperform manual processes.

But when it comes to implementing AI workflows, development teams hit frustrating roadblocks with legacy clearinghouses. Most of the functionality offered by legacy clearinghouses is not accessible programmatically. If you’re lucky, you might be able to do basic eligibility and claim submission using an API – a distant second-class citizen to the clearinghouse’s main focus: traditional EHR integration. More often, you’re relying on brittle portal scraping, email capture, and PDF parsing to attempt to stitch together a passable workflow. 

The legacy clearinghouses are unlikely to get much better. They were built pre-cloud computing (and in many cases, pre-internet), and most are the result of a series of private equity acquisitions with tech stacks that were never harmonized or modernized. As a result, the technology roadmaps move at a glacial pace – the people who built the systems have long since departed and most of the effort is expended on ‘keep the lights on’ maintenance. 

Stedi’s approach is API-first: every piece of functionality available through our user interface is available via API, from the basics like eligibility checks, claims, and remits to the often-neglected aspects like payer search and transaction enrollment. Alongside our APIs, we offer a full suite of modern user interfaces that are easy for non-technical users to use.

Our thesis is simple: as more and more aspects of RCM software are subsumed by agentic workflows, companies will shift ever-greater portions of their workloads to the platforms that offer the best accessibility and legibility to AI agents that are performing actions; since other clearinghouses don’t offer ways to perform tasks programmatically, customers will continue to migrate to Stedi as they build net-new workflows, or as they find that existing workflows come to exceed the requirements afforded by other clearinghouses.

We have a single question that we use to guide our roadmap decisions: does this make it easier for humans and agents to interact with our platform? This has led to dozens of small improvements and major launches over the past several months, and will lead to many more. This latest investment allows us to continue to expand the breadth and depth of our transaction functionality in order to serve the needs of the smallest providers and the largest health systems, and everyone in between.

Most importantly, it allows us to accelerate hiring of world-class talent across engineering, product, design, business operations, and more. If that sounds exciting to you, come work with us.

Now available in Stedi's Eligibility Manager, the Stedi Agent brings AI-powered automation to healthcare clearinghouse workflows, beginning with eligibility check recovery.

Most failed eligibility checks are recoverable. Common causes include mismatched patient details, an incorrect payer ID, or a temporary outage on the payer’s side. In most cases, these errors have clear, automatable recovery steps.

Now, the Stedi Agent can run those steps for you.

In Eligibility Manager, each eligibility check and any related retries are grouped under a search. If a check fails with a known recoverable error, a Resolve with Stedi Agent option appears next to the related search. The agent runs in Debug view, where you can watch it work – step by step, in real time.

How it works

The Resolve with Stedi Agent option only appears where the agent can currently help. We’re starting with the most common errors and expanding coverage based on what works in practice.

When you start the agent, it examines the eligibility search’s failed checks and works through recovery strategies based on the error type. For example, for mismatched patient details, it might try different combinations of patient data or adjust name formats.

The agent can make API calls to the Real-Time Eligibility Check JSON and Search Payers endpoints.  

Each check it runs is added to the same eligibility search and appears in real time in the Debug view. The agent only uses data from the eligibility search it's running on.

Security

The Stedi Agent is hosted on Stedi's HIPAA-compliant infrastructure, which runs completely on AWS. The agent uses Stedi's existing security model, including role-based access control (RBAC) and support for multi-factor authentication (MFA). You must have the Operator role or above to use the agent.

The agent only accesses data from the eligibility search it's working on. It can’t access data from other searches, customers, or systems.

Pricing

The Stedi Agent is available on all Stedi accounts at no additional cost beyond those for additional eligibility checks.

As with our APIs, there’s no charge for non-billable requests. See Billing for eligibility checks.

Try it out

The Stedi Agent is available now. Look for the Resolve with Stedi Agent option next to failed eligibility checks.

If you’re not a Stedi customer, request a trial. Most teams are up and running in less than a day.

Stedi now enriches most Blue Cross Blue Shield (BCBS) eligibility responses with the member’s home payer name and primary payer ID. 

BCBS is a collection of 33 entities that operate independently. BlueCard is BCBS’s national program that enables members of one BCBS plan to obtain healthcare service benefits while traveling or living in another BCBS plan’s service area.

Each BCBS plan has access to the BlueCard eligibility network, which means that a provider operating in one state can check eligibility for any nationwide BCBS member using the provider’s local BCBS plan payer ID, as long as the eligibility check includes the member’s first name, last name, birthdate, and full member ID (including the 3-character BCBS alpha prefix).

For example, a provider in Texas might send an eligibility check to “Blue Cross Blue Shield of Texas” for a member whose coverage is actually with “Blue Cross Blue Shield of Alabama.” BCBS of Texas will return a successful response as long as all of the member’s details were correct. 

The problem is that the returned eligibility response doesn’t say which BCBS payer is the patient’s home payer. It just lists the payer to whom the request was sent. In the example above, the eligibility response would have no indication that the member belonged to BCBS of Alabama. 

The reason that BCBS doesn’t include this information is that it’s irrelevant for most traditional care scenarios, since the BlueCard program instructs providers to always submit claims to their local payer – not the member’s home plan. However, for multi-state providers or telehealth scenarios, the rules can differ, and it becomes important for the provider to identify the actual home plan.

To simplify this process, Stedi has developed logic to automatically detect and include the home payer’s name and ID in the eligibility response whenever possible.

When detected, this info now appears in a related benefitsInformation.benefitsRelatedEntities entry in our JSON eligibility responses and in a 2120C or 2120D loop in X12 responses.

No action is needed to take advantage of this new functionality. This enhancement is already live for all related Real-Time Eligibility Check API endpoints.

How the data is included

If you’re using our JSON eligibility API, the home payer’s details appear as a benefitsInformation.benefitsRelatedEntities entry in the response. It’s included in the same benefitsInformation entry that includes the patient’s coverage status.

{
  ...
  "benefitsInformation": [
    {
      "code": "1",
      "serviceTypeCodes": ["30"],
      ...
      "benefitsRelatedEntities": [
        {
          "entityIdentifier": "Party Performing Verification",
          "entityType": "Non-Person Entity",
          "entityName": "Blue Cross Blue Shield of Alabama",
          "entityIdentification": "PI",
          "entityIdentificationValue": "00510BC"
        }
      ]
    },
    ...
  ],
  ...
}

In X12 eligibility responses, the home payer’s information is included in Loop 2120C or 2120D.

LS*2120~
NM1*VER*2*Blue Cross Blue Shield of Alabama*****PI*00510BC~
LE*2120

Try it out

You can see home payer enrichment in action by running a real-time eligibility check for any BCBS member for whom you have the first name, last name, birthdate, and member ID.

If you don’t have production access, request a free trial. Most teams are up and running in less than a day.

Stedi is now e1 certified by the HITRUST for foundational cybersecurity.

HITRUST e1 Certification demonstrates that Stedi’s healthcare clearinghouse platform is focused on the most critical controls to demonstrate that essential cybersecurity hygiene is in place. The e1 assessment is one of three progressive HITRUST assessments that leverage the HITRUST Framework (HITRUST CSF) to prescribe cyber threat adaptive controls that are appropriate for each assurance type.

“The HITRUST e1 Validated Assessment is a strong fit for cyber-conscious organizations like Stedi that are looking to establish foundational assurances and demonstrate ongoing due diligence in information security and privacy,” said Ryan Patrick, VP of Adoption at HITRUST. “We commend Stedi for their commitment to cybersecurity and congratulate them on successfully achieving their HITRUST e1 Certification.”

“How much will this cost?” It’s the first question many patients ask their provider.

Real-time eligibility checks return the data you need to estimate patient responsibility – co-pays, deductibles, limitations – but they don’t hand you the answer. The response is often nuanced and, in some cases, can seem contradictory.

With a few simple patterns in place, though, you can reliably extract the information needed to build cost estimates you – and your providers – can trust.

This guide shows you how. It walks through the structure of a 271 eligibility response and shares practical tips for using Stedi’s Real-Time Eligibility Check JSON API to estimate patient responsibility. It also gives you tips for improving cost estimates using data from Stedi’s 835 ERA Report API.

Choose the right STC

Eligibility responses organize benefits by Service Type Codes (STCs). STCs group services into broad categories like "office visit" or "surgery."

The STC you send in the eligibility request shapes what you get back in the response. Choose the right one, and you'll get the benefits you need. Choose the wrong one, and you might miss them entirely.

Here’s a reliable approach:

• Use one STC per request. Many payers don’t support multiple STCs. To test payer support for multiple STCs, see Test payer STC support in the Stedi docs.
  
  

• Don't use procedure codes (HCPCS/CPT/CDT) in eligibility requests. While Medicare and some dental payers accept them, most ignore them entirely. Map the procedure codes to STCs first.
  
  

• Only send required patient data in eligibility requests. Payers require that eligibility checks match a single member. Extra data increases the risk of a mismatch. Stick to:

  • Member ID

  • First name

  • Last name

  • Date of birth
    
    

• You may get benefits for more STCs than you request. For example, HIPAA requires medical payers to return benefits for applicable STCs for STC 30 (Health Benefit Plan Coverage).  See General benefit checks in the docs.
  
  

• Missing benefits don't mean missing coverage. Payers aren't required to respond to every STC. Compare the response for your STC to STC 30 for medical or STC 35 for dental. If there's a difference in the response, the STC is likely supported. See Test payer STC support in the docs.

For example, to estimate costs for a level 3 established patient office visit (CPT code 99213), start by mapping the procedure code to the most appropriate STC. In this case, that’s STC 30.

Then, send a real-time eligibility request with a body similar to:

{
    ...
    "encounter": {
      "serviceTypeCodes": ["30"]
    },
    "provider": {
      "organizationName": "ACME Health Services",
      "npi": "1999999984"
    },
    "subscriber": {
      "dateOfBirth": "19900101",
      "firstName": "John",
      "lastName": "Doe",
      "memberId": "123456789"
    }
}

Where to find patient costs in the response

Most of a patient’s benefit information, including patient cost, is in the eligibility response’s benefitsInformation array. For example:

{
  ...
  "benefitsInformation": [
    {
      "code": "B",                        // Co-pay
      "serviceTypeCodes": ["88"],         // Pharmacy
      "benefitAmount": "10",              // $10 co-pay
      "inPlanNetworkIndicatorCode": "Y"   // In-network only
    },
    {
      "code": "C",                         // Deductible
      "coverageLevelCode": "IND",          // Individual coverage
      "serviceTypeCodes": ["30"],          // General medical (used for CPT 99213)
      "timeQualifierCode": "23",           // Calendar year
      "benefitAmount": "1000",             // $1000 deductible
      "inPlanNetworkIndicatorCode": "Y",   // In-network only
    },
    {
      "code": "A",                         // Co-insurance
      "serviceTypeCodes": ["35"],          // Dental Care
      "benefitPercent": "0",               // 0% co-insurance    
      "inPlanNetworkIndicatorCode": "N",   // Out-of-network only
      "compositeMedicalProcedureIdentifier": {
        "productOrServiceIDQualifierCode": "AD", // American Dental Association (ADA)
        "procedureCode": "D0150"                 // Comprehensive oral evaluation
      },
      "benefitsDateInformation": {
        "latestVisitOrConsultation": "20240404" // Last service
      },
      "benefitsServiceDelivery": [           // 1 visit every 6 months
        {
          "quantityQualifierCode": "VS",     // Visits
          "quantity": "1",                   // 1 visit
          "timePeriodQualifierCode": "34",   // Months
          "numOfPeriods": "6"                // Every 6 months
        }
      ]
    }
    ...
  ],
  ...
}

Each benefitsInformation object includes a few key fields related to patient costs:

• serviceTypeCodes - The services this benefit applies to.
  
  You’ll often see the same serviceTypeCodes in more than one benefitsInformation object. That’s expected. To get the full picture for a service, look at all entries that include its STC.
  
  

• code - What the benefit is. For patient costs, the relevant codes are:

  • A – Co-insurance: Percentage the patient pays for the benefit.

  • B – Co-pay: Fixed dollar amount the patient pays for the benefit.

  • C – Deductible: Total amount the patient must pay before benefits begin.

  • F – Limitations (Maximums): Maximum benefit amount. Typically used for dental and vision plans.

  • G – Out of Pocket (Stop Loss): Maximum amount a patient can pay per year. Once reached, the plan pays 100% of covered services.

  • J – Cost Containment: Total amount the patient must pay before benefits begin, similar to a deductible. Typically used for Medicaid benefits.

  • Y – Spend Down: Total amount the patient must pay before they can receive benefits. Typically used for Medicaid benefits.
    
    

• benefitAmount or benefitPercent - The dollar or percentage value of the patient costs. benefitPercent is used for co-insurance (code = A). All other patient cost types use `benefitAmount`.
  
  

• timeQualifierCode - What the benefit amount represents. It’s often the time period it applies to. For example, if an entry has code = G (Out-of-pocket maximum) and timeQualifierCode = 29 (Remaining Amount), then benefitAmount contains the remaining out-of-pocket maximum.

For the full list of time qualifier codes, see Time Qualifier Codes in the docs.

• coverageLevelCode - Code indicating the level of coverage for the patient. For example, IND (Individual) or FAM (Family).
  
  

• inPlanNetworkIndicatorCode - Whether the benefit applies to in-network or out-of-network care – not whether the provider is in-network. Possible values are "Y" (In-network), "N" (Out-of-network), "W" (Both), and "U" (Unknown). For more details, see In Plan Network Indicator in the docs.
  
  

• additionalInformation.description - Free-text notes from the payer. For patient costs, these notes often contain limitations and qualifications, as well as carve-outs that don’t align neatly to a full STC. For example for co-pays (code = B), this may contain VISIT OFFICE PCP,TELEHEALTH PRIMARY CARE, which indicates when the co-pay applies.

Service history fields
Some benefits have frequency limits. For example, “one visit every 6 months” or “two cleanings per year.” Others depend on when the patient last received the service.

To estimate patient cost for these types of benefits, look for:

• benefitsDateInformation – Shows when a service (like a cleaning or exam) was last performed.
  
  

• benefitsServiceDelivery – Indicates how often a service is allowed, such as once every 6 months or twice per year. Many payers don’t populate this field and instead return this information as free text in additionalInformation.description.

These fields show up in responses for dental, vision, and Medicaid. They also apply to some medical services, like annual wellness visits or therapy sessions.

If the patient has already reached the allowed frequency, the next visit may not be covered. In that case, they may owe the full amount.

Some plans, especially dental, apply shared frequency limits across a group of procedures. For example, a plan might allow one X-ray series per year, regardless of the procedure code used later in the claim. If a claim has already been paid for one of the codes in the group, subsequent claims for others may be denied.

Handling multiple benefit entries

The same STC often has different patient costs for different scenarios. When you see multiple benefit entries for the same STC, check these fields to understand which cost applies when:

• coverageLevelCode - Coverage level, such as individual or family

• inPlanNetworkIndicatorCode - In-network vs. out-of-network rates

• additionalInformation.description - Specific limitations and exceptions.

These fields are easy to miss, but without them, entries with the same STC and benefits code can look contradictory when they’re actually describing different conditions.

Example: Multiple deductibles for the same STC
In the following example, both benefitsInformation entries apply to general medical coverage (STC 30), but the inPlanNetworkIndicatorCode differentiates them: the in-network deductible is $1000. The out-of-network deductible is $2500.

// In-network deductible
{
  "code": "C",                             // Deductible
  "coverageLevelCode": "IND",              // Individual coverage
  "serviceTypeCodes": ["30"],              // General medical
  "timeQualifierCode": "23",               // Calendar year
  "benefitAmount": "1000",                 // **$1000 deductible**
  "inPlanNetworkIndicatorCode": "Y",       // **In-network only**
}
// Out-of-network deductible
{
  "code": "C",                             // Deductible
  "coverageLevelCode": "IND",              // Individual coverage
  "serviceTypeCodes": ["30"],              // General medical
  "timeQualifierCode": "23",               // Calendar year
  "benefitAmount": "2500",                 // **$2500 deductible**
  "inPlanNetworkIndicatorCode": "N",       // **Out-of-network only**
}

Improve cost estimates with 835 ERAs

Eligibility responses return benefits at the service type level. But what payers actually pay shows up in the 835 ERA, broken down by procedure code.

You can retrieve ERAs as JSON using Stedi’s 835 ERA Report API endpoint. For example, the previous eligibility check above may correspond to a visit with the following ERA:

{
 ...
 "transactions": [
   {
     ...
     "detailInfo": [
       {
         "paymentInfo": [
           {
             "claimPaymentInfo": {
               "claimPaymentAmount": "500",           // What payer paid provider
               "patientResponsibilityAmount": "300",  // What patient owes
               "totalClaimChargeAmount": "800",       // Original charge
               "patientControlNumber": "1112223333"   // Your tracking number
             },
             "patientName": {
               "firstName": "JOHN",
               "lastName": "DOE",
               "memberId": "123456789"
             },
             "serviceLines": [
               {
                 "serviceAdjustments": [
                   {
                     "adjustmentAmount1": "300",         // Amount adjusted
                     "adjustmentReasonCode1": "1",       // Deductible
                     "claimAdjustmentGroupCode": "PR"    // Patient responsibility
                   }
                 ],
                 "servicePaymentInformation": {
                   "adjudicatedProcedureCode": "99213",   // CPT code
                   "lineItemChargeAmount": "800",         // Charged amount
                   "lineItemProviderPaymentAmount": "500" // Paid to provider
                 }
               }
             ]
           }
         ]
       }
     ],
     "financialInformation": {
       "totalActualProviderPaymentAmount": "1100"   // Total payment for all claims
     },
     ...
   }
 ]
}

To identify patient responsibility in an ERA, look for serviceLines entries with serviceAdjustments.claimAdjustmentGroupCode = PR (Patient responsibility). These adjustments are the amounts the patient is expected to pay. The adjustmentReasonCode tells you why. For example, Claim Adjustment Reason Codes (CARCs) are:

• 1 – Deductible

• 2 – Coinsurance

• 3 – Copay

• 119 – Benefit max reached for the period

For a full list, see the X12 Claim Adjustment Reason Codes list.

CARCs often align with benefitsInformation.code values in eligibility responses. For example, adjustmentReasonCode = 1 (Deductible) in the ERA corresponds to code = C (Deductible) in the eligibility response. By comparing both sources, you can refine your estimates over time.

Building a cost estimation engine
Several Stedi customers combine 271 eligibility checks with 835 ERAs to refine their patient cost estimates over time. The most reliable setups use a simple feedback loop:

1. Estimate patient costs using eligibility responses and historical data from prior claims (see step 5).

2. Submit claims and collect ERAs.

3. Extract payment patterns by CPT code, payer, and plan.

4. Compare actual payments to your original estimates.

5. Update your logic for patient cost estimates based on actual payments.

ERAs don’t give you market-wide benchmarks – only what happened with your own claims. For common procedures with high-volume payers, that’s often enough to make confident estimates.

Real-time support for real-time eligibility

Even clean eligibility requests sometimes return unclear responses. When that happens, our support team can help make sense of it. Our average support response time is under 10 minutes.

It’s one reason teams trust Stedi to stay in the loop while they scale.

To see how it works, start a free trial.

You can now run real-time eligibility checks using our CAQH CORE–compliant SOAP API endpoint.

CAQH CORE SOAP is a widely adopted XML-based interoperability standard for exchanging healthcare transactions, like eligibility checks. It defines how systems can connect and exchange that data in a consistent, reliable way.

If you're already using CAQH CORE SOAP, our SOAP endpoint is the fastest way to start running eligibility checks with Stedi. Just point your existing integration to our endpoint – no other changes are needed.

Most Stedi customers use our JSON API for real-time eligibility. JSON is familiar, fast to integrate, and easy to work with. But if you’ve already built on SOAP, switching to JSON adds unnecessary overhead.

This endpoint removes that step.

The endpoint supports CAQH CORE Connectivity Rule vC2.2.0. We plan to support CAQH CORE Connectivity Rule vC4.0.0 as industry adoption increases.

How it works

To use the endpoint, send a POST request to:

https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core

In the request body, use the standard CAQH CORE Connectivity Rule vC2.2.0 SOAP envelope. Wrap your X12 270 eligibility request in the Payload element as CDATA. Authenticate with WS-Security headers using your Stedi account ID and Stedi API key.

You can find your Stedi account ID at the end of any Stedi portal URL. For example, in https://portal.stedi.com/app/healthcare/eligibility?account=1111-33333-55555, the account ID is 1111-33333-55555.

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
  xmlns:cor="http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd">
  <soapenv:Header>
    <wsse:Security soapenv:mustUnderstand="true"
      xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
      xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
      <wsse:UsernameToken>
        <wsse:Username>STEDI-ACCOUNT-ID</wsse:Username>
        <wsse:Password>STEDI-API-KEY</wsse:Password>
      </wsse:UsernameToken>
    </wsse:Security>
  </soapenv:Header>
  <soapenv:Body>
    <cor:COREEnvelopeRealTimeRequest>
      <PayloadType>X12_270_Request_005010X279A1</PayloadType>
      <ProcessingMode>RealTime</ProcessingMode>
      <PayloadID>YOUR-PAYLOAD-ID</PayloadID>
      <TimeStamp>2024-07-29T12:00:00Z</TimeStamp>
      <SenderID>SENDER-ID</SenderID>
      <ReceiverID>RECEIVER-ID</ReceiverID>
      <CORERuleVersion>2.2.0</CORERuleVersion>
      <Payload><![CDATA[ISA*00*          *00*          *ZZ*SENDER         *ZZ*RECEIVER       *231106*1406*^*00501*000000001*0*T*>~GS*HS*SENDERGS*RECEIVERGS*20231106*140631*000000001*X*005010X279A1~ST*270*1234*005010X279A1~BHT*0022*13*10001234*20240321*1319~HL*1**20*1~NM1*PR*2*ABCDE*****PI*11122~HL*2*1*21*1~NM1*1P*2*ACME HEALTH SERVICES*****SV*1999999984~HL*3*2*22*0~TRN*1*11122-12345*1234567890~NM1*IL*1*JANE*DOE****MI*123456789~DMG*D8*19000101~DTP*291*D8*20240108~EQ*MH~SE*13*1234~GE*1*000000001~IEA*1*000000001~]]></Payload>
    </cor:COREEnvelopeRealTimeRequest>
  </soapenv:Body>
</soapenv:Envelope>

Stedi returns a synchronous XML response containing the X12 271 eligibility response or a 999 acknowledgement, depending on the payer's response.

Try it free

The Real-Time Eligibility Check SOAP endpoint is available on all paid Stedi plans. If you’re not a customer, request a trial. Most teams are up and running in under a day.

If you’re building a dental eligibility product, you want accurate benefits data fast.

Real-time eligibility checks are quick, reliable, and inexpensive. They return benefits data – like coverage status, deductibles, coinsurance, and plan dates – in seconds and cost pennies per transaction.

Eligibility checks can return any benefit data that a payer chooses to include. Some payers return complete data in every response. Many dental payers don’t.

To fill in those gaps, many teams turn to scraping payer portals. Scraping is quick to roll out and can surface data that checks can’t. But those scrapers require ongoing maintenance.

We’ve worked with dozens of teams building dental eligibility tools. The teams that scale best take a hybrid approach: They start with real-time checks and scrape only when it matters.

Why scraping alone doesn’t scale

In small doses, scraping is effective, but it comes with technical debt. That debt compounds faster than many teams expect. It shows up in a few ways:

1. It’s slow.
Real-time eligibility checks typically respond in 1-3 seconds. Scraping can take 10 times longer. The scraper must log in, navigate pages, and wait for load times. Multiply that by thousands or millions of requests.

Concurrency helps, but only to a point. Most portals rate-limit traffic. Some payers require monthly minimums for automated access. Those minimums often cost more than using their APIs.

2. It’s brittle.
Scrapers frequently break. Portals can make unannounced layout changes or require multi-factor authentication (MFA). When that happens, there are no structured errors. Just screenshots and HTML.

You can’t rely on retry logic. The failure modes are too varied and too unpredictable. That means near-constant patching.

3. It burns engineering time.
One CTO told us they had 60+ scrapers in production. Their best engineers weren’t building the product – they were fixing broken scrapers. Most of the data that those scrapers collected was available in eligibility checks with much lower cost and maintenance overhead.

Scraping isn’t just hard to maintain. For most teams, it’s rarely necessary.

The 85/15 rule

Teams that we’ve seen scale portal scraping follow a simple pattern:

• They use real-time eligibility checks alone for about 85% of verifications.

• For the remaining 15%, they combine checks with scraping or payer calls to fill in missing details.

Instead of scraping everything, they focus on high-impact payers: ones that don’t return key data in eligibility responses and that account for a large share of volume or revenue risk. They also use eligibility checks to verify scraper output and catch failures early.

What eligibility responses cover

To put the 85/15 rule to work, you need to know what data real-time eligibility checks reliably return.

We analyzed responses from major dental payers – including MetLife, Delta Dental, and UnitedHealthcare – to find out. Here’s what we saw:

Start with checks

Scraping is a valuable tool. It’s just not something you want to rely on for every verification.

If you’ve already built out scraping, keep it. But try running eligibility checks first. They may cover more than you expect, which can lower costs and reduce engineering effort.

Get started

Try Stedi’s real-time eligibility API for free in our sandbox. You’ll get instant access to run mock checks.

When you’re ready for production, request a free trial. Most teams are up and running in under a day.

Today, Stedi announces the release of its Model Context Protocol (MCP) server. AI agents can use Stedi’s MCP server to run eligibility checks and search payers.

A third of Stedi’s customers are generative AI companies building AI agents for revenue cycle management (RCM). Until now, connecting those agents to Stedi’s eligibility API meant writing custom integration code or copying parts of Stedi’s docs into instructions.

Stedi’s MCP server changes that.

It gives agents plug-and-play access to Stedi’s Real-Time Eligibility and Search Payers API endpoints, along with built-in guidance for common errors. You can connect your agents without having to write integration code or copy documentation.

I connected our agent to Stedi’s MCP server in minutes. Updated the instructions, and it started running eligibility checks right away.
- Rambo Wu, Engineering at Stratus

How it works

Your AI agent connects to the server using an MCP client. Once connected, the server gives your agent access to two types of capabilities – tools and prompts – as defined by the MCP server spec.

Tools perform specific actions, like running an eligibility check. They’re thin wrappers that let your agent invoke Stedi APIs – currently, the Real-Time Eligibility Check API endpoint and the Search Payers API endpoint.

Prompts help your agent decide what to do next, including how to recover from a failed check.

The following diagram show how your agent can use the MCP server to connect to Stedi’s APIs.

How to connect

The MCP server is a Streamable HTTP MCP server hosted at https://mcp.us.stedi.com/2025-07-11/mcp.

To connect your agent, add this configuration to your agent’s MCP client:

{
  "mcpServers": {
    "stedi-healthcare": {
      "type": "http",
      "url": "https://mcp.us.stedi.com/2025-07-11/mcp",
      "headers": {
        "Authorization": "YOUR_STEDI_API_KEY"
      }
    }
  }
}

Replace YOUR_STEDI_API_KEY with your actual Stedi API key.

Tools

The server provides two tools:

• eligibility_check – Runs an eligibility check using the Real-Time Eligibility Check API endpoint. The server uses our JSON format, which provides the most reliable results for AI agents.
  
  

• search_for_payer –  Finds a Stedi payer based on a provided payer ID or name. It even works with partial names or typos. For example, cig finds Cigna. This tool is powered by the Search Payers API endpoint.

Prompts

The server provides prompts to help your agent recover from common errors. The prompt instructions cover the most common recoverable scenarios we see in production:

• How to handle common errors

• When to retry eligibility checks

• What to do when a payer isn't found

You and your agent stay in control of executing follow-up actions, such as troubleshooting and retries.

Tip: Many LLM clients skip MCP prompts unless explicitly instructed to read them. You'll often get better results by adding “Read the prompts from Stedi's MCP server” to the beginning of your agent’s instructions.

Example usage

You can instruct your agent to use the MCP server to run eligibility checks.

For example, if you’re building a voice agent, you might give your model an instruction like:

Read the prompts from Stedi's MCP server.Then use Stedi’s MCP server to check
the patient’s eligibility programmatically before making a telephone call to
the payer. Only call the payer if the response doesn’t include the benefits you need

You can also use the MCP server to perform one-off checks using MCP clients. If you're using a third-party tool like Claude or ChatGPT, follow your organization’s data handling policies to ensure that you stay compliant with HIPAA and other applicable requirements. For example, your organization likely requires a BAA with any third-party tool before using the tool with Stedi’s MCP server.

When to use the MCP server

The MCP server excels are one-off eligibility checks, especially when your agent needs to retrieve coverage data in real time.

For example:

• If you're building a voice agent that calls payers for benefits, use the MCP server to check eligibility first. Call the payer only  if the response doesn’t have what you need.
  
  

• If you're building an RCM workflow agent, use Stedi’s MCP server to validate a patient’s coverage before scheduling an appointment or submitting a claim.

For bulk eligibility checks, use our eligibility APIs directly. For tips, see When to use batch eligibility checks.

For benefit interpretation, like determining remaining visits, you'll want to layer your own logic on top, just as you would with our APIs.

Performance

The MCP server adds minimal overhead to our APIs. You’ll get the same fast response times with added intelligence for your agents.

Pricing

The MCP server is available on all paid Stedi plans at no additional cost beyond those for related API calls.

As with our APIs, there’s no charge for non-billable requests. See Billing for eligibility checks.

Security and compliance

The MCP server uses the same security model as our existing APIs, including TLS encryption and API key authentication. If you're using a third-party tool to interact with the MCP server, reach out to your security team and legal counsel to ensure you have the appropriate safeguards in place.

Try it out

If you’re a Stedi customer, you can start building with the MCP server today.

If you’re not, request a trial. We can get you up and running in less than a day.

Real-time eligibility checks are built for real-time scenarios: A patient's on the phone. Someone's at the front desk. You need an answer in seconds.

But if you’re checking coverage for upcoming appointments or refreshing eligibility for entire patient panels, the timeline shifts. You don’t need answers in seconds. You need them in hours.

Stedi’s real-time eligibility API works for these bulk use cases until you’re running thousands or millions of checks at once. That’s when teams usually start writing separate logic for large batches, like queuing requests and handling long-running retries.

Stedi's batch eligibility API handles that for you. You can submit multiple checks in one request. Stedi queues and retries them automatically. And batch checks run in a separate pipeline, away from your real-time traffic.

When to use real-time vs. batch checks

Real-time checks are the default. Use them for:

• When a patient at the desk

• Verification before a visit

• Fast feedback loops while testing or debugging

• Smaller sets of bulk checks

• Any time-sensitive eligibility need

As your volume grows and you find yourself building custom logic to support it, use batch checks for bulk workflows that aren’t time sensitive:

• Monthly or weekly coverage refreshes

• Upcoming appointments

• Sets of thousands or millions of checks that can run in the background

• Any workflow where a timeline of minutes to hours works

Most teams start by using real-time checks for everything. They add batch checks when they start running several thousands of time-insensitive checks at once. Until then, using real-time checks is simpler.

Run a batch check

You submit batch checks using the Batch Eligibility Check API endpoint or a CSV upload. Each check in the batch uses the same fields as real-time requests. You can track individual checks in a batch using submitterTransactionIdentifier.

curl --request POST \
  --url "https://manager.us.stedi.com/2024-04-01/eligibility-manager/batch-eligibility" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "march-2024-eligibility-batch",
    "items": [
      {
        "submitterTransactionIdentifier": "ABC123456789",
        "controlNumber": "000022222",
        "tradingPartnerServiceId": "AHS",
        "encounter": {
          "serviceTypeCodes": [
            "MH"
          ]
        },
        "provider": {
          "organizationName": "ACME Health Services",
          "npi": "1234567891"
        },
        "subscriber": {
          "dateOfBirth": "19000101",
          "firstName": "Jane",
          "lastName": "Doe",
          "memberId": "1234567890"
        }
      },
      ...
    ]
  }'

The response includes a batchId you can use to check results:

{
  "batchId": "01928d19-df25-76c0-8d51-f5351260fa05",
  "submittedAt": "2023-11-07T05:31:56Z"
}

Get batch results

Use the Poll Batch Eligibility Checks API endpoint to poll the batchId:

curl --request GET \
  --url "https://manager.us.stedi.com/2024-04-01/eligibility-manager/polling/batch-eligibility?batchId=01928d19-df25-76c0-8d51-f5351260fa05" \
  --header "Authorization: <api_key>"

You can start polling immediately. After the initial poll, use exponential backoff with jitter. Start at 2 minutes and approximately double the wait between polls, up to 8 hours.

The endpoint returns results incrementally. The response's items array contains full 271 eligibility responses in the same JSON format as real-time checks. Failed checks appear alongside successful ones. You can debug failed checks using Stedi’s Eligibility Manager

You can track batch completion by counting returned results. You can also match submitterTransactionIdentifier values for each check.

Batch processing times

Most batches complete in 15-30 minutes. If a check in the batch fails due to payer connectivity, Stedi retries the check for up to 8 hours.

Pricing

A batch check costs the same as the equivalent number of real-time checks. For example, running a batch of 500 checks costs the same as running 500 real-time checks.

There’s no charge for non-billable checks in a batch. For details, see Billing for eligibility checks.

Get started

If you’re not currently using batch checks but are considering building logic for bulk eligibility, test the pattern with a small batch, then scale up.

Batch eligibility checks are available on all paid Stedi plans. If you don’t have a paid account, request a free trial.

A spotlight is a short-form interview with a leader in RCM or health tech. In this spotlight, you'll hear from Justin Liu, Co-founder and CEO of Charta.

What does Charta do?

Charta is a proprietary AI-powered platform that optimizes medical billing and coding workflows.

By running a pre‑bill review on every chart, Charta pinpoints documentation gaps, uncovers missed revenue opportunities, and heads off potential denials – boosting accuracy and compliance in one pass.

Our customers typically see up to a 15.2% lift in RVUs per encounter and an 11% increase in revenue, all delivered with a guaranteed ROI and less administrative drag on clinical teams.

How did you end up working in health tech?

My co-founder and CTO, Scott Morris, and I were fortunate to be part of a team at the forefront of AI infrastructure innovation at Rockset, which ultimately became OpenAI’s first ever product acquisition. We saw an opportunity to take what we had learned and apply it to a space where we could drive real, tangible change. AI infrastructure is an exciting field, but we wanted to build something where AI didn’t just optimize processes – it fundamentally improved outcomes.

Healthcare stood out because of the sheer scale of inefficiencies, particularly in administrative tasks like patient chart reviews and medical billing. What really struck us was that patient charts are essentially the data layer of the entire healthcare system – every clinical decision, every billing code, every compliance check is rooted in chart documentation. Yet, reviewing these charts remains a painfully manual process, bogging down providers and leading to lost revenue, denied claims, and time away from patient care.

Instead of optimizing AI for AI’s sake, we wanted to use our expertise to solve real-world problems in a way that directly impacted people’s lives. That perspective – combined with spending a year earning our medical coding credentials and speaking with over 100 healthcare professionals – helped us build a solution that directly addresses the root problems rather than just iterating on legacy systems.

One of those early conversations was with Dr. Caesar Djavaherian, co-founder and former Chief Medical Officer of Carbon Health. The challenges we were tackling – especially around documentation and billing – were so familiar to him that he not only invested in Charta, but ultimately joined the team as our Chief Medical Officer.

How does your role intersect with revenue cycle management (RCM)?

Charta sits squarely in the middle of the RCM stack – between clinical documentation and claim submission – by running pre‑bill AI audits that boost revenue integrity and slash denial risk. 

As CEO, I’m responsible for turning those RCM pain points into product advantages: I spent my first year interviewing medical professionals, diagramming every hand‑off from charge capture to payment posting, and hard‑coding those insights into our roadmap. 

Today we still meet often with rev‑cycle leaders and use real‑world payer & provider feedback to steer cutting-edge model training and new feature prioritization. 

What do you think RCM will look like two years from now?

CMS has widened its Medicare Advantage audit program, signaling increased scrutiny of billing practices, while new federal guidance from HHS and CMS outlines frameworks for responsible AI use in administrative systems. Together, these shifts are laying the groundwork for a new phase of operational automation across the healthcare sector.

For decades, healthcare operations have lagged behind clinical innovation. The revenue cycle – arguably the financial backbone of the healthcare system – remains manual, fragmented, and error-prone. Despite years of outsourced labor and legacy tools, the problems haven’t been solved – they’ve multiplied.

What’s different now is timing. Health systems are facing unprecedented margin pressure, workforce shortages, and growing regulatory scrutiny. At the same time, there's broad consensus that AI is not just viable – it’s urgently needed. Decision-makers are ready to buy. Infrastructure that can deliver step-change improvements, not just incremental gains, is finally in reach.

Charta already reviews 100% of charts in real time; the next wave is about extending that same AI-powered automation across the rest of the revenue cycle. 

It’s easy to ruin your company’s support by trying to scale it too early – not carelessly or intentionally – but by following the standard support playbook.

That standard playbook – async tickets, chatbots, and rigid KPIs – is meant to improve the customer experience. In practice, it often makes it worse.

Stedi is a healthcare clearinghouse for developers. We sell APIs to highly technical buyers, and we differentiate based on our technology and products. But when we ask customers why they chose us – what we do better than anyone else – they almost always say the same thing:

Support.

As one customer put it:

"I wish I could tell you that I chose Stedi because you have the best APIs or documentation, but the reality is that I went with you because you answered every message I sent within 15 minutes.”

We hear versions of that all the time. It’s not because we’ve mastered support best practices. It’s because we ignore them. Instead, we focus on one thing: solving the customer’s problem as quickly and completely as possible.

When you do support this way – the way that supposedly doesn’t scale – something unexpected happens:

You fix the root causes of customer issues. When you fix root causes, fewer things break. And when fewer things break, you avoid the type of problems that the standard support playbook was designed to manage in the first place.

Why most customer support is bad

Bad customer support is everywhere: useless chatbots, long wait times, unhelpful canned responses. Almost every company offers support. So why is support usually bad?

It’s because typical support tools and practices aren’t designed to help customers. They’re designed to make support easier at scale.

Most support systems assume your company is drowning in support requests. That might be true for some. But, early on, most companies aren’t. So when you implement these systems too soon – to solve a problem you don’t have – you don’t make the customer experience better. You make it worse.

The scale trap

Most teams start with hands-on support. Founders talk to customers, fix their problems, and improve the product. Then they make their first support hire – and assume what they’ve been doing will no longer work. This is typically when companies adopt traditional support systems.

Regardless of intent, those systems cause the company’s incentives around support to shift. You build systems that make support easier to manage at scale – all your tools are optimized for it.

That’s the scale trap.

For example, a typical support workflow looks like this:

1. The customer creates a ticket.
   A ticketing system makes support easier to manage. Agents can organize work into queues and juggle dozens of conversations at once.
   
   But those same ticketing systems make it harder for customers to reach out. To get help, customers have to find the (often buried) support portal, create an account, learn a new interface, file a ticket, and, finally, get in line – just when things are already going wrong for them.
   
   

2. Then you make them wait.
   Support teams use queues to manage their workload. Queue-based metrics also help you staff support predictably.
   
   For the customer, a queue means waiting. You need a quick answer to finish your work. Two hours later, you're still waiting. So customers learn: Don't ask until you're desperate.
   
   

3. Then you don’t fix their problem.
   Support KPIs track things like closed ticket counts and time to resolution, not solved problems. There is no “root causes fixed” metric. What gets measured gets done, so agents master quick workarounds and band-aid fixes.
   
   For customers, that means they wait days to get shallow responses and temporary fixes. It also means they end up running into the same issues over and over again. The root cause isn’t fixed. The tickets are closed, but the problems stay. Over time, customers stop trusting you to fix their problems at all – and stop reaching out.

If you look at typical support KPIs, this setup works: There are fewer tickets per customer and faster resolution times. But the metrics don’t answer two important questions:

1. Is the root cause of the customer’s problem really solved?

2. Does the customer trust you enough to bring you their next problem?

The job of customer support

Support exists to address customer pain. When something breaks, people want the same things anyone in pain wants:

1. To stop the pain.

2. To fix the root cause so it doesn’t happen again.

3. If that’s not possible, to manage the symptoms.

4. If that’s not possible, to get a direct, honest explanation so they can plan around it.

And they want those things fast. When you’re in pain, you want it to be over as soon as possible.

For support teams, speed isn't just about providing relief. It’s also about empathy. When you respond quickly to someone in pain, it shows you care.

Fixing the scale trap isn’t about tools – it’s about where you focus.

Delivering good support

At Stedi, the job of support is to eliminate customer pain as quickly and thoroughly as possible.

Most people brace for delays and friction when they contact support. Instead, we respond quickly and over-index on being helpful. The contrast often surprises them.

Any company can deliver good support. It just takes hard work, consistency, and the willingness to do things differently. Here’s what that looks like for us:

Work where your customers work.
Every customer gets a dedicated Slack or Microsoft Teams channel. No tickets, no help portals. Slack and Teams are already the customer’s virtual office. When they need help, they don't have to go anywhere. We're already there.

Respond quickly.
We’ve had customers say they were surprised to get a real human response within minutes. We don’t use bots or scripts. Just people who care and can help.

Anyone can help.
Any employee can answer any question in any customer channel. Engineers who built the feature. PMs who designed it. Even the CEO. We have customer success engineers, but support is everyone's job.

If something’s broken, fix it.
Everyone is empowered to make things better. If you have the answer, share it. If something's confusing, explain it and update the docs. If there's a bug, fix it. Don’t wait or assume someone else will do it.

Turn up the volume.
We want customers to bring us more problems, not fewer. Our best customers are often the loudest. They’re pushing our product to the limit, and the questions they ask make our product better.

Go deep.
We tackle questions most healthcare clearinghouses won't touch. We debug errors with customers. We explain complicated responses line by line.

No bots.
We use AI everywhere at Stedi – but not to deflect customer questions. When you need help or have an emergency, you want a human who understands your problem, not a chatbot suggesting knowledge base articles.

Be honest and direct.
When something's broken, we say so. We tell customers why it broke and when we'll fix it.

Do what you say.
If we commit to something, we give customers a date and hit it. If we can't make the deadline, we tell them early. 

Treat every customer the same.
We don’t sell support. Every Stedi customer gets the same level of support, whether you're a two-person startup or processing millions of transactions. There are no support tiers or upsells.

Hire the best people you can.
We hire smart, technical people to do support, and we pay them well. They work hard, understand systems, and can go deep into customer problems.

–

We didn't start with this playbook. When we started, we were just doing the obvious: trying to help.

Later, we found that our support model has a powerful side effect: it made our product much better.

The support-product flywheel

Good support means fixing things fast. More importantly, it means fixing root causes. We never want customers to hit the same problem twice.

To fix root causes, you have to understand the real problems. Where does our product break? Where do the docs confuse people? Where are users getting stuck?

You can't fix what you don't see, but if you respond quickly and fix things, customers will start to tell you where to look. They’ll point out issues. They’ll trust you to address their pain. And because they trust you, they reach out more. The feedback gets better. The signal gets stronger.

When you fix real problems, your product improves. Fewer customers hit snags. Your support team stops firefighting and starts building. They ship tools, chase harder problems, and spend less time repeating themselves. They’re happier because they’re doing work they’re proud of.

A better product with better support attracts more customers, including ones who push your product to the limit. They find new edge cases. Which you fix. Which makes the product better. Which attracts more customers.

That's the flywheel.

When the flywheel is in effect, the most important support-related metrics can't be measured in CSAT scores or ticket counts. They show up in net revenue retention, churn, and referrals.

But does it scale?

"Your support model won't scale. It works fine with a few customers, but it won’t work past that."

We hear this a lot.

When we were just getting started with our first customers, people would tell us that our approach wouldn’t scale past 10. When we had 10 and didn’t have any issues, people told us that it works fine with 10 customers, but it wouldn’t scale to 100 customers. We keep waiting for the wall, but it still hasn't shown up – even with hundreds of customers.

Why? Our guess is the flywheel is in full effect.

But, to be fair, we have some other things working in our favor. Stedi is built for developers. Our customers are smart and often technical. When they reach out to us, they've done their homework. They ask specific questions. They test things themselves. Smart customers asking real questions keeps our support manageable, even as we grow. Our model might not work if half our tickets were "How do I log in?"

People also assume our support team must cost a fortune. It doesn't. We pay our folks very well, and it pays off in spades. While good-enough support prevents churn, great support encourages customers to use our products even more. That makes for happier customers, and happy customers are our best salespeople.

Will we need to change certain aspects of our support eventually? Probably. But the idea that great human-to-human support can't scale assumes that every customer needs the same amount of help forever.

When you solve problems instead of managing them, support volume doesn't grow linearly with your customer count.

The hard choice

Here’s our pitch. If you run a support org, you have two options:

The safe path.
Buy the ticketing system. Track deflection rates. Answer customer questions with AI slop. This is what most companies do. No one gets fired for it. And your customers might not even complain – they’ve been trained to expect bad support. But no one will rave about it.

The harder path.
Ignore what everyone else does. Do the obvious thing: Be fast, be helpful, fix real problems. Don’t worry about whether it scales.

Our suggestion: Pick the harder path. When done right, support can become your company’s biggest competitive advantage.

Your competitors can copy your features. They can match your prices. But it takes courage to do support in a way that isn’t supposed to scale. Your customers will notice. 

See it for yourself

If you’re evaluating healthcare clearinghouses, give Stedi a try.

You can request a free trial and experience our support firsthand.

A spotlight is a short-form interview with a leader in RCM or health tech. In this spotlight, you'll hear from Dakota Haugen, Eligibility Lead at Grow Therapy.

What does Grow Therapy do?

Grow Therapy is a leading hybrid mental health company delivering both in-person and virtual therapy and medication management. With a nationwide network of over 20,000 rigorously vetted providers, Grow connects individuals with high-quality, affordable mental healthcare – often at little to no cost through insurance.

Currently available in all 50 states and accessible to 180 million Americans through their health plans, Grow is on a mission to make high-quality mental health care accessible and affordable to all. By removing barriers to care and empowering independent providers, Grow is transforming how people access and experience mental health support. Backed by top investors including Sequoia Capital and Goldman Sachs Alternatives, Grow reached a total of $178 million in funding in 2024 following a Series C raise of $88 million. The round was led by Sequoia and supported by PLUS Capital, alongside artists and athletes such as Anna Kendrick, Lily Collins, Dak Prescott, Joe Burrow, Jrue Holiday, and Lauren Holiday. They joined existing investors Transformation Capital, SignalFire, and TCV – underscoring a strong belief in Grow’s mission to become the most trusted destination for mental healthcare.

Why Grow?

• Accessible & Affordable: More than 90% of visits are insurance-covered; many clients pay just $0–$20 per session.
  
  

• Diverse & Inclusive Care: Providers reflect a wide range of identities, languages, and specialties – including trauma-informed, mindfulness, and faith-based care.
  
  

• Tech-Enabled Progress: Industry-leading Measurement Informed Care (MIC) platform and AI-assisted tools ensure clients and providers track meaningful progress.
  
  

• Trusted Relationships: 95% of clients report a strong therapeutic alliance; NPS of 85 signifies exceptional client satisfaction.
  
  

• Support for Providers: Grow removes the administrative and financial barriers to starting a private practice, empowering clinicians to focus on care.

How did you end up working in health tech?

I’ve always known that I wanted to help people – especially by addressing barriers to healthcare and creating pathways to access. My career began in the healthcare space as a medical biller, where I saw firsthand just how complex and discouraging it can be for individuals to access care. I realized I wasn’t even well-versed in navigating my own insurance, and that experience fueled my drive to better understand the system and make it easier for others.

Working in billing gave me insight into the structural challenges that stand between people and the care they need. I became passionate about creating a seamless, informed experience for patients. That passion deepened when I began my own mental health journey and experienced the benefits of care personally.

This led me to pivot into mental health, where I found an intersection of purpose and personal connection. When I discovered Grow Therapy, I immediately aligned with the mission. Grow’s commitment to both providers and clients resonated deeply with me – it’s the kind of meaningful, impactful work I’ve always aspired to do.

How does your role intersect with revenue cycle management (RCM)?

As the Eligibility Lead, my role sits at the front line of RCM, where I help ensure that clients are accurately verified for insurance coverage before beginning care. This early step is foundational to the entire revenue cycle – by identifying coverage details, confirming benefits, and addressing potential issues upfront, we minimize claim denials, reduce billing delays, and support timely reimbursement for our providers. But eligibility is more than just a financial checkpoint – it’s a critical access point for care. When done right, it removes barriers that might otherwise prevent someone from starting or continuing treatment. It gives clients clarity and confidence about what their insurance covers and what to expect financially, creating a smoother, more equitable path to mental healthcare. My work in eligibility helps lay the groundwork for both a positive client experience and a sustainable, efficient billing process.

What do you think RCM will look like two years from now?

I believe RCM will continue to evolve into a more specialized, data-driven function – especially within mental health. As the industry matures, I see RCM playing a pivotal role in not just operational efficiency, but also in driving financial outcomes that reflect the value of care. With the integration of AI and automation, particularly in areas like eligibility verification, we’ll be able to optimize workflows, reduce manual errors, and deliver real-time insights that help clients get approved and connected to care faster.

RCM will increasingly align with performance-based and value-driven models, where financial success is tied to meaningful health outcomes. This will allow individuals to see clearer connections between what they’re paying for and the results they experience – ultimately building more trust in the mental healthcare system. As we continue to remove financial and administrative barriers, RCM will help make mental health care more accessible and affordable, reinforcing the overall client experience and encouraging more people to seek and sustain the care they need.

It’s 3 AM. You’re on-call and just got paged. A customer – a 24-hour hospital in Des Moines – can’t verify patient coverage. Every eligibility check they send is failing.

You’re staring at a cryptic AAA error. More failures, now from other customers, are starting to come in. Account management wants answers.

You don’t know where to start. Is it your system? Your clearinghouse? The payer?

—

We’ve been there. Healthcare billing is a distributed system with multiple single points of failure. Even if you do everything right, things break: a payer goes down, a provider enters the wrong data, a request times out.

Stedi’s helped hundreds of teams debug eligibility issues.

This guide outlines the real-world scenarios where we’ve seen eligibility checks fail – and what we’ve found works. You’ll find common failure patterns, diagnostic tips, and how Stedi helps resolve each scenario.

For more tips, check out Eligibility troubleshooting in the Stedi docs.

You’re getting AAA 42 errors – a payer is down

Payer outages are common and often opaque. When you get an AAA 42 (Unable to Respond at Current Time) error or see a spike in timeouts for a specific payer, it usually means one of the following:

• The payer is having intermittent issues. They’re down for now but may be back up shortly.

• The payer is having a prolonged outage. This can be because of planned maintenance or a system failure on their end.

• An intermediary clearinghouse that connects to the payer – not the payer itself – is down.

These scenarios return the same errors, so it's hard to tell them apart.

What you’ll see

• AAA 42 errors from the payer

• A spike in timeouts for requests to the payer.

• Requests that fail even after retries

• Increased latency on failures

An example AAA 42 response:

{
 "errors": [
    {
      "field": "AAA",
      "code": "42",
      "description": "Unable to Respond at Current Time",
      "followupAction": "Please Correct and Resubmit",
      "location": "Loop 2100A",
      "possibleResolutions": "This is typically a temporary issue with the payer's system, but it can also be an extended outage or the payer throttling your requests (https://www.stedi.com/docs/healthcare/send-eligibility-checks#avoid-payer-throttling)."
    }
  ],
  ...
}

What helps
Whether it’s a full-blown outage or just a flaky payer, the remediation steps are the same:

• Check with Stedi to confirm the issue.
  
  

• If you’re using Stedi’s Eligibility API, retry the requests with exponential backoff. For suggested retry strategies, see Retry strategy in the Stedi docs.
  
  This is the most important remediation step. Most Stedi customers simply give up on retries too early. You’re not billed for eligibility checks that return a AAA 42 error, so there’s little incentive not to retry.

Avoid using cached or stale responses. This can cause false positives, which ultimately lead to denied claims.

What Stedi does
Where possible, Stedi uses multiple, redundant payer routes with automatic failover and retries to minimize the impact of intermediary clearinghouse outages. In many cases, our customers don’t notice an outage.

If the payer itself is down – or their designated gateway clearinghouse is down – there's no workaround. No clearinghouse can get traffic through. For widespread outages, we reach out to the payer or the gateway clearinghouse – and we notify affected customers in Slack or Teams.

A patient says they're covered, but eligibility checks return "Subscriber/Insured Not Found"

Payers can only return an eligibility response if the request matches exactly one member in their system.

If they can’t find a match, they return an AAA 75 (Subscriber/Insured Not Found) error. That usually means one of two things:

• The patient isn’t in the payer’s system.

• The patient information in the request doesn’t match what the payer has on file

What you’ll see
An AAA 75 error in the eligibility response. For example:

{
  "subscriber": {
    "memberId": "123456789",
    "firstName": "JANE",
    "lastName": "DOE",
    "entityIdentifier": "Insured or Subscriber",
    "entityType": "Person",
    "dateOfBirth": "19001103",
    "aaaErrors": [
      {
        "field": "AAA",
        "code": "75",
        "description": "Subscriber/Insured Not Found",
        "followupAction": "Please Correct and Resubmit",
        "location": "Loop 2100C",
        "possibleResolutions": "- Subscriber was not found."
      }
    ]
  }
}

You may also see:

• AAA 15 – Required Application Data Missing

• AAA 71 – Patient DOB Does Not Match That for the Patient on the Database

• AAA 73 – Invalid/Missing Subscriber/Insured Name

What helps
In your app or support flow, prompt the provider to:

• Check that the member ID matches what’s on the insurance card. Include any prefix or suffix.

• Double-check the patient’s name and date of birth (DOB).

• Use the full legal name. For example, “Robert,” not “Bob.” Avoid nicknames, abbreviations, or special characters.

• Try different name orderings. Ask about recent name changes.

• If the details look correct, make sure you’re sending the request to the right payer.

Note: Some payers allow a match even if either the first name or DOB is missing (but not both). If you’re not sure about the first name’s spelling, omitting it may improve your chances of a match. Most payers aren’t strict about matching first names exactly.

What Stedi does
Stedi makes proactive edits to eligibility requests for certain payers that are known to respond incorrectly to specific commonly accepted input formats. These edits increase the likelihood of a valid match.

Stedi also offers real-time support for eligibility issues over Slack and Teams. We’ve helped customers quickly diagnose data mismatches by highlighting exactly where the payer couldn’t find a match. Our support team responds within minutes and can spot common formatting issues that might otherwise take hours to debug.

You get a valid eligibility response, but it’s missing benefits

This usually comes down to the Service Type Code (STC) in the request. In requests, the STC tells the payer what kind of benefits you’re asking for, like medical, dental, or vision.

STCs are standardized, but payers don’t have to support all of them. Some payers only respond to a small set. Payers also don’t return benefits for STCs not covered by the related plan.

The only way to know which STCs a payer or plan supports is to test. For tips, check out How to pick the right STC (when there isn’t one).

What you’ll see
If you’re using Stedi’s Eligibility API, most benefit details come back in the benefitsInformation object array. Each object in the array has a serviceTypeCodes field.

• If no benefitsInformation objects include the requested STC, the payer or the plan probably doesn’t support the STC.
  
  

• If the STC shows up but the details you need aren't there, be sure to check any other returned STCs. Some payers return patient responsibility information under STC 30, while others may use a more specific STC code. If you still can’t find the details, the payer may not return that data in eligibility responses. 

If the response includes your STC but still lacks enough detail to determine whether the service is covered and the patient responsibility, you may need to get the missing information by calling the payer or using their portal. Some teams do this programmatically with an AI voice agent or portal scraping.

What helps

• Check that you're using the right STC.
  
  For a cheat sheet, see How to pick the right STC. For a full list, see Service Type Codes in the Stedi docs.
  
  

• Re-run the request with a baseline STC (like STC 30 for medical or STC 35 for dental).
  
  

• Test different STCs against the baseline to see what each payer supports.

What Stedi does
We’ve tested thousands of payer responses. In addition to our How to pick the right STC blog, we maintain internal payer-specific guidance on which STCs return which benefits. If a payer omits key details, we help teams explore alternatives – whether that’s trying another STC, making a payer call, using the payer portal, or a mix.

The patient doesn’t know their payer or member ID

Eligibility checks only work if the payer can match the request to one specific member. Some payers can match using just name and date of birth. Others require a member ID. All eligibility checks require a payer ID.

What you’ll see
If you don’t know the payer, you can’t submit a check – you don’t know which payer to send it to.

If you leave out the member ID and the payer requires it, you’ll likely get an AAA 72 (Invalid/Missing Subscriber/Insured ID) error.

What helps
Use insurance discovery. It lets you search for active coverage using basic demographic info like name, DOB, ZIP code, and SSN.

Success rates vary depending on the provided patient data – from 25% with basic info to 70%+ with more comprehensive details. For tips, see How to use insurance discovery.

What Stedi does
Getting insurance discovery right out of the gate can be tough. If you’re getting started, our team can help you set up workflows and provide prompts to ensure you get the most out of it.

How would I know if Stedi is down?

Outages are extremely rare for Stedi. We run entirely on AWS with a redundant, multi-region cloud architecture, and we have automated systems for deployment safety. We also maintain redundant routes for payers wherever possible, so a single intermediary clearinghouse or even a widespread payer outage won’t take us down.

What you’ll see

• A notice on our status page

• 500 HTTP status code errors when running eligibility checks.

What helps
Contact Stedi.

What Stedi does
If an outage does happen, we reach out to affected customers immediately in Slack and Teams. We also update our status page. You’ll get clear status updates, including timelines and next steps.

Behind the scenes, our team works across regions to fix the issue fast. Once it’s resolved, we share what went wrong with customers and what we’re doing to make sure it doesn’t happen again.

Don’t debug alone

Eligibility failures happen. With so many players – payers, intermediaries, gateways, providers – it’s not a matter of if, but when one makes a mistake. When your eligibility checks fail, your clearinghouse should help.

If you’re seeing one of these issues – or something new – reach out. We can help.

When you're evaluating a healthcare clearinghouse, there's one question that matters most:

Do they support my payers?

If you’re looking at Stedi, the Stedi Payer Network is how you check. It’s a public, searchable index of Stedi’s supported payers.

This short guide explains how to use the Payer Network and answers common questions about Stedi's payer coverage.

The Stedi Payer Network

The Payer Network includes every payer Stedi supports – currently 3,500+. Stedi covers virtually every U.S. healthcare payer that accepts electronic claims and eligibility checks.

If one’s missing:

• It might be listed under a different name. Reach out and we’ll check.

• If we truly don’t support the payer, submit a request to add it. We can usually connect to new payers quickly.

Some payers can’t be supported at all – by us or other clearinghouses. This may be because they’re low volume, mail-only, or only support portal-based operations.

What each Payer Network entry includes

Each payer entry includes:

• Payer name.

• Primary payer ID, plus historical and synonymous aliases. Payer ID aliases let you use the payer IDs you already use with no additional mapping.

• Supported transaction types, like 270/271 eligibility checks and 837P/837D/837I claim submissions.

• Transaction enrollment requirements for each transaction type

You can search payers by name or payer ID. You can also filter by supported transaction types.

Filters use AND logic – only payers that support all selected types will appear. For example, if you filter for 270/271 eligibility checks and 837P claim submissions, you’ll only see payers who support both.

How to check Stedi’s supported payers

There are three ways to check if your payers are covered by Stedi:

1. Send us your payer list.
   This is typically the easiest and fastest way to check. We’ll run a script to check for you and manually review the results. You can send us a message to start.
   
   

2. Download the full CSV.
   You can download our full payer list as CSV from the Payer Network site.
   
   

3. Use the Payers API.
   If you're a Stedi customer on a paid plan, you can use the Payers API to search and fetch our payers programmatically.

Do I need to map my current payer IDs?

No. We support the payer IDs you already use – no mapping required.

Behind the scenes, we maintain an internal mapping of historical and current payer IDs. If a payer changes its ID or merges with another, we’ll handle it automatically.

Do I need a backup clearinghouse?

In most cases, no.

Stedi covers virtually every U.S. healthcare payer. Where possible, we set up redundant routes to each payer with automatic failover. We also use a multi-region cloud infrastructure for redundancy.

How does Stedi work with other clearinghouses?

All clearinghouses rely on other clearinghouses. Some payers have exclusive clearinghouse relationships. For example, Optum is the designated gateway clearinghouse for UnitedHealthcare. No matter which clearinghouse you use, all UnitedHealthcare traffic goes through Optum.

To offer the broadest payer coverage, Stedi integrates with every major clearinghouse. We also build direct connections to payers wherever possible.

Stedi uses multiple routes, direct connections, and built-in redundancy to provide fast, reliable payer access. We’re not a wrapper for any other clearinghouse. As a Stedi customer, you don’t need to worry about which path we take. We pass back full payer responses without dropped fields or lossy normalization.

Next steps

Once you've verified our payer coverage, the typical next step is to explore our docs. When you're ready, you can request a free trial. Setup typically takes less than a day.

If there's a specific payer giving you trouble – whether with claims, enrollments, or eligibility – reach out. We may be able to help.

Most payers expect a Service Type Code (STC) in eligibility requests. It tells the payer what kind of benefits you want back – mental health, urgent care, vision, and so on.

But not every healthcare service maps cleanly to an STC.

Take medical nutrition or ABA therapy. There’s no obvious STC. Which one should you use?

The answer depends on the payer. The only way to know which STCs a payer supports – and return the benefits you need – is to test them.

This guide shows how to test for STC support and includes a cheat sheet of STCs to try for services that don't have a clear match. It also gives a quick primer on how STCs work in 270/271 eligibility checks.

Just want the cheat sheet? Scroll to the bottom.

Note: This guide is for medical STCs only. It doesn't cover dental STCs or dental-only payers.

What’s an STC?

A Service Type Code (STC) is a two-character code that groups similar healthcare services into standard categories. For example:

• 47 – Hospital

• AL – Vision

• UC – Urgent care

In eligibility requests, STCs tell the payer what type of benefits you're asking about. In responses, they indicate what type of service each returned benefit entry relates to.

The standard STC list

HIPAA standardizes the list of valid STCs in X12 version 005010. Medical payers should only send these STCs in responses – but they aren’t required to support every code in the list.

For the full set of X12 005010 STCs, see Service Type Codes in the Stedi docs.

Note: X12 maintains a broader Service Type Codes list for later X12 versions. X12’s list includes codes that aren’t part of 005010 and shouldn’t be used by medical payers.

STC 30 - The fallback

If you only send STC 30 (Health Benefit Plan Coverage) in the eligibility request and the patient’s plan covers it, HIPAA requires the payer to return benefits for the following STCs:

The payer may include benefits for other STCs as well.

How to use STCs in eligibility requests

If you’re using Stedi’s JSON-based Eligibility APIs, include an STC in the request’s encounter.serviceTypeCodes array:

"encounter": {
  "serviceTypeCodes": ["30"]
}

If you don’t include an STC in the request, Stedi defaults to 30 (Health Benefit Plan Coverage).

The array supports multiple STCs, but payer support varies. Unless you’ve tested a payer specifically, only send one STC per request.

To learn how to test for multi-STC support, see How to avoid eligibility check errors.

How STCs show up in eligibility responses

Most benefit details are in the benefitsInformation object array. Each object in the array includes a serviceTypeCodes field:

{
  ...
  "benefitsInformation": [
    {
      "code": "1",                        // Active coverage
      "serviceTypeCodes": ["CF"],         // Mental Health Provider - Outpatient
      "timeQualifierCode": "23",          // Calendar year
      "inPlanNetworkIndicatorCode": "Y",  // Applies to in-network services
      "additionalInformation": [
        {
          "description": "INCLUSIONS SPEECH/PHYSICAL/OCCUPATIONAL THERAPY; APPLIED BEHAVIOR ANALYSIS (ABA)"
        }
      ]
    },
    {
      "code": "C",                        // Deductible
      "serviceTypeCodes": ["CF"],         // Mental Health Provider - Outpatient
      "benefitAmount": "1000",            // $1000 annual deductible
      "timeQualifierCode": "23",          // Calendar year
      "inPlanNetworkIndicatorCode": "N"   // Applies to out-of-network services
    },
    {
      "code": "D",                        // Benefit Description
      "serviceTypeCodes": ["CF"],         // Mental Health Provider - Outpatient
      "additionalInformation": [
        {
          "description": "EXCLUSIONS: DEVELOPMENTAL TESTING, EDUCATIONAL THERAPY"
        }
      ]
    }
  ],
  ...
}

Responses may include entries for STCs you didn't request. And you'll typically see the same STC repeated across multiple benefit entries. That's normal – each entry covers a different aspect of benefits, like coverage status, co-pays, or deductibles.

Payers also use multiple entries to describe different subsets of services within an STC. For example, the MH STC might have one entry for standard therapy and another that notes coverage for other treatments. Descriptions typically appear in entries with code: "1" (Active Coverage) or code: "D" (Benefit Description), but they can appear in other entries as well. Often, coverage notes, inclusions, and exclusions appear in additionalInformation.description.

To get the full picture of benefits for a service, check all entries with the same serviceTypeCodes value.

For more information on interpreting eligibility responses, see How to read a 271 eligibility response in plain English.

Picking an STC

When sending an eligibility request, use the most specific STC you can. It narrows the response to the benefits you care about and reduces guesswork. For example, if you send a request for STC 33 (chiropractic) instead of STC 30, you’ll get specific benefits related to chiropractic care.

However, some services, like remote therapeutic monitoring (RTM) or speech therapy, don’t map cleanly to well-supported STCs.

In these cases, your best option is to systematically test the STCs that seem most appropriate and compare the responses to see if you get the benefits information you need.

How to test for STC support

1. Send a baseline eligibility request.
   Submit an eligibility check to the payer using STC 30 (Health Benefit Plan Coverage). This gives you a fallback response to compare against.
   
   

2. Test your specific STC.
   Send a second request to the payer for the same patient with the STC that best matches the benefit type you’re targeting. Use the STCs in the cheat sheet as a starting point.
   
   

3. Compare the specific STC response to the baseline response.
   If responses change based on the STC, the payer likely supports the specific STC.

If responses are identical, the payer may not support the specific STC – or the patient’s plan might not cover that service. When that happens, medical payers are required to return a fallback response using STC 30.

Example: Testing STC support for ABA therapy

Start with a baseline eligibility request using STC 30 (Health Benefit Plan Coverage):

{
  "encounter": {
    "serviceTypeCodes": ["30"]
  }
}

Then try a more specific STC like BD (mental health):

{
  "encounter": {
    "serviceTypeCodes": ["BD"]
  }
}

If the BD response includes benefitsInformation objects with a serviceTypeCodes field value of BD, the payer supports STC BD. Use this response if it includes the benefits information you need.

If the responses are identical, the payer or plan likely doesn't support the BD STC. You continue testing other related STCs, such as MH (Mental Health).

If you've already tried other STCs and no others seem appropriate, use the response for STC 30. If STC 30 doesn't include the benefits information you need, you may need to call the payer or visit the payer portal.

Tip: Automate your STC tests
To speed up testing, script your requests. Loop through candidate STCs and compare the responses against the baseline STC 30 response, using the same patient. Save the benefitsInformation array for each STC and diff them. This helps you spot what changes, if anything, between requests.

The STC cheat sheet

If you’re testing STC support for a service without a clear mapping, use the following table as a starting point. This list isn’t exhaustive and it isn’t payer-specific, but it’s a starting point for what we’ve seen work in production.

Try the STCs in the order shown – from the most specific to more general alternatives.

For a complete list of STCs, see Service Type Codes in the Stedi docs. For help mapping procedure codes to STCs, see How to map procedure codes to STCs.

You can now use the Retrieve Payer API endpoint to get a single payer record by its Stedi payer ID:

curl --request GET \
  --url https://healthcare.us.stedi.com/2024-04-01/payer/{stediId} \
  --header 'Authorization: <api-key>'

Every payer in the Stedi Payer Network has a Stedi Payer ID: an immutable payer ID you can use to route transactions to the payer in Stedi.

If you already have a payer’s Stedi Payer ID, this new endpoint is the fastest way to fetch their payer metadata. No filtering, no pagination. Just the one record.

The endpoint returns the same payer information as our existing JSON-based Payer API endpoints: payer ID, name, payer ID aliases, transaction support, enrollment requirements, and more. Just for a single payer.

Why we built this

Payer IDs are used to route healthcare transactions to the right payer. If the ID is wrong, the transaction fails.

We recently introduced List Payers and Search Payers API endpoints to let you retrieve payer IDs and other metadata programmatically. This ensures you can always get an accurate, up-to-date payer ID.

Since then, several customers have asked, “Is there a way to get a single payer without a search?”

Until now, you had to either:

• Use the Payer Search API endpoint, which always returns an array – even for exact matches.
  OR

• Fetch and paginate the full list of payers (thousands of records), then filter it client-side.

If you already had a Stedi Payer ID from a previous search or a saved mapping, there was no way to get just that payer’s metadata without a search or filter.

Now you can.

How it works

Make a GET request to the /payer/{stediId} endpoint. Pass the Stedi Payer ID as the {stediId} in the path:

curl --request GET \
  --url https://healthcare.us.stedi.com/2024-04-01/payer/HPQRS \
  --header 'Authorization: <api-key>'

You’ll get back a single JSON object that contains:

• The payer’s name, primary payer ID, and known payer ID aliases

• Whether the payer supports medical or dental coverage (or both)

• Supported transaction types

• Whether transaction enrollment is required for a transaction type

{
  "payer": {
    "stediId": "KRPCH",
    "displayName": "Blue Cross Blue Shield of Michigan",
    "primaryPayerId": "00710",
    "aliases": [
      "00210I",
      "00710",
      "00710D",
      "00710P",
      "1421",
      "2287",
      "2426",
      "710",
      "CBMI1",
      "MIBCSI",
      "MIBCSP",
      "SB710",
      "Z1380"
    ],
    "names": [
      "Blue Cross Blue Shield Michigan Dental",
      "Blue Cross Blue Shield Michigan Institutional",
      "Blue Cross Blue Shield Michigan Professional"
    ],
    "transactionSupport": {
      "eligibilityCheck": "SUPPORTED",
      "claimStatus": "SUPPORTED",
      "claimSubmission": "SUPPORTED",
      "professionalClaimSubmission": "SUPPORTED",
      "institutionalClaimSubmission": "SUPPORTED",
      "claimPayment": "ENROLLMENT_REQUIRED",
      "coordinationOfBenefits": "SUPPORTED",
      "dentalClaimSubmission": "NOT_SUPPORTED",
      "unsolicitedClaimAttachment": "NOT_SUPPORTED"
    },
    "enrollment": {
      "ptanRequired": false,
      "transactionEnrollmentProcesses": {
        "claimPayment": {
          "type": "ONE_CLICK"
        }
      }
    },
    "parentPayerGroupId": "AWOCR",
    "coverageTypes": [
      "medical"
    ]
  }
}

Try it out

The Retrieve Payer API endpoint is free on all paid Stedi plans.

To see how it works, check out the docs or reach out for a free trial.

A spotlight is a short-form interview with a leader in RCM or health tech.

In this spotlight, you'll hear from Eliana Berger, CEO at Joyful Health. You'll learn what Joyful Health does and how Eliana thinks RCM will change in the next few years.

What does Joyful Health do?

Joyful Health is a specialized revenue recovery service that focuses exclusively on the hardest part of the revenue cycle: following up on denied and unpaid claims. What makes us true experts in this space is that we hire people with payer-specific expertise who know exactly how to navigate each insurance company's systems, understand their unique resolution pathways, and can get things done quickly and accurately.

What makes us different:

• Performance-based pricing - We only get paid when we successfully recover revenue for you
  
  

• Cost optimization - As your clean claims rate improves, you pay us less, naturally optimizing your cost to collect
  
  

• Zero risk - No upfront costs, no minimum fees, services pay for themselves
  
  

• Seamless integration - We work entirely within your existing systems with no new software required
  
  

• Specialized focus - We handle denials and aged A/R recovery so your team can focus on scaling your core business

For fast-growing digital health companies, this means you can maintain lean operations while ensuring maximum revenue recovery from day one. We typically help practices recover revenue worth 5-10x our fees, making it a no-brainer investment that scales with your growth.

How did you end up working in health tech?

My path into health tech started at home. Growing up, I watched my mom and grandmother run an independent therapy practice, spending countless hours managing claims and constantly worrying about whether payments would come through. That experience stuck with me.

A few years ago, I became curious about what was really keeping independent practices on the brink of survival. So I started volunteering as a free consultant for several practices - helping with everything from ordering office furniture to analyzing their EHR data. What I discovered was eye-opening: practice owners had no idea where their money was.

Their financial data was scattered across multiple systems with no way to see the full picture. This led me to essentially become a fractional CFO for these practices, spending hours pulling together fragmented reports to give them clarity on their revenue. What I found was shocking - many were losing 10-30% of their revenue without even realizing it. The money was there, just trapped in denied claims and unpaid receivables.

That insight became the foundation for Joyful Health. We're building the modern financial operating system for healthcare, starting with revenue recovery. When you can finally see all that fragmented data in one place, it becomes crystal clear how much money is being left on the table - and more importantly, how to systematically recover what practices are rightfully owed.

How does your role intersect with revenue cycle management (RCM)?

As CEO, I'm constantly thinking about RCM from both a strategic and operational lens - but so is our entire team!

Everyone at Joyful, including operations, engineering, and beyond, regularly fights denied claims alongside our RCM specialists. This helps our entire team understand what the workflows actually look like, from interpreting denial codes to navigating payer portals to executing the right resolution actions. As a result, when our engineers are building features, they understand exactly what data points matter and how billers actually work. When our operations team is designing processes, they know the real bottlenecks and pain points. This deep, practical knowledge allows us to build products and services that are truly integrated within the systems and processes practices already have, rather than creating yet another tool that sits on the side.

From a strategic perspective, this operational depth helps me make better decisions about our product roadmap and service delivery. It's not enough to build cool technology - it has to directly solve real problems in the revenue cycle. And because everyone on our team has fought these battles firsthand, we can build solutions that actually work in the messy reality of healthcare billing.

What do you think RCM will look like two years from now?

I think we're heading toward a world where RCM becomes much more specialized and data-driven, with a clear separation between the "science" and "art" of revenue cycle management.

The "science" - rules-based, routine tasks like eligibility verification, claim scrubbing, and payment posting - will increasingly be handled by AI automation, which is already creating huge efficiencies. But the real breakthrough I'm excited about will be when AI starts getting better at the "art" side too: the complex human judgment required for things like denial management and aged A/R recovery. As AI learns from successful resolution patterns and begins to interpret payer behaviors and policies, it will help tackle problems that have traditionally required deep human expertise.

Another bigger shift I'm excited about is the move toward performance-based pricing models across the entire RCM ecosystem. Practices want better alignment between what they pay and the results they get - they want vendors who tie their success directly to their clients' financial outcomes.

The revenue cycle is how healthcare providers get paid. When it slows down, the provider’s cash flow dries up, and everything else breaks.

Less cash flow means providers have to make tough choices: not hiring needed staff, delaying investments, or cutting back on services. And that means worse care for everyone.

Despite the stakes, most of the revenue cycle is spent waiting.
… Waiting for eligibility responses.
… Waiting for claims to get accepted.
… Waiting for payments to show up.

A lot of that wait is avoidable.

If you're building RCM tools for healthcare providers, automating parts of the cycle – the critical path – can cut 10-20 days off the typical 30-60 day cycle. Providers – your customers – get paid faster, and you'll win more of them.

This guide walks you through what the revenue cycle is, tells you the key roles, and breaks down each step of the critical path: enrollment, eligibility, and processing claims. It shows how billing platforms can use Stedi to automate this critical path so it runs faster and at scale.

What is the revenue cycle?

The revenue cycle is everything a healthcare provider does to get paid.

In theory, it’s simple: a provider sees a patient and collects any co-pay or coinsurance. The provider records what happened during the visit and sends the details as a claim to the payer. The claim is approved, and the provider gets paid.

The reality is more complicated.

To avoid claim denials, providers need to check the patient’s insurance coverage before a visit. When submitting a claim, they have to use billing codes – picking from tens of thousands of them – to precisely describe the service they provided. Once submitted, payers don’t process their submitted claims right away. It can take days or weeks. A mistake means a rejection – which means starting over, delaying payment even more.

Revenue cycle management (RCM) is how providers stay on top of it all. It can be software, services, internal processes, or a mix of all three. Regardless of the methods, the goals are the same: prevent mistakes, get the provider paid faster, and avoid lost revenue.

The players

The revenue cycle involves several different systems and organizations. Each plays a specific role:

Providers
Short for “healthcare providers.” These are doctors, hospitals, dentists, therapists – anyone who delivers healthcare. They’re the ones trying to get paid.

Payers
Health insurers, including insurance companies like Aetna or Cigna, and government programs like Medicare. They receive claims, decide what to pay, and send back money (or denials) to the provider.

HIPAA and X12
A federal law that protects healthcare data and sets rules for how certain transactions must be conducted. HIPAA requires some healthcare transactions to be exchanged in the X12 EDI format. For example:

• A provider must send insurance eligibility checks to medical payers using an X12 270 Eligibility Inquiry.

• The payer must respond with a 271 eligibility response.

270 and 271 refer to official X12 HIPAA transaction types. Stedi’s APIs let you send and receive data for these transactions as JSON. We handle the translation from JSON and X12 (and the reverse) for you. You can also use Stedi to exchange raw X12.

Healthcare clearinghouses
Clearinghouses sit between providers and payers. Their job is to route transactions between the two and ensure that transactions sent to payers are HIPAA-compliant X12.

Most clearinghouses only connect to medical or dental payers. Stedi connects to both. We also connect to some vision and workers' compensation payers. 

For more information on clearinghouses, check out What is a healthcare clearinghouse?.

Billing platforms
Most providers don’t connect directly to clearinghouses or payers. They use billing platforms to manage the work for them. These include EHRs (electronic health record systems), practice management systems (PMS), and revenue cycle management (RCM) systems – often layered on top of each other.

In addition to billing, some of these platforms may help providers manage appointments, documentation, and clinical tasks.

The critical path

To get paid, every provider needs to complete certain steps in the revenue cycle. This “critical path” includes enrollment, eligibility checks, and claims processing.

There are other steps in the revenue cycle, but these are the most important to get right. Mistakes here slow down provider payments and create more work.

The following sections walk through each step in the critical path, covering its purpose, common pitfalls, and how it can be automated using Stedi.

Step 0. Enrollment

Before they can exchange transactions with payers, providers need to complete up to three different types of enrollment. Each enrollment is a one-time process, but providers need to repeat enrollment for each payer:

• Credentialing – Confirms the provider is licensed and qualified.

• Payer enrollment – Registers the provider with the payer’s health plan(s) and sets their contracted rates – the agreed dollar amounts for specific services. These rates are used later to calculate how much the payer will reimburse for a service in claims.
  
  

• Transaction enrollment – Lets the provider exchange certain types of healthcare transactions with the payer. 

Billing platforms may handle some or all of these enrollments for their providers. Stedi only helps billing platforms with transaction enrollment – but we make it faster, more automated, and easier to manage than other clearinghouses. 

Transaction enrollment
All payers require providers to complete transaction enrollment to receive 835 Electronic Remittance Advice (ERAs). Some also require enrollment for other transactions, like 270/271 eligibility checks or 837 claims.

If you're a billing platform serving many providers, transaction enrollment becomes a bottleneck. Each payer has its own enrollment process with different requirements: some need PDF signatures, others require portal logins. Just tracking the status of hundreds of enrollment submissions can become overwhelming. Many billing platforms end up hiring entire operations teams just to manage the paperwork.

Stedi automates transaction enrollment requests and lets you avoid most of the manual work. You can submit and track enrollment requests using Stedi’s Enrollments API, the Stedi portal, or a bulk CSV file. For the 850+ payers that support one-click transaction enrollment, that’s it – you’re done. For the rest, we offer delegated signature authority, where Stedi signs enrollment forms on your behalf. It’s a one-time step that eliminates 90%+ of your enrollment-related paperwork.

When manual enrollment steps are needed, we do the work for you. You only take action when absolutely needed – and we tell you exactly what to do next. We complete most enrollment requests in 1-2 business days.

Step 1. Eligibility check

Before a patient visit, providers need to know three things:

• Does the patient have active insurance?

• Does the patient’s plan cover what they’re coming in for?

• How much will the patient owe at the time of service? What’s the co-pay, coinsurance, or deductible?

An eligibility check checks a patient’s insurance to answer these questions. The checks help prevent claim denials and surprise bills. It’s especially important for specialty care – like therapy – where coverage can vary by service type.

In some cases, especially for scheduled services, providers may also need to give the patient an estimate of their out-of-pocket costs. For certain services, that estimate is required by the No Surprises Act.

To check coverage, you send a 270 eligibility request to the patient’s payer. The payer responds with a 271 eligibility response that includes benefit details: covered services, copays, coinsurance, deductibles, and more.

Real-time and batch eligibility checks
Most providers need to make eligibility checks in real time – during intake or on the phone – right before a visit. Fast, accurate eligibility responses are important. Stedi’s Real-Time Eligibility API typically returns results in 1-3 seconds.

Many providers also want to run weekly or monthly batch refreshes. These refreshes catch coverage between visits, which is helpful for recurring patients or upcoming visits. You can use Stedi’s Batch Eligibility API or a bulk CSV to run 1,000 checks at a time without interfering with your real-time checks.

Insurance discovery and COB checks
Payers only return a patient’s eligibility data if the request matches a single patient. Some payers can match a patient based on their name and date of birth alone, Many require a member ID.

If a patient doesn’t know their member ID or doesn’t know their payer, you can use an insurance discovery check to try to find active coverage using just their demographics, like name and SSN. Results aren’t guaranteed, but it’s a way forward when eligibility checks aren’t possible. If the discovery check returns multiple plans, use a coordination of benefits (COB) check to determine the primary plan.

MBI lookup
Medicare eligibility checks require the patient’s Medicare Beneficiary Identifier (MBI), the Medicare equivalent of a member ID. If a patient doesn’t know their MBI, you can use Stedi’s MBI Lookup feature to get it. If there’s a match, Stedi automatically runs an eligibility check using the MBI to return the patient’s benefits information.

Using Stedi
The following table outlines how billing platforms can run eligibility and related checks using Stedi.

Step 2. Charge capture

Once coverage is confirmed, the provider delivers care. During or after the visit, the provider captures what was done using procedure codes – structured billing codes that describe their services. Providers typically enter the codes into their EHR or PMS.

Later, these codes become the core of the claim sent to the payer. The type of code used depends on the service:

• Current Procedural Terminology (CPT) codes – Used for most medical services. Maintained by the American Medical Association (AMA).

• Healthcare Common Procedure Coding System (HCPCS) codes – Used for things like medical equipment, ambulance rides, and certain drugs. Includes CPT codes as Level I.

• Current Dental Terminology (CDT) codes - Used for dental services. Maintained by the American Dental Association (ADA).

Accuracy is important in this step. The captured codes later become part of the provider’s claim. Mistakes can mean a rejected or denied claim.

Stedi doesn’t handle charge capture directly. But many EHR and practice management platforms that integrate with Stedi do. To find them, check out our Platform Partners directory.

Step 3. Claim submission

Once care and charge capture are done, the provider uses their billing platform to submit a claim to the patient’s payer.

Claims must be submitted using an 837 transaction. There are three types:

• 837P – Professional claims, used for services like doctor visits, outpatient care, and therapy
  
  

• 837D – Dental claims
  
  

• 837I – Institutional claims, used for services like hospital stays and skilled nursing

You can use Stedi’s Claim Submission API or SFTP to submit 837P, 837D, and 837I claims.

275 claim attachments
Some services require additional documentation – like X-rays or itemized bills – to show that the service occurred or was needed. This is common in dental claims, where payers often require attachments for certain procedures.

Providers must send this documentation to the payer as one or more 275 claim attachments. The type of attachments required depends on the service and the payer. Without required attachments, the payer may delay (pend) or deny the claim.

You submit attachments separately from claims, but the request must reference the original claim. Most claim attachments are unsolicited – meaning they’re sent upfront without the payer requesting them.

You can use Stedi’s Claim Attachments API to upload and submit it as an unsolicited 275 claim attachments.

Using Stedi
The following table outlines how billing platforms can submit claims and claim attachments using Stedi.

Step 4. Claim acknowledgment

Payers don’t process claims in real time. After you submit a claim, you’ll receive one or more asynchronous 277CA claim acknowledgments: 

• First from Stedi or your primary clearinghouse. For Stedi, this usually arrives within 30 minutes of submitting the claim.

• From one or more intermediary clearinghouses, if applicable.

• Finally from the payer. This acknowledgment is the one you usually care about. You typically receive a payer acknowledgment 2-7 days after claims submission, but it can take longer.

Payers send claim acknowledgments to the provider’s – or their designated billing platform’s – clearinghouse. You can use a Stedi webhook or Stedi’s Poll Transactions API endpoint to listen for incoming 277 transactions. When a 277CA arrives, you can use the transaction ID to fetch the claim acknowledgment’s data using Stedi’s Claims acknowledgment (277CA) API.

Claim acceptance and rejection
The payer acknowledgment tells you whether the claim was accepted for processing or rejected:

• Acceptance  – The claim passed the payer’s initial checks and made it into their system. It doesn’t mean the claim was approved or paid.
  
  

• Rejection – The claim didn’t meet the payer’s formatting or data requirements and wasn’t processed at all. It doesn’t mean the claim was denied.

If the claim is rejected, fix the issue and try again. If it’s accepted, wait for the 835 ERA – the final word on payment or denial.

Claim repairs
The acknowledgment step is where most claim rejections happen. When you submit a claim using the Claim Submission API, Stedi automatically applies various repairs to help your requests meet X12 HIPAA specifications and individual payer requirements. This results in fewer payer rejections.

Prior authorization
Some services require prior authorization, or prior auth, before you can submit a valid claim. It means getting the payer’s approval for a service in advance – usually through a portal, fax, or EHR. Prior auth isn’t handled by Stedi and isn’t covered in this guide.

Using Stedi
The following table outlines how billing platforms can use Stedi to retrieve claim acknowledgments.

Step 5. Remittance and claim status

The 835 Electronic Remittance Advice (ERA) transaction is the final word on a claim. It’s the single source of truth for:

• What was paid and when

• What was denied and why

• What the patient owes

• How to post payments and reconcile accounts

Like a claim acknowledgment, the ERA is sent from the payer to the provider’s – or their billing platform’s – clearinghouse. You can create a Stedi webhook or Stedi’s Poll Transactions API endpoint to listen for incoming 835 transactions. When an 835 ERA arrives, you can use the transaction ID to fetch the ERA’s data using Stedi’s 835 ERA API. 

Claim approval and denial
Later, after the claim is processed, you may receive an approval or a denial:

• Approval – The payer agreed to pay for some or all of the claim.
  
  

• Denial – The claim was processed but not paid, usually because the service wasn’t covered or approved by the patient’s plan.

If the claim is approved, you can post the payment and reconcile the patient’s account.

If it’s denied, review the denial reason in the ERA. If the denial was incorrect or preventable, you can correct the issue and resubmit the claim. Otherwise, you can appeal or escalate the denial with the payer or bill the patient. The steps for appealing and escalating claims differ based on the payer’s rules and the patient’s plan.

Real-time claim status checks
If the claim is approved, an ERA typically arrives 7–20 business days after claim submission. If you haven’t received a claim acknowledgment or ERA after 21 days, you can check the claim’s status using a 276/277 real-time claim status check.

A real-time claim status check tells you whether the claim was received by the payer, is in process, or was denied.

You can make a claim status check any time after claim submission, but most billing platforms wait until day 21. Then they monitor the claim using real-time claim status checks until they receive a final status or an ERA. For example, the following table outlines a typical escalation process.

Using Stedi
The following table outlines how billing platforms can use Stedi to retrieve ERAs and make check claim statuses.