# Accounts and billing
Source: https://www.stedi.com/docs/healthcare/accounts-and-billing
Learn how to manage Stedi accounts, members, billing, and payments.
## Accounts [#accounts]
A Stedi account is a container for all of your Stedi activity and resources. Every account has a name, which you can find in the [Account profile](https://portal.stedi.com/app/settings/account-details). Your account also has an ID, which is used in dashboard URLs, where it appears in the `account` URL parameter.
Accounts can have unlimited members, and members can be [assigned different roles](#assign-member-roles) with different permissions.
It's possible to have multiple accounts, though using one account is recommended for most customers. If you need additional accounts, [contact us](https://www.stedi.com/contact) and we'll enable them for you.
### Join an existing account [#join-an-existing-account]
During [sign up](https://portal.stedi.com/auth/sign-up), Stedi checks whether your email domain is associated with an existing Stedi account. If it is, you can request to join that account instead of creating a new one.
For example, if you sign up with `john.doe@example.com` and your company already has a Stedi account for `example.com`, you'll see the option to request to join it. This helps prevent duplicate accounts for the same organization.
You'll receive an email when the account admin invites you to join the account and log in.
### Change account theme [#change-account-theme]
To change your account theme:
1. Click the account name in the top right of the portal.
2. Next to **Theme** you can choose between light, dark, or system (which matches your device settings).
### Set default landing page [#set-default-landing-page]
You can customize which page opens when you log in to the Stedi portal.
1. Go to the **General** page in your [Account settings](https://portal.stedi.com/app/settings/account-details).
2. Choose a **Default landing page** option:
* **Dynamic (default):** Stedi opens the claims view if you've processed at least one claim. Otherwise, Stedi opens the eligibility searches page.
* **Claims:** Stedi opens the claims view.
* **Eligibility:** Stedi opens the eligibility searches page.
### Delete an account [#delete-an-account]
[Contact support](https://www.stedi.com/contact). You can't delete your account through the Stedi portal or API.
## Members [#members]
Your account can have many members - a member represents an individual email address used to log into the account. You may want to add additional members so that other individuals in your organization can help manage transactions and troubleshoot issues.
### Invite members [#invite-members]
To add members to your account:
1. Go to the [Members page](https://portal.stedi.com/app/settings/members) in your account settings.
2. Click **Invite member**.
3. Enter the email address of the member you want to add.
4. Select the member's [role](#assigning-member-roles) from the dropdown.
5. Click **Send invitation**.
The invited member will receive an email with instructions about how to accept the invitation and log into the account. Invitations do not expire, but can be revoked by any account admin at any time before acceptance.
Stedi apps may automatically add one or more support users with a [Developer role](/healthcare/accounts-and-billing#assign-member-roles) to your account during installation. These support users allow your vendor to help you troubleshoot issues directly within your account and assist with implementation.
### Assign member roles [#assign-member-roles]
Admins can use role-based access control (RBAC) to ensure only authorized users can access and modify resources in a Stedi account. An Admin has the highest permissions, and they can access and update all resources in your account, including members and billing details. We recommend assigning most members to the Operator role. This role allows members to manage transactions (like claims and eligibility checks) and submit transaction enrollments requests, but not change account settings or billing information.
Admins can assign Stedi account members to one of four roles:
* **Admin:** These users can access and modify all resources within a Stedi account. This includes adding and removing members, assigning member roles, adding billing information, configuring settings, running eligibility checks, submitting claims, managing API keys, and configuring resources.
* **Developer:** These users can access and configure all resources, including managing API keys. However, they can't manage members or billing information.
* **Operator:** These users can run eligibility checks, run insurance discovery checks, submit claims, submit transaction enrollments, and review transaction data. They can also manage guides and trading partners (EDI platform). Finally, they can interact with developer resources, but can't modify them. For example, they can call our APIs, but they can't create or delete API keys.
Operator is the minimum required role for a user to interact with our
clearinghouse and review transactions (such as completed eligibility checks)
in Stedi.
* **Read-only:** These users can view some account resources, but cannot modify them. For example, they can review processed transactions in Stedi but can't call APIs.
To change a member's role:
1. Go to [Members page](https://portal.stedi.com/app/settings/members) in your **Account settings**.
2. Click the pencil icon for a member, choose the appropriate **Role** from the list, and click **Update role**.
### Remove members [#remove-members]
An account admin can remove other members from an account. Removed users will still retain their Stedi user credentials and access to other accounts of which they're a member.
To remove a member from your account:
1. Go to [Members page](https://portal.stedi.com/app/settings/members) in your **Account settings**.
2. Click the **...** (ellipses) to the right of the member you want to remove and select **Remove from account**.
3. Click **Are you sure?** to confirm.
The removed member will no longer have access to your Stedi account.
## Change your password [#change-your-password]
To change or reset your password:
1. Go to the [Authentication page](https://portal.stedi.com/app/settings/user-authentication) in your **Account settings**.
2. Click **Change password** in the **Password** section.
3. Enter your current password, then enter and confirm your new password.
4. Click **Done**.
You'll need to use the new password the next time you log in to Stedi.
## Multi-Factor Authentication (MFA) [#multi-factor-authentication-mfa]
You can enable Multi-Factor Authentication (MFA) for your user account. To enable MFA, click your user account icon in the top right of the app and then click **Enable MFA**.
### Enforce MFA for all members [#enforce-mfa-for-all-members]
You can require **all** users to enable MFA before accessing a Stedi account. To enforce MFA for all users:
1. Go to the [Account security page](https://portal.stedi.com/app/settings/account-security) in your **Account settings**.
2. Click the button to **Enforce multi-factor authentication**.
The next time a user logs into the Stedi account, Stedi prompts them to set up their MFA token: [https://portal.stedi.com/auth/setup-mfa](https://portal.stedi.com/auth/setup-mfa)
Once you enable MFA for a Stedi account, it cannot be disabled.
### Reset a member's MFA [#reset-a-members-mfa]
If a member loses access to their authenticator app, an account admin can reset their MFA token.
To reset a member's MFA token:
1. Go to [Members page](https://portal.stedi.com/app/settings/members) in your **Account settings**.
2. Click the **...** to the right of the member you want to reset.
3. Select **Reset member MFA**.
The member will be prompted to set up a new MFA token the next time they log in. If they're currently logged in, they may not be logged out immediately - the reset process can take up to an hour.
### Update your MFA [#update-your-mfa]
To update your MFA token:
1. Go to the [Account security](https://portal.stedi.com/app/settings/user-authentication) in your **Account settings**.
2. Click **Update** in the **Multi-factor authentication** section.
3. Follow the prompts to set up your new MFA token.
4. Click **Save**.
## Single Sign-On (SSO) and SCIM [#single-sign-on-sso-and-scim]
Admins can configure Single Sign-On (SSO) and directory sync (SCIM) through Stedi's WorkOS integration.
* SSO allows account members to sign in to Stedi through your chosen identity provider, such as Okta or OneLogin.
* Directory sync (SCIM) automatically creates and removes Stedi accounts through your chosen identity provider.
### Request access [#request-access]
To request SSO and/or directory sync for your account:
1. Go to the [Account security page](https://portal.stedi.com/app/settings/account-security) in your **Account settings**.
2. Click **Contact us** to go to Stedi's contact form and request SSO for your account.
Stedi support will review the request and enable access.
### Configure SSO [#configure-sso]
Once Stedi support enables SSO access, you can configure it for your account:
1. Go to the [Account security page](https://portal.stedi.com/app/settings/account-security) in your **Account settings**.
2. Click **Set up Single sign-on**. Stedi redirects you to the WorkOS portal for setup.
3. Follow the steps in the WorkOS portal to configure SSO for your identity provider. WorkOS provides detailed instructions for connecting each identity provider as part of the setup flow. You can also visit the WorkOS [Single Sign-On documentation](https://workos.com/docs/sso) for more details.
Once configured, you can manage the account's SSO settings from the [Account security page](https://portal.stedi.com/app/settings/account-security). This includes:
* **Require SSO for all members:** Toggling this to **ON** disables the standard email and password login process - account members will only be able to access Stedi through SSO.
* **Default role for new members:** Choose which [member role](#assign-member-roles) is automatically assigned to users when they join the account.
### Configure directory sync (SCIM) [#configure-directory-sync-scim]
Once SSO is configured, you can optionally also set up directory sync (SCIM) through WorkOS. If you don't see directory sync in your account, contact Stedi support to request access.
To configure directory sync:
1. Go to the [Account security page](https://portal.stedi.com/app/settings/account-security) in your **Account settings**.
2. In the **Single sign-on (SSO)** section, click **Set up directory sync**. Stedi redirects you to the WorkOS portal for setup.
3. Follow the steps in the WorkOS portal to configure directory sync for your identity provider. WorkOS provides detailed instructions for connecting each identity provider as part of the setup flow. You can also visit the WorkOS [directory sync documentation](https://workos.com/docs/directory-sync) for more details.
Once configured, you can review automatically created user accounts from the [Members page](https://portal.stedi.com/app/settings/members) in your **Account settings**.
You can manage the account's directory sync settings from the [Account security page](https://portal.stedi.com/app/settings/account-security).
## Reauthentication [#reauthentication]
Stedi requires all users to sign in every 12 hours. This aligns our maximum session duration with National Institute of Standards and Technology (NIST) best practices, and it isn't configurable.
### Enable inactivity sign-out [#enable-inactivity-sign-out]
Admins can opt in to have account members automatically sign out after 30 minutes of inactivity. This reduces the risk of unattended workstations being used to access patient data.
To enable inactivity sign-out for your account:
1. Go to the [Account security page](https://portal.stedi.com/app/settings/account-security) in your **Account settings**.
2. Click **Enable inactivity sign-out** under **Inactivity sign-out**.
Once enabled, members will be automatically signed out of the Stedi portal after 30 minutes of inactivity. Activity includes mouse movements, keyboard input, and touch events.
## Billing [#billing]
Each account will be invoiced monthly.
### Add or edit payment method [#add-or-edit-payment-method]
To add or edit your payment details:
1. Go to your [Account settings](https://portal.stedi.com/app/settings/account-details).
2. Click **Billing**. You'll be taken to a secure third-party payment site to enter or update your credit card information.
3. Click **Add payment method** or **Update payment method**.
4. Enter your payment details. You can enter either credit card details or the routing information for a United States bank account.
Once you save your changes, any charges will be billed to the payment information on file.
## Developer settings [#developer-settings]
You can create API keys and SFTP credentials from your [Account settings](https://portal.stedi.com/app/settings/account-details).
### SFTP setup [#sftp-setup]
You can:
* Create both test and production SFTP credentials to upload claims and retrieve claim responses through Stedi's fully-managed SFTP server.
* Control whether you'll receive 999s for fully accepted functional groups or only when there are rejected transactions.
Visit [Submit claims through SFTP](/healthcare/submit-claims-sftp-connection#create-sftp-users) for more details.
### API keys [#api-keys]
You can create both test and production API keys.
* Test API keys allow you to send mock eligibility checks to Stedi's Real-Time Eligibility Check API. Visit [Eligibility mock requests](/healthcare/api-reference/mock-requests-eligibility-checks) for more details.
* Production API keys allow you to authenticate with all Stedi APIs.
# Batch eligibility checks
Source: https://www.stedi.com/docs/healthcare/batch-refresh-eligibility-checks
Batch eligibility checks are a great option as your volume grows. Stedi handles complexity like queuing and retries according to established best practices, so you don't have to build this logic yourself. We recommend using batch checks for bulk workflows that aren't time sensitive, including:
* Monthly or weekly coverage refreshes
* Upcoming appointments
* Sets of thousands or millions of checks that can run in the background
However, batch checks have a longer feedback cycle than real-time checks because you don't receive the payer's response immediately. That's why we strongly recommend starting with [real-time checks](/healthcare/api-reference/post-healthcare-eligibility) when integrating with a new payer or working with eligibility checks for the first time. This approach allows you to ensure that your pipeline is working smoothly before you begin staging batch checks.
You can submit batch checks manually by uploading CSV files to the Stedi portal or programmatically through the API.
## Transaction enrollment [#transaction-enrollment]
If the provider is already enrolled for real-time eligibility checks through Stedi, you don't need to enroll again for batch eligibility checks.
[Transaction enrollment](/healthcare/transaction-enrollment) is the process of registering a provider to exchange specific healthcare transactions with a payer.
Most payers don't require transaction enrollment for eligibility checks. Those that do, such as the Centers for Medicare & Medicaid Services (CMS), typically allow multiple enrollments with different clearinghouses. That means enrolling through Stedi shouldn't cancel or interfere with any existing enrollments you have through other clearinghouses.
Enrolling through Stedi for eligibility checks also doesn't affect your existing enrollments for other transaction types. For example, enrolling with Stedi won't unenroll the provider from receiving transactions like Electronic Remittance Advices (ERAs) through other clearinghouses.
You can check whether a specific payer requires enrollment for eligibility checks in the [Payer Network](https://www.stedi.com/healthcare/network) or through the [Payers API](/healthcare/api-reference/get-payer).
If enrollment is required, complete the following steps:
1. Create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step. [Stedi portal](https://portal.stedi.com/app/healthcare/providers) | [API endpoint](/healthcare/api-reference/post-enrollment-create-provider)
2. Submit an enrollment request for real-time eligibility checks - batch eligibility checks use the same enrollment process as real-time eligibility checks. [Stedi portal](https://portal.stedi.com/app/healthcare/enrollments) | [API endpoint](/healthcare/api-reference/post-enrollment-create-enrollment)
## Manual submission [#manual-submission]
You can submit batch eligibility checks through bulk CSV upload.
### Create new CSV batch [#create-new-csv-batch]
To create a new CSV batch:
1. Go to the [Batch eligibility checks page](https://portal.stedi.com/app/healthcare/checks/batch).
2. Click **+ New batch from CSV**.
3. Enter a unique name for the batch. Stedi displays this name in the list of batch uploads. This name is for your reference only - we don't send it to payers.
4. (Optional) Click **Advanced options** to configure a custom **Retry duration** between 8 and 24 hours. This is the maximum number of hours that Stedi will retry checks in the batch that fail due to payer connectivity issues. The default is 8 hours.
5. Click **Create** to go to the CSV upload page for your new batch.
### Upload CSV file [#upload-csv-file]
On the CSV upload page for your batch:
1. Click **Download a template** to download the CSV template with the supported fields. You can also download it from this link: [template CSV file](/files/batch-eligibility-template.csv).
2. Populate the template with eligibility checks. Each row in the template represents one eligibility check. You can submit up to 10,000 checks per CSV file. The upload page contains detailed documentation for each possible field and recommendations for which fields to include for the best chance of success.
You can also submit [MBI lookups](/healthcare/mbi-lookup) through CSV upload. Set the `tradingPartnerServiceId` for each check to either **MBILU** (for MBI lookups with SSN) or **MBILUNOSSN** (for MBI lookups without SSN). Then, include the required patient demographic information for each lookup.
3. Click **+ Upload file** to upload your complete CSV file.
4. Click **Verify file** so Stedi can validate the data in each eligibility check. You can fix any errors and re-upload the CSV file as many times as needed. When the file is error-free, you'll be able to execute the batch.
5. Click **Execute batch** to send the eligibility checks to Stedi for processing.
Stedi processes the checks asynchronously, implementing best practices to avoid payer throttling. Each eligibility check in the batch is stored in its own eligibility search. You can review the details of each check from the [Eligibility searches page](https://portal.stedi.com/app/healthcare/eligibility).
### Batch status [#batch-status]
The batch status changes to **In progress** while Stedi is processing the batch. The status changes to **Completed** when Stedi has sent all checks in the batch to payers and received responses. A completed batch may contain both successful and failed eligibility checks.
You can [retrieve the results](#retrieve-batch-results) of each check in the batch through the Stedi portal or API.
## API submission [#api-submission]
You can use Stedi's [Batch Eligibility Check](/healthcare/api-reference/post-healthcare-batch-eligibility) API to submit up to 10,000 eligibility checks in a single request. Stedi processes these eligibility checks asynchronously, implementing best practices to avoid payer throttling.
### Headers - required [#headers---required]
You must include the following headers in your API request:
* **`Authorization`:** [Generate an API key](/healthcare/api-reference#authentication) to use for authentication.
* **`Content-Type`:** Set to `application/json`.
```bash
curl --request POST \
--url https://manager.us.stedi.com/2024-04-01/eligibility-manager/batch-eligibility \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
```
### Headers - situational [#headers---situational]
When sending eligibility checks to the Centers for Medicare & Medicaid Services (CMS), you may need to include the `X-Forwarded-For` header set to a comma-separated list of any upstream IP addresses. Visit [CMS traceability requirements](#cms-traceability-requirements) for details and examples.
### Request data [#request-data]
The information you provide to the payer in an eligibility check can vary, depending on the circumstances. However, each batch eligibility check must include at least the following information:
| Information | Description |
| ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tradingPartnerServiceId` | - This is the payer ID. Visit the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list. You can send requests using the primary payer ID, the Stedi payer ID, or any alias listed in the payer record.
- You must include leading `0` characters in payer IDs. For example, use `00540` for SISCO, not `540`.
- If you don't know the payer, try submitting an [insurance discovery check](/healthcare/insurance-discovery) instead.
|
| `submitterTransactionIdentifier` | - A unique identifier for the eligibility check within the batch.
- Stedi returns this identifier in the response for the [Retrieve Batch Check Statuses](/healthcare/api-reference/get-healthcare-batch-eligibility-check-statuses) and [Poll Batch Eligibility Checks](/healthcare/api-reference/get-healthcare-polling-eligibility) endpoints so you can correlate the original eligibility request with its processing status and the payer's response.
|
| `provider` object, name and identifier | - You must include the provider's name - either the `firstName` and `lastName` of a specific provider within a practice or the `organizationName`.
- You must include an identifier - this is typically the provider's [National Provider Identifier](https://www.stedi.com/docs/healthcare/national-provider-identifier) (`npi`). If the provider doesn't have an NPI, you can supply an alternative, such as their `taxId` or `ssn`.
|
| `subscriber` and/or `dependents` objects | - The `dependents` object is optional - refer to the scenarios when the [patient qualifies as a dependent](/healthcare/send-eligibility-checks#dependents).
- At a minimum, our API requires that you supply at least one of these fields in the request: `memberId`, `dateOfBirth`, or `lastName`. However, each payer has different requirements, so you should supply the fields necessary for each payer to identify the subscriber in their system.
- When all four of `memberId`, `dateOfBirth`, `firstName`, and `lastName` are provided, payers are required to return a response if the member is in their database. Some payers may be able to search with less information, but this varies by payer.
- We recommend always including the patient's member ID when possible. Learn more about [patient information](/healthcare/send-eligibility-checks#patient-information).
|
| `encounter` object, service dates | - You can specify either a single `dateOfService` or a `beginningDateOfService` and `endDateOfService`. The payer defaults to using the current date in their timezone if you don't include one.
- When checking eligibility for today, omit the `dateOfService` property to ensure consistent behavior across payers.
- We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers such as the Centers for Medicare and Medicaid Services (CMS) do support requests for dates further in the future - especially the next calendar month. Check the payer's documentation to determine their specific behavior.
|
| `encounter` object, service or procedure codes | - Specify `serviceTypeCodes` and/or a `procedureCode` and `productOrServiceIDQualifier` to request specific types of benefits information.
- We recommend including no more than one service type code in each request.
- If you don't include any service type code or procedure code information, Stedi defaults to using `30` (Plan coverage and general benefits) as the only `serviceTypeCodes` value.
- Learn more about [STCs and procedure codes](/healthcare/eligibility-stc-procedure-codes).
|
#### Patient information [#patient-information]
Batch checks should follow the same best practices as real-time eligibility checks when entering patient information. Visit [Real-time eligibility checks](/healthcare/send-eligibility-checks#patient-information) for guidance on:
* Which patient identifiers to use for best results
* How to know if a patient qualifies as a dependent
* How to enter patient names for best results
#### MBI for CMS checks [#mbi-for-cms-checks]
A Medicare Beneficiary Identifier (MBI) is a unique, randomly-generated identifier assigned to individuals enrolled in Medicare. You must include the patient's MBI in every eligibility check to the Centers for Medicare and Medicaid Services (payer ID: CMS).
Some payers return the patient's MBI in one of the following properties of the standard eligibility response:
* [`benefitsInformation[].benefitsAdditionalInformation.hicNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.benefitsInformation.benefitsAdditionalInformation.hicNumber)
* [`planInformation.hicNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.planInformation.hicNumber)
If the value in either of these properties matches the format specified in the [Medicare Beneficiary Identifier documentation](https://www.cms.gov/training-education/partner-outreach-resources/new-medicare-card/medical-beneficiary-identifiers-mbis), the number is likely an MBI, and we recommend sending a follow-up eligibility check to CMS for additional benefits data. You're most likely to receive an MBI in eligibility check responses from commercial Medicare Advantage plans, but they can also be present in responses from Medicaid plans for dual-eligible patients.
When you don't know a patient's MBI, you can use Stedi's eligibility check APIs to perform an MBI lookup instead of a standard eligibility check. Stedi returns a complete benefits response from CMS with the patient's MBI in the `subscriber` object for future reference. Visit [Medicare Beneficiary Identifier (MBI) lookup](/healthcare/mbi-lookup) for complete details.
**Don't** submit eligibility checks for Medicare Advantage plans to CMS (HETS)
– you should submit them to the actual Medicare Advantage plan payer
instead.
#### Conditional requirements [#conditional-requirements]
Note that objects marked as **required** are required for all requests, while others are conditionally required depending on the circumstances. When you include a conditionally required object, you must include all of its required properties.
For example, you must always include the `provider` object in your request, but you only need to include the `dependents` object when you need to request benefits information for a dependent on the subscriber's insurance plan.
#### Character restrictions [#character-restrictions]
Only use the X12 Basic and Extended character sets in request data. Using characters outside these sets may cause errors.
The X12 Basic character set includes uppercase letters, digits, space, and some special characters. Lowercase letters and special language characters like `ñ` are not included.
The following special characters are included:
The Extended character set includes the characters listed in Basic, plus lowercase letters and additional special characters, such as `@`.
The following additional special characters are included:
In addition, the following characters are reserved for delimiters in the final X12 EDI transaction to the payer: `~`, `*`, `:` and `^`. X12 doesn't support using escape sequences to represent delimiters or special characters. Stedi returns a `400` error if you use these restricted characters improperly.
Don't include delimiter characters anywhere in your request data.
**Autocorrection for backticks**
Stedi automatically replaces backticks (`` ` ``), also known as backquotes or grave accents, with an apostrophe (`'`) in `subscriber` and `dependents` first and last names. These corrections prevent errors when submitting your request. Stedi returns a message in the response's `warnings` array when it makes this replacement.
### Sample request and response [#sample-request-and-response]
The following example demonstrates how to submit a batch of eligibility checks in the `items` array, where each item represents an individual eligibility check. Stedi returns a `batchId` that you can use to retrieve the results of these checks later.
Visit [Determine patient benefits](/healthcare/eligibility-active-coverage-benefits) for detailed explanations of how to determine the patient's active coverage, financial responsibility, whether referrals and authorizations are required, and more.
{/* schema:BatchEligibilityChecksRequestContent */}
```bash
curl --request POST \
--url https://manager.us.stedi.com/2024-04-01/eligibility-manager/batch-eligibility \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--data '{
"items": [
{
"submitterTransactionIdentifier": "ABC123456789",
"tradingPartnerServiceId": "AHS",
"encounter": {
"serviceTypeCodes": [
"MH"
]
},
"provider": {
"organizationName": "ACME Health Services",
"npi": "1999999984"
},
"subscriber": {
"dateOfBirth": "19000101",
"firstName": "Jane",
"lastName": "Doe",
"memberId": "1234567890"
}
},
{
"submitterTransactionIdentifier": "DEF123456799",
"tradingPartnerServiceId": "AHS",
"encounter": {
"serviceTypeCodes": [
"78"
]
},
"provider": {
"organizationName": "ACME Health Services",
"npi": "1999999984"
},
"subscriber": {
"dateOfBirth": "19001021",
"firstName": "John",
"lastName": "Doe",
"memberId": "1234567892"
}
}
]
}'
```
{/* schema:BatchEligibilityChecksResponseContent */}
```json
{
"batchId": "01928d19-df25-76c0-8d51-f5351260fa05",
"submittedAt": "2023-11-07T05:31:56Z"
}
```
### Delimiter normalization [#delimiter-normalization]
Stedi normalizes delimiters in both the JSON and raw X12 responses you receive to ensure consistency and prevent parsing issues. When the following delimiter characters appear within data values - meaning they are used as content - Stedi replaces them as shown:
| Delimiter type | Original | Replaced with |
| --------------------------- | -------- | ------------- |
| Element separator | `*` | `\|` |
| Repetition separator | `^` | `\|` |
| Component element separator | `` ` `` | `'` |
| Segment terminator | `~` | `\|` |
**Examples:**
* `O*CONNOR` becomes `O|CONNOR`
* `CODE^01` becomes `CODE|01`
* ``O`CONNOR`` becomes `O'CONNOR`
* `MSG~HELLO` becomes `MSG|HELLO`
If you parse raw X12 EDI responses, ensure your parser reads delimiters from the `ISA` segment instead of assuming fixed delimiters.
### Concurrency limit [#concurrency-limit]
Asynchronous batch checks don’t count toward your Stedi account [concurrency limit for real-time checks](/healthcare/api-reference#concurrency-limits).
There are no limits on the number of batches you can run in parallel.
## Configure automatic retries [#configure-automatic-retries]
Stedi retries checks that fail due to [payer connectivity issues](/healthcare/eligibility-troubleshooting#payer-connectivity-issues) for 8 - 24 hours, depending on the specified retry period. It can take up to the configured retry period for all checks in a batch to return results.
You can configure the retry period for a batch by:
* **API:** Include the optional `maxRetryHours` property in the request.
* **CSV upload:** Open **Advanced options** during creation and select a **Retry duration** from the dropdown.
For both submission methods, you can choose a value between 8 and 24 hours. If not set, the default is 8 hours.
## Track batch status [#track-batch-status]
After you've submitted a batch of eligibility checks, you can track the processing status through the Stedi portal or API.
### Processing status vs. eligibility outcome [#processing-status-vs-eligibility-outcome]
You can track the overall batch processing status, the processing status of each eligibility check, and each eligibility check's outcome (eligibility search status).
| Status | Description |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Batch | - The processing status of an eligibility check batch within Stedi.
- In the API, this is the Batch Status response [`status` property](/healthcare/api-reference/get-healthcare-batch-eligibility-status#response.status).
- In the Stedi portal, this is the batch **Status**.
|
| Eligibility check | - The processing status of an individual eligibility check (batch item). It doesn't indicate whether the payer returned benefits information.
- In the API, this is the Retrieve Batch Check Statuses response [`items[].state` property](/healthcare/api-reference/get-healthcare-batch-eligibility-check-statuses#response.items.state).
- In the Stedi portal, this is the **Processing status** of each eligibility check within a batch.
|
| Eligibility search | - The outcome of an eligibility check based on the payer's response. Use it to determine whether a completed eligibility check returned active coverage types.
- Stedi groups retries of the same eligibility check (if present) into a larger record called an eligibility search. The eligibility search status reflects the outcome of the last retry attempt in the record.
- In the API, this is the Retrieve Batch Check Statuses response [`items[].additionalInfo.eligibility.eligibilitySearchStatus` property](/healthcare/api-reference/get-healthcare-batch-eligibility-check-statuses#response.items.additionalInfo.eligibility.eligibilitySearchStatus).
- In the Stedi portal, this is the **Search outcome**. The search outcome reflects the eligibility search's status after the last retry attempt, so it's only relevant for completed searches - not those with a `queued` or `started` processing status.
|
### Stedi portal [#stedi-portal]
You can review the progress of batch eligibility checks submitted through API or CSV upload on the [Eligibility check batches page](https://portal.stedi.com/app/healthcare/checks/batch).
Click the batch name to view its details, including the **Processing status** and **Search outcome** of each check. You can also download the original CSV input, if the batch was submitted as a CSV file.
### Status endpoints [#status-endpoints]
You can use the following endpoints to programmatically check the status of batch eligibility checks submitted through the API or CSV upload. These endpoints help you determine when to start polling for results.
#### Retrieve Batch Status [#retrieve-batch-status]
The [Retrieve Batch Status](/healthcare/api-reference/get-healthcare-batch-eligibility-status) endpoint returns a summary of the batch's processing status, including the number of completed checks, the error count, and the overall batch status. You can use it to determine when to start polling for the results of the eligibility checks within the batch. For example:
* Don't start polling until either the `successCount` or the `errorCount` are greater than zero because these properties indicate checks that Stedi has finished processing. Or, you may want to poll once when the batch `status` is `COMPLETED` or `COMPLETED_WITH_ERRORS`, meaning all checks have been processed.
* You can stop polling when the `inProgressCount` reaches zero or when the batch `status` is `COMPLETED` or `COMPLETED_WITH_ERRORS`.
The following is an example response for a batch submitted through the API. The `successCount` matches the `totalCount`, indicating that all checks in the batch have been successfully processed and that the payer returned a response.
Note that successful processing doesn't necessarily mean that the patient has active coverage; it simply means that the payer returned a response for the check. You'll need to review the individual check results to determine the patient's coverage status.
```json
{
"batchType": "ELIGIBILITY",
"createdAt": "2025-06-13T17:14:20.02Z",
"errorCount": 0,
"id": "01976a49-05f4-7421-bc33-aed86f1fccc6",
"inProgressCount": 0,
"name": "01976a49-05f4-7421-bc33-aed86f1fccc6",
"source": "API",
"status": "COMPLETED",
"successCount": 9000,
"totalCount": 9000,
"updatedAt": "2025-06-13T17:14:24.872Z",
"validatedCount": 0,
"validationFailedCount": 0
}
```
#### Retrieve Batch Check Statuses [#retrieve-batch-check-statuses]
The [Retrieve Batch Check Statuses](/healthcare/api-reference/get-healthcare-batch-eligibility-check-statuses) endpoint retrieves the processing status of the eligibility checks in the specified batch. You can use it to determine whether specific eligibility checks within a batch have completed. You can also use the response to determine whether patients have active or inactive coverage without having to poll.
The following is an example response for two checks in a batch submitted through a CSV upload. You can tell because the results include the `rowNumber`, which indicates the row number for that eligibility check in the CSV file.
* The first check has an `eligibilitySearchStatus` of `active`, indicating that the payer returned at least one active eligibility and benefit type. This means that the patient has active coverage for at least some services. it's `state` is `COMPLETED`, indicating that the check was successfully processed and that the payer returned a response.
* The second check has an `eligibilitySearchStatus` of `failed`, indicating that Stedi didn't receive benefits information from the payer. Its `state` is `COMPLETED_WITH_ERRORS`, which typically indicates that Stedi couldn't get a response from the payer after retrying. Failures like this are often due to payer connectivity issues.
Each check's `additionalInfo.eligibility` object includes the following [eligibility check identifiers](#eligibility-check-identifiers):
* `submitterTransactionIdentifier`: The identifier you assigned to the check when submitting the batch.
* `id`: The globally unique, Stedi-assigned eligibility check ID.
```json
{
"items": [
{
"additionalInfo": {
"eligibility": {
"eligibilitySearchId": "01932c61-2d4f-7d22-85fa-c7db2e13e771",
"id": "ec_01932c61-2d4f-7d22-85fa-c7db2e13e770",
"submitterTransactionIdentifier": "ABC123456789",
"eligibilitySearchStatus": "active",
"payerId": "BCBS",
"subscriberFirstName": "John",
"subscriberLastName": "Doe",
"subscriberMemberId": "123456789"
}
},
"batchId": "01932c61-2d4f-7d22-85fa-c7db2e13e771",
"createdAt": "2025-03-31T14:25:30Z",
"requestId": "req-01a2b3c4-d5e6-7f89-0123-456789abcdef",
"rowNumber": 3,
"state": "COMPLETED",
"updatedAt": "2025-03-31T14:26:45Z"
},
{
"additionalInfo": {
"eligibility": {
"eligibilitySearchId": "01932c61-2d4f-7d22-85fa-c7db2e13e772",
"submitterTransactionIdentifier": "GHJ987654321",
"eligibilitySearchStatus": "failed",
"payerId": "AETNA",
"subscriberFirstName": "Jane",
"subscriberLastName": "Smith",
"subscriberMemberId": "987654321"
}
},
"batchId": "01932c61-2d4f-7d22-85fa-c7db2e13e771",
"createdAt": "2025-03-31T14:25:30Z",
"requestId": "req-02a2b3c4-d5e6-7f89-0123-456789abcdef",
"rowNumber": 2,
"state": "COMPLETED_WITH_ERRORS",
"updatedAt": "2025-03-31T14:27:15Z"
}
],
"nextPageToken": "945ff6de213d3ef481d028065d4c12fb996a166a3a90ef98564318decfae50ce4b36d74b7e9d9bafa6e1d169"
}
```
## Retrieve batch results [#retrieve-batch-results]
You can retrieve batch check results through the Stedi portal or API.
### Stedi portal [#stedi-portal-1]
To review batch results:
1. Go to the [Batch eligibility checks](https://portal.stedi.com/app/healthcare/checks/batch) page.
2. Click the batch name to view its details, including the status of each check in the batch.
3. Click any eligibility check to go to its details. You'll be able to review the full request and response payload as well as any error messages (if present). You'll also be able to edit the request details for failed eligibility checks and resubmit them to the payer.
### Polling endpoint [#polling-endpoint]
You can use the [Poll Batch Eligibility Checks](/healthcare/api-reference/get-healthcare-polling-eligibility) endpoint to retrieve the results from batch checks submitted through both the API and CSV upload.
You should [track completed checks](#track-completed-checks) to determine when to stop polling.
#### Polling strategy [#polling-strategy]
We recommend using the [Retrieve Batch Status](/healthcare/api-reference/get-healthcare-batch-eligibility-status) endpoint to monitor the progress of large batches and determine when to start polling for results.
* Don't start polling until either the `successCount` or the `errorCount` are greater than zero because these properties indicate checks that Stedi has finished processing. Or, you may want to poll once when the batch `status` is `COMPLETED` or `COMPLETED_WITH_ERRORS`, meaning all checks have been processed.
* You can stop polling when the `inProgressCount` reaches zero or when the batch `status` is `COMPLETED` or `COMPLETED_WITH_ERRORS`.
While batches are in progress, a single polling attempt may not retrieve responses for all checks within the batch. Most batches complete in 15 to 30 minutes. However, Stedi retries checks that fail due to [payer connectivity issues](/healthcare/eligibility-troubleshooting#payer-connectivity-issues) for 8 - 24 hours, depending on the configured retry period. It can take up to the configured retry period for all checks in a batch to return results.
After your initial poll, use exponential backoff with jitter. Start at 2 minutes and approximately double the wait between polls, up to the end of the configured retry period. For example, you might use something similar to the following formula (all values in seconds) for the 8-hour default retry period:
```
wait_time = (0 if attempt == 0 else min(120 * 2**(attempt - 1), 8*60*60)) + random(0, 30)
```
In this formula:
* **Immediate first poll:** if `attempt == 0` then wait time is `0`.
* **Start at 2 minutes:** On attempt == `1`, base wait is 120 seconds (2 minutes).
* **Exponential backoff:** Doubles each time: 2, 4, 8, 16, ... minutes.
* **Cap at 8 hours:** min(..., 8*60*60) ensures it never exceeds 480 minutes.
* **Jitter:** Adds a random delay between 0 and 30 seconds.
#### Filter polling results [#filter-polling-results]
You can filter the polling results using the following query parameters:
* `batchId`: Retrieve results for a specific batch of eligibility checks. You can find this value in the synchronous response from the [Batch Eligibility Check](/healthcare/api-reference/post-healthcare-batch-eligibility) endpoint.
* `startDateTime`: Retrieve results for checks submitted after a specific date and time (in ISO 8601 format).
The following example example retrieves the results for batch checks submitted after `2025-12-31T00:00:00Z`:
```bash
curl --request GET \
--url https://manager.us.stedi.com/2024-04-01/eligibility-manager/polling/batch-eligibility?startDateTime=2025-12-31T00:00:00Z \
--header 'Authorization: '
```
#### Track completed checks [#track-completed-checks]
The polling endpoint only returns checks that have been fully processed. These are checks that:
* Returned benefits information indicating either active or inactive coverage. These checks have a final `state` of `COMPLETED` and an `eligibilitySearchStatus` of `active` or `inactive`.
* Returned an error response from the payer that doesn't indicate payer connectivity issues. For example, if the payer returns an error indicating that the member ID is invalid, Stedi considers this a completed check and returns it in the batch results with the associated [`AAA` error](/healthcare/eligibility-troubleshooting#payer-aaa-errors) of `72` (Invalid/Missing Subscriber/Insured ID). These checks have a final `state` of `COMPLETED` and an `eligibilitySearchStatus` of `failed`.
* Returned `AAA` errors `42` or `80` for the entire retry period. These `AAA` errors indicate payer connectivity issues, and Stedi retries checks that fail due to payer connectivity issues for 8 - 24 hours. After the configured retry period, Stedi returns it in the batch results with the associated `AAA` error. These checks have a final `state` of `COMPLETED_WITH_ERRORS` and an `eligibilitySearchStatus` of `failed`.
* Stedi couldn't process due to validation errors in the request data. These checks have a final `state` of `VALIDATION_FAILED` and an `eligibilitySearchStatus` of `failed`.
Checks that Stedi hasn't yet finished processing aren't included in the polling results. For example, the polling endpoint won't return results for checks that are eligible for automatic retries.
You'll need to track the status of pending checks to determine when to stop polling. You can do this with either of the status endpoints:
* [Retrieve Batch Status](/healthcare/api-reference/get-healthcare-batch-eligibility-status): Returns summary information about the batch, including the `inProgressCount`, which indicates how many checks are still pending. You can stop polling when this count reaches zero or when the batch `status` is `COMPLETED` or `COMPLETED_WITH_ERRORS`.
* [Retrieve Batch Check Statuses](/healthcare/api-reference/get-healthcare-batch-eligibility-check-statuses): Returns status information for all checks in the batch, including those that are still pending. The information for each check includes the `submitterTransactionIdentifier` you assigned when you submitted the batch. This identifier is also present in the polling results, allowing you to correlate the original eligibility request with its processing status and the payer's response.
## Eligibility check identifiers [#eligibility-check-identifiers]
There are two identifiers you can use to reference individual eligibility checks within a batch. They're returned in both the Retrieve Batch Check Statuses and the Poll Batch Checks endpoint responses.
### Submitter transaction identifier [#submitter-transaction-identifier]
The submitter transaction identifier is an ID that you assign to each eligibility check you submit in a batch. It must be unique within the batch.
* **Batch Check Statuses:** [`items[].additionalInfo.eligibility.submitterTransactionIdentifier`](/healthcare/api-reference/get-healthcare-batch-eligibility-check-statuses#response.items.additionalInfo.eligibility.submitterTransactionIdentifier)
* **Poll Batch Checks:** [`items[].submitterTransactionIdentifier`](/healthcare/api-reference/get-healthcare-polling-eligibility#response.items.submitterTransactionIdentifier)
You can use the submitter transaction identifier to correlate the original eligibility request with both its processing status and the payer's benefit response.
### Eligibility check ID [#eligibility-check-id]
The eligibility check ID is a globally unique identifier that Stedi automatically assigns to each eligibility check. It's formatted as `ec_`.
* **Batch Check Statuses:** [`items[].additionalInfo.eligibility.id`](/healthcare/api-reference/get-healthcare-batch-eligibility-check-statuses#response.items.additionalInfo.eligibility.id)
* **Poll Batch Checks:** [`items[].id`](/healthcare/api-reference/get-healthcare-polling-eligibility#response.items.id)
You can use the eligibility check ID to link directly to an eligibility check's results in the Stedi portal. The format for direct portal links is: `https://portal.stedi.com/app/healthcare/eligibility/{search-id}/inspect/{check-id}`, where `{search-id}` is the [eligibility search ID](/healthcare/api-reference/get-healthcare-polling-eligibility#response.items.eligibilitySearchId) and `{check-id}` is the unique, Stedi-assigned eligibility check ID. You can find the eligibility search ID at the top of an eligibility search's details page in the [Stedi portal](https://portal.stedi.com/app/healthcare/eligibility).
## Minimize waste [#minimize-waste]
We recommend the following to optimize batch eligibility checks:
* Periodically purge or archive records for inactive patients. It's a waste to perform eligibility checks on patients who have died or who haven't scheduled an encounter for several years.
* Remove or deactivate patients that are no longer eligible. The payer indicates ineligibility by setting `benefitsInformation.code = “6”` (Inactive) in the response.
## Monitor for potential coverage loss [#monitor-for-potential-coverage-loss]
When you receive the results of your batch eligibility checks, look for patients who have coverage that may be at risk.
Check for `benefitsInformation[].code` = `5`, which stands for Active - Pending investigation, or a response containing a `benefitsInformation[].benefitsDateInformation.premiumPaidToDateEnd` before the current date. Some payers may still show active coverage while the subscriber is behind on premium payments.
You may want to conduct additional checks on these patients because they have an elevated risk of losing coverage soon.
## Costs [#costs]
The costs for running a batch eligibility check – manually or using the API – are the same as running the equivalent number of real-time eligibility checks.
For example, if you run a batch with 500 checks, it will cost the same as running 500 real-time eligibility checks.
## CMS traceability requirements [#cms-traceability-requirements]
All parties involved in HETS eligibility transactions must comply with the [HETS Rules of Behavior](https://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/hetshelp/downloads/eligibilitytransactionsysteminquiriesrulesofbehavior.pdf). Compliance is also required under our terms. Review the Rules of Behavior before sending eligibility checks to CMS.
Starting November 8, 2025, the Centers for Medicare & Medicaid Services (CMS) requires submitters to include the entire chain of network hops for every eligibility request sent to CMS's eligibility system, HETS.
Specifically, requests must include an `X-Forwarded-For` HTTP header containing the network IP addresses from the point of origin through receipt by the HETS system. CMS expects `X-Forwarded-For` to list each IP, comma-separated, starting with the originating system and continuing through every intermediary.
To comply with this requirement:
* You must collect all IP addresses for upstream requests and pass them in the standard `X-Forwarded-For` header when calling Stedi's API. If you are yourself an intermediary – for example, an RCM, EHR, or PMS system – you'll need to coordinate with your providers and any third-party organizations to ensure they include the Network IP details as part of the `X-Forwarded-For` header. This enables CMS to receive a complete list of all IPs, including the original initiator of the request (typically, the provider).
* Stedi records the IP address you use when you call our API, as well as all the IP addresses listed in the `X-Forwarded-For` header. We include these IP addresses in the list submitted to CMS.
You only need to include the `X-Forwarded-For` header in eligibility requests when there are upstream IP addresses.
The following examples illustrate when and how to include the header:
| Scenario | `X-Forwarded-For` required? | Result |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------- |
| A provider (IP `2.2.2.2`) connects directly to Stedi without intermediaries. | No. | CMS ultimately receives `X-Forwarded-For: 2.2.2.2` |
| A provider (IP `2.2.2.2`) routes through an RCM platform's transactional system (IP `3.3.3.3`) that calls Stedi's API using a separate integration backend (IP `4.4.4.4`). | Yes. The RCM platform sets `X-Forwarded-For: 2.2.2.2, 3.3.3.3`. Stedi records the IP address of the API caller (`4.4.4.4` ) and sends it to CMS. | CMS ultimately receives `X-Forwarded-For: 2.2.2.2, 3.3.3.3, 4.4.4.4`. |
| A provider network (IP `2.2.2.2`) passes through an office firewall (IP `4.4.4.4`) and then an RCM platform (IP `3.3.3.3`), which calls Stedi's API. | Yes. The RCM platform sets `X-Forwarded-For: 2.2.2.2, 4.4.4.4`. Stedi records the IP address of the API caller (`3.3.3.3`) and sends it to CMS. | CMS ultimately receives `X-Forwarded-For: 2.2.2.2, 4.4.4.4, 3.3.3.3`. |
### U.S. IP address requirement [#us-ip-address-requirement]
Stedi blocks eligibility requests to CMS when any IP address in the chain – the originating IP address or any in the X-Forwarded-For header – is located outside the United States.
# Build with AI
Source: https://www.stedi.com/docs/healthcare/build-with-ai
Stedi provides AI-powered tools and resources to help you build eligibility and claims processing workflows faster.
* **Build agents that work with eligibility data:** Install the [Model Context Protocol (MCP) server](#model-context-protocol-server)
* **Code with AI assistants:** Give them [AI-friendly versions](#ai-friendly-documentation) of our developer guides and API specifications, and use [test workflows](#test-workflows) to develop without real patient data
## Get started [#get-started]
Try building with Stedi's AI-friendly resources by following our step-by-step tutorial. You'll build a functional insurance verification app in under 30 minutes using Stedi's JSON Eligibility API and a coding agent like Claude Code or Cursor.
The tutorial walks through the complete process: setting up your Stedi account, generating test API keys, building a Next.js backend with AI assistance, and creating a web UI. You'll use the same AI-friendly documentation and test workflows described on this page.
[Build an insurance verification app with a coding agent](https://www.stedi.com/blog/build-an-insurance-verification-app-with-a-coding-agent)
## Test workflows [#test-workflows]
Stedi provides test workflows that AI coding agents can use to build and test integrations without using real patient data or contacting actual payers.
### Get a test API key [#get-a-test-api-key]
Test API keys allow you to send mock requests and receive realistic responses without transmitting PHI or PII.
To create a test API key:
1. Log into your [Stedi account](https://portal.stedi.com/app).
2. Click your account name at the top right.
3. Select **API Keys**.
4. Click **Generate new API Key**.
5. Enter a name with a `test` prefix and choose **Test** as the key type.
6. Click **Generate** and copy your key.
Learn more about [API authentication](/healthcare/api-reference#authentication).
### Test eligibility checks [#test-eligibility-checks]
Use your test API key to send [mock eligibility requests](/healthcare/api-reference/mock-requests-eligibility-checks) that return realistic responses including coverage indicators, copays, and deductibles. Mock requests work with Stedi's JSON, Raw X12, and SOAP endpoints. Test keys are free on the **Basic** plan.
Here's an example test request your AI assistant can use:
```bash
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "60054",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "John",
"lastName": "Doe",
"memberId": "AETNA9wcSu"
},
"dependents": [
{
"firstName": "Jordan",
"lastName": "Doe",
"dateOfBirth": "20010714"
}
],
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
### Test claims [#test-claims]
Use production API keys with the test usage indicator (`"usageIndicator": "T"`) to submit test claims. Claims aren't forwarded to payers, and you receive test 277CA acknowledgments. Submit to the Stedi Test Payer (ID: `STEDI`) to generate test ERAs within minutes.
Visit [Test claims workflow](/healthcare/test-claims-workflow) for complete instructions.
## Data security and compliance [#data-security-and-compliance]
When using AI tools with healthcare data, follow your organization's data handling policies to ensure HIPAA compliance. Most organizations require a Business Associate Agreement (BAA) with third-party AI tools before using them with production healthcare data.
Stedi's [test workflows](#test-workflows) let you develop and test integrations without transmitting PHI or PII.
## Model Context Protocol server [#model-context-protocol-server]
The [Model Context Protocol (MCP) server](/healthcare/mcp-server) provides tools that AI agents can use to perform and troubleshoot eligibility checks through Stedi's APIs. It includes built-in logic for finding the correct payer, handling errors, and implementing retry strategies, so you can focus on building your agent's core functionality.
The MCP server is ideal for:
* Voice agents that need to verify benefits in real time
* Revenue Cycle Management (RCM) workflow agents that validate coverage before scheduling appointments
* Development teams using MCP clients to test integrations and troubleshoot issues
The MCP server supports both API key and OAuth 2.x authentication, and works with popular AI platforms like Claude Code.
## AI-friendly documentation [#ai-friendly-documentation]
Stedi's documentation is available in AI-friendly formats that you can provide to tools like ChatGPT, Claude, Cursor, and other AI assistants.
For best results, provide both [OpenAPI specifications](#openapi-specifications) and [`llms-full.txt`](#llms-full-txt) for comprehensive developer guides.
### OpenAPI specifications [#openapi-specifications]
[github.com/Stedi/openApi](https://github.com/Stedi/openApi)
OpenAPI specifications provide machine-readable API definitions including endpoints, parameters, request/response schemas, and real-world examples.
**When to use:** Provide these to your AI assistant when you need it to help you generate API calls, understand API structure, or validate request and response formats.
### llms.txt [#llmstxt]
[/llms.txt](https://www.stedi.com/docs/llms.txt)
A simple list of available documentation pages with titles and descriptions.
**When to use:** Use this to give your AI assistant a quick overview of available pages. Many AI assistants check for this file automatically.
### llms-full.txt [#llms-fulltxt]
[/llms-full.txt](https://www.stedi.com/docs/llms-full.txt)
The complete markdown content of all documentation pages in a single file. This includes guides, how-tos, troubleshooting, and conceptual explanations.
**When to use:** Provide this to your AI assistant when you need comprehensive context about how to build eligibility and claims processing workflows with Stedi.
### Individual markdown pages [#individual-markdown-pages]
Individual documentation pages are available in markdown format at `/llms.mdx/[page-url]`. For example, `/llms.mdx/healthcare/send-eligibility-checks`. You can also copy them from the UI by clicking the **Copy for LLM** menu at the top of each documentation page.
**When to use:** Use individual pages when you have token limits that prevent loading `llms-full.txt`, or when you only need context about specific features.
### How to use these resources [#how-to-use-these-resources]
The specific method depends on which AI tool you're using.
You may want to add references to your agent's configuration - for example, a [Cursor rule](https://cursor.com/docs/rules#rule-file-structure) or [Claude skill](https://code.claude.com/docs/en/skills) file. This ensures the context is applied automatically across sessions.
```
You have access to Stedi's healthcare API documentation and specifications:
- Full documentation: https://www.stedi.com/docs/llms-full.txt
- OpenAPI specs: https://github.com/Stedi/openApi
When helping with Stedi integrations, consult these resources first.
```
You can also provide these resources as context when starting a conversation with tools like ChatGPT, Claude, or Google Gemini.
```
I'm working with Stedi's healthcare APIs. Please reference:
- Full documentation: https://www.stedi.com/docs/llms-full.txt
- OpenAPI specs: https://github.com/Stedi/openApi
Help me [describe your task].
```
**Example prompts**
Once your AI assistant has access to the documentation, you can ask it to help with tasks like:
* "Help me implement eligibility checks for a new RCM system. Show me how to construct the JSON request and handle the response."
* "Generate TypeScript code to submit professional claims using Stedi's API, including error handling and retry logic."
* "What's the correct Claim Frequency Code for resubmitting an institutional claim that was already adjudicated?"
Always review and test AI-generated code before using it in production. While AI assistants can help you build integrations faster, you should verify that the generated code meets your specific requirements and follows your organization's standards.
# Check claim status
Source: https://www.stedi.com/docs/healthcare/check-claim-status
You may need to check the status of a claim when you don't receive a 277CA or 835 ERA response from the payer within your expected timeframe. You may also want to check the status of a claim submitted by another entity. For example, a billing agency may want to check the status of a claim submitted by their customer, who is a provider.
## Testing [#testing]
You can only run real-time claim status checks for production claims that have entered the payer's processing system.
Requests for test claims or claims the payer hasn't yet accepted for processing won't return results. That's why our [claim status best practices](#best-practices) recommend waiting at least a week after submission before attempting to check a claim's status. You also won't be able to check the status if Stedi or the payer rejected a claim with a [277CA claim acknowledgment](/healthcare/receive-claim-responses).
You can find examples of claim status requests and responses in the [sample requests and responses](#sample-requests-and-responses) section on this page.
## Transaction enrollment [#transaction-enrollment]
[Transaction enrollment](/healthcare/transaction-enrollment) is the process of registering a provider to exchange specific healthcare transactions with a payer. Some payers require enrollment before allowing providers to submit real-time claim status checks through a new clearinghouse. This enrollment process is separate from the transaction enrollment process for 837 claims.
Enrolling through Stedi may cancel existing real-time claim status enrollments you have through other clearinghouses. We can help you determine whether this applies to your specific payers. However, enrolling through Stedi for real-time claim status checks doesn't affect your existing enrollments for other transaction types. For example, enrolling with Stedi won't unenroll the provider from receiving transactions like Electronic Remittance Advices (ERAs) through other clearinghouses.
You can check whether a specific payer requires transaction enrollment for real-time claim status checks in the [Payer Network](https://www.stedi.com/healthcare/network) or through the [Payers API](/healthcare/api-reference/get-payer).
To enroll, complete the following steps:
1. Create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step. [Stedi portal](https://portal.stedi.com/app/healthcare/providers) | [API endpoint](/healthcare/api-reference/post-enrollment-create-provider)
2. Submit an enrollment request for real-time claim status. [Stedi portal](https://portal.stedi.com/app/healthcare/enrollments) | [API endpoint](/healthcare/api-reference/post-enrollment-create-enrollment)
## Manual submission [#manual-submission]
You can submit a claim status request manually through the [Create claim status check](https://portal.stedi.com/app/healthcare/claims/status/create) form in Stedi.
The response view shows both claim-level and service-level details. If the claim status request returns information for multiple claims, you can use the dropdown to navigate between them.
## API Submission [#api-submission]
Call one of the following endpoints to send a 276/277 real-time claim status:
* [Claim Status](/healthcare/api-reference/post-healthcare-claim-status) to send requests in JSON
* [Claim Status Raw X12](/healthcare/api-reference/post-healthcare-claim-status-raw-x12) to send requests in X12 EDI
Both endpoints return a synchronous claim status response from the payer in JSON format. The response may contain information about more than one claim, if the payer has multiple claims on file that match the information you provided.
### Headers [#headers]
When constructing the request, you must include the following information in HTTP headers:
* **`Authorization`:** [Generate an API key](https://portal.stedi.com/app/settings/api-keys) to use for authentication.
* **`Content-Type`:** Set to `application/json`.
### Body - JSON [#body---json]
For best results, you should start with our [recommended base request](/healthcare/check-claim-status#json-base-request) and add more information only as needed.
Note that objects marked as **required** are required for all requests, while others are conditionally required depending on the circumstances. When you include a conditionally required object, you must include all of its required properties.
For example, you must always include the `subscriber` object in requests, but you only need to include the `serviceLinesInformation` object when you want to request the status for a specific service line.
### Body - X12 EDI [#body---x12-edi]
Your payload must conform to [276 X12 EDI format](https://portal.stedi.com/app/guides/view/hipaa/claim-status-request-x212/01GRYB6A4XEJQ61Y2K2KT606E5).
For best results, you should start with our [recommended base request](/healthcare/check-claim-status#x12-base-request) and add more information only as needed.
#### Envelope and header [#envelope-and-header]
Stedi generates its own `ISA` and `GS` headers and `IEA` and `GE` trailers before sending your claim status request to the payer. You can submit your request to Stedi with any values in these segments, as long as they conform to the X12 EDI specification.
However, you must set `ST03` (Version, Release, or Industry Identifier) to `005010X212`.
### Character restrictions [#character-restrictions]
Only use the X12 Basic and Extended character sets in request data. Using characters outside these sets may cause errors.
The X12 Basic character set includes uppercase letters, digits, space, and some special characters. Lowercase letters and special language characters like `ñ` are not included.
The following special characters are included:
The Extended character set includes the characters listed in Basic, plus lowercase letters and additional special characters, such as `@`.
The following additional special characters are included:
In addition, the following characters are reserved for delimiters in the final X12 EDI transaction to the payer: `~`, `*`, `:`, and `^`. X12 doesn’t support using escape sequences to represent delimiters or special characters. Stedi returns a `400` error if you use these restricted characters improperly.
* **JSON endpoint:** Don't include delimiter characters anywhere in your request data.
* **Raw X12 endpoint:** You can use these characters as delimiters, but not in the body of the request data.
### Delimiter normalization [#delimiter-normalization]
Stedi normalizes delimiters in both the JSON and raw X12 responses you receive to ensure consistency and prevent parsing issues. When the following delimiter characters appear within data values - meaning they are used as content - Stedi replaces them as shown:
| Delimiter type | Original | Replaced with |
| --------------------------- | -------- | ------------- |
| Element separator | `*` | `\|` |
| Repetition separator | `^` | `\|` |
| Component element separator | `` ` `` | `'` |
| Segment terminator | `~` | `\|` |
**Examples:**
* `O*CONNOR` becomes `O|CONNOR`
* `CODE^01` becomes `CODE|01`
* ``O`CONNOR`` becomes `O'CONNOR`
* `MSG~HELLO` becomes `MSG|HELLO`
If you parse raw X12 EDI responses, ensure your parser reads delimiters from the `ISA` segment instead of assuming fixed delimiters.
### Timeout [#timeout]
Requests to payers typically time out at 1 minute, though Stedi can keep connections open longer than that if needed.
### Concurrency limit [#concurrency-limit]
Our real-time claim status endpoints share a concurrency pool with other real-time healthcare APIs. For more information, visit [Concurrency Limits](/healthcare/api-reference#concurrency-limits).
### Recommended API clients [#recommended-api-clients]
You may want to use an API client to make testing and debugging easier.
We **don't recommend** using Postman for requests containing Protected Health Information (PHI) because Postman defaults to storing request history - including full request payloads - on its cloud servers. You can’t turn this feature off without impractical workarounds.
Visit [API clients](/healthcare/api-reference#api-clients) for a list of recommended clients you can use instead.
## Best practices [#best-practices]
We recommend following these best practices when checking claim status.
### Wait at least a week [#wait-at-least-a-week]
Don't run a claim status check until at least 7 days after the claim's submission date. It usually takes a few weeks for payers to process and fully adjudicate a claim.
If you haven't received an 835 ERA, we recommend checking the claim's status at 21 days after submission and then again at 1 month.
### Supply a date of services range [#supply-a-date-of-services-range]
We recommend the following best practices when providing dates of service in a claim status request:
* The date range should be at least plus or minus 7 days from the date of the services listed in the claim. The payer may have stored a different date for the encounter than the one in your records, so providing a date range increases the likelihood that the payer will find a match.
* Keep the date range to 30 days or less. Some payers may reject requests with a date range that is too wide.
* Don't submit future dates - only submit date ranges up to and including today's date. Some payers reject requests containing future service dates.
### Don't provide too much information [#dont-provide-too-much-information]
Providing too much information in a claim status request can negatively affect the results. That's why we recommend first sending a base request with only the following information.
You will eventually learn payer-specific nuances and can adjust your approach accordingly. For example, some payers may have better success rates when you include the claim number.
#### JSON base request [#json-base-request]
We recommend starting with the following properties in a request to the [Real-Time Claim Status JSON](/healthcare/api-reference/post-healthcare-claim-status) endpoint:
| Information | Description |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tradingPartnerServiceId` | This is the payer ID. Visit the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list. You can send requests using the primary payer ID, the Stedi payer ID, or any payer ID alias listed in the payer record. |
| `providers` | The provider information from the original claim. To start, provide only the `npi`, `organizationName`, and `providerType` properties. |
| `subscriber` | The subscriber information from the original claim. To start, provide only the `firstName`, `lastName`, `dateOfBirth`, `gender`, and `memberId` properties. |
| `dependent` | The dependent information from the original claim. To start, provide only the `firstName`, `lastName`, `dateOfBirth`, and `gender` properties. If the patient is the subscriber, you can omit this object. |
| `encounter` | The encounter information from the original claim. To start, provide only the `beginningDateOfService` and `endDateOfService` properties. Remember that you should provide a date range that is plus or minus 7 days from the date of service listed in the claim for best results. Only use date ranges that are up to and including today's date - some payers reject requests containing future service dates. |
If this base request fails to return results, try adding in other information like `encounter.tradingPartnerClaimNumber` and `providers.taxId`.
The following examples show two base request payloads: one where the patient is the subscriber and one where the patient is the dependent. They include only the minimum recommended information:
{/* schema:ClaimStatusRequestContent */}
```json
{
"encounter": {
"beginningDateOfService": "20240318",
"endDateOfService": "20240402"
},
"providers": [
{
"npi": "1999999984",
"organizationName": "Behavioral Services P.C.",
"providerType": "BillingProvider"
}
],
"subscriber": {
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "19000806",
"gender": "F",
"memberId": "111222333"
},
"tradingPartnerServiceId": "3429"
}
```
{/* schema:ClaimStatusRequestContent */}
```json
{
"encounter": {
"beginningDateOfService": "20240318",
"endDateOfService": "20240402"
},
"providers": [
{
"npi": "1999999984",
"organizationName": "Behavioral Services P.C.",
"providerType": "BillingProvider"
}
],
"subscriber": {
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "19000806",
"gender": "F",
"memberId": "111222333"
},
"dependent": {
"firstName": "John",
"lastName": "Doe",
"dateOfBirth": "19100323",
"gender": "M"
},
"tradingPartnerServiceId": "3429"
}
```
#### X12 base request [#x12-base-request]
We recommend starting with the following properties in a request to the [Real-Time Claim Status Raw X12](/healthcare/api-reference/post-healthcare-claim-status-raw-x12) endpoint:
* `Loop 2100A NM109` (Payer Identifier): This identifier allows Stedi to route the claim status request to the correct payer. It must be a payer ID or payer ID alias listed in the [Payer Network](https://www.stedi.com/healthcare/network). For example, you could use `60054`, `HPQRS`, `AETNA`, or any other listed payer ID alias for Aetna.
* `Loop 2100C NM109` (National Provider Identifier) and `NM103` (Provider Last Name or Organization Name)
* `Loop 2000D DMG02` or `Loop 2000E DMG02` (Subscriber/Patient Birth Date)
* `Loop 2100B NM1` (Information Receiver Name)
* `Loop 2100D NM103` (Subscriber Last Name), `NM103` (Subscriber First Name), and `NM109` (Member Identification Number)
* `Loop 2200D DTP03` (Claim Service Period) that is plus or minus 7 days from the date of service listed in the claim
* `Loop 2200D` or `2200E`: `TRN` (Claim Status Tracking Number)
If this base request fails to return results, try adding in other information like `Loop 2200D REF02` (Payer Claim Control Number).
## Sample requests and responses [#sample-requests-and-responses]
The following examples show a 276 claim status request and 277 claim status response for Stedi's JSON endpoint.
### Accepted claims [#accepted-claims]
The following example shows a claim status request and response for a claim that has been accepted by the payer and is awaiting payment. The payer is UnitedHealthcare, and the request uses the payer ID alias `3429`.
```bash
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/claimstatus/v2 \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--data '{
"encounter": {
"beginningDateOfService": "20240318",
"endDateOfService": "20240402"
},
"providers": [
{
"npi": "1999999984",
"organizationName": "Behavioral Services P.C.",
"providerType": "BillingProvider"
}
],
"subscriber": {
"dateOfBirth": "19000806",
"firstName": "Jane",
"lastName": "Doe",
"gender": "F",
"memberId": "111222333"
},
"tradingPartnerServiceId": "3429"
}'
```
{/* schema:ClaimStatusResponseContent */}
```json
{
"claims": [
{
"claimStatus": {
"amountPaid": "95.55",
"claimServiceDate": "20240325",
"effectiveDate": "2024-03-29",
"paidDate": "2024-03-29",
"patientAccountNumber": "3333333",
"statusCategoryCode": "P5",
"statusCategoryCodeValue": "Pending/Payer Administrative/System hold",
"statusCode": "3",
"statusCodeValue": "Claim has been adjudicated and is awaiting payment cycle.",
"submittedAmount": "238.44",
"trackingNumber": "222222222",
"tradingPartnerClaimNumber": "5332034153-KK"
},
"serviceDetails": [
{
"service": {
"amountPaid": "95.55",
"procedureId": "90837",
"serviceIdQualifier": "Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes",
"serviceIdQualifierCode": "HC",
"submittedAmount": "238.44",
"submittedUnits": "1"
},
"status": [
{
"effectiveDate": "2024-03-29",
"statusCategoryCode": "P5",
"statusCategoryCodeValue": "Pending/Payer Administrative/System hold",
"statusCode": "3",
"statusCodeValue": "Claim has been adjudicated and is awaiting payment cycle."
}
]
}
]
}
],
"controlNumber": "222222222",
"meta": {
"applicationMode": "production",
"traceId": "bf27223e-46c3-451e-b2b4-46f3f0b6fe3b"
},
"payer": {
"organizationName": "UNITEDHEALTHCARE",
"payerIdentification": "3429"
},
"providers": [
{
"organizationName": "Behavioral Services P.C.",
"providerType": "BillingProvider",
"taxId": "123456789"
},
{
"npi": "1999999984",
"organizationName": "Behavioral Services P.C.",
"providerType": "ServiceProvider"
}
],
"reassociationKey": "000000001",
"status": "success",
"subscriber": {
"firstName": "JANE",
"lastName": "DOE",
"memberId": "111222333"
},
"tradingPartnerServiceId": "3429",
"x12": "..."
}
```
The following example shows a claim status request and response for a claim that has been processed and paid. The payer is UnitedHealthcare, and the request uses the primary payer ID `87726`.
Note that this example response includes the payment amount and the service line item details. Some payers return this information in claim status responses, but most don't. You should typically plan to get these details from the 835 Electronic Remittance Advice (ERA) instead.
```bash
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/claimstatus/v2 \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "87726",
"providers": [
{
"organizationName": "Provider Name",
"npi": "1999999984",
"providerType": "BillingProvider"
}
],
"subscriber": {
"memberId": "UHC123456",
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "19710101"
},
"encounter": {
"beginningDateOfService": "20250630",
"endDateOfService": "20250702"
}
}'
```
{/* schema:ClaimStatusResponseContent */}
```json
{
"claims": [
{
"claimStatus": {
"amountPaid": "108.77",
"checkIssueDate": "2025-07-17",
"checkNumber": "A123456789",
"claimServiceDate": "20250701",
"effectiveDate": "2025-07-17",
"paidDate": "2025-07-15",
"patientAccountNumber": "12345678",
"statusCategoryCode": "F1",
"statusCategoryCodeValue": "Finalized/Payment - The claim/line has been paid.",
"statusCode": "65",
"statusCodeValue": "Claim/line has been paid.",
"submittedAmount": "267.54",
"trackingNumber": "0123456789",
"tradingPartnerClaimNumber": "0123456789"
},
"serviceDetails": [
{
"service": {
"amountPaid": "108.77",
"procedureId": "90837",
"serviceIdQualifier": "Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes",
"serviceIdQualifierCode": "HC",
"submittedAmount": "267.54",
"submittedUnits": "1"
},
"status": [
{
"effectiveDate": "2025-07-17",
"statusCategoryCode": "F1",
"statusCategoryCodeValue": "Finalized/Payment - The claim/line has been paid.",
"statusCode": "107",
"statusCodeValue": "Processed according to contract provisions (Contract refers to provisions that exist between the Health Plan and a Provider of Health Care Services)."
}
]
}
]
}
],
"controlNumber": "123456789",
"payer": {
"organizationName": "UNITEDHEALTHCARE",
"payerIdentification": "87726"
},
"providers": [
{
"npi": "1999999984",
"organizationName": "Provider Name",
"providerType": "BillingProvider"
}
],
"subscriber": {
"firstName": "Jane",
"lastName": "Doe",
"memberId": "UHC123456"
},
"tradingPartnerServiceId": "87726",
"x12": "ISA*00* *00* *ZZ*STEDI *01*117151744 *250912*1718*^*00501*123456789*0*P*:~GS*HN*STEDI*117151744*20250912*171842*1*X*005010X212~ST*277*1001*005010X212~BHT*0010*08*0123456789*20250912*171841*DG~HL*1**20*1~NM1*PR*2*UNITEDHEALTHCARE*****PI*87726~HL*2*1*21*1~NM1*41*2*PROVIDER NAME*****46*1234567890~HL*3*2*19*1~NM1*1P*2*PROVIDER NAME*****XX*1999999984~HL*4*3*22*0~NM1*IL*1*DOE*JANE****MI*UHC123456~TRN*2*0123456789~STC*F1:65*20250717**267.54*108.77*20250715**20250717*123456789~REF*1K*0123456789~REF*EJ*12345678~DTP*472*D8*20250701~SVC*HC:90837:GT*267.54*108.77****1~STC*F1:107*20250717~DTP*472*D8*20250701~SE*19*1001~GE*1*1~IEA*1*123456789~"
}
```
### Denied claims [#denied-claims]
The following example shows a claim status request and response for a denied claim. The payer is Anthem Blue Cross Blue Shield of Virginia, and the request uses the primary payer ID `423`.
In this example, the `subscriber` in the request is actually a dependent using the subscriber's member ID.
```bash
curl --request POST \
--url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/claimstatus/v2" \
--header "Authorization: " \
--header "Content-Type: application/json" \
--data '{
"encounter": {
"beginningDateOfService": "20241101",
"endDateOfService": "20241112"
},
"providers": [
{
"npi": "1999999984",
"organizationName": "PROVIDER NAME",
"providerType": "BillingProvider"
}
],
"subscriber": {
"dateOfBirth": "19800101",
"firstName": "JANE",
"lastName": "DOE",
"memberId": "XYZO9NUSPD6R"
},
"tradingPartnerServiceId": "423"
}'
```
{/* schema:ClaimStatusResponseContent */}
```json
{
"claims": [
{
"claimStatus": {
"amountPaid": "0",
"claimServiceDate": "20241107-20241107",
"effectiveDate": "2024-11-10",
"paidDate": "2024-11-10",
"patientAccountNumber": "12345678",
"statusCategoryCode": "F0",
"statusCategoryCodeValue": "Finalized - The claim/encounter has completed the adjudication cycle and no more action will be taken.",
"statusCode": "1",
"statusCodeValue": "For more detailed information,see remittance advice.",
"submittedAmount": "200.02",
"trackingNumber": "VZYTLPWDTPMIG66PX0GRNPFGR8",
"tradingPartnerClaimNumber": "XP5BPO2GRUVIR"
},
"serviceDetails": [
{
"service": {
"amountPaid": "0",
"procedureId": "90800",
"serviceIdQualifier": "Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes",
"serviceIdQualifierCode": "HC",
"submittedAmount": "200.02",
"submittedUnits": "1"
},
"status": [
{
"effectiveDate": "2024-11-10",
"statusCategoryCode": "F2",
"statusCategoryCodeValue": "Finalized/Denial - The claim/line has been denied.",
"statusCode": "585",
"statusCodeValue": "Denied Charge or Non-covered Charge."
}
]
}
]
}
],
"controlNumber": "987654321",
"dependent": {
"firstName": "JANE",
"lastName": "DOE"
},
"payer": {
"organizationName": "ANTHEM BLUE CROSS BLUE SHIELD",
"payerIdentification": "423"
},
"providers": [
{
"npi": "1999999984",
"organizationName": "PROVIDER NAME",
"providerType": "BillingProvider"
}
],
"subscriber": {
"firstName": "JOHN",
"lastName": "DOE",
"memberId": "XYZO9NUSPD6R"
},
"tradingPartnerServiceId": "423",
"x12": "..."
}
```
The following examples show a request and response for a denied claim. The payer is Aetna, and the request uses the primary payer ID `60054`.
In this example, the claim is for a dependent.
```bash
curl --request POST \
--url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/claimstatus/v2" \
--header "Authorization: " \
--header "Content-Type: application/json" \
--data '{
"dependent": {
"dateOfBirth": "20010714",
"firstName": "JORDAN",
"lastName": "DOE"
},
"encounter": {
"beginningDateOfService": "20250804",
"endDateOfService": "20250806"
},
"providers": [
{
"npi": "1999999984",
"organizationName": "Provider Name",
"providerType": "BillingProvider"
}
],
"subscriber": {
"dateOfBirth": "19710101",
"firstName": "JANE ",
"lastName": "DOE",
"memberId": "AETNA12345"
},
"tradingPartnerName": "Aetna",
"tradingPartnerServiceId": "60054"
}'
```
{/* schema:ClaimStatusResponseContent */}
```json
{
"claims": [
{
"claimStatus": {
"amountPaid": "0",
"checkIssueDate": "2025-08-14",
"checkNumber": "123456789",
"claimServiceDate": "20250805",
"effectiveDate": "2025-09-12",
"paidDate": "2025-08-09",
"patientAccountNumber": "123456789",
"statusCategoryCode": "F2",
"statusCategoryCodeValue": "Finalized/Denial - The claim/line has been denied.",
"statusCode": "585",
"statusCodeValue": "Denied Charge or Non-covered Charge.",
"submittedAmount": "1101",
"trackingNumber": "123456789",
"tradingPartnerClaimNumber": "123456789"
},
"serviceDetails": [
{
"service": {
"amountPaid": "0",
"procedureId": "D1120",
"serviceIdQualifier": "American Dental Association Codes",
"serviceIdQualifierCode": "AD",
"submittedAmount": "141",
"submittedUnits": "1"
},
"status": [
{
"effectiveDate": "2025-09-12",
"statusCategoryCode": "F2",
"statusCategoryCodeValue": "Finalized/Denial - The claim/line has been denied.",
"statusCode": "585",
"statusCodeValue": "Denied Charge or Non-covered Charge."
}
]
},
{
"service": {
"amountPaid": "0",
"procedureId": "D0801",
"serviceIdQualifier": "American Dental Association Codes",
"serviceIdQualifierCode": "AD",
"submittedAmount": "274",
"submittedUnits": "1"
},
"status": [
{
"effectiveDate": "2025-09-12",
"statusCategoryCode": "F2",
"statusCategoryCodeValue": "Finalized/Denial - The claim/line has been denied.",
"statusCode": "585",
"statusCodeValue": "Denied Charge or Non-covered Charge."
}
]
},
{
"service": {
"amountPaid": "0",
"procedureId": "D0603",
"serviceIdQualifier": "American Dental Association Codes",
"serviceIdQualifierCode": "AD",
"submittedAmount": "161",
"submittedUnits": "1"
},
"status": [
{
"effectiveDate": "2025-09-12",
"statusCategoryCode": "F2",
"statusCategoryCodeValue": "Finalized/Denial - The claim/line has been denied.",
"statusCode": "107",
"statusCodeValue": "Processed according to contract provisions (Contract refers to provisions that exist between the Health Plan and a Provider of Health Care Services)."
}
]
},
{
"service": {
"amountPaid": "0",
"procedureId": "D0350",
"serviceIdQualifier": "American Dental Association Codes",
"serviceIdQualifierCode": "AD",
"submittedAmount": "145",
"submittedUnits": "1"
},
"status": [
{
"effectiveDate": "2025-09-12",
"statusCategoryCode": "F2",
"statusCategoryCodeValue": "Finalized/Denial - The claim/line has been denied.",
"statusCode": "585",
"statusCodeValue": "Denied Charge or Non-covered Charge."
}
]
},
{
"service": {
"amountPaid": "0",
"procedureId": "D0350",
"serviceIdQualifier": "American Dental Association Codes",
"serviceIdQualifierCode": "AD",
"submittedAmount": "145",
"submittedUnits": "1"
},
"status": [
{
"effectiveDate": "2025-09-12",
"statusCategoryCode": "F2",
"statusCategoryCodeValue": "Finalized/Denial - The claim/line has been denied.",
"statusCode": "585",
"statusCodeValue": "Denied Charge or Non-covered Charge."
}
]
},
{
"service": {
"amountPaid": "0",
"procedureId": "D0330",
"serviceIdQualifier": "American Dental Association Codes",
"serviceIdQualifierCode": "AD",
"submittedAmount": "235",
"submittedUnits": "1"
},
"status": [
{
"effectiveDate": "2025-09-12",
"statusCategoryCode": "F2",
"statusCategoryCodeValue": "Finalized/Denial - The claim/line has been denied.",
"statusCode": "585",
"statusCodeValue": "Denied Charge or Non-covered Charge."
}
]
}
]
}],
"controlNumber": "123456789",
"dependent": {
"firstName": "JORDAN",
"lastName": "DOE"
},
"payer": {
"organizationName": "AETNA",
"payerIdentification": "60054"
},
"providers": [
{
"npi": "1999999984",
"organizationName": "Provider Name",
"providerType": "BillingProvider"
}
],
"subscriber": {
"firstName": "JANE",
"lastName": "DOE",
"memberId": "AETNA12345"
},
"tradingPartnerServiceId": "60054",
"x12": "ISA*00* *00* *ZZ*STEDI *01*117151744 *250911*1726*^*00501*123456789*0*P*:~GS*HN*STEDI*117151744*20250911*1226*123456789*X*005010X212~ST*277*123456789*005010X212~BHT*0010*08*1234567890*20250911*13263006*DG~HL*1**20*1~NM1*PR*2*AETNA*****PI*60054~PER*IC*Aetna*TE*1234567890~HL*2*1*21*1~NM1*41*2*PROVIDER NAME*****46*1234567890~HL*3*2*19*1~NM1*1P*2*PROVIDER NAME*****XX*1999999984~HL*4*3*22*1~NM1*IL*1*DOE*JANE****MI*AETNA12345~HL*5*4*23~NM1*QC*1*DOE*JORDAN~TRN*2*123456789~STC*F2:585*20250911**1101*0*20250809**20250814*123456789*F2:107~REF*1K*123456789~REF*EJ*123456789~DTP*472*D8*20250805~SVC*AD:D1120*141*0****1~STC*F2:585*20250911~DTP*472*D8*20250805~SVC*AD:D0801*274*0****1~STC*F2:585*20250911~DTP*472*D8*20250805~SVC*AD:D0603*161*0****1~STC*F2:107*20250911********F2:735~DTP*472*D8*20250805~SVC*AD:D0350*145*0****1~STC*F2:585*20250911~DTP*472*D8*20250805~SVC*AD:D0350*145*0****1~STC*F2:585*20250911~DTP*472*D8*20250805~SE*34*123456789~GE*1*123456789~IEA*1*123456789~"
}
```
### No matches found [#no-matches-found]
The following example shows a request and response for a claim status check that failed because the payer couldn't find a matching claim. The payer is Cigna, and the request uses the payer ID alias `CIGNA`.
```bash
curl --request POST \
--url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/claimstatus/v2" \
--header "Authorization: " \
--header "Content-Type: application/json" \
--data '{
"encounter": {
"beginningDateOfService": "20250526",
"endDateOfService": "20250601"
},
"providers": [
{
"organizationName": "Provider Name",
"providerType": "BillingProvider",
"npi": "1999999984"
}
],
"subscriber": {
"dateOfBirth": "19910202",
"firstName": "James",
"lastName": "Jones",
"memberId": "CIGNA12345"
},
"tradingPartnerServiceId": "CIGNA"
}'
```
{/* schema:ClaimStatusResponseContent */}
```json
{
"claims": [
{
"claimStatus": {
"amountPaid": "0",
"claimServiceDate": "20250526-20250601",
"effectiveDate": "2025-09-12",
"entity": "Insurer",
"entityCode": "IN",
"statusCategoryCode": "D0",
"statusCategoryCodeValue": "Data Search Unsuccessful - The payer is unable to return status on the requested claim(s) based on the submitted search criteria.",
"statusCode": "97",
"statusCodeValue": "Patient eligibility not found with entity.",
"submittedAmount": "0",
"trackingNumber": "123456789"
}
}
],
"controlNumber": "123456789",
"payer": {
"organizationName": "CHLIC",
"payerIdentification": "CIGNA"
},
"providers": [
{
"npi": "1999999984",
"organizationName": "Provider Name",
"providerType": "BillingProvider"
}
],
"subscriber": {
"firstName": "JAMES",
"lastName": "JONES",
"memberId": "CIGNA12345"
},
"tradingPartnerServiceId": "CIGNA",
"x12": "ISA*00* *00* *ZZ*STEDI *01*117151744 *250825*2004*^*00501*123456789*0*P*:~GS*HN*STEDI*117151744*20250825*1504*123456789*X*005010X212~ST*277*123456789*005010X212~BHT*0010*08*123456789*20250825*160450*DG~HL*1**20*1~NM1*PR*2*CHLIC*****PI*CIGNA~PER*IC*CHC Medical*TE*8002725713~HL*2*1*21*1~NM1*41*2*PROVIDER NAME*****46*123456789~HL*3*2*19*1~NM1*1P*2*PROVIDER NAME*****XX*1999999984~HL*4*3*22*0~NM1*IL*1*JONES*JAMES****MI*CIGNA12345~TRN*2*123456789~STC*D0:97:IN*20250825**0*0~DTP*472*RD8*20250526-20250601~SE*15*123456789~GE*1*123456789~IEA*1*123456789~"
}
```
### Validation error (999) [#validation-error-999]
The [Real-Time Claim Status Raw X12](/healthcare/api-reference/post-healthcare-claim-status-raw-x12) endpoint returns a 999 Implementation Acknowledgment when the request data fails validation. Common failure reasons are missing required segments and invalid values.
The following example request is missing required `HL` loops.
```bash
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/claimstatus/raw-x12 \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*SENDER *ZZ*STEDI *210101*1200*^*00501*000000001*0*P*>~GS*HR*SENDER*STEDI*20210101*120000*1*X*005010X212~ST*276*0001*005010X212~SE*1*0001~GE*1*1~IEA*1*000000001~"
}'
```
```json
{
"controlNumber": "736013965",
"implementationTransactionSetSyntaxError": "5",
"status": "ERROR",
"transactionSetAcknowledgement": "R",
"x12": "ISA*00* *00* *ZZ*STEDI *ZZ*SENDER *260403*0930*^*00501*736013965*0*P*`~GS*FA*STEDI*117151744*20260403*093042*736013965*X*005010X231A1~ST*999*0001*005010X231A1~AK1*HR*1*005010X212~AK2*276*0001*005010X212~IK3*SE*2**2~IK3*SE*2**3~IK5*R*5~AK9*R*1*1*0~SE*8*0001~GE*1*736013965~IEA*1*736013965~"
}
```
## Claims submitted by other providers [#claims-submitted-by-other-providers]
You likely won't be able to check the status of a claim submitted by a different provider organization or by the patient themselves, even if you have all of the details about the claim.
Payers generally only allow a provider organization to check the status of the claims they submitted. They impose these access controls to protect plan member privacy and confidential commercial data.
## Claims older than 18 months [#claims-older-than-18-months]
Payers often archive claims older than 18 months, but this varies by payer. If you try to check the status of a claim from several years ago, the payer may return an error even if the information you submit matches a real historical claim.
## Billing [#billing]
Transactions are billable at the usage rates specified in your contract unless they fall into the following non-billable categories:
* API calls that return 4xx or 5xx errors. For example, you won't be charged when a request fails because the payer isn't supported - in this case, Stedi returns a `400` HTTP status code.
* Claim status responses that exclusively contain one or more of these non-billable [Claim Status Codes](https://x12.org/codes/claim-status-codes) in `STC01-02` (Status Code): `484`, `494`, `667`, or `689`.
These codes appear in the [`claims[].claimStatus.statusCode`](/healthcare/api-reference/post-healthcare-claim-status#response.claims.claimStatus.statusCode) and [`claims[].serviceDetails[].status[].statusCode`](/healthcare/api-reference/post-healthcare-claim-status#response.claims.serviceDetails.status.statusCode) properties of the JSON response.
# Claim edits and repairs
Source: https://www.stedi.com/docs/healthcare/claim-edits-and-repairs
Stedi checks each claim you submit for errors that could lead to rejections or denials.
Depending on the type of error, Stedi will either fix the issue automatically (repair) or reject the claim (edit rejection) with instructions explaining what to change before resubmitting. This process helps ensure claims are complete, accurate, HIPAA-compliant, and aligned with payer-specific rules *before* they reach the payer.
Catching and resolving issues early through claim edits and repairs streamlines claims processing so providers can get paid faster.
## Repairs [#repairs]
Repairs are fixes that Stedi applies to claims before checking them against our library of [claim edits](#edits). They fix problems with a known, deterministic solution, such as formatting issues. For example, if a phone number contains dashes or spaces, a repair might remove them so the claim passes validation.
We don't use repairs to change substantive or clinical content. For example, a repair won't change a CPT code in a claim to reflect a different procedure. That's a substantive change that requires resubmission.
Claim repairs don't require any action from you - they happen automatically, so you don't need to make changes or resubmit.
## Edits [#edits]
Claim edits are validation rules that check a specific requirement. For example, an edit might check that each phone number in the claim contains exactly 10 digits. Many of our [repairs](#repairs) fix issues that would cause claims to fail one or more edits. For example, a repair may remove dashes in a phone number so it's in the right format for the edit validation. If the phone number still doesn't have 10 digits, the claim fails the edit.
Stedi runs our entire library of edits on each claim you submit. This applies to both new claims and existing claims you're resubmitting through Stedi.
When a claim fails one or more edits, Stedi rejects the claim and doesn't send it to the payer. You'll receive detailed error messages for all of the edits the claim failed along with instructions for what to change before resubmission.
* **API:** Stedi returns an HTTP `400` status and includes the edit rejections in the `errors` array.
* **Stedi portal:** Stedi indicates edit rejections immediately in the portal form.
* **SFTP:** Stedi rejects the claim with a [277CA claim acknowledgment](/healthcare/submit-claims-sftp-connection#277ca-claim-acknowledgment) containing the edit rejection details. You'll receive the 277CA rejection within minutes after claim submission in your `from-stedi` directory.
You'll need to fix the issues causing the edit failures and resubmit the claim with the same Claim Frequency Code. For example, if you initially submitted the claim to Stedi with code `1`, you should resubmit it to Stedi with code `1`.
### Example edit rejections [#example-edit-rejections]
The following example shows edit rejections returned in an API response. The `errors` array contains all the edits that the claim failed, along with detailed descriptions and follow-up actions:
```json
{
"status": "ERROR",
"controlNumber": "1",
"tradingPartnerServiceId": "6400",
"claimReference": {
"correlationId": "01AAAC3A5BB1CCCC3DDD5JJJJ3",
"patientControlNumber": "12345678",
"timeOfResponse": "2026-01-06T19:21:18.287Z",
"payerId": "6400",
"formatVersion": "5010",
"rhclaimNumber": "01AAAC3A5BB1CCCC3DDD5JJJJ3",
"serviceLines": [
{
"lineItemControlNumber": "111222333"
}
]
},
"errors": [
{
"code": "33",
"description": "The subscriber date of birth, 20260201, is invalid. The date of birth cannot be later than the transaction date and must reflect a reasonable subscriber age. Correct and resubmit.",
"followupAction": "Please Correct and Resubmit"
},
{
"code": "33",
"description": "Diagnosis Code FZ9888 does not exist in ICD-10. Please review and resubmit.",
"followupAction": "Please Correct and Resubmit"
},
{
"code": "33",
"description": "Total claim charge amount ($130.00) does not equal the sum of all service line charge amounts ($109.20) for this claim. Correct and resubmit.",
"followupAction": "Please Correct and Resubmit"
}
],
"meta": {
"traceId": "bd67003d-ce55-4b94-a89d-66e11110d0c"
},
"payer": {
"payerName": "Cigna",
"payerId": "6400"
},
"httpStatusCode": "400 BAD_REQUEST"
}
```
### Stedi's edit database [#stedis-edit-database]
Stedi has a growing library of claim edits, including edits for specific payers. You can review a filterable, up-to-date list of all our claim edits in our [Edits database](https://edits.stedi.com/).
There's no standardized universal library of claim edits. However, a large number of industry-standard edits originate from HIPAA rules (such as using ICD-10 as the standard coding system) and from Centers for Medicare & Medicaid Services (CMS) rules, such as the National Correct Coding Initiative (NCCI). NCCI edits were originally developed by CMS for Medicare, but many non-Medicare payers have adopted them or use them as a baseline.
Our goal is to eventually cover all non-provider-specific edits that can be deterministically applied to claims. You can submit requests for new edits or updates to existing ones through our [Request a claim edit](https://www.stedi.com/request-claim-edit) form.
### SNIP framework [#snip-framework]
Edits are often categorized using the Strategic National Implementation Process (SNIP) framework. The framework was created by the Workgroup for Electronic Data Interchange (WEDI), which sets guidelines (but not standards) for how EDI should be implemented in healthcare.
Each SNIP type, or level, checks a different aspect of a claim's correctness. You can find the SNIP level of all of our edits in the [Edits database](https://edits.stedi.com/).
**SNIP Type 1: EDI Standard Integrity Testing**
Edits that check whether the claim uses valid EDI syntax. Examples:
* Are the EDI segments in the right order?
* Do fields meant for numbers contain numbers?
**SNIP Type 2: HIPAA Implementation Guide Requirement Testing**
Edits that check whether the claim uses HIPAA-compliant X12 syntax. Examples:
* Invalid phone numbers
* Invalid date of birth
* Invalid billing provider address
* Missing primary payer
**SNIP Type 3: HIPAA Balance Testing**
Edits that check whether the billing amounts in the claim add up correctly. Examples:
* Non-zero adjustment amounts
* COB claims must be balanced
* Total claim charges must equal line-level charges
**SNIP Type 4: HIPAA Inter-Segment Situation Testing**
Edits that check whether fields are present or missing based on the presence of other fields. Examples:
* Missing accident date
* Missing admission source code
**SNIP Type 5: HIPAA External Code Set Testing**
Checks that fields that use official HIPAA-adopted code sets only contain valid values. For example, an edit could check for invalid ICD-10-CM diagnosis codes.
**SNIP Type 6: Product Type/Type of Service Testing**
Edits that check whether the claim is valid and in the right format for the type of healthcare service listed. These edits catch mismatches between the procedure code being billed and the type of claim or service category. Examples:
* Using a CDT dental code in an 837P professional claim.
* Billing a surgery CPT code under a diagnostic service type.
* Including a revenue code, which is used only in 837I institutional claims, in an 837P professional claim.
**SNIP Type 7: Trading Partner-Specific Testing**
Edits that check whether the claim complies with rules in HIPAA guides that apply only to government payers like Medicare and Medicaid. Examples:
* Invalid primary diagnosis on Medicare chiropractic claims
* Missing initial treatment date for Medicare chiropractic claims
# Acknowledgments and ERAs overview
Source: https://www.stedi.com/docs/healthcare/claim-responses-overview
You can receive two types of transactions after you submit a professional, institutional, or dental claim through Stedi's APIs, an SFTP connection, or the Stedi portal:
* 277CA claim acknowledgments
* 835 Electronic Remittance Advice (ERA)
If you're submitting claims through SFTP, you'll also receive 999 Implementation Acknowledgments. Visit [SFTP submission](/healthcare/submit-claims-sftp-connection#monitor-for-999-rejections-strongly-recommended) for details.
## Claim response overview [#claim-response-overview]
Claim responses provide information about the status of a submitted claim as it moves through various stages of processing, validation, and adjudication. The following diagram illustrates the types of claim responses you may receive at each stage:
Stedi validates the claim according to industry standards and payer-specific rules (edits).
* If the claim fails validation, Stedi rejects it and doesn't send the claim to the payer. You'll need to correct the errors and resubmit.
* If the claim passes validation, Stedi accepts it and routes it to the payer. This doesn't indicate that the claim has been approved, only that the claim has passed Stedi's validation.
During this process, you may receive one or more 277CA claim acknowledgments from Stedi indicating the claim's acceptance or rejection status.
You may receive additional 277CA claim acknowledgments from the payer letting you know that the claim has been received and whether it's been accepted or rejected for adjudication.
* If the payer rejects the claim, you'll need to correct the errors and resubmit. The payer can reject a claim before or after it enters their processing system.
* If the payer accepts the claim, they'll begin adjudication. This doesn't mean that the claim has been approved.
Once a claim has entered the payer's processing system, the 277CA usually contains the Payer Claim Control Number (PCCN) assigned to the claim in:
* [`transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].patientClaimStatusDetails[].claims[].claimStatus.tradingPartnerClaimNumber`](https://www.stedi.com/docs/healthcare/api-reference/get-healthcare-reports-277#response.transactions.payers\[].claimStatusTransactions\[].claimStatusDetails\[].patientClaimStatusDetails\[].claims\[].claimStatus.tradingPartnerClaimNumber)
* `Loop 2200D REF02`, where `REF01` = `1K` (Payor's Claim Number)
The payer may briefly pend the claim for additional review before making a final decision. This is common for high-dollar or complex claims which require manual review or supporting documentation (attachments).
Once the claim has been adjudicated, you'll receive an 835 Electronic Remittance Advice (ERA) from the payer with the adjudication details for each line item.
## 277CA claim acknowledgment [#277ca-claim-acknowledgment]
The 277CA indicates whether a claim was accepted for processing or rejected due to correctable errors, such as invalid data, missing information, or failure to comply with payer-specific rules.
A rejection is different from a denial. Claims are denied during adjudication, so you'll only see denial statuses in the 835 Electronic Remittance Advice (ERA). A 277CA rejection indicates that the claim never made it to the adjudication step. In these cases, the 277CA will include error codes and descriptions to help you correct the issues before resubmitting the claim.
You may receive multiple 277CAs for each claim you submit. You should monitor these 277CAs to track the claim's status as it moves through Stedi and the payer's systems:
* **Clearinghouse:** You'll receive the first 277CA from Stedi within about 30 minutes of submitting the claim to indicate whether we have accepted or rejected it. You may receive additional 277CAs as we route the claim to the payer.
* **Payer:** You may receive one or more 277CAs from the payer. Typically, there is one 277CA that indicates receipt of the claim and a second 277CA that contains summary counts of transactions received, information about accepted transactions, and details for rejected transactions.
Each 277CA typically correlates to one 837 claim. However:
* Some payers may send a single 277CA that [references multiple claims](/healthcare/receive-claim-responses#correlate-277ca).
* Payers sometimes split a single claim into multiple claims during processing. In these cases, you may receive multiple 277CAs from the payer for the original claim you submitted.
* Payers may send another 277CA when they forward a claim to a secondary payer in a coordination of benefits scenario.
* (SFTP only) When you submit a [bulk claim](/healthcare/submit-claims-sftp-connection#bulk-claims), you'll typically receive one 277CA per claim. For example, if you submit a bulk transaction containing information for 10 claims, you'll typically receive 10 separate 277CAs.
### API responses [#api-responses]
Our claim submission APIs return an initial 277CA in the `x12` property of the response body that indicates whether the claim has passed Stedi's claim edits. This 277CA is in X12 EDI format.
When the claim fails one or more edits, the 277CA contains information about each error. These are the same error codes that appear in the `errors` array.
Note that this initial 277CA only indicates whether Stedi has accepted or rejected the claim submission. You may receive additional 277CA acceptances or rejections as the claim is routed to the payer. You'll need to monitor for and retrieve those additional 277CAs through webhooks or polling.
```json
{
"status": "SUCCESS",
"controlNumber": "1",
"tradingPartnerServiceId": "6400",
"claimReference": {
"correlationId": "01KHC8Y4HNP0GVQ5NSVTPZBC0F",
"patientControlNumber": "111222333",
"timeOfResponse": "2026-02-13T19:51:51.496Z",
"payerId": "6400",
"formatVersion": "5010",
"rhclaimNumber": "01KHC8Y4HNP0GVQ5NSVTPZBC0F",
"serviceLines": [
{
"lineItemControlNumber": "111222333"
}
]
},
"meta": {
"traceId": "d61ca4bc-e9e7-4d0f-93d0-6f7ff810b0e6"
},
"payer": {
"payerName": "Cigna",
"payerId": "6400"
},
"x12": "ISA*00* *00* *ZZ*STEDITEST *ZZ*574183004559 *260213*1951*^*00501*980180479*0*T*`~GS*HN*STEDITEST*574183004559*20260213*195151*1*X*005010X214~ST*277*0001*005010X214~BHT*0085*08*01KHC8YJE8EY6A5HFR00Z5H305*20260213*195151*TH~HL*1**20*1~NM1*AY*2*STEDI INC*****46*117151744~TRN*1*01KHC8YJE8EY6A5HFR00Z5H305~DTP*050*D8*20260213~DTP*009*D8*20260213~HL*2*1*21*1~NM1*41*2*Test Data Health Services, Inc.*****46*123456~TRN*2*01KHC8Y4HNP0GVQ5NSVTPZBC0F~STC*A0`17`AY*20260213*WQ*109.2~QTY*90*1~AMT*YU*109.2~HL*3*2*19*1~NM1*85*2*Therapy Associates*****XX*1234567890~TRN*1*0~REF*TJ*123456789~QTY*QA*1~AMT*YU*109.2~HL*4*3*PT*0~NM1*QC*1*Anon*John****MI*U7777788888~TRN*2*111222333~STC*A1`20*20260213*WQ*109.2~DTP*472*RD8*20240101-20240101~SE*25*0001~GE*1*1~IEA*1*980180479~",
"httpStatusCode": "200 OK"
}
```
### 277CA vs. claim status check [#277ca-vs-claim-status-check]
The 277CA contains different information than a real-time claim status check. Specifically:
* **277CAs**: Tell you whether the payer has received a claim and accepted it for processing. If the claim was rejected, 277CAs tell you why so you can resubmit. They don't indicate whether the claim has been adjudicated or paid.
* **Real-time claim status checks**: Tell you the status of a claim that's already been accepted into the payer's system. They provide information about whether the claim has been adjudicated, paid, denied, or is pending further review.
That's why claim status checks can return more [Claim Status Category Codes](https://x12.org/codes/claim-status-category-codes) than a 277CA. Specifically, they can return codes in the `P` range for pending claims and codes in the `F` range for final claim statuses.
If you're waiting for an ERA, you should first check the related 277CA to confirm that the claim was accepted for processing. If the claim was rejected, you won't receive an ERA because the payer didn't adjudicate the claim.
Then, you can run a real-time claim status check to get updates about the claim's adjudication and payment status.
### Transaction enrollment [#transaction-enrollment]
[Transaction enrollment](/healthcare/transaction-enrollment) isn't required to receive 277CA claim acknowledgments through Stedi. Stedi automatically processes 277CAs for all claims submitted through Stedi, regardless of the submission method (API, SFTP, or portal).
## 835 Electronic Remittance Advice (ERA) [#835-electronic-remittance-advice-era]
Processing ERAs always requires [transaction
enrollment](/healthcare/transaction-enrollment) with the payer.
The ERA contains details about payments for specific services and explanations for any adjustments or denials. The payer only sends ERAs for claims they have accepted for adjudication. If a claim is rejected in a 277CA, there's no adjudication or payment information to report.
You'll typically only receive one 835 ERA per claim. However, payers may occasionally retransmit another identical [duplicate ERA](/healthcare/receive-claim-responses#duplicate-eras).
### Transaction enrollment [#transaction-enrollment-1]
[Transaction enrollment](/healthcare/transaction-enrollment) is the process of registering a provider to exchange specific healthcare transactions with a payer. Transaction enrollment is **always** required before a provider can receive 835 ERAs through Stedi.
ERAs can only be sent to a single clearinghouse, so enrolling with Stedi cancels existing ERA enrollments you have through other clearinghouses. Once enrolled with Stedi, the provider will no longer receive ERAs from that payer through the previous clearinghouse.
However, enrolling through Stedi for 835 ERAs doesn't affect your existing enrollments for other transaction types. For example, enrolling with Stedi won't automatically unenroll the provider from transactions, such as 837 claims, that they're processing through other clearinghouses.
To enroll for ERAs through Stedi, complete the following steps:
1. Create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step. [Stedi portal](https://portal.stedi.com/app/healthcare/providers) | [API endpoint](/healthcare/api-reference/post-enrollment-create-provider)
2. Submit an enrollment request for claim payment (835 ERA). [Stedi portal](https://portal.stedi.com/app/healthcare/enrollments) | [API endpoint](/healthcare/api-reference/post-enrollment-create-enrollment)
# Claims code lists
Source: https://www.stedi.com/docs/healthcare/claims-code-lists
This page contains code lists that are too long to represent clearly within the [API reference documentation](https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-claims). You can find code lists for:
* [837 claims](#837-claim-code-lists) (professional, dental, and institutional)
* [277CA claim acknowledgments](#277ca-code-lists)
* [835 Electronic Remittance Advice (ERAs)](#era-code-lists)
* [276/277 claim status checks](#claim-status-code-lists)
## 837 claim code lists [#837-claim-code-lists]
You may need to reference the following code lists when submitting professional, dental, and institutional claims.
### Ambulance Certification Condition Codes [#ambulance-certification-condition-codes]
Used in the professional claims `claimInformation.ambulanceCertification.conditionCodes` property.
* `01` - Patient was admitted to a hospital
* `04` - Patient was moved by stretcher
* `05` - Patient was unconscious or in shock
* `06` - Patient was transported in an emergency situation
* `07` - Patient had to be physically restrained
* `08` - Patient had visible hemorrhaging
* `09` - Ambulance service was medically necessary
* `12` - Patient is confined to a bed or chair; use to indicate that the patient was bedridden during transport
### Ambulance Transport Reason Codes [#ambulance-transport-reason-codes]
Used in the professional claims `claimInformation.ambulanceTransportInformation.ambulanceTransportReasonCode` property.
* `A` - Patient was transported to nearest facility for care of symptoms, complaints, or both
* `B` - Patient was transported for the benefit of a preferred physician
* `C` - Patient was transported for the nearness of family members
* `D` - Patient was transported for the care of a specialist or for availability of specialized equipment
* `E` - Patient Transferred to Rehabilitation Facility
### Attachment Report Type Codes [#attachment-report-type-codes]
Used in the following APIs and properties:
* Professional claims `claimInformation.serviceLines[].serviceLineSupplementalInformation[].attachmentReportTypeCode` property
* Institutional claims `claimInformation.claimSupplementalInformation.reportInformation.attachmentReportTypeCode` property
* Dental claims `claimInformation.claimSupplementalInformation.reportInformation.attachmentReportTypeCode` property. A subset of the codes are supported for [dental claims](#dental).
- `03` - Report Justifying Treatment Beyond Utilization Guidelines
- `04` - Drugs Administered
- `05` - Treatment Diagnosis
- `06` - Initial Assessment
- `07` - Functional Goals
- `08` - Plan of Treatment
- `09` - Progress Report
- `10` - Continued Treatment
- `11` - Chemical Analysis
- `13` - Certified Test Report
- `15` - Justification for Admission
- `21` - Recovery Plan
- `A3` - Allergies/Sensitivities Document
- `A4` - Autopsy Report
- `AM` - Ambulance Certification
- `AS` - Admission Summary
- `B2` - Prescription
- `B3` - Physician Order
- `B4` - Referral Form
- `BR` - Benchmark Testing Results
- `BS` - Baseline
- `BT` - Blanket Test Results
- `CB` - Chiropractic Justification
- `CK` - Consent Form(s)
- `CT` - Certification
- `D2` - Drug Profile Document
- `DA` - Dental Models
- `DB` - Durable Medical Equipment Prescription
- `DG` - Diagnostic Report
- `DJ` - Discharge Monitoring Report
- `DS` - Discharge Summary
- `EB` - Explanation of Benefits (Coordination of Benefits or Medicare Secondary Payor)
- `HC` - Health Certificate
- `HR` - Health Clinic Records
- `I5` - Immunization Record
- `IR` - State School Immunization Records
- `LA` - Laboratory Results
- `M1` - Medical Record Attachment
- `MT` - Models
- `NN` - Nursing Notes
- `OB` - Operative Note
- `OC` - Oxygen Content Averaging Report
- `OD` - Orders and Treatments Document
- `OE` - Objective Physical Examination (including vital signs) Document
- `OX` - Oxygen Therapy Certification
- `OZ` - Support Data for Claim
- `P4` - Pathology Report
- `P5` - Patient Medical History Document
- `PE` - Parenteral or Enteral Certification
- `PN` - Physical Therapy Notes
- `PO` - Prosthetics or Orthotic Certification
- `PQ` - Paramedical Results
- `PY` - Physician's Report
- `PZ` - Physical Therapy Certification
- `RB` - Radiology Films
- `RR` - Radiology Reports
- `RT` - Report of Tests and Analysis Report
- `RX` - Renewable Oxygen Content Averaging Report
- `SG` - Symptoms Document
- `V5` - Death Notification
- `XP` - Photographs
#### Dental [#dental]
For dental claims, only the following attachment report type codes are supported:
* `B4` - Referral Form
* `DA` - Dental Models
* `DG` - Diagnostic Report
* `EB` - Explanation of Benefits (Coordination of Benefits or Medicare Secondary Payor)
* `OZ` - Support Data for Claim
* `P6` - Periodontal Charts
* `RB` - Radiology Films
* `RR` - Radiology Reports
### Attachment Transmission Codes [#attachment-transmission-codes]
Used in the professional claims `claimInformation.serviceLines[].durableMedicalEquipmentCertificateOfMedicalNecessity.attachmentTransmissionCode` property.
* `AB` - Previously Submitted to Payer
* `AD` - Certification Included in this Claim
* `AF` - Narrative Segment Included in this Claim
* `AG` - No Documentation is Required
* `NS` - Not Specified; Paperwork is available on request at the provider's site. This means that the paperwork is not being sent with the claim at this time. Instead, it is available to the payer (or appropriate entity) at their request.
### Claim Filing Indicator Codes [#claim-filing-indicator-codes]
Used in the following APIs and properties:
* Professional Claims `claimInformation.claimFilingCode` and `claimInformation.otherSubscriberInformation[].claimFilingIndicatorCode` properties.
* Dental Claims `claimInformation.claimFilingCode` and `claimInformation.otherSubscriberInformation[].claimFilingIndicatorCode` properties.
* Institutional Claims `claimInformation.claimFilingCode` and `claimInformation.otherSubscriberInformation.claimFilingIndicatorCode` properties.
- `11` - Other Non-Federal Programs
- `12` - Preferred Provider Organization (PPO)
- `13` - Point of Service (POS)
- `14` - Exclusive Provider Organization (EPO)
- `15` - Indemnity Insurance
- `16` - Health Maintenance Organization (HMO) Medicare Risk
- `17` - Dental Maintenance Organization
- `AM` - Automobile Medical
- `BL` - Blue Cross/Blue Shield
- `CH` - Champus
- `CI` - Commercial Insurance Co.
- `DS` - Disability
- `FI` - Federal Employees Program
- `HM` - Health Maintenance Organization
- `LM` - Liability Medical
- `MA` - Medicare Part A
- `MB` - Medicare Part B
- `MC` - Medicaid
- `OF` - Other Federal Program; Use when submitting Medicare Part D claims
- `TV` - Title V
- `VA` - Veterans Affairs Plan
- `WC` - Workers' Compensation Health Claim
- `ZZ` - Mutually Defined; Use when Type of Insurance is not known
#### Choosing the right code [#choosing-the-right-code]
For some payers, the value for `claimInformation.claimFilingCode` is relatively obvious. For example, if you're submitting a claim to Medicaid California Medi-Cal, then it makes sense to default to populating `claimInformation.claimFilingCode` with `MC` (Medicaid).
For other payers, the correct code may be more difficult to determine. For example, if submitting a claim to the Centers for Medicare and Medicaid Services (CMS), you may need to submit `MA` (Medicare Part A) or `MB` (Medicare Part B).
In these cases, you can run a [real-time eligibility check](/healthcare/send-eligibility-checks) and evaluate whether the response contains any information that clearly suggests which claim filing code to use. For example, if the eligibility response contains `"benefitsInformation.insuranceType" : "Commercial"` then you should submit `"claimInformation.claimFilingCode": "CI"`.
One thing to note is that you may not always get back a `benefitsInformation.insuranceType` value in an eligibility response because payers are not required to send it. In these cases, you can just submit `ZZ` as the `claimFilingCode` because the vast majority of payers will accept that value.
Once you use this workflow to determine a best guess for the Claim Filing Indicator Code for each payer, you can try sending a claim.
* **Rejection:** The rejection message will clearly state that the claim filing indicator code was incorrect, and should state which one to send instead.
* **Acceptance:** The claim filing indicator code you submitted was correct.
### Claim Pricing (Institutional Claims) [#claim-pricing-institutional-claims]
For properties in the Institutional Claims `claimInformation.claimPricingInformation` object and the `claimInformation.serviceLines[].lineAdjudicationInformation` object.
#### Exception Codes [#exception-codes]
Used in the institutional claims `claimInformation.claimPricingInformation.exceptionCode` property.
* `1` - Non-Network Professional Provider in Network Hospital
* `2` - Emergency Care
* `3` - Services or Specialist not in Network
* `4` - Out-of-Service Area
* `5` - State Mandates
* `6` - Other
#### Policy Compliance Codes [#policy-compliance-codes]
Used in the institutional claims `claimInformation.claimPricingInformation.policyComplianceCode` and `claimInformation.serviceLines[].linePricingInformation.policyComplianceCode` properties.
* `1` - Procedure Followed (Compliance)
* `2` - Not Followed - Call Not Made (Non-Compliance Call Not Made)
* `3` - Not Medically Necessary (Non-Compliance Non-Medically Necessary)
* `4` - Not Followed Other (Non-Compliance Other)
* `5` - Emergency Admit to Non-Network Hospital
#### Pricing Methodology Codes [#pricing-methodology-codes]
Used in the institutional claims `claimInformation.claimPricingInformation.pricingMethodologyCode` and `claimInformation.serviceLines[].lineRepricingInformation.pricingMethodologyCode` properties.
* `00` - Zero Pricing (Not Covered Under Contract)
* `01` - Priced as Billed at 100%
* `02` - Priced at the Standard Fee Schedule
* `03` - Priced at a Contractual Percentage
* `04` - Bundled Pricing
* `05` - Peer Review Pricing
* `06` - Per Diem Pricing
* `07` - Flat Rate Pricing
* `08` - Combination Pricing
* `09` - Maternity Pricing
* `10` - Other Pricing
* `11` - Lower of Cost
* `12` - Ratio of Cost
* `13` - Cost Reimbursed
* `14` - Adjustment Pricing
#### Product or Service ID Qualifier Codes [#product-or-service-id-qualifier-codes]
Used in the institutional claims properties:
* `claimInformation.claimPricingInformation.productOrServiceIDQualifier`
* `claimInformation.serviceLines[].lineAdjudicationInformation.productOrServiceIDQualifier`
* `claimInformation.serviceLines[].institutionalService.procedureIdentifier`
* `claimInformation.serviceLines[].lineRepricingInformation.productOrServiceIDQualifier`
- `ER` - Jurisdiction Specific Procedure and Supply Codes; Not allowed for use under HIPAA. You can only use this code if a new rule names the Jurisdiction Specific Procedure and Supply Codes as an allowable code set under HIPAA, OR the Secretary grants an exception to use the code set as a pilot project as allowed under the law, OR for claims not covered by HIPAA.
- `HC` - Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes; Because the AMA's CPT codes are also level 1 HCPCS codes, they are reported under HC.
- `HP` - Health Insurance Prospective Payment System (HIPPS) Skilled Nursing Facility Rate Code
- `IV` - Home Infusion EDI Coalition (HIEC) Product/Service Code; Not allowed for use under HIPAA. You can only use this qualifier if a new rule names the Home Infusion EDI Coalition (HIEC) Product/Service Codes as an allowable code set under HIPAA, OR the Secretary grants an exception to use the code set as a pilot project as allowed under the law, OR for claims not covered by HIPAA.
- `WK` - Advanced Billing Concepts (ABC) Codes; Approved by the Secretary of HHS as a pilot project allowed under HIPAA law. Only parties registered in the pilot project and their trading partners can use this qualifier in transactions covered by HIPAA. Otherwise, you can only use this code if a new rule names the Complementary, Alternative, or Holistic Procedure Codes as an allowable code set under HIPAA OR for claims not covered by HIPAA.
#### Reject Reason Codes [#reject-reason-codes]
Used in the institutional claims `claimInformation.claimPricingInformation.rejectReasonCode` and `claimInformation.serviceLines[].lineRepricingInformation.rejectReasonCode` properties.
* `T1` - Cannot Identify Provider as TPO (Third Party Organization) Participant
* `T2` - Cannot Identify Payer as TPO (Third Party Organization) Participant
* `T3` - Cannot Identify Insured as TPO (Third Party Organization) Participant
* `T4` - Payer Name or Identifier Missing
* `T5` - Certification Information Missing
* `T6` - Claim does not contain enough information for re-pricing
### Composite Medical Procedure - Product or Service ID Qualifier Codes [#composite-medical-procedure---product-or-service-id-qualifier-codes]
Used in the professional claims `claimInformation.serviceLines[].lineAdjudicationInformation.serviceIdQualifier` and `claimInformation.serviceLines[].professionalService.procedureIdentifier` properties.
* `ER` - Jurisdiction Specific Procedure and Supply Codes; Not allowed for use under HIPAA. You can only use this code if a new rule names the Jurisdiction Specific Procedure and Supply Codes as an allowable code set under HIPAA, OR the Secretary grants an exception to use the code set as a pilot project as allowed under the law, OR for claims not covered by HIPAA.
* `HC` - Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes; Because the AMA's CPT codes are also level 1 HCPCS codes, they are reported under HC.
* `IV` - Home Infusion EDI Coalition (HIEC) Product/Service Code; Not allowed for use under HIPAA. You can only use this qualifier if a new rule names the Home Infusion EDI Coalition (HIEC) Product/Service Codes as an allowable code set under HIPAA, OR the Secretary grants an exception to use the code set as a pilot project as allowed under the law, OR for claims not covered by HIPAA.
* `WK` - Advanced Billing Concepts (ABC) Codes; Approved by the Secretary of HHS as a pilot project allowed under HIPAA law. Only parties registered in the pilot project and their trading partners can use this qualifier in transactions covered by HIPAA. Otherwise, you can only use this code if a new rule names the Complementary, Alternative, or Holistic Procedure Codes as an allowable code set under HIPAA OR for claims not covered by HIPAA.
### Delay Reason Codes [#delay-reason-codes]
Used in the following APIs and properties:
* Professional claims `claimInformation.delayReasonCode` property.
* Institutional claims `claimInformation.delayReasonCode` property.
* Dental claims `claimInformation.delayReasonCode` property.
- `1` - Proof of Eligibility Unknown or Unavailable
- `2` - Litigation
- `3` - Authorization Delays
- `4` - Delay in Certifying Provider
- `5` - Delay in Supplying Billing Forms
- `6` - Delay in Delivery of Custom-made Appliances
- `7` - Third Party Processing Delay
- `8` - Delay in Eligibility Determination
- `9` - Original Claim Rejected or Denied Due to a Reason Unrelated to the Billing Limitation Rules
- `10` - Administration Delay in the Prior Approval Process
- `11` - Other
- `15` - Natural Disaster
### Drug Identification Product or Service ID Qualifier Codes [#drug-identification-product-or-service-id-qualifier-codes]
Used in the professional claims `claimInformation.serviceLines[].drugIdentification.serviceIdQualifier` property.
* `EN` - EAN/UCC - 13
* `EO` - EAN/UCC - 8
* `HI` - HIBC (Health Care Industry Bar Code) Supplier Labeling Standard Primary Data Message
* `N4` - National Drug Code in 5-4-2 Format
* `ON` - Customer Order Number
* `UK` - GTIN 14-digit Data Structure
* `UP` - UCC - 12
### Individual Relationship Codes [#individual-relationship-codes]
Used in the following APIs and properties:
* Professional claims `claimInformation.otherSubscriberInformation[].individualRelationshipCode` property.
* Dental claims `claimInformation.otherSubscriberInformation[].individualRelationshipCode` property.
* Institutional claims `claimInformation.otherSubscriberInformation.individualRelationshipCode` property.
- `01` - Spouse
- `18` - Self
- `19` - Child
- `20` - Employee
- `21` - Unknown
- `39` - Organ Donor
- `40` - Cadaver Donor
- `53` - Life Partner
- `G8` - Other Relationship
### Insurance Type Codes [#insurance-type-codes]
Used in the following APIs and properties:
* Professional claims `subscriber.insuranceTypeCode` and `claimInformation.otherSubscriberInformation[].insuranceTypeCode` properties.
* Dental claims `subscriber.insuranceTypeCode` and `claimInformation.otherSubscriberInformation[].insuranceTypeCode` properties.
- `12` - Medicare Secondary Working Aged Beneficiary or Spouse with Employer Group Health Plan
- `13` - Medicare Secondary End-Stage Renal Disease Beneficiary in the Mandated Coordination Period with an Employer's Group Health Plan
- `14` - Medicare Secondary, No-fault Insurance including Auto is Primary
- `15` - Medicare Secondary Worker's Compensation
- `16` - Medicare Secondary Public Health Service (PHS)or Other Federal Agency
- `41` - Medicare Secondary Black Lung
- `42` - Medicare Secondary Veteran's Administration
- `43` - Medicare Secondary Disabled Beneficiary Under Age 65 with Large Group Health Plan (LGHP)
- `47` - Medicare Secondary, Other Liability Insurance is Primary
### Payment Responsibility Sequence Number Codes [#payment-responsibility-sequence-number-codes]
Used in the following APIs and properties:
* Professional claims `subscriber.paymentResponsibilityLevelCode` and `claimInformation.otherSubscriberInformation[].paymentResponsibilityLevelCode` properties.
* Dental claims `subscriber.paymentResponsibilityLevelCode` and `claimInformation.otherSubscriberInformation[].paymentResponsibilityLevelCode` properties.
* Institutional claims `subscriber.paymentResponsibilityLevelCode` and `claimInformation.otherSubscriberInformation.paymentResponsibilityLevelCode` properties.
- `A` - Payer Responsibility Four
- `B` - Payer Responsibility Five
- `C` - Payer Responsibility Six
- `D` - Payer Responsibility Seven
- `E` - Payer Responsibility Eight
- `F` - Payer Responsibility Nine
- `G` - Payer Responsibility Ten
- `H` - Payer Responsibility Eleven
- `P` - Primary
- `S` - Secondary
- `T` - Tertiary
- `U` - Unknown; This code may only be used in payer to payer COB claims when the original payer determined the presence of this coverage from eligibility files received from this payer or when the original claim did not provide the responsibility sequence for this payer.
### Pricing/Repricing (Professional and Dental Claims) [#pricingrepricing-professional-and-dental-claims]
Used in the professional claims and dental claims APIs.
#### Exception Codes [#exception-codes-1]
Used in the following APIs and properties:
* Professional claims `claimInformation.claimPricingRepricingInformation.exceptionCode` and `claimInformation.serviceLines[].linePricingRepricingInformation.exceptionCode` properties.
* Dental claims `claimInformation.claimPricingRepricingInformation.exceptionCode` and `claimInformation.serviceLines[].linePricingRepricingInformation.exceptionCode` properties.
- `1` - Non-Network Professional Provider in Network Hospital
- `2` - Emergency Care
- `3` - Services or Specialist not in Network
- `4` - Out-of-Service Area
- `5` - State Mandates
- `6` - Other
#### Policy Compliance Codes [#policy-compliance-codes-1]
Used in the following APIs and properties:
* Professional claims `claimInformation.claimPricingRepricingInformation.policyComplianceCode` and `claimInformation.serviceLines[].linePricingRepricingInformation.policyComplianceCode` properties.
* Dental claims `claimInformation.claimPricingRepricingInformation.policyComplianceCode` and `claimInformation.serviceLines[].linePricingRepricingInformation.policyComplianceCode` properties.
- `1` - Procedure Followed (Compliance)
- `2` - Not Followed - Call Not Made (Non-Compliance Call Not Made)
- `3` - Not Medically Necessary (Non-Compliance Non-Medically Necessary)
- `4` - Not Followed Other (Non-Compliance Other)
- `5` - Emergency Admit to Non-Network Hospital
#### Pricing Methodology Codes [#pricing-methodology-codes-1]
Used in the following APIs and properties:
* Professional claims `claimInformation.claimPricingRepricingInformation.pricingMethodologyCode` and `claimInformation.serviceLines[].linePricingRepricingInformation.pricingMethodologyCode` properties.
* Dental claims `claimInformation.claimPricingRepricingInformation.pricingMethodologyCode` and `claimInformation.serviceLines[].linePricingRepricingInformation.pricingMethodologyCode` properties.
- `00` - Zero Pricing (Not Covered Under Contract)
- `01` - Priced as Billed at 100%
- `02` - Priced at the Standard Fee Schedule
- `03` - Priced at a Contractual Percentage
- `04` - Bundled Pricing
- `05` - Peer Review Pricing
- `07` - Flat Rate Pricing
- `08` - Combination Pricing
- `09` - Maternity Pricing
- `10` - Other Pricing
- `11` - Lower of Cost
- `12` - Ratio of Cost
- `13` - Cost Reimbursed
- `14` - Adjustment Pricing
#### Reject Reason Codes [#reject-reason-codes-1]
Used in the following APIs and properties:
* Professional claims `claimInformation.claimPricingRepricingInformation.rejectReasonCode` and `claimInformation.serviceLines[].linePricingRepricingInformation.rejectReasonCode` properties.
* Dental claims `claimInformation.claimPricingRepricingInformation.rejectReasonCode` and `claimInformation.serviceLines[].linePricingRepricingInformation.rejectReasonCode` properties.
- `T1` - Cannot Identify Provider as TPO (Third Party Organization) Participant
- `T2` - Cannot Identify Payer as TPO (Third Party Organization) Participant
- `T3` - Cannot Identify Insured as TPO (Third Party Organization) Participant
- `T4` - Payer Name or Identifier Missing
- `T5` - Certification Information Missing
- `T6` - Claim does not contain enough information for re-pricing
### Service Authorization Exception Codes [#service-authorization-exception-codes]
Used in the following APIs and properties:
* Professional claims `claimInformation.claimSupplementalInformation.serviceAuthorizationExceptionCode` property
* Dental claims `claimInformation.claimSupplementalInformation.serviceAuthorizationExceptionCode` property
* Institutional claims `claimInformation.claimSupplementalInformation.serviceAuthorizationExceptionCode` property.
- `1` - Immediate/Urgent Care
- `2` - Services Rendered in a Retroactive Period
- `3` - Emergency Care
- `4` - Client has Temporary Medicaid
- `5` - Request from County for Second Opinion to Determine if Recipient Can Work
- `6` - Request for Override Pending
- `7` - Special Handling
### Vision Condition Codes [#vision-condition-codes]
Used in the professional claims `claimInformation.patientConditionInformationVision.conditionCodes` property.
* `L1` - General Standard of 20 Degree or .5 Diopter Sphere or Cylinder Change Met
* `L2` - Replacement Due to Loss or Theft
* `L3` - Replacement Due to Breakage or Damage
* `L4` - Replacement Due to Patient Preference
* `L5` - Replacement Due to Medical Reason
## 277CA code lists [#277ca-code-lists]
You may need to refer to the following code lists while evaluating the 277CA claim acknowledgment.
### Claim Status Category Code [#claim-status-category-code]
A claim's status is reported using a category code, which is returned in multiple locations within the 277CA. For each instance, Stedi returns two properties:
* `healthCareClaimStatusCategoryCode`: The code, such as `A1`, `P2`, or `F1`.
* `healthCareClaimStatusCategoryCodeValue`: The description associated with that code.
These values indicate the status of a claim or encounter.
* `A0` - Acknowledgement/Forwarded - The claim/encounter has been forwarded to another entity.
* `A1` - Acknowledgement/Receipt - The claim/encounter has been received. This does not mean that the claim has been accepted for adjudication.
* `A2` - Acknowledgement/Acceptance into adjudication system - The claim/encounter has been accepted into the adjudication system.
* `A3` - Acknowledgement/Returned as unprocessable claim - The claim/encounter has been rejected and has not been entered into the adjudication system.
* `A4` - Acknowledgement/Not Found - The claim/encounter can not be found in the adjudication system.
* `A5` - Acknowledgement/Split Claim - The claim/encounter has been split upon acceptance into the adjudication system.
* `A6` - Acknowledgement/Rejected for Missing Information - The claim/encounter is missing the information specified in the Status details and has been rejected.
* `A7` - Acknowledgement/Rejected for Invalid Information - The claim/encounter has invalid information as specified in the Status details and has been rejected.
* `A8` - Acknowledgement/Rejected for relational field in error.
* `DR01` - Acknowledgement/Receipt - The claim/encounter has been received. This does not mean the claim has been accepted into the data reporting/processing system.
* `DR02` - Acknowledgement/Acceptance into the data reporting/processing system - The claim/encounter has been accepted into the data reporting/processing system.
* `DR03` - Acknowledgement/Returned as unprocessable claim - The claim/encounter has been rejected and has not been entered into the data reporting/processing system.
* `DR04` - Acknowledgement/Not Found - The claim/encounter can not be found in the data reporting/processing system.
* `DR05` - Acknowledgement/Rejected for Missing Information - The claim/encounter is missing the information specified in the Status details and has been rejected.
* `DR06` - Acknowledgment/Rejected for invalid information - The claim/encounter has invalid information as specified in the Status details and has been rejected.
* `DR07` - Acknowledgement/Rejected for relational field in error.
* `DR08` - Acknowledgement/Warning - The claim/encounter has been accepted into the data reporting/processing system but has received a warning as specified in the Status details.
* `P0` - Pending: Adjudication/Details - This is a generic message about a pended claim. A pended claim is one for which no remittance advice has been issued,or only part of the claim has been paid.
* `P1` - Pending/In Process - The claim or encounter is in the adjudication system.
* `P2` - Pending/Payer Review - The claim/encounter is suspended and is pending review (e.g. medical review,repricing,Third Party Administrator processing).
* `P3` - Pending/Provider Requested Information - The claim or encounter is waiting for information that has already been requested from the provider.
* `P4` - Pending/Patient Requested Information - The claim or encounter is waiting for information that has already been requested from the patient.
* `P5` - Pending/Payer Administrative/System hold
* `F0` - Finalized - The claim/encounter has completed the adjudication cycle and no more action will be taken.
* `F1` - Finalized/Payment - The claim/line has been paid.
* `F2` - Finalized/Denial - The claim/line has been denied.
* `F3` - Finalized/Revised - Adjudication information has been changed
* `F3F` - Finalized/Forwarded - The claim/encounter processing has been completed. Any applicable payment has been made and the claim/encounter has been forwarded to a subsequent entity as identified on the original claim or in this payer's records.
* `F3N` - Finalized/Not Forwarded - The claim/encounter processing has been completed. Any applicable payment has been made. The claim/encounter has NOT been forwarded to any subsequent entity identified on the original claim.
* `F4` - Finalized/Adjudication Complete - No payment forthcoming - The claim/encounter has been adjudicated and no further payment is forthcoming.
* `R0` - Requests for additional Information/General Requests - Requests that don't fall into other R - type categories.
* `R1` - Requests for additional Information/Entity Requests - Requests for information about specific entities (subscribers,patients,various providers).
* `R3` - Requests for additional Information/Claim/Line - Requests for information that could normally be submitted on a claim.
* `R4` - Requests for additional Information/Documentation - Requests for additional supporting documentation. Examples: certification,x - ray,notes.
* `R5` - Request for additional information/more specific detail - Additional information as a follow up to a previous request is needed. The original information was received but is inadequate. More specific/detailed information is requested.
* `R6` - Requests for additional information – Regulatory requirements
* `R7` - Requests for additional information – Confirm care is consistent with Health Plan policy coverage
* `R8` - Requests for additional information – Confirm care is consistent with health plan coverage exceptions
* `R9` - Requests for additional information – Determination of medical necessity
* `R10` - Requests for additional information – Support a filed grievance or appeal
* `R11` - Requests for additional information – Pre - payment review of claims
* `R12` - Requests for additional information – Clarification or justification of use for specified procedure code
* `R13` - Requests for additional information – Original documents submitted are not readable. Used only for subsequent request(s).
* `R14` - Requests for additional information – Original documents received are not what was requested. Used only for subsequent request(s).
* `R15` - Requests for additional information – Workers Compensation coverage determination.
* `R16` - Requests for additional information – Eligibility determination
* `R17` - Replacement of a Prior Request. Used to indicate that the current attachment request replaces a prior attachment request.
* `E0` - Response not possible - error on submitted request data
* `E1` - Response not possible - System Status
* `E2` - Information Holder is not responding; resubmit at a later time.
* `E3` - Correction required - relational fields in error.
* `E4` - Trading partner agreement specific requirement not met: Data correction required.
* `D0` - Data Search Unsuccessful - The payer is unable to return status on the requested claim(s) based on the submitted search criteria.
## ERA code lists [#era-code-lists]
You may need to refer to the following code lists while evaluating the 835 Electronic Remittance Advice (ERA).
### Claim Adjustment Group Code [#claim-adjustment-group-code]
This code is returned in the [`transactions[].detailInfo[].paymentInfo[].claimAdjustments[].claimAdjustmentGroupCode`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.claimAdjustments.claimAdjustmentGroupCode) property. It categorizes the adjustment reason codes returned in `claimAdjustments` array items.
* `CO` - Contractual Obligations | The payer uses this code when a joint payer/payee contractual agreement or a regulatory requirement resulted in an adjustment. An example of a contractual obligation might be a Participating Provider Agreement.
* `OA` - Other adjustments | The payer uses this code when the adjustment doesn't fall within the other categories.
* `PI` - Payor Initiated Reductions | The payer uses this code when, in their opinion, the adjustment is not the responsibility of the patient, but there is no supporting contract between the provider and the payer (i.e., medical review or professional review organization adjustments).
* `PR` - Patient Responsibility | The payer uses this code when the adjustment amount is the responsibility of the patient.
### Claim Adjustment Reason Code (CARC) [#claim-adjustment-reason-code-carc]
This code is returned in the following properties:
* [`transactions[].detailInfo[].paymentInfo[].claimAdjustments[].adjustmentReasonCode`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.claimAdjustments.adjustmentReasonCode1) (1-6)
* [`transactions[].detailInfo[].paymentInfo[].serviceLines[].serviceAdjustments[].adjustmentReasonCode`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.serviceLines.serviceAdjustments.adjustmentReasonCode1) (1-6)
CARCs identify the reason for an adjustment. Visit [Claim Adjustment Reason Codes](https://x12.org/codes/claim-adjustment-reason-codes) in the X12 documentation for a complete list.
### Claim Filing Indicator Code [#claim-filing-indicator-code]
This code is returned in the [`transactions[].detailInfo[].paymentInfo[].claimPaymentInfo.claimFilingIndicatorCode`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.claimPaymentInfo.claimFilingIndicatorCode) property. It identifies the type of claim submitted.
* `12` - Preferred Provider Organization (PPO) | This code is also used for Blue Cross/Blue Shield participating provider arrangements.
* `13` - Point of Service (POS)
* `14` - Exclusive Provider Organization (EPO)
* `15` - Indemnity Insurance | This code is also used for Blue Cross/Blue Shield non-participating provider arrangements.
* `16` - Health Maintenance Organization (HMO) Medicare Risk
* `17` - Dental Maintenance Organization
* `AM` - Automobile Medical
* `CH` - Champus
* `DS` - Disability
* `HM` - Health Maintenance Organization
* `LM` - Liability Medical
* `MA` - Medicare Part A
* `MB` - Medicare Part B
* `MC` - Medicaid
* `OF` - Other Federal Program | This code is used for the Black Lung Program.
* `TV` - Title V
* `VA` - Veterans Affairs Plan
* `WC` - Workers' Compensation Health Claim
* `ZZ` - Mutually Defined
### Claim Status Code [#claim-status-code]
This code is returned in the [`transactions[].detailInfo[].paymentInfo[].claimPaymentInfo.claimStatusCode`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.claimPaymentInfo.claimStatusCode) property. It identifies the status of an entire claim as assigned by the payer, claim review organization, or repricing organization.
Codes `19`, `20`, and `21` indicate that the claim is a [crossover claim](/healthcare/receive-claim-responses#crossover-claims) that has been forwarded to an additional payer for processing. This practice is common in coordination of benefits (COB) scenarios. You may need to enroll the provider with the additional payer before they can process the claim.
* `1` - Processed as Primary | The payer uses this code when the claim was adjudicated by the current payer as primary regardless of whether any part of the claim was paid.
* `2` - Processed as Secondary | The payer uses this code when the claim was adjudicated by the current payer as secondary regardless of whether any part of the claim was paid.
* `3` - Processed as Tertiary | The payer uses this code when the claim was adjudicated by the current payer as tertiary (or subsequent) regardless of whether any part of the claim was paid.
* `4` - Denied | The payer uses this code when the Patient/Subscriber is not recognized, and the claim was not forwarded to another payer.
* `19` - Processed as Primary, Forwarded to Additional Payer(s)
* `20` - Processed as Secondary, Forwarded to Additional Payer(s)
* `21` - Processed as Tertiary, Forwarded to Additional Payer(s)
* `22` - Reversal of Previous Payment
* `23` - Not Our Claim, Forwarded to Additional Payer(s) | The payer sends this code when the patient/subscriber is not recognized or the claim was not adjudicated by the payer, but other payers are known and the claim has been forwarded to another payer.
* `25` - Predetermination Pricing Only - No Payment
### Credit or Debit Flag Code [#credit-or-debit-flag-code]
This code is returned in the [`transactions[].financialInformation.creditOrDebitFlagCode` property](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.financialInformation.creditOrDebitFlagCode). It indicates whether the payment is a credit or a debit.
* `C` - Credit | The payer uses this code to indicate a credit to the provider's account and a debit to the payer's account, initiated by the payer. In the case of an EFT, no additional action is required of the provider. The payer also uses this code when a check is issued for the payment.
* `D` - Debit | The payer uses this code to indicate a debit to the payer's account and a credit to the provider's account, initiated by the provider at the instruction of the payer.
### Payment Method Code [#payment-method-code]
This code is returned in the [`transactions[].financialInformation.paymentMethodCode` property](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.financialInformation.paymentMethodCode). It identifies the payment format. Note that the remaining properties in the `financialInformation` object contain additional requirements and information about the payment.
* `ACH` - Automated Clearing House (ACH) | The payer uses this code to move money electronically through the ACH, or to notify the provider that an ACH transfer was requested.
* `BOP` - Financial Institution Option | The payer uses this code to indicate that the third-party processor will choose the method of payment based upon endpoint requests or capabilities.
* `CHK` - Check | The payer uses this code to indicate that a check has been issued for payment.
* `FWT` - Federal Reserve Funds/Wire Transfer - Nonrepetitive | The payer uses this code to indicate that the funds were sent through the wire system.
* `NON` - Non-Payment Data | The payer uses this code when the `transactions.financialInformation.transactionHandlingCode` is `H`, indicating that this is information only and no dollars are to be moved.
### Provider Adjustment Reason Code [#provider-adjustment-reason-code]
This code is returned in the [`transactions[].providerAdjustments[].adjustments[].adjustmentReasonCode` property](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.providerAdjustments.adjustments.adjustmentReasonCode). It identifies the reason for an adjustment made to the provider's account outside of the claim-level and service-line-level adjustments. The valid codes for X12 release 5010, which Stedi uses for ERAs, differ from the Provider Adjustment Reason Codes list on the X12 website. Use the following code list for ERAs you receive through Stedi.
* `50` - Late Charge | This is the Late Claim Filing Penalty or Medicare Late Cost Report Penalty
* `51` - Interest Penalty Charge | This is the interest assessment for late filing.
* `72` - Authorized Return | This is the provider refund adjustment. This adjustment acknowledges a refund received from a provider for previous overpayment. The payer should provide an identifying number in the `providerAdjustmentIdentifier` property. The adjustment amount is always a negative value.
* `90` - Early Payment Allowance
* `AH` - Origination Fee | This is the claim transmission fee. This is used for transmission fees that aren't specific to or dependent upon individual claims.
* `AM` - Applied to Borrower's Account | This identifies a loan repayment amount. This is capitation specific.
* `AP` - Acceleration of Benefits | This is the accelerated payment amount or withholding. A positive value for the adjustment represents a withholding. A negative value represents a payment.
* `B2` - Rebate | The provider has remitted an overpayment to the health plan in excess of the amount requested. The excess amount is being returned to the provider. The amount accepted by the health plan is reported using code `72` (Authorized Return) and is offset by the amount with code `WO` (Overpayment Recovery). This code reports the excess amount (represented as a negative adjustment amount) returned to the provider.
* `B3` - Recovery Allowance | This represents the check the payer received from the provider for overpayments from other payers. This is different from the provider refund adjustment represented by code `72` (Authorized Return). This adjustment should always be offset by another adjustment referring to the original refund request or reason.
* `BD` - Bad Debt Adjustment | This is the bad debt passthrough.
* `BN` - Bonus | This is capitation specific.
* `C5` - Temporary Allowance | This is the tentative adjustment.
* `CR` - Capitation Interest | This is capitation specific.
* `CS` - Adjustment
* `CT` - Capitation Payment | This is capitation specific.
* `CV` - Capital Passthru
* `CW` - Certified Registered Nurse Anesthetist Passthru
* `DM` - Direct Medical Education Passthru
* `E3` - Withholding
* `FB` - Forwarding Balance | This is the balance forward. A negative adjustment value represents a balance moving forward to a future ERA. A positive value represents a balance being applied from a previous ERA. The payer should provide a reference number for tracking purposes in the `providerAdjustmentIdentifier` property.
* `FC` - Fund Allocation | This is capitation specific.
* `GO` - Graduate Medical Education Passthru
* `HM` - Hemophilia Clotting Factor Supplement
* `IP` - Inceptive Premium Payment | This is capitation specific.
* `IR` - Internal Revenue Service Withholding
* `IS` - Interim Settlement | This is the interim rate lump sum adjustment.
* `J1` - Nonreimbursable | This offsets the claim or service level data that reflects what could be paid if not for demonstration program or other limitation that prevents issuance of payment.
* `L3` - Penalty | This is the capitation-related penalty. Withholding or release is identified by the sign of the adjustment amount.
* `L6` - Interest Owed | This is the interest paid on claims in this ERA.
* `LE` - Levy | IRS levy.
* `LS` - Lump Sum | This is the disproportionate share adjustment, indirect medical education passthrough, non-physician passthrough, passthrough lump sum adjustment, or other passthrough amount. The payer should identify the specific type of lump sum adjustment in the `providerAdjustmentIdentifier` property.
* `OA` - Organ Acquisition Passthru
* `OB` - Offset for Affiliated Providers | The payer should identify the affiliated providers in the `providerAdjustmentIdentifier` property.
* `PI` - Periodic Interim Payment | This is the periodic interim lump sum payments and reductions (PIP). The payments are made to a provider at the beginning of some period in advance of claims. These payments are advances on the expected claims for the period. The reductions are the recovery of actual claims payments during the period. For example, when a provider has a PIP payment, claims within this ERA covered by that payment are offset using this code to remove the claim payment from the current check. The sign of the adjustment amount determines whether this is a payment (negative) or reduction (positive). This payment and recoupment is effectively a loan to the provider and loan repayment.
* `PL` - Payment Final | This is the final settlement.
* `RA` - Retro-activity Adjustment | This is capitation specific.
* `RE` - Return on Equity
* `SL` - Student Loan Repayment
* `TL` - Third Party Liability | This is capitation specific.
* `WO` - Overpayment Recovery | This is the recovery of previous overpayment. The payer should provide an identifying number in the `providerAdjustmentIdentifier` property.
* `WU` - Unspecified Recovery | Medicare is currently using this code to represent penalty collections withheld for the IRS (an outside source).
### Remittance Advice Remark Code (RARC) [#remittance-advice-remark-code-rarc]
This code is returned in the following properties:
* [`transactions[].detailInfo[].paymentInfo[].inpatientAdjudication.claimPaymentRemarkCode`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.inpatientAdjudication.claimPaymentRemarkCode1) (1-6)
* [`transactions[].detailInfo[].paymentInfo[].outpatientAdjudication.claimPaymentRemarkCode`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.outpatientAdjudication.claimPaymentRemarkCode1) (1-6)
* [`transactions[].detailInfo[].paymentInfo[].serviceLines[].healthCareCheckRemarkCodes[].remarkCode`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.serviceLines.healthCareCheckRemarkCodes.remarkCode) - this property can either be a RARC or a National Council for Prescription Drug Programs Reject/Payment Code
RARCs provide additional explanation for an adjustment already described by a Claim Adjustment Reason Code (CARC) or convey information about remittance processing.
Visit [Remittance Advice Remark Codes](https://x12.org/codes/remittance-advice-remark-codes) in the X12 documentation for a complete list.
### Transaction Handling Code [#transaction-handling-code]
This code is returned in the [`transactions[].financialInformation.transactionHandlingCode`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.financialInformation.transactionHandlingCode) property. It indicates the actions taken by both the sender and the receiver.
* `C` - Payment Accompanies Remittance Advice | The payer uses this code to instruct the third-party processor to move funds and remittance details together through the banking system.
* `D` - Make Payment Only | The payer uses this code to instruct the third-party processor to move only funds through the banking system and to ignore any remittance information.
* `H` - Notification Only | The payer uses this code when the actual provider payment (listed in the `transactions.financialInformation.totalActualProviderPaymentAmount` property) is zero, and the transaction is not being used for Prenotification of Future Transfers. This indicates remittance information without any associated payment.
* `I` - Remittance Information Only | The payer uses this code to indicate to the payee that the remittance detail is moving separately from the payment.
* `P` - Prenotification of Future Transfers | This code is used only by the payer and the banking system to initially validate account numbers before beginning an EFT relationship.
* `U` - Split Payment and Remittance | The payer uses this code to instruct the third-party processor to split the payment and remittance details and send each on a separate path.
* `X` - Handling Party's Option to Split Payment and Remittance | The payer uses this code to instruct the third-party processor to move the payment and remittance detail, together or separately, based upon endpoint requests or capabilities.
## Claim status code lists [#claim-status-code-lists]
You may need to reference the following code lists when working with the 276/277 claim status request or response.
### Claim status [#claim-status]
Used in the [`claims[].claimStatus.statusCode`](/healthcare/api-reference/post-healthcare-claim-status#response.claims.claimStatus.statusCode) property. This is the status code used to identify the status of an entire claim or a service line. For example, code `20` means `Accepted for Processing`.
This is either a Health Care Claim Status Code or a National Council for Prescription Drug Programs (NCPDP) Reject/Payment Code, when the status is related to pharmacy claims.
* Visit [Claim Status Codes](https://x12.org/codes/claim-status-codes) in the official X12 documentation for a complete list of Health Care Claim Status Codes.
* Visit the [National Council for Prescription Drug Programs website](https://www.ncpdp.org/) for access to the Reject/Payment Code list.
### Claim status category [#claim-status-category]
A code that provides more detail about the claim status. For example, code `F1` means `Finalized/Revised - Adjudication information has been changed`.
It's returned in the following properties:
* [`claims[].claimStatus.statusCategoryCode`](https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-claim-status#response.claims.claimStatus.statusCategoryCode)
* [`claims[].serviceDetails[].status[].statusCategoryCode`](/healthcare/api-reference/post-healthcare-claim-status#response.claims.serviceDetails.status.statusCategoryCode)
Visit [Claim Status Category Codes](https://x12.org/codes/claim-status-category-codes) in the official X12 documentation for a complete list.
### Entity identifier [#entity-identifier]
A code identifying the organizational entity, physical location, property, or individual associated with the `claims.claimStatus.statusCode`. For example, code `1G` means `Oncology Center`.
It's returned in the following properties:
* [`claims[].claimStatus.entityCode`](/healthcare/api-reference/post-healthcare-claim-status#response.claims.claimStatus.entityCode)
* [`claims[].serviceDetails[].status[].entityCode`](/healthcare/api-reference/post-healthcare-claim-status#response.claims.serviceDetails.status.entityCode)
- `1E` - Health Maintenance Organization (HMO)
- `1G` - Oncology Center
- `1H` - Kidney Dialysis Unit
- `1I` - Preferred Provider Organization (PPO)
- `1O` - Acute Care Hospital
- `1P` - Provider
- `1Q` - Military Facility
- `1R` - University, College or School
- `1S` - Outpatient Surgicenter
- `1T` - Physician, Clinic or Group Practice
- `1U` - Long Term Care Facility
- `1V` - Extended Care Facility
- `1W` - Psychiatric Health Facility
- `1X` - Laboratory
- `1Y` - Retail Pharmacy
- `1Z` - Home Health Care
- `2A` - Federal, State, County or City Facility
- `2B` - Third-Party Administrator
- `2D` - Miscellaneous Health Care Facility
- `2E` - Non-Health Care Miscellaneous Facility
- `2I` - Church Operated Facility
- `2K` - Partnership
- `2P` - Public Health Service Facility
- `2Q` - Veterans Administration Facility
- `2S` - Public Health Service Indian Service Facility
- `2Z` - Hospital Unit of an Institution (prison hospital, college infirmary, etc.)
- `03` - Dependent
- `3A` - Hospital Unit Within an Institution for the Mentally Retarded
- `3C` - Tuberculosis and Other Respiratory Diseases Facility
- `3D` - Obstetrics and Gynecology Facility
- `3E` - Eye, Ear, Nose and Throat Facility
- `3F` - Rehabilitation Facility
- `3G` - Orthopedic Facility
- `3H` - Chronic Disease Facility
- `3I` - Other Specialty Facility
- `3J` - Children's General Facility
- `3K` - Children's Hospital Unit of an Institution
- `3L` - Children's Psychiatric Facility
- `3M` - Children's Tuberculosis and Other Respiratory Diseases Facility
- `3N` - Children's Eye, Ear, Nose and Throat Facility
- `3O` - Children's Rehabilitation Facility
- `3P` - Children's Orthopedic Facility
- `3Q` - Children's Chronic Disease Facility
- `3R` - Children's Other Specialty Facility
- `3S` - Institution for Mental Retardation
- `3T` - Alcoholism and Other Chemical Dependency Facility
- `3U` - General Inpatient Care for AIDS/ARC Facility
- `3V` - AIDS/ARC Unit
- `3W` - Specialized Outpatient Program for AIDS/ARC
- `3X` - Alcohol/Drug Abuse or Dependency Inpatient Unit
- `3Y` - Alcohol/Drug Abuse or Dependency Outpatient Services
- `3Z` - Arthritis Treatment Center
- `4A` - Birthing Room/LDRP Room
- `4B` - Burn Care Unit
- `4C` - Cardiac Catherization Laboratory
- `4D` - Open-Heart Surgery Facility
- `4E` - Cardiac Intensive Care Unit
- `4F` - Angioplasty Facility
- `4G` - Chronic Obstructive Pulmonary Disease Service Facility
- `4H` - Emergency Department
- `4I` - Trauma Center (Certified)
- `4J` - Extracorporeal Shock-Wave Lithotripter (ESWL) Unit
- `4L` - Genetic Counseling/Screening Services
- `4M` - Adult Day Care Program Facility
- `4N` - Alzheimer's Diagnostic/Assessment Services
- `4O` - Comprehensive Geriatric Assessment Facility
- `4P` - Emergency Response (Geriatric) Unit
- `4Q` - Geriatric Acute Care Unit
- `4R` - Geriatric Clinics
- `4S` - Respite Care Facility
- `4U` - Patient Education Unit
- `4V` - Community Health Promotion Facility
- `4W` - Worksite Health Promotion Facility
- `4X` - Hemodialysis Facility
- `4Y` - Home Health Services
- `4Z` - Hospice
- `5A` - Medical Surgical or Other Intensive Care Unit
- `5B` - Histopathology Laboratory
- `5C` - Blood Bank
- `5D` - Neonatal Intensive Care Unit
- `5E` - Obstetrics Unit
- `5F` - Occupational Health Services
- `5G` - Organized Outpatient Services
- `5H` - Pediatric Acute Inpatient Unit
- `5I` - Psychiatric Child/Adolescent Services
- `5J` - Psychiatric Consultation-Liaison Services
- `5K` - Psychiatric Education Services
- `5L` - Psychiatric Emergency Services
- `5M` - Psychiatric Geriatric Services
- `5N` - Psychiatric Inpatient Unit
- `5O` - Psychiatric Outpatient Services
- `5P` - Psychiatric Partial Hospitalization Program
- `5Q` - Megavoltage Radiation Therapy Unit
- `5R` - Radioactive Implants Unit
- `5S` - Therapeutic Radioisotope Facility
- `5T` - X-Ray Radiation Therapy Unit
- `5U` - CT Scanner Unit
- `5V` - Diagnostic Radioisotope Facility
- `5W` - Magnetic Resonance Imaging (MRI) Facility
- `5X` - Ultrasound Unit
- `5Y` - Rehabilitation Inpatient Unit
- `5Z` - Rehabilitation Outpatient Services
- `6A` - Reproductive Health Services
- `6B` - Skilled Nursing or Other Long-Term Care Unit
- `6C` - Single Photon Emission Computerized Tomography (SPECT) Unit
- `6D` - Organized Social Work Service Facility
- `6E` - Outpatient Social Work Services
- `6F` - Emergency Department Social Work Services
- `6G` - Sports Medicine Clinic/Services
- `6H` - Hospital Auxiliary Unit
- `6I` - Patient Representative Services
- `6J` - Volunteer Services Department
- `6K` - Outpatient Surgery Services
- `6L` - Organ/Tissue Transplant Unit
- `6M` - Orthopedic Surgery Facility
- `6N` - Occupational Therapy Services
- `6O` - Physical Therapy Services
- `6P` - Recreational Therapy Services
- `6Q` - Respiratory Therapy Services
- `6R` - Speech Therapy Services
- `6S` - Women's Health Center/Services
- `6U` - Cardiac Rehabilitation Program Facility
- `6V` - Non-Invasive Cardiac Assessment Services
- `6W` - Emergency Medical Technician
- `6X` - Disciplinary Contact
- `6Y` - Case Manager
- `7C` - Place of Occurrence
- `13` - Contracted Service Provider
- `17` - Consultant's Office
- `28` - Subcontractor
- `30` - Service Supplier
- `36` - Employer
- `40` - Receiver
- `43` - Claimant Authorized Representative
- `44` - Data Processing Service Bureau
- `61` - Performed At
- `71` - Attending Physician
- `72` - Operating Physician
- `73` - Other Physician
- `74` - Corrected Insured
- `77` - Service Location
- `80` - Hospital
- `82` - Rendering Provider
- `84` - Subscriber's Employer
- `85` - Billing Provider
- `87` - Pay-to Provider
- `95` - Research Institute
- `CK` - Pharmacist
- `CZ` - Admitting Surgeon
- `D2` - Commercial Insurer
- `DD` - Assistant Surgeon
- `DJ` - Consulting Physician
- `DK` - Ordering Physician
- `DN` - Referring Provider
- `DO` - Dependent Name
- `DQ` - Supervising Physician
- `E1` - Person or Other Entity Legally Responsible for a Child
- `E2` - Person or Other Entity With Whom a Child Resides
- `E7` - Previous Employer
- `E9` - Participating Laboratory
- `FA` - Facility
- `FD` - Physical Address
- `FE` - Mail Address
- `G0` - Dependent Insured
- `G3` - Clinic
- `GB` - Other Insured
- `GD` - Guardian
- `GI` - Paramedic
- `GJ` - Paramedical Company
- `GK` - Previous Insured
- `GM` - Spouse Insured
- `GY` - Treatment Facility
- `HF` - Healthcare Professional Shortage Area (HPSA) Facility
- `HH` - Home Health Agency
- `I3` - Independent Physicians Association (IPA)
- `IJ` - Injection Point
- `IL` - Insured or Subscriber
- `IN` - Insurer
- `LI` - Independent Lab
- `LR` - Legal Representative
- `MR` - Medical Insurance Carrier
- `MSC` - Mammography Screening Center
- `OB` - Ordered By
- `OD` - Doctor of Optometry
- `OX` - Oxygen Therapy Facility
- `P0` - Patient Facility
- `P2` - Primary Insured or Subscriber
- `P3` - Primary Care Provider
- `P4` - Prior Insurance Carrier
- `P6` - Third Party Reviewing Preferred Provider Organization (PPO)
- `P7` - Third Party Repricing Preferred Provider Organization (PPO)
- `PRP` - Primary Payer
- `PT` - Party to Receive Test Report
- `PV` - Party performing certification
- `PW` - Pickup Address
- `QA` - Pharmacy
- `QB` - Purchase Service Provider
- `QC` - Patient
- `QD` - Responsible Party
- `QE` - Policyholder
- `QH` - Physician
- `QK` - Managed Care
- `QL` - Chiropractor
- `QN` - Dentist
- `QO` - Doctor of Osteopathy
- `QS` - Podiatrist
- `QV` - Group Practice
- `QY` - Medical Doctor
- `RC` - Receiving Location
- `RW` - Rural Health Clinic
- `S4` - Skilled Nursing Facility
- `SEP` - Secondary Payer
- `SJ` - Service Provider
- `SU` - Supplier/Manufacturer
- `T4` - Transfer Point | Used to identify the geographic location where a patient is transferred or diverted.
- `TL` - Testing Laboratory
- `TQ` - Third Party Reviewing Organization (TPO)
- `TT` - Transfer To
- `TTP` - Tertiary Payer
- `TU` - Third Party Repricing Organization (TPO)
- `UH` - Nursing Home
- `X3` - Utilization Management Organization
- `X4` - Spouse
- `X5` - Durable Medical Equipment Supplier
- `ZZ` - Mutually Defined
### Product or service ID qualifier [#product-or-service-id-qualifier]
Used in the [`serviceLineInformation.productOrServiceIDQualifier`](/healthcare/api-reference/post-healthcare-claim-status#body.serviceLineInformation.productOrServiceIDQualifier) request property and returned in the [`claims[].serviceDetails[].service.serviceIdQualifierCode`](/healthcare/api-reference/post-healthcare-claim-status#response.claims.serviceDetails.service.serviceIdQualifierCode) response property.
It identifies the source of the associated procedure code.
| Code | Description | Usage Notes |
| ---- | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `AD` | American Dental Association Codes | - |
| `ER` | Jurisdiction Specific Procedure and Supply Codes | This code is not allowed for use under HIPAA. The qualifier can only be used when 1) If a new rule names the Jurisdiction Specific Procedure and Supply Codes as an allowable code set under HIPAA, OR 2) The Secretary grants an exception to use the code set as a pilot project as allowed under the law, OR 3) For claims that aren't covered under HIPAA. |
| `HC` | Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes | Because the CPT codes of the American Medical Association are also level 1 HCPCS codes, the CPT codes are reported under the code HC. |
| `HP` | Health Insurance Prospective Payment System (HIPPS) Skilled Nursing Facility Rate Code | - |
| `IV` | Home Infusion EDI Coalition (HIEC) Product/Service Code | This code is not allowed for use under HIPAA. The qualifier can only be used when 1) If a new rule names the Home Infusion EDI Coalition Codes as an allowable code set under HIPAA, OR 2) The Secretary grants an exception to use the code set as a pilot project as allowed under the law, OR 3) For claims that aren't covered under HIPAA. |
| `N4` | National Drug Code in 5-4-2 Format | - |
| `NU` | National Uniform Billing Committee (NUBC) UB92 Codes | This code is the NUBC Revenue Code. |
| `WK` | Advanced Billing Concepts (ABC) Codes | This code set has been approved by the Secretary of HHS as a pilot project allowed under HIPAA law. The qualifier may only be used in transactions covered under HIPAA; by parties registered in the pilot project and their trading partners, OR when a new rule names the Complementary, Alternative, or Holistic Procedure Codes as an allowable code set under HIPAA, OR for claims that aren't covered under HIPAA. |
# Overview
Source: https://www.stedi.com/docs/healthcare/claims-processing-workflows-overview
You can use Stedi to automate your claims processing workflow from claim submission through payment. Once you integrate with Stedi, you can monitor claim submissions and responses in the Stedi portal.
## Claims processing workflow [#claims-processing-workflow]
Here's an overview of the claims processing steps you can automate with Stedi.
### Transaction enrollment [#transaction-enrollment]
[Transaction enrollment](/healthcare/transaction-enrollment) is the process of registering a provider to exchange specific healthcare transactions with a payer. It's **always** required for 835 Electronic Remittance Advice (ERAs) and sometimes required for other transaction types, depending on the payer.
You'll submit transaction enrollment requests through either the [Enrollments API](/healthcare/api-reference/post-enrollment-create-enrollment) or the Stedi portal. Once submitted, Stedi handles the entire process for you, including sending the required information to the payer and monitoring each enrollment's status.
### Submit claims and attachments [#submit-claims-and-attachments]
You can submit [837P professional](/healthcare/submit-professional-claims), [837D dental](/healthcare/submit-dental-claims), [837I institutional](/healthcare/submit-institutional-claims), [workers' compensation](/healthcare/submit-workers-comp-auto-liability-claims), and [automobile](/healthcare/submit-workers-comp-auto-liability-claims) claims through the following methods:
* [Clearinghouse APIs](/healthcare/api-reference/post-healthcare-claims) in either JSON or X12 EDI format.
* [SFTP](/healthcare/submit-claims-sftp-connection) in X12 EDI format.
* [Stedi portal](https://portal.stedi.com/app/healthcare/transactions) in either X12 EDI format (all claim types) or through our CMS-1500 form (professional claims).
Before sending claims to the payer, Stedi checks them against our growing library of [claim edits](/healthcare/claim-edits-and-repairs) to identify errors that could lead to rejections or denials. Our APIs return edit rejections in real time, so you can fix and resubmit claims immediately.
You can also submit [unsolicited 275 claim attachments](/healthcare/submit-claim-attachments) as needed to support claims, such as medical records and treatment plans. You can submit attachments through Stedi APIs, SFTP, or the Stedi portal.
### Retrieve 277CA claim acknowledgments [#retrieve-277ca-claim-acknowledgments]
You'll likely receive multiple [277CA claim acknowledgments](/healthcare/claim-responses-overview#277ca-claim-acknowledgment) for each claim as it moves through Stedi and the payer's systems. A 277CA indicates whether a claim was accepted or rejected at a particular processing stage.
* **APIs:** You can [poll](/healthcare/receive-claim-responses#poll-for-transactions) or set up [webhooks](/healthcare/receive-claim-responses#listen-for-webhooks) to discover new 277CAs. Then, you can [retrieve 277CAs](/healthcare/receive-claim-responses#retrieve-responses-from-stedi) through Stedi APIs in either JSON or X12 EDI format.
* **SFTP:** You can [retrieve 277CA files](/healthcare/submit-claims-sftp-connection#retrieve-claim-responses) from the `from-stedi` directory.
* **Stedi portal:** You can review the 277CAs for submitted claims from the [claims view](/healthcare/claims-view).
### Resubmit rejected claims [#resubmit-rejected-claims]
When you receive a 277CA indicating a claim was rejected, you'll need to review the rejection reason, fix the errors in the claim data, and [resubmit the claim](/healthcare/resubmit-cancel-claims). Common rejection reasons include invalid or missing data, incorrect patient or provider details, incorrect billing codes or modifiers, and missing attachments.
You can resubmit claims through Stedi APIs, SFTP, or the Stedi portal.
### Run real-time claim status checks [#run-real-time-claim-status-checks]
Once a claim has been accepted into the payer's adjudication system, you can run [real-time claim status checks](/healthcare/check-claim-status) to get the current status of the claim.
You can submit real-time claim status requests through Stedi APIs in either JSON or X12 EDI format. You can also submit them manually through the Stedi portal as needed.
### Retrieve 835 Electronic Remittance Advice (ERAs) [#retrieve-835-electronic-remittance-advice-eras]
When the payer has finished adjudicating a claim, they'll send back an [835 Electronic Remittance Advice (ERA)](/healthcare/claim-responses-overview#835-electronic-remittance-advice-era) with details about payments for specific services and explanations for any adjustments or denials.
* **APIs:** You can either [poll](/healthcare/receive-claim-responses#poll-for-transactions) or set up [webhooks](/healthcare/receive-claim-responses#listen-for-webhooks) to discover new 835 ERAs. Then, you can [retrieve 835 ERAs](/healthcare/receive-claim-responses#retrieve-responses-from-stedi) through Stedi APIs in either JSON or X12 EDI format.
* **SFTP:** You can [retrieve 835 ERA files](/healthcare/submit-claims-sftp-connection#retrieve-claim-responses) from the `from-stedi` directory.
## Example API implementation [#example-api-implementation]
To build a professional claims workflow using Stedi JSON APIs, you would typically follow these steps:
1. Submit required transaction enrollment requests through the [Providers](/healthcare/api-reference/post-enrollment-create-provider) and [Enrollments](/healthcare/api-reference/post-enrollment-create-enrollment) APIs.
2. Configure [webhooks](/healthcare/configure-webhooks) to listen for events indicating Stedi has processed new 277CA claim acknowledgments and 835 Electronic Remittance Advice (ERAs).
3. Call the [Professional Claims JSON endpoint](/healthcare/api-reference/post-healthcare-claims) to submit claims in JSON format.
4. Call the [277CA Report endpoint](/healthcare/api-reference/get-healthcare-reports-277) to retrieve processed 277CAs from Stedi in JSON format.
5. Evaluate 277CAs. If the claim was rejected, fix the errors and resubmit through the [Professional Claims JSON endpoint](/healthcare/api-reference/post-healthcare-claims).
6. Call the [835 Report endpoint](/healthcare/api-reference/get-healthcare-reports-835) to retrieve 835 ERAs from Stedi in JSON format.
You may also call the [Real-Time Claim Status JSON endpoint](/healthcare/api-reference/post-healthcare-claim-status) as needed to check on claims that have entered the payer's adjudication system.
## Claims view [#claims-view]
The [claims view](/healthcare/claims-view) in the Stedi portal provides insight into your claims processing pipeline. In the claims view, you can:
* Review every claim you submit through Stedi and the details of related claim transactions, such as 277CA claim acknowledgments.
* Review a clear timeline of activity for each claim, including resubmissions and responses you receive from Stedi and the payer.
* Understand a claim's current status within the processing pipeline, such as whether the claim has been accepted or rejected.
* Filter submitted claims by key details, such as processed date, status, patient name, and service date(s).
# Claims view
Source: https://www.stedi.com/docs/healthcare/claims-view
The [claims view](https://portal.stedi.com/app/healthcare/claims) in the Stedi portal provides insight into your claims processing pipeline. In the claims view, you can:
* Review every claim you submit through Stedi and the details of related claim transactions, such as 277CA claim acknowledgments.
* Review a clear timeline of activity for each claim, including resubmissions and responses you receive from Stedi and the payer.
* Understand a claim's current [status](#claim-processing-status) within the processing pipeline, such as whether the claim has been accepted or rejected.
* Filter submitted claims by key details, such as processed date, status, patient name, and service date(s).
## Filter claims [#filter-claims]
On the [claims view](https://portal.stedi.com/app/healthcare/claims), you can filter all of the claims you've submitted through Stedi. Available filters include:
* **Processed date:** When Stedi received each claim.
* **Status:** Where a claim is in the processing pipeline. Refer to [claim processing status](#claim-processing-status) for details on how we determine a claim's status and how to know if action is required to move the claim forward.
* **Type:** Claim type - professional, dental, or institutional.
* **Patient control number:** The patient control number for the claim, sometimes referred to as the claim ID. You submitted this value in:
* CMS-1500 claim form: Box 26 (Patient's Account No.)
* JSON: `claimInformation.patientControlNumber`
* X12 EDI: `Loop 2300` (Claim Information) `CLM01` (Patient Control Number)
* **Patient name:** The patient's first or last name. Partial matching is supported.
* **Member ID:** The subscriber's member ID for their health plan.
* **Payer:** Payer name, ID, or alias. Refer to the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list for each payer.
* **Billing provider NPI:** The billing provider's NPI.
* **Billing Provider TIN:** The billing provider's TIN.
* **Total charges:** Claims with a minimum or maximum charge amount.
* **Service date:** Claims with specific service dates.
Toggle **Test mode** to **ON** to review test claims you've submitted.
## Claim timeline [#claim-timeline]
From the claims view, click any claim to review a timeline of its processing activity, including when the claim was submitted and when you received 277CA claim acknowledgments from Stedi and the payer.
The timeline view also includes resubmissions for the claim and any associated 277CAs resulting from those resubmissions.
835 Electronic Remittance Advice (ERAs) and real-time claim status requests aren't currently included in the timeline. You can review 835 ERAs for adjudicated claims from the [transactions view](https://portal.stedi.com/app/healthcare/transactions) in the Stedi portal.
## Transaction details [#transaction-details]
From a claim's timeline view, hover over a transaction and click **See more detail** to review a user-friendly summary of key information, such as patient information, service dates, and service line details. You'll also be able to review the raw X12 EDI for the transaction.
## Resubmit or cancel claims [#resubmit-or-cancel-claims]
You can resubmit or cancel claims from within the claims view. Visit [Preparing claim resubmissions or cancellations](/healthcare/resubmit-cancel-claims#preparing-claim-resubmissions-or-cancellations) for detailed instructions, including how to choose the right Claim Frequency Code.
### CMS-1500 form (professional) [#cms-1500-form-professional]
Stedi's CMS-1500 claim form UI is mostly limited to the CMS-1500 form fields. It may not be able to successfully resubmit complex claims originally submitted through our APIs or SFTP.
To resubmit a professional claim through Stedi's interactive CMS-1500 form:
1. Go to the [claims view](https://portal.stedi.com/app/healthcare/claims) and click the claim you want to resubmit to open its timeline.
2. Click **See more detail** above the claim submission to review its details page.
3. Click **Edit and resubmit** and select **CMS-1500 resubmission**. Stedi opens the interactive CMS-1500 form prepopulated with the claim's information.
4. Make any necessary changes to the claim.
* Make sure to update the Claim Frequency Code, the Payer Claim Control Number, and the Patient Control Number according to best practices.
* Click **Claims timeline** to open a side panel with the claim's activity. You can review related 277CA claim acknowledgments containing the errors you need to address before resubmitting. Hover over a transaction and click **See more detail** to review its details.
5. Click **Submit claim** to resubmit the updated claim to the payer.
The updated claim will appear on the [claims view](https://portal.stedi.com/app/healthcare/claims) within a few minutes. The claim timeline will reflect that this claim is a resubmission along with the original claim and any associated responses.
You'll receive new 277CA claim acknowledgments indicating whether the resubmitted claim was accepted or rejected.
### X12 EDI editor [#x12-edi-editor]
To resubmit a professional, dental, or institutional claim through Stedi's X12 EDI editor:
1. Go to the [claims view](https://portal.stedi.com/app/healthcare/claims) and click the claim you want to resubmit to open its timeline.
2. Click **See more detail** above the claim submission to review its details page.
3. Click **Edit and resubmit** and select **X12 transaction resubmission**. Stedi opens the claim in an interactive editor with the X12 EDI on the left and the EDI specification on the right.
As you hover over different parts of the EDI, Stedi highlights the corresponding part of the specification on the right to help you understand what each part of the EDI means and how to edit it correctly.
4. Make changes to the claim EDI.
* You can type directly in the EDI editor or copy and paste updated EDI from another source.
* Make sure to update the Claim Frequency Code, the Payer Claim Control Number, and the Patient Control Number according to best practices.
* Click **Claims timeline** to open a side panel with the claim's activity. You can review related 277CA claim acknowledgments containing the errors you need to address before resubmitting. Hover over a transaction and click **See more detail** to review its details.
5. Click **Review and submit**. Stedi shows a comparison of the original claim and the new claim containing your changes.
6. Click **Resubmit claim** to send the updated claim to the payer.
The updated claim will appear on the [claims view](https://portal.stedi.com/app/healthcare/claims) within a few minutes. The claim timeline will reflect that this claim is a resubmission along with the original claim and any associated responses.
You'll receive new 277CA claim acknowledgments indicating whether the resubmitted claim was accepted or rejected.
## Claim processing status [#claim-processing-status]
The claims view displays each claim's current processing status. These statuses are designed to help you quickly understand whether action is required to move claims forward.
Stedi's claim processing statuses are different from the status codes you receive in 277CAs and in real-time claim status checks:
* **277CAs:** Each 277CA contains one or more status category codes that indicate receipt, acceptance or rejection at a *specific stage* of processing. Stedi evaluates all available 277CAs to determine the claim's current *overall* processing status.
* **Real-time claim status checks:** Claim status checks can only provide status information about claims that have been accepted into the payer's adjudication system. Stedi's statuses provide insight both before and after the claim reaches the payer.
Stedi currently doesn't use information from real-time claim status checks or 835 ERAs to determine claim status. That means Stedi's statuses won't indicate when claims have been adjudicated or paid. You'll need to monitor for 835 ERAs independently.
### Stedi claim status codes [#stedi-claim-status-codes]
A claim in the Stedi portal can have one of the following processing statuses:
| status | description | What to do |
| --------- | --------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Submitted | You submitted the claim to Stedi but haven't yet received a 277CA response from Stedi or the payer. | No action needed. Monitor for the next 277CA claim acknowledgment with acceptance or rejection status. |
| Received | The clearinghouse or payer has acknowledged receipt of the claim. This doesn't mean the claim has been accepted for adjudication. | No action needed. Monitor for the next 277CA claim acknowledgment with acceptance or rejection status. |
| Rejected | Either Stedi or the payer rejected the claim. This can happen even when the payer has acknowledged receipt. | Review the 277CA claim acknowledgment for error details, correct the claim, and resubmit. |
| Accepted | The payer has accepted the claim into their adjudication system and it's currently being processed or adjudicated. | No action needed. Monitor for the next 277CA claim acknowledgment or the 835 ERA with adjudication details. |
| Invalid | The 277CA contains unsupported or invalid status codes. | Review the 277CA claim acknowledgment for details. If the 277CA is from Stedi, contact Stedi support. If the 277CA is from the payer, contact the payer for clarification. |
#### Received vs. Accepted [#received-vs-accepted]
Many payers send two 277CAs:
* An initial 277CA with `STC01-01` (Health Care Claim Status Category Code) set to `A1` (Acknowledgment/Receipt). Stedi sets the claim status to **Received**.
* A second 277CA with `STC01-01` set to an explicit Accepted or Rejected code. Stedi then updates the claim status to **Accepted** or **Rejected** accordingly.
However, some payers don't send 277CAs with explicit Accepted codes. In these cases, the claims view keeps the claim in **Received** status.
If a claim has been in **Received** status longer than expected, you can run a [claim status check](/healthcare/check-claim-status) to determine its processing status with the payer. You can also contact Stedi support with questions about behavior for particular payers.
### How we determine status [#how-we-determine-status]
Once you submit a claim, you'll receive several [277CA claim acknowledgments](/healthcare/claim-responses-overview#277ca-claim-acknowledgment) from the clearinghouse and the payer that indicate receipt, acceptance, or rejection at various stages of processing.
Stedi uses the information in the 277CAs to determine the current status of a claim.
#### Step 1: Classify each 277CA [#step-1-classify-each-277ca]
We assign each 277CA transaction a submission status based on the `STC01-1` (Health Care Claim Status Category Code) status category codes present in the transaction. [Full code list](https://x12.org/codes/claim-status-category-codes)
When there are multiple codes present within a 277CA, we evaluate codes in the following priority order:
1. Rejected
2. Accepted
3. Received
4. Invalid (unrecognized STC codes)
For example, if a 277CA contains both rejected and received status category codes, we classify the 277CA as rejected.
#### Step 2: Decide which 277CA reflects the claim's status [#step-2-decide-which-277ca-reflects-the-claims-status]
Each claim can receive multiple 277CAs from Stedi and the payer as it moves through the processing pipeline. Once we evaluate the status of all existing 277CAs for a claim, we apply the following rules to determine which 277CA reflects the claim's overall status:
1. **Current submission:** We focus on the 277CAs tied to the most-recent 837 submission. If there are no 277CAs for the most recent submission, the claim's status is set to **Submitted**.
2. **Terminal outcomes:** We prioritize by Rejected --> Accepted --> Received. For example, if any 277CA from Stedi or the payer has a rejected status, we use the 277CA rejection to set the claim status, even if there are other 277CAs with accepted codes. This helps ensure you don't miss required actions to correct and resubmit a rejected claim.
3. **Payer > Clearinghouse:** We prioritize 277CAs from the payer over 277CAs from Stedi or intermediaries. For example, if a claim has a Stedi 277CA with received status codes and a payer 277CA with received status codes, we use the payer's 277CA to set the overall claim status to **Received**.
4. **Recency:** We use recency as a final tiebreaker to ensure deterministic results. If a claim has multiple 277CAs from the same source with the same status category codes, we first check the effective date listed in the EDI transaction and use the most recent one. If those are the same, we'll use the 277CA that most recently entered Stedi's system.
Note that at this time, we **only** use 277CAs to determine claim status. We don't incorporate information from real-time claim status responses or 835 Electronic Remittance Advice (ERAs). For example, if a claim has been paid, that won't be reflected in Stedi's claim processing statuses - you'll need to monitor for the 835 ERA independently.
#### Examples [#examples]
The following scenarios illustrate how we use the above rules to determine a claim's status when there are multiple 277CAs.
**Scenario 1**
You submit a claim to Stedi and receive the following 277CAs:
| Source | Status classification | Effective date |
| ------ | --------------------- | -------------- |
| Stedi | Received | 2026-01-01 |
| Payer | Accepted | 2026-01-02 |
The claim's status would be set to **Accepted** based on the accepted status category codes in the payer's 277CA.
**Scenario 2**
You submit a claim to Stedi and receive the following 277CAs:
| Source | Status classification | Effective date |
| ------ | --------------------- | -------------- |
| Payer | Rejected | 2026-01-01 |
| Payer | Received | 2026-01-02 |
This scenario can happen when a payer sends responses out-of-order due to network delays, outage recovery, retries, or batch processes. In this case, the claim's status would be set to **Rejected** because we prioritize terminal statuses over the timing of the responses.
# CMS-1500 Claim Form PDF
Source: https://www.stedi.com/docs/healthcare/cms-1500-claim-form-pdf
Stedi automatically generates a [CMS-1500 Claim Form](https://www.nucc.org/index.php/1500-claim-form-mainmenu-35) PDF for each professional claim you submit.
We strongly recommend reviewing the following behavior and recommendations if you plan to send these PDFs to payers or retain them for your records.
## Retrieve PDFs [#retrieve-pdfs]
You can manually download generated any claim's generated CMS-1500 PDF from the transaction details page for the claim in Stedi.
You can also retrieve PDFs through either of the following endpoints:
* [CMS-1500 PDF: Business Identifier](/healthcare/api-reference/get-pdf-1500-business-identifier): Retrieve PDFs through a claim's business identifier. You can find the business identifier value in the `claimReference.correlationId` property Stedi returns in the synchronous claim submission response.
* [CMS-1500 PDF: Transaction ID](/healthcare/api-reference/get-pdf-1500): Retrieve PDFs through the `transactionId` Stedi assigns to the processed claim. This ID is included in the transaction processed event for the claim, which you can receive automatically through [webhooks](/healthcare/configure-webhooks). You can also retrieve this ID from the transaction's details page in Stedi.
Both endpoints return a base64 encoded string of the PDF. To render the PDF, you must decode the base64 string and save it to a file with a `.pdf` extension.
## Generation notes [#generation-notes]
Note the following behavior and recommendations to generate optimal CMS-1500 PDFs.
### PDF background [#pdf-background]
You can generate CMS-1500 PDFs with a white background by adding the query parameter `?background=false` when calling the PDF generation endpoints.
The National Uniform Claim Committee (NUCC) and CMS provide exact specifications for blank CMS-1500 forms, including paper size and ink color. Many provider offices are accustomed to using these pre-printed forms, and their Practice Management System (PMS) applications are designed to print claim data onto them. Generating PDFs with a white background allows you to print the claim data directly onto official pre-printed forms.
### The PDF may truncate claim data. [#the-pdf-may-truncate-claim-data]
The maximum length for many fields in the CMS-1500 Claim Form is less than the maximum length for the corresponding properties in the claim request.
**Recommendation:** Ensure that your claim data is within the maximum length for claim form fields. We especially recommend using [USPS abbreviations](https://pe.usps.com/text/pub28/28apc_002.htm) to avoid truncated addresses in the generated PDF.
### The PDF may omit the second line of some addresses. [#the-pdf-may-omit-the-second-line-of-some-addresses]
Some CMS-1500 Claim Form items contain address fields that can only be mapped to a single address line. If you include the `address2` JSON property (X12 EDI `N302`) in your claim submission, that information may not appear in the PDF.
**Recommendation:** Put all street address line data into the `address1` JSON property (X12 EDI `N301`), ensuring that you adhere to the claim form length constraints.
### The PDF won't populate Item 7 when the patient is a dependent. [#the-pdf-wont-populate-item-7-when-the-patient-is-a-dependent]
Stedi validates the claim data you submit to the API and uses it to generate a compliant X12 EDI transaction to send to the payer. The PDF is generated from the final X12 EDI transaction.
The X12 EDI standard specifies that claims should only contain the insured's address when the patient is the subscriber. To maintain compliance, Stedi doesn't include the insured's address information in the generated X12 EDI transaction when the patient is a dependent, even if you provided the subscriber's address in the original API request. Since this address information isn't present in final X12 EDI claim, it's also not added to Item 7 (Insured's Address) in the generated PDF.
### Payer address (Carrier Block) [#payer-address-carrier-block]
You can populate the payer's address on the PDF by providing the `payerAddress` object in your claim submission API request. Include the payer's address details that you want to appear on the form.
### Standard form size [#standard-form-size]
The generated PDFs use the standard 8.5" x 11" format.
## Edit PDFs [#edit-pdfs]
Single-page PDFs are editable so you can make any necessary adjustments before printing and sending them to payers. You can use any PDF editor to make changes to the generated CMS-1500 PDF.
## Print PDFs [#print-pdfs]
Note the following behavior and recommendations when printing CMS-1500 PDFs.
* We recommend generating PDFs with a white background (no red form overlay) if you plan to print them on pre-printed claim forms.
* The form boxes and labels **must** be printed in red ink and the item values **must** be printed in black ink for the claim form to be read by a scanner. Your vendor may choose not to process claim forms that don't conform to these specifications.
* Set the **Page Size & Handling** option to **Actual size** or the equivalent in your PDF reader application. The **Fit** option may cause the contents to be scaled down to fit within the printable area, causing the form fields to be misaligned when printed.
* Don't print forms from the Apple Preview app built in to macOS. There appear to be problems with field alignment and fonts. Instead, we recommend using either Adobe Acrobat or Google Chrome.
### Printer models [#printer-models]
We generally recommend using business laser printers to print CMS-1500 PDFs. However, due to mechanical variations between printer models, we can't guarantee that the generated PDFs will align perfectly with pre-printed forms. You should always test the alignment with your printer before using the generated PDFs for official submissions.
You may not get acceptable results when using inkjet printer models because the file contents can extend beyond the normal printable area. If you do plan to use an inkjet printer, don't enable a **borderless** option because this may cause the printer (or printer driver) to slightly magnify the page image regardless of other print settings. This behavior can crop form edges and cause form fields to appear in the wrong positions. Some inkjet printers have a manual setting to change the extension amount, but this isn't always available and may not give consistent results.
# Interpret COB response
Source: https://www.stedi.com/docs/healthcare/cob-response
The coordination of benefits (COB) response includes information about the patient's active health plans, subscriber information, and coordination of benefits.
Unlike standard eligibility checks, the COB response shape is standardized across all supported payers. There are no payer-specific variations in what information is included or how the response is structured.
COB check results may be partial or negative and may fail to include some or all of a patient's health plans. Results depend on whether the patient's payers contribute to the COB database.
## COB status [#cob-status]
The `coordinationOfBenefits` object contains status information about whether a COB instance exists and whether Stedi was able to determine the primary payer.
{/* schema:COB:unwrap */}
```json
"coordinationOfBenefits": {
"classification": "CobInstanceExistsPrimacyDetermined",
"instanceExists": true,
"primacyDetermined": true,
"coverageOverlap": true,
"benefitOverlap": true
}
```
A COB check response can have one of the following statuses, indicated by the `coordinationOfBenefits.classification` property.
{/* prettier-ignore-start */}
| status | Description |
| -------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `MemberFoundNoCob` | The patient has coverage with the payer you checked, but Stedi didn't find any other health plans with overlapping coverage. Note that Stedi can only report information for other COB-supported health plans from our payer list. For example, if the individual has coverage from Cigna and Medicare, a COB check to Cigna will state that no COB was detected, since Medicare is not a supported payer. You can find a complete list of supported payers for COB checks in the [Payer Network](https://www.stedi.com/healthcare/network?query=eyIyNzAiOnt9LCIyNzYiOnt9LCI4MzUiOnt9LCI4MzdQIjp7fSwiODM3SSI6e30sIjgzN0QiOnt9LCJDT0IiOnsiaXNTdXBwb3J0ZWQiOnRydWV9fQ%3D%3D\&page=0). |
| `CoverageOverlapNoBenefitOverlap` | The patient has overlapping coverage with at least one other health plan, but there is no benefit overlap between the plans. Coordination of benefits is not required. |
| `CoverageOverlapExistsNotSubjectToCob` | The patient has overlapping coverage with at least one other health plan, but coordination of benefits is not required. |
| `CobInstanceExistsPrimacyUndetermined` | The patient has overlapping coverage with at least one other health plan and coordination of benefits is required. However, Stedi could not determine the primary payer. We recommend contacting the patient's health plans for further guidance. |
| `CobInstanceExistsPrimacyDetermined` | The patient has overlapping coverage with at least one other health plan, and Stedi was able to identify the primary payer. |
{/* prettier-ignore-end */}
## Payer primacy [#payer-primacy]
The response includes a `benefitsInformation` object with `code` = `R` when Stedi finds overlapping coverage with another health plan.
The `benefitsInformation[].benefitsRelatedEntities` array contains information about the other payer, and the `entityIdentifier` property indicates the payer's primacy for payment on claims when this information is available. It can be set to:
* `Payer`: Stedi didn't find a COB instance or could not determine primacy.
* `Primary Payer`: This payer is the primary payer for the service type.
* `Secondary Payer`: This payer is the secondary payer for the service type.
* `Tertiary Payer`: This payer is the tertiary payer for the service type.
In the following example, the patient has overlapping coverage for medical care services with Cigna, the primary payer for medical care services.
{/* schema:COBBenefitsInformation */}
```json
{
"code": "R",
"name": "Other or Additional Payor",
"serviceTypeCodes": ["1"],
"serviceTypes": ["Medical Care"],
"benefitsDateInformation": {
"coordinationOfBenefits": "2024-07-01"
},
"benefitsRelatedEntities": [
{
"entityIdentifier": "Primary Payer",
"entityName": "CIGNA",
"entityIdentification": "PI",
"entityIdentificationValue": "1006"
},
{
"entityIdentifier": "Insured or Subscriber",
"entityFirstname": "JOHN",
"entityMiddlename": "X",
"entityIdentification": "MI",
"entityIdentificationValue": "00000000000",
"entityLastname": "DOE"
}
],
"subscriber": {
"dateOfBirth": "2002-12-31"
}
}
```
When Stedi can't reliably determine primacy, you should contact the patient's health plans directly for further guidance.
### Primacy rules [#primacy-rules]
Medicare plans aren't supported, so they're not included in the primacy
determination process. However, many Medicare Advantage plans are supported
and will be included in primacy determination.
Our COB service follows the guidelines set by the [National Association of Insurance Commissioners (NAIC)](https://content.naic.org/) to determine payer primacy. You may also want to refer to these guidelines when submitting claims.
#### Plan responsibilities [#plan-responsibilities]
In almost all cases, the **primary** plan pays benefits first as if no other plan exists. The one exception to this policy is when the patient has both an HMO (closed network plan) and a PPO (open network plan). When the HMO is the primary plan and the PPO is secondary, the PPO will pay first when the patient uses out-of-network providers unless it's an emergency or an authorized referral covered by the HMO.
When multiple policies are treated as a single plan, the primacy determination applies to the entire plan. The plans must coordinate amongst themselves according to their contracts. If more than one insurance company provides benefits under the plan, the one designated as primary is responsible for complying with coordination of benefits rules.
#### Order of benefits rules [#order-of-benefits-rules]
After the primary plan pays, each subsequent plan pays remaining eligible costs. Each health plan determines their order of benefits using the first of the following rules that apply:
**1. Non-Dependent vs. Dependent vs. Medicare**
* A plan covering the patient as an employee, subscriber, or retiree is primary over a plan that covers them as a dependent.
* If the patient also has Medicare, special rules apply:
* Medicare is secondary to a plan covering the person as a dependent.
* Medicare is primary to a plan covering the person as an employee (from an employer with more than 20 employees), subscriber, or retiree.
* If the patient has all three plan types, the order of primacy is: Medicare, then the plan covering the person as a dependent, and then any other plans.
**2. Dependent child with multiple plans**
Note that the following rules are the same regardless of whether the subscribers of the multiple plans are the child's parents or other significant individuals in their life (not their parents).
* If the two subscribers are married or living together: The subscriber with the birthday that occurs first in the calendar year has the primary plan. If both subscribers have the same birthday, the plan that has covered the child the longest is primary.
* If the dependent child's coverage under the spouse's plan began on the same date as their coverage under either or both parents' plans, the order of benefits will be determined using the birthday rule.
* If the two subscribers are divorced, separated, or not living together, a court order typically decides which plan is primary. Otherwise:
* The plan of the custodial parent is primary.
* The plan of the spouse of the custodial parent is secondary.
* The plan of the non-custodial parent is tertiary.
* The plan of the spouse of the non-custodial parent is last.
* If a dependent child has coverage under either or both parents' plans and is also covered as a dependent under a spouse's plan, apply rule 5 - Length of coverage.
**3. Active vs. retired employees**
Coverage from a current employer (active employee) is primary to retired or laid-off employee plans.
**4. COBRA vs. state continuation coverage**
Employer-based plans are primary to COBRA coverage.
**5. Length of coverage**
If other rules don’t decide, the plan covering the person for the longest time is primary.
**6. Final rule (If no other rules apply)**
If no clear primary plan is determined, costs are split equally between the plans.
# Sample response interpretation [#sample-response-interpretation]
The following example COB response shows information for a dependent who is covered by multiple health plans through their parents' policies. The COB check was submitted to Aetna with a service type code of `30` and a date of service of `2024-11-27`.
The response indicates the following:
* **Active coverage:** The patient has active coverage with Aetna for medical care services, pharmacy services, and vision services. This is indicated by the three objects in the `benefitsInformation` array with the `code` set to `1`.
* **Coverage overlap:** The patient has overlapping coverage for medical care services between two health plans. This is indicated by the `benefitsInformation` object with the `code` set to `R`.
* **Primacy:** The other health plan is Cigna, listed in `benefitsInformation[].benefitsRelatedEntities`. Cigna is the primary payer for medical care services. Note that the ID returned in this property is proprietary to our COB check product, so you can't use it as the Payer ID for eligibility checks or other API requests to Stedi. It likely doesn't match the Payer IDs listed in the [Payer Network](https://www.stedi.com/healthcare/network).
* **COB instance:** There is a COB instance for medical care services on the date of service provided in the request. This is indicated in the `coordinationOfBenefits` object.
Based on this response, you must send claims first to Cigna as the primary payer for medical care services. Once Cigna adjudicates the claim, you can send another one, if necessary, to Aetna as the secondary payer (subject to specific payer claims processing rules).
Before sending claims we'd also recommend sending a separate eligibility check to Aetna to verify coverage status.
{/* schema:CoordinationOfBenefitsResponseContent */}
```json
{
"benefitsInformation": [
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": ["1"],
"serviceTypes": ["Medical Care"],
"benefitsDateInformation": {
"benefitBegin": "2023-03-01"
},
"subscriber": {
"dateOfBirth": "2002-02-27"
}
},
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": ["88"],
"serviceTypes": ["Pharmacy"],
"benefitsDateInformation": {
"benefitBegin": "2023-03-01"
},
"subscriber": {
"dateOfBirth": "2002-02-27"
}
},
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": ["AL"],
"serviceTypes": ["Vision (Optometry)"],
"benefitsDateInformation": {
"benefitBegin": "2023-03-01"
},
"subscriber": {
"dateOfBirth": "2002-02-27"
}
},
{
"code": "R",
"name": "Other or Additional Payor",
"serviceTypeCodes": ["1"],
"serviceTypes": ["Medical Care"],
"benefitsDateInformation": {
"coordinationOfBenefits": "2024-07-01"
},
"benefitsRelatedEntities": [
{
"entityIdentifier": "Primary Payer",
"entityName": "CIGNA",
"entityIdentification": "PI",
"entityIdentificationValue": "1006"
},
{
"entityIdentifier": "Insured or Subscriber",
"entityFirstname": "JOHN",
"entityMiddlename": "X",
"entityIdentification": "MI",
"entityIdentificationValue": "00000000000",
"entityLastname": "DOE"
}
],
"subscriber": {
"dateOfBirth": "2002-12-31"
}
}
],
"coordinationOfBenefits": {
"classification": "CobInstanceExistsPrimacyDetermined",
"instanceExists": true,
"primacyDetermined": true,
"coverageOverlap": true,
"benefitOverlap": true
},
"dependent": {
"firstName": "JORDAN",
"lastName": "DOE",
"gender": "M",
"dateOfBirth": "2002-12-31",
"relationToSubscriber": "Child",
"relationToSubscriberCode": "19",
"address": {
"address1": "1 MAIN ST.",
"city": "NEW YORK",
"state": "NY",
"postalCode": "10000"
}
},
"errors": [],
"meta": {
"applicationMode": "production",
"traceId": "01JDQFT4W3KTWZNTADEZ55BFFX",
"outboundTraceId": "01JDQFT4W3KTWZNTADEZ55BFFX"
},
"payer": {
"name": "Aetna",
"payerIdentification": "AETNA-USH"
},
"provider": {
"providerOrgName": "AETNA-USH",
"npi": "1999999984"
},
"subscriber": {
"memberId": "W000000000",
"firstName": "JOHN",
"lastName": "DOE",
"address": {
"address1": "1 MAIN ST.",
"city": "NEW YORK",
"state": "NY",
"postalCode": "10000"
}
}
}
```
## Request and response examples [#request-and-response-examples]
The following examples show request and response data for common COB scenarios.
### COB exists, primacy determined [#cob-exists-primacy-determined]
In the following example, the COB check was submitted to Cigna with a service type code of `30` and a date of service of `2024-12-19`.
The response indicates that the patient has active coverage with Cigna for medical care services, and that there is overlapping coverage with Kaiser Foundation Health Plan of Massachusetts. COB is required for medical care services, and Kaiser is the primary payer.
{/* schema:CoordinationOfBenefitsRequestContent */}
```bash
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/coordination-of-benefits \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--data '{
"test": false,
"tradingPartnerServiceId": "62308",
"provider": {
"organizationName": "PPROVIDER",
"npi": "1999999984"
},
"subscriber": {
"memberId": "X999999999",
"firstName": "Goofy",
"lastName": "Goof",
"dateOfBirth": "1948-11-01"
},
"encounter": {
"dateOfService": "2024-12-19",
"serviceTypeCode": "30"
}
}'
```
{/* schema:CoordinationOfBenefitsResponseContent */}
```json
{
"benefitsInformation": [
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": ["1"],
"serviceTypes": ["Medical Care"],
"benefitsDateInformation": {
"benefitBegin": "2024-01-01"
},
"subscriber": {
"dateOfBirth": "1948-11-01"
}
},
{
"code": "R",
"name": "Other or Additional Payor",
"serviceTypeCodes": ["1"],
"serviceTypes": ["Medical Care"],
"benefitsDateInformation": {
"coordinationOfBenefits": "2024-01-01"
},
"benefitsRelatedEntities": [
{
"entityIdentifier": "Primary Payer",
"entityName": "KAISER FOUNDATION HEALTH PLAN OF MAS",
"entityIdentification": "PI",
"entityIdentificationValue": "1009"
},
{
"entityIdentifier": "Insured or Subscriber",
"entityFirstname": "GOOFY",
"entityMiddlename": "X",
"entityIdentification": "MI",
"entityIdentificationValue": "999999999",
"entityLastname": "GOOF"
}
],
"subscriber": {
"dateOfBirth": "1948-11-01"
}
}
],
"coordinationOfBenefits": {
"classification": "CobInstanceExistsPrimacyDetermined",
"instanceExists": true,
"primacyDetermined": true,
"coverageOverlap": true,
"benefitOverlap": true
},
"dependent": {
"firstName": "GOOFY",
"lastName": "GOOF",
"gender": "M",
"dateOfBirth": "1948-11-01",
"relationToSubscriber": "Spouse",
"relationToSubscriberCode": "01",
"address": {
"address1": "3 DISNEY RD",
"city": "ORLANDO",
"state": "FL",
"postalCode": "32801"
}
},
"errors": [],
"meta": {
"applicationMode": "production",
"traceId": "01JJQRFYSXPKNYQ96EVM7XDXC4",
"outboundTraceId": "01JJQRFYSXPKNYQ96EVM7XDXC4"
},
"payer": {
"name": "CIGNA",
"payerIdentification": "CIGNA-HCIN"
},
"provider": {
"providerOrgName": "PROVIDER",
"npi": "1999999984"
},
"subscriber": {
"memberId": "X99999999",
"firstName": "MRS",
"lastName": "GOOF",
"groupNumber": "12345678",
"address": {
"address1": "3 DISNEY RD",
"city": "ORLANDO",
"state": "FL",
"postalCode": "32801"
}
}
}
```
### Coverage overlap, no benefit overlap [#coverage-overlap-no-benefit-overlap]
In the following example, the COB check was submitted to Cigna with a service type code of `30` and a date of service of `2025-01-01`.
The response indicates that the patient has active coverage with Cigna for medical care services, and that there is overlapping coverage with Aetna for dental care services. There is no benefit overlap between the two health plans because dental and medical benefits have two different service type codes. COB is not required.
{/* schema:CoordinationOfBenefitsRequestContent */}
```bash
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/coordination-of-benefits \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--data '{
"test": false,
"tradingPartnerServiceId": "62308",
"provider": {
"organizationName": "PROVIDER",
"npi": "1999999984"
},
"subscriber": {
"memberId": "X999999999",
"firstName": "MICKEY",
"lastName": "MOUSE",
"dateOfBirth": "1928-11-28"
},
"encounter": {
"dateOfService": "2025-01-01",
"serviceTypeCode": "30"
}
}'
```
```json
{
"benefitsInformation": [
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": ["1"],
"serviceTypes": ["Medical Care"],
"benefitsDateInformation": {
"benefitBegin": "2024-10-03"
},
"subscriber": {
"dateOfBirth": "1925-11-28"
},
"dependent": {
"firstName": "MICKEY",
"lastName": "MOUSE",
"memberId": "X999999999",
"dateOfBirth": "1928-11-28",
"familySeqNum": "0003",
"relationToSubscriber": "Spouse",
"relationToSubscriberCode": "01"
}
},
{
"code": "R",
"name": "Other or Additional Payor",
"serviceTypeCodes": ["35"],
"serviceTypes": ["Dental Care"],
"benefitsDateInformation": {
"periodStart": "2024-10-03"
},
"benefitsRelatedEntities": [
{
"entityIdentifier": "Payer",
"entityName": "AETNA",
"entityIdentification": "PI",
"entityIdentificationValue": "1000"
},
{
"entityIdentifier": "Insured or Subscriber",
"entityFirstname": "MINNIE",
"entityMiddlename": "X",
"entityIdentification": "MI",
"entityIdentificationValue": "X999999999",
"entityLastname": "MOUSE"
}
],
"subscriber": {
"dateOfBirth": "1925-11-28"
},
"dependent": {
"firstName": "MICKEY",
"lastName": "MOUSE",
"memberId": "X999999999",
"dateOfBirth": "1928-11-28",
"familySeqNum": "0003",
"relationToSubscriber": "Spouse",
"relationToSubscriberCode": "01"
}
}
],
"coordinationOfBenefits": {
"classification": "CoverageOverlapNoBenefitOverlap",
"instanceExists": true,
"coverageOverlap": true,
"benefitOverlap": false,
"primacyDetermined": false
},
"dependent": {
"firstName": "MICKEY",
"lastName": "MOUSE",
"gender": "M",
"dateOfBirth": "1928-11-28",
"relationToSubscriber": "Spouse",
"relationToSubscriberCode": "01",
"address": {
"address1": "3 DISNEY RD",
"city": "ORLANDO",
"state": "FL",
"postalCode": "32801"
}
},
"errors": [],
"meta": {
"applicationMode": "production",
"traceId": "01JJVW6QJWXESXYAAAE4H996HR",
"outboundTraceId": "01JJVW6QJWXESXYAAAE4H996HR"
},
"payer": {
"name": "CIGNA",
"payerIdentification": "CIGNA-HCIN"
},
"provider": {
"providerOrgName": "PROVIDER",
"npi": "1999999984"
},
"subscriber": {
"memberId": "X99999999",
"firstName": "MINNIE",
"lastName": "MOUSE",
"middleName": "X",
"groupNumber": "3340181",
"address": {
"address1": "3 DISNEY RD",
"city": "ORLANDO",
"state": "FL",
"postalCode": "32801"
}
}
}
```
### Member found, no COB [#member-found-no-cob]
In the following example, the COB check was submitted to UnitedHealthcare with a service type code of `30` and a date of service of `2023-01-10`.
The response indicates that the patient has active coverage with UnitedHealthcare for medical care services, but there is no overlapping coverage with any other health plan.
{/* schema:CoordinationOfBenefitsRequestContent */}
```bash
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/coordination-of-benefits \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--data '{
"test": false,
"tradingPartnerServiceId": "87726",
"provider": {
"organizationName": "PROVIDER",
"npi": "1999999984"
},
"subscriber": {
"memberId": "999999999",
"firstName": "Donald",
"lastName": "Duck",
"dateOfBirth": "1960-01-01"
},
"dependent": {
"firstName": "Huey",
"lastName": "Duck",
"dateOfBirth": "1990-01-01"
},
"encounter": {
"dateOfService": "2023-01-10",
"serviceTypeCode": "30"
}
}'
```
{/* schema:CoordinationOfBenefitsResponseContent */}
```json
{
"benefitsInformation": [
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": ["1"],
"serviceTypes": ["Medical Care"],
"benefitsDateInformation": {
"benefitBegin": "2024-01-01"
}
}
],
"coordinationOfBenefits": {
"classification": "MemberFoundNoCob",
"instanceExists": false,
"coverageOverlap": false,
"benefitOverlap": false,
"primacyDetermined": false
},
"dependent": {
"firstName": "HUEY",
"lastName": "DUCK",
"middleName": "M",
"gender": "F",
"dateOfBirth": "1990-01-01",
"relationToSubscriber": "Child",
"relationToSubscriberCode": "19",
"address": {
"address1": "25 THE ROAD",
"city": "READING",
"state": "MA",
"postalCode": "01867"
}
},
"errors": [],
"meta": {
"applicationMode": "production",
"traceId": "09JJSWD8RBGZMVCCYGQZS3P1F7",
"outboundTraceId": "09JJSWD8RBGZMVCCYGQZS3P1F7"
},
"payer": {
"name": "UnitedHealthcare",
"payerIdentification": "UHC"
},
"provider": {
"providerOrgName": "PROVIDER",
"npi": "1999999984"
},
"subscriber": {
"memberId": "999999999",
"firstName": "DONALD",
"lastName": "DUCK",
"middleName": "X",
"address": {
"address1": "25 THE ROAD",
"city": "READING",
"state": "MA",
"postalCode": "01867"
}
}
}
```
## Follow up with eligibility checks [#follow-up-with-eligibility-checks]
Our COB data is updated weekly, and the response doesn't contain complete details about the patient's coverage with each health plan.
When Stedi finds overlapping coverage, we strongly recommend conducting follow-up [eligibility checks](/healthcare/send-eligibility-checks) with each payer to verify coverage status and retrieve the patient's complete, up-to-date benefits information.
# COB troubleshooting
Source: https://www.stedi.com/docs/healthcare/cob-troubleshooting
A list of potential errors and possible resolutions when submitting coordination of benefits (COB) checks.
## Inaccurate patient data [#inaccurate-patient-data]
COB checks are significantly more sensitive to data accuracy than eligibility checks. To perform successful COB checks, the patient information you provide in the check **must** match the payer's data exactly.
For example, if a payer has a patient's name stored as "Jonathan Doe", they may return benefits information when you submit an eligibility check for "Jon Doe", as long as they can identify the patient through the other information provided. However, a COB request for "Jon Doe" will fail because the name doesn't match the payer's records exactly.
To avoid unnecessary COB check failures, we strongly recommend that you first submit an eligibility check request for the patient. Then use the following data from the successful eligibility response to build the COB request: `firstName`, `lastName`, `dateOfBirth`, `memberId`.
## Invalid or unsupported payer ID [#invalid-or-unsupported-payer-id]
COB requests require a valid payer ID in the `tradingPartnerServiceId` property. Visit the Stedi [Payer Network](https://www.stedi.com/healthcare/network?query=eyIyNzAiOnt9LCIyNzYiOnt9LCI4MzUiOnt9LCI4MzdQIjp7fSwiODM3SSI6e30sIjgzN0QiOnt9LCJDT0IiOnsiaXNTdXBwb3J0ZWQiOnRydWV9fQ%3D%3D\&page=0) for a complete list of supported payers and their payer IDs.
You should also ensure that you're sending the request to the correct payer entity. For example, Blue Cross Blue Shield (BCBS) has multiple entities that operate in different states. If you send a request to the wrong entity, the request will fail with an `AAA` = `75` error (Subscriber/Insured Not Found).
## Missing data [#missing-data]
COB requests must contain the patient’s `firstName`, `lastName`, `dateOfBirth`, plus `memberId` and/or `ssn`. If you do not send all data points, Stedi returns an HTTP `400` error with a message listing the missing data.
{/* schema:ValidationExceptionResponseContent */}
```json
{
"fieldList": [
{
"path": "/subscriber/dateOfBirth",
"message": "Value at '/subscriber/dateOfBirth' failed to satisfy constraint: Member must not be null"
}
],
"message": "1 validation error detected. Value at '/subscriber/dateOfBirth' failed to satisfy constraint: Member must not be null"
}
```
## Request found multiple patients [#request-found-multiple-patients]
The `Duplicate Subscriber/Insured ID Number` error can occur when Stedi finds more than one member ID for the patient in the request. For example, this could occur if you only provide the patient's Social Security Number (SSN), and the search returns more than one member ID associated with that SSN.
In this case, Stedi returns a HTTP `200` response with an `AAA` error in the `subscriber` object.
{/* schema:COBResponseSubscriber:unwrap */}
```json
"subscriber": {
"memberId": "123456789",
"firstName": "John",
"lastName": "Doe",
"dateOfBirth": "1961-10-21",
"aaaErrors": [
{
"field": "AAA",
"code": "76",
"description": "Duplicate Subscriber/Insured ID Number",
"followupAction": "Please Correct and Resubmit",
"location": "Loop 2100C",
"possibleResolutions": "Duplicate member ID was found in the payer database."
}
]
}
```
## Member not found [#member-not-found]
If Stedi cannot find a member ID for the patient in the request, it returns an HTTP `200` response with an `AAA` error in the `subscriber` object.
{/* schema:COBResponseSubscriber:unwrap */}
```json
"subscriber": {
"memberId": "123456789",
"firstName": "John",
"lastName": "Doe",
"dateOfBirth": "1961-10-21",
"aaaErrors": [
{
"field": "AAA",
"code": "75",
"description": "Subscriber/Insured Not Found",
"followupAction": "Please Correct and Resubmit",
"location": "Loop 2100C",
"possibleResolutions": "- Subscriber was not found."
}
]
}
```
Mismatches in the `memberId` are one of the most common causes of `Subscriber/Insured Not Found` errors. We strongly recommend first performing an eligibility check and using the `memberId` in the response to populate your COB check.
You will also receive a `Subscriber/Insured Not Found` error if you try to submit a COB check to a Medicare plan. Medicare plans aren't supported for COB checks, though many Medicare Advantage plans are supported.
## Invalid service dates [#invalid-service-dates]
The service dates you provide **must** be within the past 2 years. COB checks don't support requests with dates outside of this range.
Don't send service dates that are in the future. Future service dates typically result in errors from the payer.
## Inactive coverage [#inactive-coverage]
For COB checks to return a positive result, the patient must have active coverage. Sometimes, you can receive a false negative or error on a COB check when a patient's coverage has very recently changed. For example, if the patient recently became eligible for coverage within the last few days, that information may not yet be reflected in the COB member data, and you will receive a `Subscriber/Insured Not Found` error.
Payers typically update COB member data on a weekly basis. If you receive an error and the patient's coverage has recently changed, we recommend trying again next week to give the changes time to propagate to the COB database.
## AAA errors [#aaa-errors]
The COB response may contain one or more `AAA` errors specify issues with your request and any recommended follow-up actions. Stedi includes this information in the `aaaErrors` object in the response JSON.
`AAA` errors can be present at multiple different levels in the response, depending on the type. In the COB response, the `subscriber`, `dependent`, and `provider` objects can each contain their own `aaaErrors` array.
Common causes for AAA errors include:
* Missing or incorrect information for the subscriber, dependent, provider, or payer. In this case, you should correct any errors before resubmitting.
* Issues with payer enrollment. Many of these issues require that the provider contact the payer directly to resolve, due to PHI/HIPAA guidelines.
Each error contains a code field that corresponds to a `followupAction`:
* `C` - Please correct and resubmit
* `N` - Resubmission not allowed | Note that this code doesn't mean you should never resubmit the request. Intermediary clearinghouses may send this code when they have temporarily lost connection to the payer, so this code indicates that you should wait at least a few minutes before retrying instead of retrying immediately.
* `P` - Please resubmit original transaction
* `R` - Resubmission allowed
* `S` - Do not resubmit; Inquire initiated to a third party
* `Y` - Do not resubmit; We will hold your request and respond again shortly
# Configure webhooks
Source: https://www.stedi.com/docs/healthcare/configure-webhooks
You can set up webhooks that automatically send claim processing events to your endpoint.
These events contain the information you need to retrieve 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA) responses through Stedi APIs. They can also help you monitor your claims pipeline when you're submitting claims through [Stedi SFTP](/healthcare/submit-claims-sftp-connection).
You can either create a single webhook that forwards events from all transactions, or create a separate webhook for each transaction type.
Configuring a webhook involves:
* Creating a [credential set](#credential-set) for authentication to the endpoint.
* Creating a [webhook](#webhook) that specifies the URL where Stedi should deliver events.
* Adding one or more [event bindings](#event-bindings) that trigger the webhook.
## Credential set [#credential-set]
A credential set defines how to authenticate with a specific API. You can use a single credential set across multiple webhooks. Stedi supports the following types of configurations.
| Type | Description |
| ---------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| API Keys | The API keys as headers in the request. The most common version is ‘bearer tokens’. |
| Basic Auth | [HTTP Basic Auth](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Authentication), where you provide a username and password. |
| None | For endpoints that don't require any authentication. |
### Unauthenticated endpoints [#unauthenticated-endpoints]
When using the 'None' credential set type in webhooks, it's functionally the same as using 'API Keys'. However, we set a dummy value for `Header name` and `Value` (`x-stedi-noauth` and `dummy`). Since the receiving API isn't authenticating the call, it will ignore these values and accept the request.
### Create credential set [#create-credential-set]
You can define a credential set as part of configuring a new webhook. You can also create a new credential set independently and then attach it to one or more webhooks.
To create a credential set:
1. Go to the [Webhooks](https://portal.stedi.com/app/settings/webhooks) page.
2. Click **Manage credentials**, and then click **Create credential set**.
3. Enter a name.
4. Choose the appropriate **Authentication type**.
5. Enter the details.
6. Click **Create credential set**.
## Webhook [#webhook]
A webhook defines which URL endpoint Stedi should call when the webhook is invoked, and which HTTP method to use (`POST`, `PUT`, `GET`, `PATCH`, `DELETE`).
You can only attach one credential set to each webhook. However, you might have multiple webhooks for a single system integration, each with a different endpoint.
### Create webhook [#create-webhook]
To create a new webhook:
1. Go to the [Webhooks](https://portal.stedi.com/app/settings/webhooks) page.
2. Click **Create webhook**.
3. Enter a name.
4. Choose a **Method** and enter an **Endpoint** URL. This is where Stedi delivers the events when the webhook is invoked.
5. Select a **Credential set** to use for authentication or create a new one for this endpoint.
6. (Optional) Set the **Concurrency**. You can set the maximum number of deliveries that Stedi will attempt to deliver to the endpoint at one time. This can help you avoid overloading the target service.
## Event bindings [#event-bindings]
Event bindings allow you to specify which events trigger the webhook. You can create multiple event bindings for a single webhook. For example, you may want to create an event binding for each type of transaction you want to send to your API.
### Create event binding [#create-event-binding]
To create a new event binding:
1. Go to the [Webhooks](https://portal.stedi.com/app/settings/webhooks) page.
2. Click the webhook.
3. Click the **Event bindings** tab.
4. Click **New event binding**.
5. Choose **Transaction processed** as the **Event type**.
6. (Optional) Set one or more [filters](#event-filters).
7. Click **Create binding**.
### Choosing event types [#choosing-event-types]
The recommended event bindings depend on your use case:
* **API claim submission:** At a minimum, you should create an event binding for transaction processed events because they contain the information you need to retrieve claim responses from Stedi. You may also want to set up event bindings for file delivered and file failed events.
* **SFTP claim submission:** At a minimum, you should create an event binding for file failed events because they're emitted when Stedi is unable to deliver your claim to the payer. You may also want to set up event bindings for file delivered events and transaction processed events.
The file processed and fragment processed events are not relevant to claims
processing.
#### Transaction processed events [#transaction-processed-events]
Stedi emits a transaction processed event after it successfully receives and translates a payer or intermediary clearinghouse response into JSON. It also emits this event once it successfully translates a JSON claim submission into X12 EDI format for the payer. The event payload contains the information you need to retrieve processed responses through Stedi APIs:
* `x12.transactionSetIdentifier` specifies the transaction type (277 or 835).
* `transactionId` allows you to retrieve the transaction in JSON format using either the [277CA Report](/healthcare/api-reference/get-healthcare-reports-277) or [835 ERA Report](/healthcare/api-reference/get-healthcare-reports-835) endpoint.
* `fileExecutionId` allows you to retrieve the transaction in X12 EDI format through the [Retrieve Execution Input](/healthcare/api-reference/get-execution-input) endpoint.
Even if you plan to retrieve claim responses through Stedi SFTP, you may want to monitor these events so you can receive alerts when new claim responses are available.
#### Example transaction processed events for 277CA and 835 ERA [#example-transaction-processed-events-for-277ca-and-835-era]
processed 277CA
processed 835 ERA
```json
{
"event": {
"version": "0",
"id": "f972fb53-653a-1747-ce30-bed15fc04f5c",
"detail-type": "transaction.processed.v2",
"source": "stedi.core",
"account": "",
"time": "2024-07-18T16:21:24Z",
"region": "us-east-1",
"resources": [
"https://core.us.stedi.com/2023-08-01/transactions/f0d3f790-0bc9-432b-93kd-e4b7ece67946"
],
"detail": {
"transactionId": "f0d4f780-0ec9-432b-93gd-e4b7ece93946",
"direction": "INBOUND",
"mode": "test",
"fileExecutionId": "9f76b485-6hca-43bf-917e-d5b54bec6234",
"processedAt": "2024-07-18T16:21:24.658Z",
"fragments": null,
"artifacts": [
{
"artifactType": "application/edi-x12",
"usage": "input",
"url": "https://core.us.stedi.com/2023-08-01/transactions/f0d9f790-0ec9-431b-93fd-e4h7ece63946/input",
"sizeBytes": 1313,
"model": "transaction"
},
{
"artifactType": "application/json",
"usage": "output",
"url": "https://core.us.stedi.com/2023-08-01/transactions/f0d3f740-0ec9-432b-98fd-e4b7ece63946/output",
"sizeBytes": 5602,
"model": "transaction"
}
],
"partnership": {
"partnershipId": "local-clearinghouse-test",
"partnershipType": "x12",
"sender": {
"profileId": "clearinghouse-test"
},
"receiver": {
"profileId": "local"
}
},
"x12": {
"transactionSetting": {
"guideId": "01J1M50C1Q44KYDZY8V7R1TPBW",
"transactionSettingId": "01J1M50P9623BFE0FFT5Q2BR49"
},
"metadata": {
"interchange": {
"acknowledgmentRequestedCode": "0",
"controlNumber": 11
},
"functionalGroup": {
"controlNumber": 11,
"release": "005010X214",
"date": "2024-07-18",
"time": "16:20:47",
"functionalIdentifierCode": "HN"
},
"transaction": {
"controlNumber": "1001",
"transactionSetIdentifier": "277"
},
"receiver": {
"applicationCode": "001690149382",
"isa": {
"qualifier": "ZZ",
"id": "001690149382"
}
},
"sender": {
"applicationCode": "STEDITEST",
"isa": {
"qualifier": "ZZ",
"id": "STEDITEST"
}
}
}
},
"connectionId": "01J1M5124B2HWMNN91Q3Z6AM61"
}
}
}
```
```json
{
"event": {
"version": "0",
"id": "5d1bcb90-cb0b-1844-5b93-86d5e5b9c4a8",
"detail-type": "transaction.processed.v2",
"source": "stedi.core",
"account": "",
"time": "2025-07-14T20:43:39Z",
"region": "us-east-1",
"resources": [
"https://core.us.stedi.com/2023-08-01/transactions/95e7786c-7066-4494-b83a-b1f300624902"
],
"detail": {
"transactionId": "95e7786c-7066-4494-b83a-b1f300624902",
"direction": "INBOUND",
"mode": "test",
"fileExecutionId": "5d30f0a0-63af-4aeb-b96c-353b4b25c99a",
"processedAt": "2025-07-14T20:43:39.808Z",
"fragments": null,
"artifacts": [
{
"artifactType": "application/edi-x12",
"usage": "input",
"url": "https://core.us.stedi.com/2023-08-01/transactions/95e7786c-7066-4494-b83a-b1f300624902/input",
"sizeBytes": 2016,
"model": "transaction"
},
{
"artifactType": "application/json",
"usage": "output",
"url": "https://core.us.stedi.com/2023-08-01/transactions/95e7786c-7066-4494-b83a-b1f300624902/output",
"sizeBytes": 13864,
"model": "transaction"
}
],
"partnership": {
"partnershipId": "local-clearinghouse-test",
"partnershipType": "x12",
"sender": {
"profileId": "clearinghouse-test"
},
"receiver": {
"profileId": "local"
}
},
"x12": {
"transactionSetting": {
"guideId": "01J8JH1SGTB2FYKN2PG4MH84RP",
"transactionSettingId": "01J8JH23VA3G2X8GENVVE6XZB9"
},
"metadata": {
"interchange": {
"acknowledgmentRequestedCode": "0",
"controlNumber": 1
},
"functionalGroup": {
"controlNumber": 1,
"release": "005010X221A1",
"date": "2025-07-14",
"time": "20:43:21",
"functionalIdentifierCode": "HP"
},
"transaction": {
"controlNumber": "0001",
"transactionSetIdentifier": "835"
},
"receiver": {
"applicationCode": "599264680681",
"isa": {
"qualifier": "ZZ",
"id": "599264680681"
}
},
"sender": {
"applicationCode": "STEDITEST",
"isa": {
"qualifier": "ZZ",
"id": "STEDITEST"
}
}
}
},
"connectionId": "01JE9257XJ4G4YFMXCHJPFR434"
}
}
}
```
#### File delivered events [#file-delivered-events]
Stedi emits a file delivered event when it successfully generates and delivers a claim. You may want to send these events to your system for monitoring and alerting.
Note that this event is emitted when Stedi delivers your claim to our connection with the payer. It doesn't indicate whether the payer received the claim or whether they have accepted or rejected it.
#### Example file delivered event [#example-file-delivered-event]
```json file.delivered.v2 event
{
"event": {
"version": "0",
"id": "3fb45b5f-bd7f-f9d0-c0a2-84946f20a9da",
"detail-type": "file.delivered.v2",
"source": "stedi.core",
"account": "",
"time": "2025-05-06T19:35:17Z",
"region": "us-east-1",
"resources": [],
"detail": {
"fileExecutionId": "e181c2ab-f85c-42bd-9cda-a7bd1e32b4c9",
"processedAt": "2025-05-05T20:14:57.882927984Z",
"artifacts": [
{
"artifactType": "application/edi-x12",
"usage": "input",
"sizeBytes": 1270,
"url": "https://core.us.stedi.com/2023-08-01/executions/e181c2ab-f85c-42bd-9cda-a7bd1e32b4c9/input",
"model": "execution"
},
{
"artifactType": "application/edi-x12",
"usage": "output",
"sizeBytes": 1270,
"url": "https://core.us.stedi.com/2023-08-01/executions/e181c2ab-f85c-42bd-9cda-a7bd1e32b4c9/output",
"model": "execution"
}
],
"connection": {
"connectionType": "STEDI_ACCOUNT_FTP",
"connectionId": "01JM0XF37DXZ3THZ7N75YJTW52"
},
"delivery": {
"status": "DELIVERED",
"message": "Delivered to 'Test Account SFTP'",
"artifactId": "9d7c38f4-410b-4032-aad4-016d8140b265.x12"
}
}
}
}
```
#### File failed events [#file-failed-events]
Stedi emits a file failed event when it either fails to process a response from a payer or cannot deliver a submitted claim.
If you're submitting claims through Stedi's SFTP connection, we strongly recommend monitoring these events so that you can receive instant notifications when a submitted claim fails due to validation errors in the EDI file.
File failed events can indicate connection problems or other issues that our engineering team must resolve with the payer. If you're submitting claims through Stedi APIs, you may want to also monitor these events so you can alert our customer support team if needed.
#### Example file failed event [#example-file-failed-event]
```json file failed event
{
"event": {
"version": "0",
"id": "cef43062-0258-cbac-b06d-ec6a21f03c69",
"detail-type": "file.failed.v2",
"source": "stedi.core",
"account": "",
"time": "2025-06-05T11:26:16Z",
"region": "us-east-1",
"resources": [
"https://core.us.stedi.com/2023-08-01/executions/7590afcd-26d7-4182-a8fc-1d1051e2815c"
],
"detail": {
"fileExecutionId": "7590afcd-26d7-4182-a8fc-1d1051e2815c",
"direction": "INBOUND",
"processedAt": "2025-06-05T11:26:16.354Z",
"source": {
"dirname": "remote-ftp/test/01JJYJ0GGVZD5GR230YP6G3MEA/fromPartner",
"name": "Test_Dental.1234567.835"
},
"artifacts": [
{
"artifactType": "application/edi-x12",
"url": "https://core.us.stedi.com/2023-08-01/executions/7590afcd-26d7-4182-a8fc-1d1051e2815c/input",
"usage": "input",
"model": "execution"
}
],
"connectionId": "01JJYJ0GGVZD5GR230YP6G3MEA",
"partnership": {
"partnershipId": "stedi-test_dentalpartner",
"partnershipType": "x12",
"receiver": {
"profileId": "stedi-test"
},
"sender": {
"profileId": "dentalpartner"
}
},
"errors": [
{
"message": "String element BPR-10 must have a length of 10, actual length is 5\nElement PER-02 is not used by this guide",
"faultCode": "FAILED_TO_TRANSLATE"
}
],
"x12": {
"metadata": {
"interchange": {
"acknowledgmentRequestedCode": "1",
"controlNumber": 56199839
}
},
"receiver": {
"isa": {
"qualifier": "30",
"id": "117151744"
}
},
"sender": {
"isa": {
"qualifier": "ZZ",
"id": "900117186"
}
}
}
}
}
}
```
### Event filters [#event-filters]
You may want to further filter the events Stedi sends to your endpoint:
* **Transaction:** This is useful if you want to send events for 277CA claim acknowledgments to one endpoint and events for 835 ERAs to another. For example, if you set this to `835: Health Care Claim Payment/Advice`, Stedi only sends events for processed 835 ERAs to your endpoint.
* **Partnership:** This is useful if you want to send test claims to one endpoint and production claims to another. For example, if you set this to `local-clearinghouse-test`, Stedi only sends events for test claims to your endpoint.
The **Guide**, **Connection**, and **Mode** filters are not relevant to claims
processing.
### Event schema [#event-schema]
All Stedi events follow a standard JSON Schema. The event payload itself does not include the contents of a given file or transaction. Instead, it references an API path to retrieve the entire object.
```json JSON event structure example
{
"version": "0",
"id": "8a9fc08a-24b2-4eeb-af7c-f96376ea471e",
"detail-type": "transaction.processed.v2",
"source": "stedi.core",
"account": "",
"time": "2021-11-12T00:00:00Z",
"region": "us-east-1",
"resources": [
"https://core.us.stedi.com/2023-08-01/transactions/3543b3f7-0d78-48cc-97c3-ac145e250a1d"
],
"detail": { ... }
}
```
In addition to their `version`, `id`, and `time`, events have the following properties:
* **`detail-type`** - Indicates the type of event, such as `transaction.processed.v2` or `file.failed.v2`.
* **`source`** - Indicates the component that generated the event. All events use `source: “stedi.core”`.
* **`account`** - The account ID that generated the event.
* **`region`** - The AWS region where the event was generated.
* **`resources`** - The URL to the resource that Stedi created. This could be a transaction or a file execution, depending on the event type.
* **`detail`** - The JSON payload. The schema for each payload is determined by the `detail-type`.
## HTTP response codes [#http-response-codes]
Stedi considers a `2xx` response a success, and marks any other response as a failure.
Stedi retries events associated with status codes other than `2xx` for up to 4 times with a 90 second wait period inbetween retries.
If the maximum number of retries has been exhausted, Stedi adds the event to the [error queue](#error-queue) for the webhook.
You can set the **Concurrency** when configuring the webhook to prevent throttling. This setting determines the maximum number of deliveries that Stedi will attempt to deliver to the endpoint at one time.
## Certificates [#certificates]
Webhooks only support valid, publicly trusted certificates. Self-signed certificates or certificates from private certificate authorities aren't supported.
You'll receive the following error if the endpoint configured for the webhook uses a certificate that isn't signed by a known, trusted certificate authority:
```
"awsResponse": "Unable to invoke ApiDestination endpoint: API destination endpoint cannot be reached."
```
## Timeouts [#timeouts]
The target endpoint must respond with a `2xx` status code within 5 seconds, or the event will be counted as a failed delivery.
This is a hard limit that cannot be increased or configured.
Because of this timeout limitation, we recommend designing your webhook endpoints to immediately acknowledge receipt with a `2xx` response, then process the data asynchronously. See [Best practices for webhook endpoints](#best-practices-for-webhook-endpoints).
## Retries and duplicate deliveries [#retries-and-duplicate-deliveries]
When a delivery fails, Stedi will retry up to 4 times every 90 seconds. After the fifth retry, Stedi moves the event to the error queue.
If your webhook doesn't respond within 5 seconds, Stedi marks that as a failure and then automatically retries. This can result in duplicate deliveries.
We strongly recommend using idempotency in your webhook receivers to safely
handle duplicate deliveries. See [Best practices for webhook endpoints](#best-practices-for-webhook-endpoints).
## Error queue [#error-queue]
Each webhook includes an error queue. Each item in the queue consists of the original event that was attempted to be delivered. This ensures if the target service has some downtime, or anything else goes wrong, the missed events can be retried later. The error queue retains items for 14 days.
The order of the error queue is not guaranteed. The downstream service must be designed to be idempotent to handle at-least-once delivery of events, and must accept events out of order.
## Logs [#logs]
To view logs, click the webhook to go to its detail page, and then navigate to the **Logs** tab.
## Deauthorized connections [#deauthorized-connections]
If a webhook sends a message to an endpoint that returns a 401 (Unauthorized) response, the destination will be 'deauthorized'. In this state, the webhook won't be able to deliver messages.
If there is an issue with your authentication information (such as the password, API key, or OAuth settings), edit the webhook to fix it.
If the authentication information is correct, and there was a different reason for the endpoint returning a 401, you can try again by adding a temporary header. For example, `x-stedi-reauthorize` with today's date as a value. When you save, the webhook will attempt to deliver again. This header can be removed later. Editing the value of a header will also restart deliveries.
You will likely have a queue of messages to deliver, so Stedi will automatically start retrying them after you make this change. If the endpoint is still returning an invalid response, the webhook will return to `Deauthorized`.
## Best practices for webhook endpoints [#best-practices-for-webhook-endpoints]
When creating endpoints to receive webhooks from Stedi, we recommend the following architecture:
1. **Acknowledge first, process later**: Design your endpoint to immediately return a `2xx` status code to acknowledge receipt, then process the payload asynchronously.
2. **Store payloads for processing**: Capture the webhook data in a queue, database, or other storage mechanism before processing.
3. **Process asynchronously**: Handle the actual business logic in a separate process or worker after acknowledging receipt.
4. **Implement idempotency**: Use idempotency keys from the event payload to prevent duplicate processing.
* Store the `eventId` from each webhook payload in your database
* Before processing an incoming webhook, check if its `eventId` has already been processed
* Design operations to be idempotent, ensuring that processing the same event multiple times doesn't cause issues (e.g., avoid incrementing counters on each processing attempt)
This architecture prevents [timeouts](#timeouts), handles potential duplicate deliveries, and allows you to process high volumes of events.
# Coordination of benefits (COB) checks
Source: https://www.stedi.com/docs/healthcare/coordination-of-benefits
Some patients have multiple health plans. For example, a dependent may have coverage with two private insurance companies through their parents. When a patient has active coverage with multiple plans, you need to know which health plan is primarily responsible for paying claims (coordination of benefits).
You can use a coordination of benefits (COB) check to determine:
* If a patient is covered by more than one health plan
* Whether there is coverage overlap between plans
* Whether coverage overlap requires coordination of benefits
* Each payer's responsibility for payment (primacy) in coordination of benefits scenarios
COB checks can help ensure that you submit claims to the correct payer and avoid claim denials. We recommend performing COB checks for all new patients who have coverage through one of Stedi’s supported payers. When Stedi identifies overlapping coverage, we strongly recommend performing follow-up [eligibility checks](/healthcare/send-eligibility-checks) with each payer to verify coverage status and retrieve the patient's complete and current benefits information before you submit claims.
COB checks require that you know at least one of the patient's active health
plans. If you're unsure whether a patient has any active coverage at all, you
can perform an [insurance discovery check](/healthcare/insurance-discovery) to
find potential coverage.
## Supported payers [#supported-payers]
COB doesn't support Medicare plans. However, many Medicare Advantage plans are supported. Visit the [Payer Network](https://www.stedi.com/healthcare/network?query=eyIyNzAiOnt9LCIyNzYiOnt9LCI4MzUiOnt9LCI4MzdQIjp7fSwiODM3SSI6e30sIjgzN0QiOnt9LCJDT0IiOnsiaXNTdXBwb3J0ZWQiOnRydWV9fQ%3D%3D\&page=0) for a complete list of supported payers.
## Transaction enrollment [#transaction-enrollment]
[Transaction enrollment](/healthcare/transaction-enrollment) isn't required to run COB checks through Stedi.
## How COB checks work [#how-cob-checks-work]
You submit a coordination of benefits request with information for one of the patient's health plans. The information required is similar to a standard eligibility check – first name, last name, DOB, and either member ID or SSN – and you should first run a [real-time eligibility check](https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-eligibility) to ensure that the member’s details are accurate.
Once you submit the request, Stedi searches a database of eligibility data from regional and national plans. This database has 245+ million patient coverage records from 45+ health plans, ASOs, TPAs, and others, including participation from the vast majority of national commercial health plans. Data is updated at least weekly to ensure accuracy.
COB check results may be partial or negative and may fail to include some or all of a patient's health plans. Results depend on whether the patient's payers contribute to the COB database.
Stedi synchronously returns summary information about each of the patient's active health plans, whether there is coverage overlap, and, if so, the responsibility sequence number for each payer (such as primary or secondary, if that can be determined).
Once you receive the results, we strongly recommend performing follow-up [eligibility checks](/healthcare/send-eligibility-checks) with each payer to verify coverage status and retrieve the patient's complete and current benefits information before you submit claims.
## Check COB [#check-cob]
Each COB check must be for a participating health plan for which the patient has coverage. For example, if the patient has coverage from Cigna and UnitedHealthcare, a COB check to Aetna will return an error.
Medicare plans are not supported. However, many Medicare Advantage plans are
supported.
### Accurate patient data [#accurate-patient-data]
COB checks are significantly more sensitive to data accuracy than eligibility checks. To perform successful COB checks, the patient information you provide in the check **must** match the payer's data exactly.
For example, if a payer has a patient's name stored as "Jonathan Doe", they may return benefits information when you submit an eligibility check for "Jon Doe", as long as they can identify the patient through the other information provided. However, a COB request for "Jon Doe" will fail because the name doesn't match the payer's records exactly.
To avoid unnecessary COB check failures, we strongly recommend that you first submit an eligibility check request for the patient. Then use the following data from the successful eligibility response to build the COB request: `firstName`, `lastName`, `dateOfBirth`, `memberId`.
### Service type code [#service-type-code]
You can submit COB checks with the `30` service type code for Health Benefit Plan Coverage. This is the broadest service type code that covers all medical services and subtypes included in the patient's health plan.
### API submission [#api-submission]
Use the [Coordination of Benefits Check](/healthcare/api-reference/post-coordination-of-benefits) endpoint to submit COB checks programmatically. The information required in the request is similar to a standard eligibility check – first name, last name, DOB, and either member ID or SSN.
The following example shows a COB check for a dependent named Jordan Doe who has coverage with Blue Cross Blue Shield of Massachusetts (Stedi payer ID: `EWDCI`).
```bash
curl --request POST \
--url "https://healthcare.us.stedi.com/2024-04-01/coordination-of-benefits" \
--header "Authorization: " \
--header "Content-Type: application/json" \
--data "'{
"tradingPartnerServiceId": "EWDCI",
"provider": {
"organizationName": "ACME Health Services",
"npi": "1999999984"
},
"subscriber": {
"firstName": "John",
"lastName": "Doe",
"dateOfBirth": "1985-05-27",
"memberId": "W000000000"
},
"dependent": {
"firstName": "Jordan",
"lastName": "Doe",
"dateOfBirth": "2002-12-31"
},
"encounter": {
"dateOfService": "2024-08-02",
"serviceTypeCode": "30"
}
}'"
```
Visit [Request and response examples](/healthcare/cob-response#request-and-response-examples) to review sample COB checks for common scenarios.
#### Concurrency limit [#concurrency-limit]
Visit [Concurrency limits](/healthcare/api-reference#concurrency-limits) for more information.
### Manual submission [#manual-submission]
To prevent accidentally sending checks to unsupported payers, the Stedi portal only provides the option to perform a COB check within successful eligibility checks to supported COB payers.
To submit a new COB check through the Stedi portal:
1. Go to the [Eligibility searches](https://portal.stedi.com/app/healthcare/eligibility) page.
2. Click the eligibility check for the patient you want to check for coordination of benefits. This must be a successful eligibility check for the patient's health plan - failed checks can't be used as the basis for COB checks.
3. Click **View** to review the details of the eligibility check.
4. Click `New COB check` to open the coordination of benefits check form. Stedi prefills the patient's information from the eligibility check.
# Transaction enrollment requests
Source: https://www.stedi.com/docs/healthcare/create-manage-transaction-enrollments
An enrollment request includes the provider record, the transaction type you want to enroll, the payer you want to enroll with, and a designated contact that the payer can communicate with about the enrollment. All requests go through the same high-level [enrollment process](/healthcare/transaction-enrollment#enrollment-process) once submitted.
Developers can create enrollment requests individually in the UI, through bulk CSV import, or through the API.
**Electronic Remittance Advice (ERAs):** Once enrollments are live, you'll no longer receive ERAs for that provider through your previous clearinghouse. If the payer supports it, you can specify a [requested effective date](#requested-effective-date) to help coordinate your migration to Stedi.
## Consider enrollment scope [#consider-enrollment-scope]
When you enroll a provider for 835 Electronic Remittance Advice (ERAs), payers can scope the enrollment in one of two ways:
* **NPI:** The payer registers only the specific National Provider Identifier (NPI) you submitted in the enrollment request. Other NPIs under the same Tax Identification Number (TIN) continue receiving ERAs through their existing clearinghouses.
* **TIN:** The payer registers all NPIs under the TIN. When you enroll one NPI, the payer switches the entire TIN to Stedi, affecting all NPIs that share that TIN.
Payers vary in how they manage enrollment scope, and this information isn't always disclosed to Stedi. For payers with TIN scope, enrolling one NPI may unintentionally enroll the other NPIs under that TIN. This means the ERAs for all of the associated NPIs will start flowing through Stedi - not just ERAs for the NPI you meant to enroll.
### Prevent disruptions [#prevent-disruptions]
To reduce the likelihood of unintentionally disrupting your workflows, we recommend:
* Enroll all NPIs that share the same TIN at the same time. This is common for hospital systems, clinic networks, or large medical groups that have multiple service locations operating under the same billing entity.
* If you need to keep some NPIs with your existing clearinghouse, contact Stedi support before submitting enrollment requests. We can help ensure the process goes smoothly.
## Submit enrollment requests [#submit-enrollment-requests]
Submit enrollment requests individually through the [Stedi portal](#individual-ui-submission), in bulk using [CSV import](#bulk-csv-import), or programmatically through the [Enrollments API](#api-submission).
### Individual UI submission [#individual-ui-submission]
Creating individual enrollment requests through the Stedi portal involves two steps: creating a provider record and submitting enrollment requests.
#### Step 1: Create a provider record [#step-1-create-a-provider-record]
You must create a provider record with the name, tax ID, NPI, and contact information of the billing provider you plan to use in claims. Stedi submits this information to the payer as part of the enrollment process.
If you're a solo provider, this is likely your information. If you're [enrolling a group practice](#practices-and-facilities-with-multiple-providers-or-locations), you only need to create provider records for the NPIs and the tax IDs you use for billing. You don't need to create provider records for individual rendering providers.
To create a provider record:
1. Go to the [Providers page](https://portal.stedi.com/app/healthcare/providers).
2. Click **New provider**.
3. Enter the required information:
* **Display name**: A name to help you identify the provider record in your account. For example, "XYZ Medical Group". We don't share this name with payers.
* **NPI**: The National Provider Identifier (NPI) on file with the payer that you use for billing. If you're enrolling a group practice, this is typically the group's NPI.
* **Tax ID**: The tax ID, which can be an EIN or SSN. This should be the tax ID on file with the payer that you use for billing.
* **Contacts**: This is where the payer will send communications about the enrollment, if needed. For many providers, Stedi can fetch contact information from the NPI registry. The name and address should exactly match what the payer has on file. However, the email and phone number can be set to wherever you want to receive payer communications.
4. Click **Create provider**.
The provider record is created and appears in the list on the [**Providers** page](https://portal.stedi.com/app/healthcare/providers).
#### Step 2: Create enrollment requests [#step-2-create-enrollment-requests]
Once you've created a provider record, you can attach it to one or more enrollment requests.
To create an enrollment request:
1. Go to the [Enrollments page](https://portal.stedi.com/app/healthcare/enrollments).
2. Click **New enrollment**.
3. Complete the required information:
* **Payer**: Select the payer you want to enroll with. Start typing the payer's name to filter the list.
* **Provider**: Select an existing provider record. The form automatically populates the provider's information. You can choose to use an existing contact or enter new contact information for the payer to use for communications about the enrollment. Review our guidance on [provider contact information](#provider-contact) to ensure updates go to the correct location.
* **Transaction**: Select the transaction type you want to enroll for. The form populates the list of transaction types that the payer supports, and you'll only be able to select transaction types that require enrollment.
* **Aggregate ERAs by (optional)**: For Electronic Remittance Advice (ERA) enrollments with supported payers, you can specify an [aggregation preference](#era-aggregation-preference).
* **Requested effective date (optional)**: For supported payers, you can specify the date you'd like the enrollment to take effect. This is helpful for coordinating the migration from your previous clearinghouse, especially for ERA enrollments. Visit [Requested effective date](#requested-effective-date) to learn more.
* **Stedi contact person**: This is the email address where Stedi will send updates about the enrollment request. We'll use it to notify you when there are next steps and send updates on the enrollment's status. This email address can be different from the contact information you provided in the provider record. Set it to wherever you want to receive Stedi's communications about the enrollment.
4. Click **Create enrollment**. Stedi asks you to confirm the information.
5. Review the enrollment information carefully and then click **Submit enrollment**.
The enrollment request is created and appears in the list of enrollments on the [Enrollments page](https://portal.stedi.com/app/healthcare/enrollments).
### Bulk CSV import [#bulk-csv-import]
You can import enrollment requests from a CSV file. This is a great option if you need to submit many requests at once.
To submit enrollment requests through bulk CSV import:
1. Go to the [Bulk imports page](https://portal.stedi.com/app/healthcare/enrollments/bulk).
2. Click **New bulk import**. The upload page contains detailed instructions for formatting the CSV file.
3. Download the CSV template and prepare your file according to the provided instructions. We also recommend reviewing the instructions about [enrollment contact information](#enrollment-contact-information) and [practices and facilities with multiple providers or locations](#practices-and-facilities-with-multiple-providers-or-locations) to ensure your file is set up correctly.
4. Click **+ Upload file** and select your file or drag and drop your file into the **Upload CSV** section.
5. Enter a **Name** for the batch. Stedi displays this batch name in the portal, so choose something descriptive.
6. Click **Verify file**. Stedi checks for errors and flags any rows that require adjustments. If there are errors, you can either fix them and re-upload the CSV file or click **Execute import without invalid rows** to proceed with importing valid rows.
7. Click **Execute import**. Stedi processes the import and creates the enrollment requests.
You can review the status of each bulk import on the [Bulk imports page](https://portal.stedi.com/app/healthcare/enrollments/bulk). The overview shows the number of rows that were successfully imported, the number of rows that were skipped due to errors or duplicates, and the date and time of the import. Click an import to view more details and download the [import status report](#import-status-report).
Imported enrollment requests appear in the list of enrollments on the [Enrollments page](https://portal.stedi.com/app/healthcare/enrollments).
#### Importing behavior [#importing-behavior]
Stedi automatically does the following when importing enrollment requests from a CSV file:
* Creates a new provider record for each unique combination of NPI and tax ID in the CSV file. For example, these two providers would be created as separate records even though they have the same name and NPI:
* `John Doe, NPI: 1999999984, Tax ID: 987654321`
* `John Doe, NPI: 1999999984, Tax ID: 123456789`
When a row in your CSV file contains an NPI and tax ID that match an
existing provider record in your account, Stedi overwrites the existing
provider record with the information in the CSV file. Any changes (such as
updated address or contact information) aren't automatically applied to
existing enrollment requests for that provider, only to requests created
after Stedi updated the record.
* Creates and submits enrollment requests.
* Removes duplicate rows to prevent duplicate requests.
* Skips rows that contain errors. For example, if a row contains an invalid NPI, Stedi skips that row and imports the rest of the file. Review the import status report to understand which rows were skipped and why.
#### Import status report [#import-status-report]
After importing, you can download a report that shows the status of each row in the CSV file. For example, duplicate rows are marked as `Duplicate: Enrollment already exists` in the `result` column.
To download the report:
1. Go to the [Bulk imports page](https://portal.stedi.com/app/healthcare/enrollments/bulk).
2. Click an import to view its details.
3. Click **Download full report**.
Rows with errors display a clear inline error message to help you make the necessary adjustments. You can fix rows with errors and re-upload the CSV file as many times as needed until all imports are successful.
### API submission [#api-submission]
Creating enrollment requests programmatically through Stedi APIs involves two steps:
1. **Create a provider record:** Call the [Create Provider](/healthcare/api-reference/post-enrollment-create-provider) endpoint.
2. **Create an enrollment request:** Call the [Create Enrollment](/healthcare/api-reference/post-enrollment-create-enrollment) endpoint. You can create enrollment requests in `DRAFT` status first and change the status to `STEDI_ACTION_REQUIRED` later when you're ready to submit them to Stedi. Stedi won't process the enrollment until it is in `STEDI_ACTION_REQUIRED` status.
## Enrollment contact information [#enrollment-contact-information]
When you submit enrollment requests, you'll need to provide two types of contact information. It's important to understand the difference between them.
### Provider contact [#provider-contact]
This is where the **payer** will send communications about the enrollment, if needed.
* The name and address should match exactly what the payer has on file for the provider. Some payers reject enrollment requests with addresses that don't match their records.
* However, you may want to set the phone number or email to a different contact - for example, a credentialing or general inbox - to ensure payer communications go to the right place.
* If you're enrolling a group practice, select a single administrative entity as the contact - don't use individual provider emails.
#### Where to set [#where-to-set]
You can specify contacts on both the provider record and on the enrollment request.
* **(Optional) Provider record:** These contacts are for convenience - they allow the Stedi portal to prepopulate contact information options when you create enrollment requests manually. They aren't required when you create provider records, and they aren't automatically added to enrollment requests you submit through the portal or API.
* **(Required) Enrollment request:** You must specify a provider contact on the enrollment request. This is the information that Stedi shares with the payer when submitting the enrollment on your behalf. This contact information doesn't need to match the existing contact information on the provider record, which allows you to use different contacts for different payers as needed.
### Stedi contact email [#stedi-contact-email]
This is the email address where **Stedi** will send updates about the enrollment. It's required when you submit an enrollment request - we use it to notify you when there are next steps and send updates on the enrollment's status.
This is called the [`userEmail` property](/healthcare/api-reference/post-enrollment-create-enrollment#body.userEmail) in the Stedi API, the **user\_email** column in the CSV file for bulk imports, and the **Stedi contact person** in the UI form.
This email address can be different from the contact information you provided in the provider record. Set it to wherever you want to receive Stedi's communications about the enrollment.
## Requested effective date [#requested-effective-date]
You can specify a requested effective date for transaction enrollments. This is the date you'd like the enrollment to take effect with the payer. For example, setting this for an 835 Electronic Remittance Advice (ERAs) enrollment to a future date helps you coordinate the migration from your previous clearinghouse to Stedi.
Stedi processes enrollments accordingly, but can't guarantee that the enrollment will be effective on this exact date.
### Check payer support [#check-payer-support]
You can determine which payers support requested effective dates through the:
* [Payers API](/healthcare/api-reference/get-payer): Check the `requestedEffectiveDate` property in the transaction-specific enrollment process.
* [Payer Network](https://www.stedi.com/healthcare/network): Check the **Requested effective date** field for the transaction type.
### Set requested effective date [#set-requested-effective-date]
To specify a requested effective date on enrollments:
* **API:** Set the [`requestedEffectiveDate` property](/healthcare/api-reference/post-enrollment-create-enrollment#body.requestedEffectiveDate) in your [Create Enrollment request](/healthcare/api-reference/post-enrollment-create-enrollment). Use YYYYMMDD format. You can submit today's date or a future date up to 6 months from today.
* **Stedi portal:** Enter a date in the **Requested effective date** field when submitting enrollments. This field is visible for supported payers once you select a transaction type.
* **CSV import:** Populate the `requested_effective_date` column in YYYYMMDD format for each enrollment. Only set this for payers that support requested effective dates.
If you include a requested effective date for an unsupported payer, Stedi rejects the enrollment request. If you don't set a requested effective date, Stedi defaults to the enrollment's submission date for submitted enrollments.
## ERA aggregation preference [#era-aggregation-preference]
835 Electronic Remittance Advice (ERAs) can contain payment and adjudication details for multiple claims.
For supported payers, you can specify an aggregation preference for grouping claim information within each ERA. This helps ensure ERAs arrive in the way your billing system expects, reducing time spent matching payments to providers or practices.
### Aggregation types [#aggregation-types]
Payers use one of the following billing provider identifiers to group claim information in ERAs:
* **NPI:** The National Provider Identifier (NPI) always uniquely identifies a single provider entity, either an individual provider or an organization. For example, a doctor employed by multiple clinics may use the same NPI to submit claims across multiple TINs.
* **TIN:** The Tax Identification Number (TIN) can be the provider's Social Security Number (SSN) or Employee Identification Number (EIN). TINs are sometimes shared across multiple billing providers within the same organization. For example, a clinic may submit claims for several doctors using a single TIN.
Most payers default to TIN-based aggregation, and not all payers support both aggregation types.
### Check payer support [#check-payer-support-1]
You can determine which aggregation types your payers support through the:
* [Payers API](/healthcare/api-reference/get-payer): Check the `supportedAggregationPreferences` array in any endpoint response.
* [Payer Network](https://www.stedi.com/healthcare/network): Check the **ERA aggregation preferences** field.
### Set aggregation preference [#set-aggregation-preference]
To specify your aggregation preference on ERA enrollments:
* **API:** Set the [`aggregationPreference` property](/healthcare/api-reference/post-enrollment-create-enrollment#body.aggregationPreference) in your [Create Enrollment request](/healthcare/api-reference/post-enrollment-create-enrollment#body.aggregationPreference).
* **Stedi portal:** Choose an identifier in the **Aggregate ERAs by** section when submitting ERA enrollments.
* **CSV import:** Populate either the `aggregationPreferenceNpi` (10 digit string) or `aggregationPreferenceTaxId` (9 digit string) column for each enrollment.
Stedi attempts to enroll with with your specified preference, but it's not guaranteed - ultimately, the payer controls how ERAs are grouped and routed. If you don't set a preference, Stedi automatically selects a default based on the payer's supported aggregation types and the available identifiers for the provider.
When available, Stedi displays the aggregation preference on the enrollment request's details page in the Stedi portal. It's also available in Enrollment API endpoint responses in the [`aggregationPreference` property](/healthcare/api-reference/get-enrollment#response.aggregationPreference).
### Independent from scope [#independent-from-scope]
ERA aggregation preferences and [enrollment scope](#consider-enrollment-scope) are independent payer behaviors:
* **Enrollment scope:** Controls which NPIs the payer registers when you submit an enrollment request.
* **ERA aggregation:** Controls how the payer packages 835 ERAs after enrollment is complete - grouping claim information by NPI or TIN.
The payer's supported aggregation types don't indicate how they manage enrollment scope. A payer can support NPI-level aggregation preferences for 835 ERAs *and* manage enrollments at the TIN level. In these cases, specifying **NPI** as your preferred aggregation type in the enrollment request won't prevent the payer from enrolling all the NPIs associated with a specific TIN once the request is processed.
## Manage tasks and documents [#manage-tasks-and-documents]
After submitting an enrollment request, you may need to complete tasks to move the enrollment process forward. Tasks can include providing documentation, completing payer-specific requirements, or reviewing enrollment details.
Learn how to [complete enrollment tasks and manage documents](/healthcare/transaction-enrollment-tasks-documents).
## Review enrollment details [#review-enrollment-details]
You can track the status of your transaction enrollment requests from the [Enrollments page](https://portal.stedi.com/app/healthcare/enrollments) in your account.
Click an enrollment request to view its details, including:
* The provider and payer associated with the enrollment.
* The transaction types included in the enrollment.
* The current status of the enrollment.
* Any notes or instructions from Stedi or the payer.
* The history of status changes and actions taken on the enrollment.
* Enrollment documents, such as signed PDF forms.
Alternatively, you can retrieve information about enrollment requests through the [List Enrollments](/healthcare/api-reference/get-enrollment-list-enrollments) endpoint.
## Cancel enrollments [#cancel-enrollments]
You can only cancel enrollment requests that are in `DRAFT`, `STEDI_ACTION_REQUIRED`, or `PROVIDER_ACTION_REQUIRED` status. Reach out to Stedi support in Slack or Teams to cancel. Once an enrollment is canceled, Stedi sets its status to `CANCELED` and stops the enrollment process with the payer.
We can't cancel enrollments that are in `PROVISIONING` or `LIVE` status. Once an enrollment is in one of these statuses, the only way to stop 835 ERAs from coming to Stedi is to submit an enrollment through another clearinghouse.
## Notification emails [#notification-emails]
Once an hour, Stedi checks for enrollment request status changes. If there are updates, Stedi sends a notification email with a summary of the affected enrollment requests. The email includes links to each updated enrollment request where you can review required tasks, notes, and other details.
Email notifications are sent to the address designated as the **Stedi contact person** ([`userEmail` property](/healthcare/api-reference/post-enrollment-create-enrollment#body.userEmail)) about the enrollment. This is typically the email associated with the Stedi account that created the enrollment request, and it may differ from the provider's designated contact.
If you aren't receiving notification emails for enrollment request updates, contact Stedi support in Slack or Teams.
## Automatic enrollment requests [#automatic-enrollment-requests]
Some payers, such as the Centers for Medicare and Medicaid Services (CMS), require enrollment for eligibility checks.
Eligibility checks fail when a provider isn't properly enrolled. In these cases, Stedi automatically submits the required transaction enrollment request. Payers typically process these requests within 1-2 days.
We support automatic enrollment requests for the following payers in the [Payer Network](https://www.stedi.com/healthcare/network):
* The Centers for Medicare and Medicaid Services (CMS) (Payer ID: `CMS`)
* CMS MBI Lookup with SSN (Payer ID: `MBILU`)
* Highmark of Pennsylvania (Payer ID: `54771`)
* Highmark Senior Health Company (Payer ID: `15460`)
* Highmark Blue Cross Blue Shield of Delaware (Payer ID: `030`)
* Highmark Blue Cross Blue Shield of West Virginia (Payer ID: `54828`)
Please note:
* If the provider's NPI isn't active in the [National Plan & Provider Enumeration System (NPPES)](https://npiregistry.cms.hhs.gov/search), Stedi won't automatically create the enrollment for the NPI. The provider will need to apply directly with CMS to be added to the registry.
* For CMS enrollments, the provider must also complete [attestation](#cms-attestation). Stedi adds a task to the enrollment request when attestation is required.
* For CMS enrollments, the transaction enrollment request will be rejected and set to `REJECTED` status if the provider's NPI isn't active in [PECOS](https://pecos.cms.hhs.gov/pecos/login.do#headingLv1), the system CMS uses to manage active Medicare providers. In this case, we'll send you instructions explaining how to resolve the issue.
* Stedi sets the [Stedi contact email](#stedi-contact-email) to the oldest account member with the Admin role. This is where Stedi sends enrollment status notifications.
## CMS eligibility enrollment [#cms-eligibility-enrollment]
The Centers for Medicare and Medicaid Services (CMS) requires providers to complete attestation, also called HETS EDI Enrollment, before running Medicare eligibility checks. Attestation confirms that clearinghouses like Stedi have authorization to conduct eligibility checks on the provider's behalf. This requirement applies only to traditional Medicare, not Medicare Advantage (Part C) or Part D plans.
### How attestation works [#how-attestation-works]
Attestation is required for each billing National Provider Identifier (NPI) enrolled with CMS for eligibility checks. Stedi can't complete this step on the provider's behalf, and there is no bulk attestation across NPIs. The process takes approximately 5-15 minutes per NPI.
When you submit a CMS eligibility check enrollment request, Stedi moves the enrollment to the **Provider Action Required** status and adds an enrollment task to complete attestation. The task contains instructions for completing attestation. After the provider completes attestation, they can start submitting eligibility checks immediately, even if the enrollment status is not yet **Live**.
CMS rejects Medicare eligibility requests from providers who haven't completed attestation using `AAA` error code `41`.
You can view the attestation task and its status in:
* The **Tasks** section of the enrollment request's details page in the Stedi portal.
* The `tasks` object array of the [List Enrollments](/healthcare/api-reference/get-enrollment-list-enrollments) and [Retrieve Enrollment](/healthcare/api-reference/get-enrollment) API responses.
## Enrollments hub [#enrollments-hub]
Our network and enrollment operations team knows the nuances of each payer’s enrollment requirements and maintains a public repository of payers that require additional steps through our [Transaction Enrollments Hub](https://enrollments.stedi.com).
## Practices and facilities with multiple providers or locations [#practices-and-facilities-with-multiple-providers-or-locations]
Some healthcare organizations operate multiple facilities or practices under a shared structure. This is common in hospital systems, clinic networks, or large medical groups where multiple service locations operate under the same billing entity.
Transaction enrollment requires the billing provider's tax ID and NPI that you plan to use in claims and Electronic Remittance Advice (ERAs). When the same group NPI and tax ID are used as the billing provider throughout the healthcare organization, you should:
* Create a single provider record with that NPI and the tax ID. You don't need to create provider records for individual rendering providers.
* Create enrollment requests with the billing provider record attached. You don't need to submit additional enrollment requests for individual rendering providers. Select a single administrative entity as the contact - don't include individual provider emails. This should be a credentialing or general inbox.
* Use the taxonomy code that matches the billing provider's credentials when submitting claims.
# Credentialing and enrollment
Source: https://www.stedi.com/docs/healthcare/credentialing-and-enrollment
Healthcare providers may need to complete three distinct enrollment processes to work with payers and send transactions through clearinghouses. Which processes are required depends on the payer and the types of transactions the provider wants to send and receive.
* **Credentialing:** Validating a healthcare provider's qualifications
* **Payer enrollment:** Registering a credentialed provider with a specific payer's health plan(s)
* **Transaction enrollment:** Registering a provider to send and receive EDI transactions (such as claims and eligibility checks) through a specific clearinghouse with a specific payer
These enrollments typically happen in sequence: first credentialing, then payer enrollment, and then transaction enrollment, although credentialing and payer enrollment are sometimes combined into a single process.
Stedi specifically handles [transaction
enrollment](/healthcare/transaction-enrollment), the final step needed to
exchange eligibility and claims transactions through our clearinghouse. Stedi
doesn't handle credentialing or payer enrollment, which providers must
complete directly with each payer or through a specialized credentialing
service.
## Credentialing [#credentialing]
Credentialing is the process of validating a healthcare provider's qualifications, including:
* Verification of education, training, and licensure
* Review of board certifications and medical specialties
* Confirmation of work history and malpractice insurance
* Review of any sanctions, restrictions, or malpractice claims
Credentialing establishes that a provider meets the payer's standards for providing care to their members. Once credentialed, a provider becomes eligible to join the payer's networks. Some payers have multiple networks and those networks may contain multiple tiers of providers. In order to actually join a network, the payer may require the provider to agree to a rate schedule and sign a contract with other terms.
**Timeline:** Credentialing typically takes 90-180 days to complete.
**Who handles it:** Providers must complete credentialing directly with each payer or through a specialized credentialing service. **Stedi doesn't handle the credentialing process.**
There are several third-party vendors you can use for credentialing, including:
* [Assured](https://www.withassured.com/) - An AI-powered platform for provider network management, including automated credentialing, licensing, and payer enrollment.
* [Medallion](https://medallion.co/) - An all-in-one provider data network management platform to automate credentialing, payer enrollment, monitoring, and licensing.
* [Verifiable](https://verifiable.com/) - An API-first platform for credentialing, plus an AI agent designed to automate end-to-end credentialing with human oversight.
There is a subset of eligibility payers who require credentialing but not transaction enrollment. If you get [`AAA` errors](/healthcare/eligibility-troubleshooting#payer-aaa-errors) in the `4x` range (such as `43`), the provider may need to complete credentialing with the payer even if transaction enrollment isn't required. Contact the payer to resolve.
## Payer enrollment [#payer-enrollment]
Payer enrollment (also called provider enrollment) is the process of registering a credentialed provider with a specific payer's health plan(s). This involves:
* Submitting applications to payers for specific lines of business (Medicare, Medicaid, commercial plans)
* Providing information about the provider's practice, such as locations and billing details
* Establishing contract terms for services and reimbursement rates
* Setting up payment arrangements
Payer enrollment establishes a business relationship between the provider and the payer. Once enrolled, the provider can submit claims to the payer and receive payments for services provided to the payer's members. (Payers might also accept at least certain types of claims from non-enrolled providers subject to legal requirements and plan rules.)
**Timeline:** Payer enrollment typically takes 60-120 days after credentialing is complete. However, this process is sometimes combined with or conducted in parallel with the credentialing process.
**Who handles it:** Providers must complete payer enrollment directly with each payer. **Stedi doesn't handle the payer enrollment process.**
## Transaction enrollment [#transaction-enrollment]
Transaction enrollment is the process of registering a provider to send and receive electronic EDI transactions (such as claims and eligibility checks) through a specific clearinghouse with a specific payer. Once enrolled, the provider can send and receive specific transactions with the payer through the clearinghouse.
Transaction enrollment involves:
* Submitting the provider's name, tax ID (EIN / TIN), NPI, billing address, and contact information
* Specifying which transaction types, such as claims, eligibility checks, and Electronic Remittance Advice (ERAs), the provider wants to exchange electronically
* Setting up the necessary technical connections between the clearinghouse and payer
All payers require providers to complete transaction enrollment before receiving ERAs because ERAs can only be sent to a single clearinghouse. When you submit an ERA enrollment in Stedi, it overrides the provider's existing ERA routing.
A much smaller number of payers also require transaction enrollment before providers can start submitting other transaction types, such as claims and eligibility checks.
**When it's required:** Check the [Payer Network](https://www.stedi.com/healthcare/network) to determine whether your payers require enrollment for the transaction types you want to send and receive. If the network says enrollment isn't required, then you can start sending those transactions right away - no transaction enrollment needed. However, you'll still need to include the provider's information (like their [NPI](/healthcare/national-provider-identifier)) in API requests when required.
**Timeline:** Transaction enrollment typically takes 2-6 weeks, depending on the payer.
**Who handles it:** Stedi handles the transaction enrollment process on behalf of providers. Visit [Transaction enrollment](/healthcare/transaction-enrollment) to learn how to complete transaction enrollment through Stedi.
Transaction enrollment is specific to each clearinghouse. If you switch from
another clearinghouse to Stedi, you'll need to complete transaction enrollment
through Stedi even if you were previously enrolled with the same payer through
a different clearinghouse.
# Active coverage, eligibility dates, plan details
Source: https://www.stedi.com/docs/healthcare/eligibility-active-coverage-benefits
After you send a successful eligibility or insurance discovery check, the payer sends back an X12 271 eligibility response containing the patient’s benefits information. Stedi transforms the 271 response from the original X12 EDI into JSON, making it easier to read, understand, and ingest into your system.
You can find the full benefits response shape in the [Real-Time Eligibility Check](/healthcare/api-reference/post-healthcare-eligibility) and [Insurance Discovery Check](/healthcare/api-reference/post-insurance-discovery) API references. This documentation describes how to use the eligibility response to determine the patient's active coverage, plan details, and specific benefits.
New to eligibility? Check out these blogs:
* [How to read a 271 eligibility response in plain English](https://www.stedi.com/blog/how-to-read-a-271-eligibility-response-in-plain-english)
* [What you can (and can't) reliably get from a 271 eligibility response](https://www.stedi.com/blog/what-you-can-reliably-get-from-a-271-eligibility-response)
* [How to deal with gaps in eligibility responses](https://www.stedi.com/blog/how-to-deal-with-gaps-in-eligibility-responses)
## Does the patient have coverage for the requested service? [#does-the-patient-have-coverage-for-the-requested-service]
You need two key pieces of information to determine whether the patient's health plan covers the requested service. The patient has coverage when:
1. The date of service is within the [eligibility period](#when-is-the-patient-eligible-for-benefits) for their health plan.
2. They have [active coverage](#active-and-inactive-coverage) for the applicable [service type code](#service-type-codes).
Once you know that the patient has coverage, you can determine [patient responsibility](/healthcare/eligibility-patient-responsibility-benefits), or how much the patient will pay for the service. For example, you can determine the patient's co-payment, deductible, and out-of-pocket maximum.
## When is the patient eligible for benefits? [#when-is-the-patient-eligible-for-benefits]
The `planDateInformation` object contains dates related to the patient's coverage under their health plan. Most commercial payers only return information for the current calendar year.
You can use these dates to determine the patient's eligibility for benefits.
* The dates in `planDateInformation` apply to every benefit within the patient's health plan unless specifically overridden within a `benefitsInformation[].benefitsDateInformation` object. Visit [Benefit-specific eligibility dates](#benefit-specific-eligibility-dates) for more details.
* The patient likely doesn't have active coverage if the date of service is after the earliest ending `plan`, `eligibility` `planEnd`, `eligibilityEnd`, `policyEffective`, or `policyExpiration` value.
The following example shows part of the benefits response for a health plan that began on January 1, 2024 and ended on December 31, 2024. The patient was eligible for benefits under that health plan starting on January 2, 2024.
{/* schema:PlanDateInformation:unwrap */}
```json
"planDateInformation":
{
"planBegin": "20240101",
"planEnd": "20241231",
"eligibilityBegin": "20240102"
}
```
### Plan dates for dependents [#plan-dates-for-dependents]
Dependents can have different coverage dates than the subscriber due to qualifying life events, such as starting a new job or passing the age limit for coverage through their parent's plan.
When the patient is a dependent, and the payer sends back date(s) that are different for the subscriber and dependent, Stedi includes only the dates for the dependent and omits the subscriber's date(s).
## What are the patient's benefits? [#what-are-the-patients-benefits]
The vast majority of the information you need to determine a patient's benefits under their health plan is contained in the `benefitsInformation` array. Each object in this array contains information about a specific benefit type, such as co-payments, deductibles, and exclusions.
The `benefitsInformation[].code` property indicates the type of benefits information described in the `benefitsInformation` object. Sometimes, the code simply indicates that the patient has active coverage for the `serviceTypes` listed. For example, the following excerpt shows a member with active coverage for service type code `30` (Health Benefit Plan Coverage).
{/* schema:BenefitsInformation */}
```json
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"planCoverage": "Open Access Plus",
"additionalInformation": [
{
"description": "Complete Care Management"
}
]
}
```
In other array entries, the code indicates that the `benefitsInformation` object contains details about specific benefits, such as co-payments, deductibles, and exclusions.
The following example shows a patient's co-payment for psychiatric, psychotherapy, and social work in-office visits.
* The copayment is $20 for providers considered in-network, as indicated by the `Y` in the `inPlanNetworkIndicatorCode` property.
* Note that the `inPlanNetworkIndicatorCode` doesn't tell you whether the provider that requested the eligibility check is in-network for the health plan, so you shouldn't assume a $20 copay for that provider until you can verify that they are in-network. Visit [Provider network status, authorizations, referrals](/healthcare/eligibility-network-status-authorization-referrals) for more details about verifying a provider's network status.
{/* schema:BenefitsInformation */}
```json
{
"code": "B",
"name": "Co-Payment",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "22"],
"serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
"timeQualifierCode": "27",
"timeQualifier": "Visit",
"benefitAmount": "20",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"industryCode": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"industryCode": "Office"
}
]
}
```
### Active and inactive coverage [#active-and-inactive-coverage]
You can quickly determine whether a patient has active coverage for specific service types when the `benefitsInformation[].code` is set to values `1` - `5`. The following example shows a member with active coverage for service type code `30` (Health Benefit Plan Coverage).
{/* schema:BenefitsInformation */}
```json
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"insuranceTypeCode": "C1",
"insuranceType": "Commercial",
"planCoverage": "Gold Plan HMO",
"authOrCertIndicator": "Y",
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable",
"benefitsRelatedEntity": {
"entityIdentifier": "Payer",
"entityType": "Non-Person Entity",
"entityName": "UNITEDHEALTHCARE",
"entityIdentification": "PI",
"entityIdentificationValue": "87726"
}
}
```
Likewise, you can quickly determine when a patient has inactive coverage for a service type when the `benefitsInformation[].code` is set to values `6` - `8`. The following example shows a member with inactive coverage for service type code `30` (Health Plan Benefit Coverage).
{/* schema:BenefitsInformation */}
```json
{
"code": "6",
"name": "Inactive",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable"
}
```
You can also assume the patient has active coverage for a service type when benefits information for that service type is included in the response, even if there is no explicit `benefitsInformation` object with `code` = `1` - `5`. For example, if the response contains a `benefitsInformation` object with `code` = `B` (Co-Payment) for service type code `30`, you can assume the patient has active coverage for that service type.
### Benefit type codes [#benefit-type-codes]
The benefit type code indicates the type of benefit described in the `benefitsInformation` object, such as co-payments, deductibles, and exclusions. The benefit type code is different from the service type code, which indicates the type of service covered by the benefit. Payers may send multiple `benefitsInformation` objects for the same service type code with different benefit type codes to communicate different aspects of the benefits.
The following is a complete list of codes that can be returned in the `benefitsInformation[].code` property.
* `1` - Active Coverage
* `2` - Active - Full Risk Capitation
* `3` - Active - Services Capitated
* `4` - Active - Services Capitated to Primary Care Physician
* `5` - Active - Pending Investigation
* `6` - Inactive
* `7` - Inactive - Pending Eligibility Update
* `8` - Inactive - Pending Investigation
* `A` - [Co-Insurance](/healthcare/eligibility-patient-responsibility-benefits#co-insurance)
* `B` - [Co-Payment](/healthcare/eligibility-patient-responsibility-benefits#co-payment)
* `C` - [Deductible](/healthcare/eligibility-patient-responsibility-benefits#deductible)
* `CB` - Coverage Basis
* `D` - Benefit Description
* `E` - Exclusions
* `F` - Limitations
* `G` - [Out of Pocket (Stop Loss)](/healthcare/eligibility-patient-responsibility-benefits#out-of-pocket-stop-loss)
* `H` - Unlimited
* `I` - Non-Covered
* `J` - [Cost Containment](/healthcare/eligibility-patient-responsibility-benefits#cost-containment)
* `K` - Reserve
* `L` - Primary Care Provider
* `M` - Pre-existing Condition
* `MC` - Managed Care Coordinator
* `N` - Services Restricted to Following Provider
* `O` - Not Deemed a Medical Necessity
* `P` - Benefit Disclaimer
* `Q` - Second Surgical Opinion Required
* `R` - Other or Additional Payor
* `S` - Prior Year(s) History
* `T` - Card(s) Reported Lost/Stolen | Typically used by Medicaid to indicate to a provider that the person who has presented the ID card is using a stolen ID card.
* `U` - Contact Following Entity for Eligibility or Benefit Information
* `V` - Cannot Process
* `W` - Other Source of Data
* `X` - Health Care Facility
* `Y` - [Spend Down](/healthcare/eligibility-patient-responsibility-benefits#spend-down)
#### Code `V` - Cannot Process [#code-v---cannot-process]
These are the most common reasons a payer may return a `benefitsInformation[].code` of `V`:
* **Request errors:** The payer didn't actually return any benefits information because of errors in the request - listed in the `errors` object. You should ignore the stub benefits data in the `benefitsInformation` object, correct the errors, and resubmit the eligibility check.
* **Wrong submission method:** The payer doesn't support automated X12 EDI eligibility checks for the service type code you provided and requires that you obtain benefits information through a different channel, such as by phone or online portal. The `benefitsInformation[].additionalInformation[].description` typically contains an explanation. The payer may also include contact information in `payer.contactInformation`.
* **Unable to interpret:** The payer located the member but couldn't make sense of the request. For example, a dental payer can't return benefits information for a vision service type code.
* **Alternate service type code:** The payer has grouped the service type code you submitted into a different one. In this case, the payer typically returns a `benefitsInformation` entry with `code` = `V` immediately followed by an entry with an active code and `benefitsInformation[].serviceTypeCodes` set to the preferred service type code.
### Service type codes [#service-type-codes]
The `benefitsInformation[].serviceTypeCodes` property contains the service type codes (STCs) that apply to the benefit.
You should review the [STC list](/healthcare/eligibility-stc-procedure-codes#full-stc-list) to determine which STCs are relevant to the benefits you're interested in and check for all of them in the response. This is helpful because the payer may return relevant benefits under a different STC than the one you submitted. For example, mental health benefits are typically returned with STC `MH` (Mental Health), but some payers may use other STCs, such as `BH` (Behavioral Health), `A4` (Psychiatric) or `SA` (Substance Abuse) for related services.
You should also check all `benefitsInformation` objects with relevant `serviceTypeCodes` values because the same STC is typically repeated across multiple `benefitsInformation` objects in the response.
* Each object communicates a different aspect of benefits, such as coverage status, co-pays, or deductibles.
* Payers also use multiple objects 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.
**Example**
The following three `benefitsInformation` objects all have the same `serviceTypeCodes` value of `CF`, which corresponds to `Mental Health Provider - Outpatient`. However, the `code` property is different for each object, indicating that they describe different aspects of the benefits:
* The first object has `code` = `1`, indicating that the patient has active coverage for outpatient mental health services.
* The second object has `code` = `C`, indicating that the patient has a $1000 deductible for outpatient mental health services.
* The third object has `code` = `D`, indicating that the patient has a benefit description that qualifies the coverage for outpatient mental health services.
{/* schema:BenefitsInformation:unwrapArray */}
```json
"benefitsInformation": [
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": ["CF"],
"serviceTypes": [
"Mental Health Provider - Outpatient"
],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "INCLUSIONS SPEECH/PHYSICAL/OCCUPATIONAL THERAPY; APPLIED BEHAVIOR ANALYSIS (ABA)"
}
]
},
{
"code": "C",
"name": "Deductible",
"serviceTypeCodes": ["CF"],
"serviceTypes": [
"Mental Health Provider - Outpatient"
],
"benefitAmount": "1000",
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes"
},
{
"code": "D",
"name": "Benefit Description",
"serviceTypeCodes": ["CF"],
"serviceTypes": [
"Mental Health Provider - Outpatient"
],
"additionalInformation": [
{
"description": "EXCLUSIONS: DEVELOPMENTAL TESTING, EDUCATIONAL THERAPY"
}
]
}
]
```
### Benefit-specific eligibility dates [#benefit-specific-eligibility-dates]
When present, the `benefitsInformation[].benefitsDateInformation` object contains dates that determine the patient's eligibility for a specific type of benefits. You should use these dates to determine the patient's eligibility for that specific benefit type instead of the dates in the `planDateInformation` object.
Payers send benefit-specific dates when certain benefits within a plan have different activation rules or waiting periods than the overall plan coverage. This can happen in a variety of scenarios, including:
* Employers may offer plans with benefits that activate based on employment duration or role. For example, Medical coverage may start on your hire date, but life insurance or disability coverage begins after 90 days.
* Some plans require a delay before certain benefits start, even though your general plan is active. For example, dental insurance may have a 6-month waiting period for major services (like crowns), but basic services (like cleanings) are covered immediately.
* Some government programs like Medicare split coverage (Part A, B, D, etc.), each with its own effective date.
* You may switch plans during open enrollment, and new benefits might have different effective dates.
### Carveout benefits [#carveout-benefits]
A carveout is when the primary payer for a plan lets another entity handle certain benefits. Carveout administrators often specialize in benefits for a particular service, such as mental health services or pharmacy benefits. For example, many Blue Cross Blue Shield (BCBS) plans carve out mental (behavioral) health benefits to Magellan, a mental health payer.
Carveouts are part of a single health plan, so they're different from secondary or tertiary insurance coverage. A patient can have carveout benefits for their primary plan and still have secondary insurance coverage through other payers.
Most payers omit carveout benefits from eligibility responses, but many include the carveout administrator's information.
#### Carveout administrator information [#carveout-administrator-information]
Don't rely on `benefitsRelatedEntities[].entityIdentifier` to identify carveout administrators because the value can vary between payers.
Instead, look for a `benefitsInformation` object that has:
* `code` = `U` (Contact Following Entity for Eligibility or Benefit Information) or `code` = `1` (Active coverage).
* `serviceTypeCodes` with [related STCs](#service-type-codes).
* a `benefitsRelatedEntities` object containing contact information. If present, `benefitsRelatedEntities[].entityIdentificationValue` contains the patient's member ID for the carveout administrator.
You should also examine `benefitsInformation` objects with `code` = `D` (Benefit Description). The `additionalInformation[].description` property may contain relevant details.
The following example shows a benefits response for a patient whose mental health benefits (`serviceTypeCodes` = `MH`) are handled by a third-party administrator called Acme Health Payer. The `description` property in the second object indicates that these benefits are managed separately.
{/* schema:BenefitsInformation:unwrapArray */}
```json
"benefitsInformation": [
{
"code": "U",
"serviceTypeCodes": [
"MH"
],
"benefitsRelatedEntities": [
{
"entityIdentifier": "Third-Party Administrator",
"entityType": "Non-Person Entity",
"entityName": "Acme Health Payer",
"entityIdentificationValue": "123456789",
"contactInformation": {
"contacts": [
{
"communicationMode": "Telephone",
"communicationNumber": "1234567890"
}
]
}
}
]
},
{
"code": "D",
"serviceTypeCodes": ["MH"],
"additionalInformation": [
{
"description": "BEHAVIORAL HEALTH MANAGED SEPARATELY"
}
]
}
]
```
#### Get carveout benefits details [#get-carveout-benefits-details]
When payers return carveout administrator information, you can:
1. Get the carveout administrator's payer ID from the [Payer Network](https://www.stedi.com/healthcare/network) or [Search Payers](/healthcare/api-reference/get-search-payers) endpoint.
2. Get the patient's member ID for the carveout administrator. It's in the `benefitsRelatedEntities[].entityIdentificationValue` property, if present.
3. Send a second eligibility check to the carveout administrator.
If you use the right STC, many carveout admins will return the missing carveout benefits. The STC may differ from the one you sent to the primary payer. Visit [STCs and procedure codes](/healthcare/eligibility-stc-procedure-codes) for tips on choosing the right STC.
If the primary payer doesn't return the carveout administrator's details, you can try checking the patient's member ID card. The back of the card often lists the carveout administrator's name and contact information. You can also try calling the primary payer and checking their website or portal.
### Pharmacy benefits [#pharmacy-benefits]
Some payers include benefits for STC `88` (Pharmacy) in eligibility responses, but these benefit entries usually only indicate that pharmacy coverage exists with `code` = `1` (Active coverage). They often don't include specific benefit details.
The following example shows a `benefitsInformation` object indicating that the patient has active pharmacy benefits.
{/* schema:BenefitsInformation */}
```json
{
"planCoverage": "Advantage Pharmacy",
"serviceTypes": ["Pharmacy"],
"serviceTypeCodes": ["88"],
"code": "1",
"name": "Active Coverage"
}
```
However, some payers do return specific pharmacy benefit details, such as co-payments and out-of-pocket maximums. The following example shows a patient's [out of pocket (stop loss)](/healthcare/eligibility-patient-responsibility-benefits#out-of-pocket-stop-loss) benefit per calendar year for pharmacy services. This is the maximum amount the patient will pay for covered pharmacy services in a year. The payer includes a note that the patient's co-payments count toward this out-of-pocket maximum.
{/* schema:BenefitsInformation */}
```json
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["88"],
"serviceTypes": ["Pharmacy"],
"benefitAmount": "6000",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"additionalInformation": [
{
"description": "Copay does apply to member's out-of-pocket maximum"
}
]
}
```
#### Pharmacy Benefits Manager [#pharmacy-benefits-manager]
Pharmacy benefits are often handled by a Pharmacy Benefits Manager (PBM), a company separate from the payer.
Information for the plan's PBM is often (but not always) returned in a `benefitsRelatedEntities` object. Don't rely solely on the `benefitsRelatedEntities[].entityIdentifier` field to identify PBMs because the value can vary between payers. Review the `entityName` and `contactInformation` to confirm that the entity is a PBM.
The following example shows a benefits response indicating that the patient's pharmacy benefits are managed by a third-party administrator called Acme Pharmacy Services.
{/* schema:BenefitsInformation */}
```json
{
"code": "U",
"name": "Contact Following Entity for Eligibility or Benefit Information",
"serviceTypeCodes": ["88"],
"serviceTypes": ["Pharmacy"],
"benefitsRelatedEntities": [
{
"entityIdentifier": "Third-Party Administrator",
"entityType": "Non-Person Entity",
"entityName": "Acme Pharmacy Services",
"contactInformation": {
"contacts": [
{
"communicationMode": "Telephone",
"communicationNumber": "1234567890"
}
]
}
}
]
}
```
#### RxBINs and RxPCNs [#rxbins-and-rxpcns]
Pharmacy Bank Identification Numbers (RxBINs) and Processor Control Numbers (RxPCNs) tell pharmacies where to send claims. RxBINs and RxPCNs are often on the member's insurance card.
Payers don't typically include these codes in eligibility responses.
### Crossover coverage [#crossover-coverage]
Crossover coverage is the process where a primary insurance payer (usually Medicare) automatically forwards claims and related information to a secondary payer (typically Medicaid or a supplemental private insurer) after processing. When there's crossover coverage, you won't need to manually resubmit claims to the secondary payer - it happens automatically.
When the patient has crossover coverage, the eligibility response may contain information about crossover carriers, such as their names and identifiers, in the `benefitsInformation[].benefitsRelatedEntities` array. However, you **shouldn't** automatically assume the responding payer will automatically forward crossover claims to those payers.
To determine whether a claim has been sent to a crossover carrier, you must review the 835 ERA. Visit [crossover claims](/healthcare/receive-claim-responses#crossover-claims) for more details.
## What are the patient's plan details? [#what-are-the-patients-plan-details]
The following details about the patient's health plan are sometimes included in the eligibility response. Not all payers return this information, and behavior can vary by payer.
### Plan name [#plan-name]
The only standard property that contains a health plan product or program name is `benefitsInformation[].planCoverage`.
Payers are only required to provide a plan name when returning Service Type Code (STC) `30`, but the plan name itself isn't tied to any specific STC. The `benefitsInformation` array can contain many entries for multiple plans, such as medical, dental, and vision.
For example, a payer might send back multiple `benefitsInformation` objects with STC `30`. Each one can have a different `planCoverage` value. You might see `"PPO DENTAL"` in one and `"PREFERRED PROVIDER OPTION MEDICAL"` in another. This just means the member has multiple plans – a dental plan and a medical plan. Each plan gets its own set of objects.
In the following example, the plan name is `Open Access Plus`:
{/* schema:BenefitsInformation */}
```json
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"planCoverage": "Open Access Plus",
"additionalInformation": [
{
"description": "Complete Care Management"
}
]
}
```
You may also be able to identify the plan name through the following properties, but they're not as reliable as `planCoverage.` Payers aren't required to return information for these properties, so behavior can vary by payer or even by plan.
* Some properties may contain a name for the group (often named for the employer if they sponsor the plan), insurance policy, or network. These properties are: `groupDescription`, `planDescription`, and `planNetworkIdDescription`. These properties may be included in the `subscriber`, `dependents`, or `benefitsInformation[].benefitsAdditionalInformation` objects, depending on where the payer places this information in the benefit response.
* Some payers may send something like a plan name in `planInformation.planDescription` or as unstructured text in `benefitsInformation[].additionalInformation[].description`.
#### BCBS home plan [#bcbs-home-plan]
Many Blue Cross Blue Shield (BCBS) payers are part of the BlueCard Program, which makes it easier to run eligibility checks for patients receiving care outside their home state. With BlueCard, you can send eligibility checks to any participating BCBS payer, and BlueCard routes them to the patient's home plan for benefits verification.
For example, if you send a request to BCBS Florida for a patient covered by BCBS Alabama, the response will include benefits information from the patient's home plan BCBS Alabama.
Stedi enriches the eligibility response with information about the patient's home plan when the eligibility check includes the member's first name, last name, birthdate, and full member ID (including the 3-character BCBS alpha prefix).
In JSON responses, Stedi returns information about the patient's home plan in a `benefitsInformation[].benefitsRelatedEntities` entry. The relevant object's `entityIdentifier` property is set to `Party Performing Verification`.
{/* schema:BenefitsInformation */}
```json
{
"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 EDI responses, Stedi returns this information in `Loop 2120C` (Subscriber Benefit Related Entity) or `Loop 2120D` (Dependent Benefit Related Entity), depending on whether the patient is the subscriber or a dependent. The `NM1-01` composite is set to `VER` (Party Performing Verification).
```
LS*2120~
NM1*VER*2*Blue Cross Blue Shield of Alabama*****PI*00510BC~
LE*2120~
```
BCBS enrichment isn't supported when:
* The patient's member ID doesn't contain the 3-character alpha prefix.
* The patient has stand-alone vision and pharmacy cards issued through an intermediary model.
* The patient's plan is a stand-alone dental product.
* The patient is part of a Federal Employee Program (FEP). In this case, the patient has `R` before their member ID.
### Plan number [#plan-number]
A plan number is the payer's unique ID for a plan. Not all payers return the patient's plan number. When returned, it can appear in multiple places, including outside the `benefitsInformation` object. Check the following properties in order:
* [`subscriber.planNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.subscriber.planNumber)
* [`benefitsInformation[].benefitsAdditionalInformation.planNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.benefitsInformation.benefitsAdditionalInformation.planNumber)
* [`planInformation.planNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.planInformation.planNumber)
### Group number [#group-number]
A group number is the payer's code for the employer or other party that purchased the plan. Employees on a group plan typically share the same group number, though there are exceptions. Some employers use different group numbers for different employee categories, like union members and management.
Not all payers return the patient's group number. When returned, it can appear in multiple places, including outside the `benefitsInformation` object. Check the following properties in order:
* [`subscriber.groupNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.subscriber.groupNumber)
* [`benefitsInformation[].benefitsAdditionalInformation.groupNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.benefitsInformation.benefitsAdditionalInformation.groupNumber)
* [`planInformation.groupNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.planInformation.groupNumber)
### Medicare Advantage plans [#medicare-advantage-plans]
A Medicare Advantage plan (also known as Medicare Part C) is a type of health plan offered by private insurance companies approved by Medicare. It provides all the benefits of standard Medicare (Parts A and B) and often includes additional services such as prescription drug coverage, vision, dental, and hearing care. Medicare Advantage plans also include an annual out-of-pocket spending limit, offering financial protection beyond what standard Medicare provides.
Here's how to identify Medicare Advantage plans in eligibility responses from commercial payers and CMS.
#### Commercial payers [#commercial-payers]
A response from a commercial payer likely contains a Medicare Advantage plan when it has any of the following properties:
* `benefitsInformation[].insuranceTypeCode` = `MA` or `MB` which correspond to `benefitsInformation[].insuranceType` = `Medicare Part A` and `Medicare Part B`, respectively.
* `planInformation.hicNumber` and/or `benefitsInformation[].benefitsAdditionalInformation.hicNumber`. These properties contain the Medicare Beneficiary Identifier (MBI), so if either of these are present, then it's almost certainly a Medicare Advantage plan.
Behavior varies by payer, so these properties may not always be included, even if the patient has a Medicare Advantage plan.
#### CMS [#cms]
A response from CMS likely contains a Medicare Advantage plan when it has the following properties:
* `benefitsInformation[].code` = `U` (which corresponds to `benefitsInformation[].name` = `Contact Following Entity for Eligibility or Benefit Information`) combined with `serviceTypeCodes` = `30`.
* `benefitsInformation[].additionalInformation[].description` - CMS provides what they call the MA Bill Option Code in this property.
The MA Bill Option code may be one of two sets of values, depending on whether the Medicare beneficiary is locked in. When a Medicare beneficiary is locked in, they can only make changes to their coverage during specific times of the year, unless they qualify for a Special Enrollment Period (SEP).
In the following code sets, the Fiscal Intermediary is what CMS refers to as a MAC.
**Medicare Beneficiary locked in to Medicare Advantage (MA)**
* `A`: Fiscal Intermediary should process all claims
* `B`: MA should process only in-plan Part A claims and in-area Part B claims
* `C`: MA should process all claims
**Medicare Beneficiary NOT locked in to Medicare Advantage (MA)**
* `1`: Fiscal Intermediary should process all claims
* `2`: MA should process only in-plan Part A claims and in-area Part B claims
# Eligibility code lists
Source: https://www.stedi.com/docs/healthcare/eligibility-code-lists
You may need to reference the following code lists when submitting eligibility checks through Stedi. Note that this page doesn’t contain every code list in the eligibility request and response; it only contains code lists that are too long to represent clearly within the [API reference documentation](/healthcare/api-reference/post-healthcare-eligibility).
## Delivery Frequency Codes [#delivery-frequency-codes]
Returned in the `benefitsInformation[].benefitsServiceDelivery[].deliveryOrCalendarPatternCode` property. This code specifies the routine shipments, deliveries, or calendar pattern.
* `1` - 1st Week of the Month
* `2` - 2nd Week of the Month
* `3` - 3rd Week of the Month
* `4` - 4th Week of the Month
* `5` - 5th Week of the Month
* `6` - 1st & 3rd Weeks of the Month
* `7` - 2nd & 4th Weeks of the Month
* `8` - 1st Working Day of Period
* `9` - Last Working Day of Period
* `A` - Monday through Friday
* `B` - Monday through Saturday
* `C` - Monday through Sunday
* `D` - Monday
* `E` - Tuesday
* `F` - Wednesday
* `G` - Thursday
* `H` - Friday
* `J` - Saturday
* `K` - Sunday
* `L` - Monday through Thursday
* `M` - Immediately
* `N` - As Directed
* `O` - Daily Mon. through Fri.
* `P` - 1/2 Mon. & 1/2 Thurs.
* `Q` - 1/2 Tues. & 1/2 Thurs.
* `R` - 1/2 Wed. & 1/2 Fri.
* `S` - Once Anytime Mon. through Fri.
* `SG`- Tuesday through Friday
* `SL` - Monday, Tuesday and Thursday
* `SP` - Monday, Tuesday and Friday
* `SX` - Wednesday and Thursday
* `SY` - Monday, Wednesday and Thursday
* `SZ` - Tuesday, Thursday and Friday
* `T` - 1/2 Tue. & 1/2 Fri.
* `U` - 1/2 Mon. & 1/2 Wed.
* `V` - 1/3 Mon., 1/3 Wed., 1/3 Fri.
* `W` - Whenever Necessary
* `X` - 1/2 By Wed., Bal. By Fri.
* `Y` - None (Also Used to Cancel or Override a Previous Pattern)
## Delivery Pattern Time Codes [#delivery-pattern-time-codes]
Returned in the `benefitsInformation[].benefitsServiceDelivery[].deliveryPatternTimeQualifierCode` property. This code specifies the time for routine shipments or deliveries.
* `A` - 1st Shift (Normal Working Hours)
* `B` - 2nd Shift
* `C` - 3rd Shift
* `D` - A.M.
* `E` - P.M.
* `F` - As Directed
* `G` - Any Shift
* `Y` - None (Also Used to Cancel or Override a Previous Pattern)
## Eligibility and benefit type codes [#eligibility-and-benefit-type-codes]
Returned in the `benefitsInformation[].code` property. Visit [Determine patient benefits](/healthcare/eligibility-active-coverage-benefits#benefit-type-codes) for a complete list.
## Employment Status Codes [#employment-status-codes]
Returned in the `subscriber.employmentStatusCode` and `dependents.employmentStatusCode` properties. These codes indicate the employment status of the subscriber or dependent as it relates to military service.
* `AE` - Active Reserve
* `AO` - Active Military - Overseas
* `AS` - Academy Student
* `AT` - Presidential Appointee
* `AU` - Active Military - USA
* `CC` - Contractor
* `DD` - Dishonorably Discharged
* `HD` - Honorably Discharged
* `IR` - Inactive Reserves
* `LX` - Leave of Absence: Military
* `PE` - Plan to Enlist
* `RE` - Recommissioned
* `RM` - Retired Military - Overseas
* `RR` - Retired Without Recall
* `RU` - Retired Military - USA
## Government Service Affiliation Codes [#government-service-affiliation-codes]
Returned in the `subscriber.governmentServiceAffiliationCode` and `dependent.governmentServiceAffiliationCode` properties. These codes indicate the government service affiliation of the subscriber or dependent as it relates to military service.
* `A` - Air Force
* `B` - Air Force Reserves
* `C` - Army
* `D` - Army Reserves
* `E` - Coast Guard
* `F` - Marine Corps
* `G` - Marine Corps Reserves
* `H` - National Guard
* `I` - Navy
* `J` - Navy Reserves
* `K` - Other
* `L` - Peace Corp
* `M` - Regular Armed Forces
* `N` - Reserves
* `O` - U.S. Public Health Service
* `Q` - Foreign Military
* `R` - American Red Cross
* `S` - Department of Defense
* `U` - United Services Organization
* `W` - Military Sealift Command
## Identification Code Qualifiers [#identification-code-qualifiers]
Returned in the `benefitsInformation[].benefitsRelatedEntities[].entityIdentification` object. This property designates the type of identifier in the `benefitsInformation[].benefitsRelatedEntities[].entityIdentificationValue` property.
* `24` - Employer's Identification Number
* `34` - Social Security Number
* `46` - Electronic Transmitter Identification Number (ETIN)
* `FA` - Facility Identification
* `FI` - Federal Taxpayer's Identification Number
* `II` - Standard Unique Health Identifier for each Individual in the United States
* `MI` - Member Identification Number
* `NI` - National Association of Insurance Commissioners (NAIC) Identification
* `PI` - Payor Identification
* `PP` - Pharmacy Processor Number
* `SV` - Service Provider Number
* `XV` - Centers for Medicare and Medicaid Services PlanID
* `XX` - Centers for Medicare and Medicaid Services National Provider Identifier
## Industry Codes [#industry-codes]
Returned in the `benefitsInformation[].eligibilityAdditionalInformationList[].industryCode` property when `benefitsInformation[].eligibilityAdditionalInformationList[].codeListQualifierCode` is set to `ZZ` - Mutually defined.
Visit the Centers for Medicare and Medicaid Services [Place of Service Code Set](https://www.cms.gov/medicare/coding-billing/place-of-service-codes/code-sets) for a complete list of codes and descriptions.
## Information Status Codes [#information-status-codes]
Returned in the `subscriber.informationStatusCode` and `dependents.informationStatusCode` properties. These codes are used to report military service data.
* `A` - Partial
* `C` - Current
* `L` - Latest
* `O` - Oldest
* `P` - Prior
* `S` - Second Most Current
* `T` - Third Most Current
## Insurance Type Codes [#insurance-type-codes]
Returned in the `benefitsInformation[].insuranceTypeCode` property. These codes indicate the type of insurance policy within a specific insurance program.
* `12` - Medicare Secondary Working Aged Beneficiary or Spouse with Employer Group Health Plan
* `13` - Medicare Secondary End-Stage Renal Disease Beneficiary in the Mandated Coordination Period with an Employer's Group Health Plan
* `14` - Medicare Secondary, No-fault Insurance including Auto is Primary
* `15` - Medicare Secondary Worker's Compensation
* `16` - Medicare Secondary Public Health Service (PHS) or Other Federal Agency
* `41` - Medicare Secondary Black Lung
* `42` - Medicare Secondary Veteran's Administration
* `43` - Medicare Secondary Disabled Beneficiary Under Age 65 with Large Group Health Plan (LGHP)
* `47` - Medicare Secondary, Other Liability Insurance is Primary
* `AP` - Auto Insurance Policy
* `C1` - Commercial
* `CO` - Consolidated Omnibus Budget Reconciliation Act (COBRA)
* `CP` - Medicare Conditionally Primary
* `D` - Disability
* `DB` - Disability Benefits
* `EP` - Exclusive Provider Organization
* `FF` - Family or Friends
* `GP` - Group Policy
* `HM` - Health Maintenance Organization (HMO)
* `HN` - Health Maintenance Organization (HMO) - Medicare Risk
* `HS` - Special Low Income Medicare Beneficiary
* `IN` - Indemnity
* `IP` - Individual Policy
* `LC` - Long Term Care
* `LD` - Long Term Policy
* `LI` - Life Insurance
* `LT` - Litigation
* `MA` - Medicare Part A
* `MB` - Medicare Part B
* `MC` - Medicaid
* `MH` - Medigap Part A
* `MI` - Medigap Part B
* `MP` - Medicare Primary
* `OT` - Other | When this code is returned by Medicare or a Medicare Part D administrator, it indicates a type of insurance of Medicare Part D.
* `PE` - Property Insurance - Personal
* `PL` - Personal
* `PP` - Personal Payment (Cash - No Insurance)
* `PR` - Preferred Provider Organization (PPO)
* `PS` - Point of Service (POS)
* `QM` - Qualified Medicare Beneficiary
* `RP` - Property Insurance - Real
* `SP` - Supplemental Policy
* `TF` - Tax Equity Fiscal Responsibility Act (TEFRA)
* `WC` - Workers Compensation
* `WU` - Wrap Up Policy
## Military Service Rank Codes [#military-service-rank-codes]
Returned in the `subscriber.militaryServiceRankCode` and `dependents.militaryServiceRankCode` properties. These codes indicate the military service rank of the subscriber or dependent.
* `A1` - Admiral
* `A2` - Airman
* `A3` - Airman First Class
* `B1` - Basic Airman
* `B2` - Brigadier General
* `C1` - Captain
* `C2` - Chief Master Sergeant
* `C3` - Chief Petty Officer
* `C4` - Chief Warrant
* `C5` - Colonel
* `C6` - Commander
* `C7` - Commodore
* `C8` - Corporal
* `C9` - Corporal Specialist 4
* `E1` - Ensign
* `F1` - First Lieutenant
* `F2` - First Sergeant
* `F3` - First Sergeant-Master Sergeant
* `F4` - Fleet Admiral
* `G1` - General
* `G4` - Gunnery Sergeant
* `L1` - Lance Corporal
* `L2` - Lieutenant
* `L3` - Lieutenant Colonel
* `L4` - Lieutenant Commander
* `L5` - Lieutenant General
* `L6` - Lieutenant Junior Grade
* `M1` - Major
* `M2` - Major General
* `M3` - Master Chief Petty Officer
* `M4` - Master Gunnery Sergeant Major
* `M5` - Master Sergeant
* `M6` - Master Sergeant Specialist 8
* `P1` - Petty Officer First Class
* `P2` - Petty Officer Second Class
* `P3` - Petty Officer Third Class
* `P4` - Private
* `P5` - Private First Class
* `R1` - Rear Admiral
* `R2` - Recruit
* `S1` - Seaman
* `S2` - Seaman Apprentice
* `S3` - Seaman Recruit
* `S4` - Second Lieutenant
* `S5` - Senior Chief Petty Officer
* `S6` - Senior Master Sergeant
* `S7` - Sergeant
* `S8` - Sergeant First Class Specialist 7
* `S9` - Sergeant Major Specialist 9
* `SA` - Sergeant Specialist 5
* `SB` - Staff Sergeant
* `SC` - Staff Sergeant Specialist 6
* `T1` - Technical Sergeant
* `V1` - Vice Admiral
* `W1` - Warrant Officer
## Provider Codes [#provider-codes]
This code list is used in the request `provider.providerCode` property. It's also returned in the following response properties:
* `provider.providerCode`
* `benefitsInformation[].benefitsRelatedEntities[].providerInformation.providerCode`
These codes indicate the type of provider.
* `AD` - Admitting
* `AT` - Attending
* `BI` - Billing
* `CO` - Consulting
* `CV` - Covering
* `H` - Hospital
* `HH` - Home Health Care
* `LA` - Laboratory
* `OT` - Other Physician
* `P1` - Pharmacist
* `P2` - Pharmacy
* `PC` - Primary Care Physician
* `PE` - Performing
* `R` - Rural Health Clinic
* `RF` - Referring
* `SB` - Submitting
* `SK` - Skilled Nursing Facility
* `SU` - Supervising
## Quantity Qualifier Codes [#quantity-qualifier-codes]
Returned in the `benefitsInformation[].quantityQualifierCode` property. These codes provide more information about the type of quantity.
* `8H` - Minimum
* `99` - Quantity Used
* `CA` - Covered - Actual
* `CE` - Covered - Estimated
* `D3` - Number of Co-insurance Days
* `DB` - Deductible Blood Units
* `DY` - Days
* `HS` - Hours
* `LA` - Life-time Reserve - Actual
* `LE` - Life-time Reserve - Estimated
* `M2` - Maximum
* `MN` - Month
* `P6` - Number of Services or Procedures
* `QA` - Quantity Approved
* `S7` - Age, High Value | Use this code when a benefit is based on a maximum age for the patient.
* `S8` - Age, Low Value | Use this code when a benefit is based on a minimum age for the patient.
* `VS` - Visits
* `YY` - Years
## Service Type Codes [#service-type-codes]
Returned in the `benefitsInformation[].serviceTypeCodes` array.
Visit [Service Type Codes](/healthcare/eligibility-active-coverage-benefits#service-type-codes) for a complete list. This list is specific to X12 version 005010, the mandated version for eligibility checks. It differs from the current [X12 Service Type Codes](https://x12.org/codes/service-type-codes) list, which applies to X12 versions later than 005010. Payers shouldn't send service type codes not explicitly listed in version 005010.
## Time Qualifier Codes [#time-qualifier-codes]
Returned in the `benefitsInformation[].timeQualifierCode` and `benefitsInformation[].benefitsServiceDelivery[].timePeriodQualifierCode` properties. These codes provide more information about the time period to which the benefit applies.
* `6` - Hour
* `7` - Day
* `13` - 24 Hours
* `21` - Years
* `22` - Service Year
* `23` - Calendar Year
* `24` - Year to Date
* `25` - Contract
* `26` - Episode
* `27` - Visit
* `28` - Outlier
* `29` - Remaining
* `30` - Exceeded
* `31` - Not Exceeded
* `32` - Lifetime
* `33` - Lifetime Remaining
* `34` - Month
* `35` - Week
* `36` - Admission
# Provider network status, authorizations, referrals
Source: https://www.stedi.com/docs/healthcare/eligibility-network-status-authorization-referrals
You have a few options for determining whether the requesting provider is in- or out-of-network for the patient. The most reliable method is contacting the payer or provider directly.
You can also use the `benefitsInformation` objects in the eligibility response to determine whether prior authorization or a referral is required for requested services.
## Is the provider in- or out-of-network? [#is-the-provider-in--or-out-of-network]
Unfortunately, you can't reliably answer this question from a standard eligibility response.
Payers typically don't explicitly indicate whether the requesting provider is in- or out-of-network for the patient (though there are some [exceptions](#additional-network-status-details)). You also can't use the [`inPlanNetworkIndicatorCode` property](#in-plan-network-indicator) for this purpose. The `inPlanNetworkIndictorCode` indicates whether the specific benefit type applies to in- versus out-of-network, not the requesting provider.
The most reliable way to determine network status is to check directly with the payer or the provider. Note that payers may have different networks for different health plans, such as employer-sponsored plans versus Medicare Advantage, and these networks may have different contact paths.
### Payer FHIR APIs [#payer-fhir-apis]
Some payers have implemented the HL7 Da Vinci PDEX Plan Net (FHIR) API, which allows you to query directly for provider network status. Here are links to these APIs for a few large, commercial payers:
* [Aetna](https://developerportal.aetna.com/welcome)
* [Cigna](https://developer.cigna.com/docs/service-apis)
* [Humana](https://developers.humana.com/provider-directory-api/doc)
* [UnitedHealthcare](https://www.uhc.com/legal/interoperability-apis)
This is not an exhaustive list, and we provide these links for convenience and reference only. Stedi can't give any additional support on how to use third-party APIs.
### Additional network status details [#additional-network-status-details]
Some payers do provide additional information about whether the requesting provider is in- or out-of-network. They may do this through either selective inclusion of benefits in the response or through freeform messages.
#### Selective inclusion of benefits [#selective-inclusion-of-benefits]
A small subset of payers selectively include portions of the eligibility response according to the provider’s network status. For example, some payers only return out-of-network benefits if the requesting provider is out-of-network. Likewise, if the provider is in-network, they only provide in-network benefits.
One example is Blue Cross and Blue Shield of New Mexico (BCBSNM). Their [270/271 Transaction Standard Companion Guide](https://www.bcbsnm.com/docs/provider/nm/nm_eligibility_benefits_270_271.pdf) states in section 5.3:
> "When local transactions are submitted, BCBSNM uses the provider type and/or provider specialty along with the providers contracting network status to determine the applicable benefits."
Stedi doesn't have a complete list of payers that selectively include or exclude benefits based on the provider's network status. The most reliable way to determine network status is to reach out to the provider or payer directly.
#### Freeform messages [#freeform-messages]
While uncommon, some payers communicate information about the requesting provider's network status using freeform messages. For example, Cigna's [270/271 Companion Guide](https://www.cigna.com/static/www-cigna-com/docs/5010-270-271-companion-guide.pdf) states:
> "When the requestor's network participation status can be determined, Cigna will send a Message on the EB1\*30 Row that indicates either the Health Care Professional (or facility) is in or out of the customer's medical network."
In Stedi's eligibility response, these types of freeform messages are typically included in the `benefitsInformation[].additionalInformation[].description` property. For example:
* `PROVIDER IS OUT NETWORK FOR MEMBER`
* `BENEFITS RETURNED BASED ON NON-AFFILIATED PROVIDER STATUS`
This `description` property may also contain information about network tier levels, since some plans have more complex benefit structures with reduced patient responsibility for higher-tier providers.
**These freeform messages are not standardized across payers and may even differ across plans for the same payer.** Again, the most reliable way to determine network status is to reach out to the provider or payer directly.
### In Plan Network Indicator [#in-plan-network-indicator]
The X12 EDI 271 eligibility response includes a data element called `EB12` (In Plan Network Indicator). Stedi represents this field as the `benefitsInformation[].inPlanNetworkIndicatorCode` property in the eligibility benefits response.
Counterintuitively, **this value doesn't indicate whether the provider is in- or -out-of-network for the patient's health plan.**
Instead, the `InPlanNetworkIndicatorCode` specifies whether the specific benefit type applies to in- vs. out-of-network. Most payers include information about both the patient’s in- and out-of-network coverage and benefits in the response, regardless of the requesting provider's network status.
Payers can send the following `inPlanNetworkIndicatorCode` values:
* `Y` - Yes
* `N` - No
* `W` - Not Applicable | This indicates that the benefit applies to **both** in and out-of-network providers.
* `U` - Unknown | This indicates that it is unknown whether the benefits apply to in- or out-of-network providers.
The example `benefitsInformation` object below shows the patient's out-of-network deductible for the calendar year, which is $7,500 dollars. The `inPlanNetworkIndicatorCode` is `N`, indicating that the deductible is applicable to services performed by providers outside the patient's network.
{/* schema:BenefitsInformation */}
```json
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "7500",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No"
}
```
## Is prior authorization required? [#is-prior-authorization-required]
Prior authorization (also called pre-authorization or pre-certification) is a requirement that the patient or their provider must get approval before a payer will cover specific services, procedures, medications, or devices. Without it, the payer may deny claims.
For example, some payers require prior authorization for:
* Elective surgeries, such as joint replacements
* Advanced imaging, such as MRIs or CT scans
* Step therapy, where a patient must try lower-cost treatments before a higher-cost one is approved
Payers use the `benefitsInformation[].authOrCertIndicator` property to indicate whether prior authorization is required for the service type code in the eligibility check. It can have the following values:
* `Y` indicates that prior authorization is required.
* `N` indicates that prior authorization is not required.
* `U` indicates that the payer is unable to confirm whether or not prior authorization is required.
The following example `benefitsInformation` object shows that prior authorization is required for anesthesia services:
{/* schema:BenefitsInformation */}
```json
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["7"],
"serviceTypes": ["Anesthesia"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitPercent": ".20",
"authOrCertIndicator": "Y"
}
```
If you don't receive the `benefitsInformation[].authOrCertIndicator` property in the response, you can assume that prior authorization is not required.
### Authorization notes [#authorization-notes]
Some payers may send additional notes about prior authorization rules in the `benefitsInformation[].additionalInformation[].description` property. Payers may also send these notes in a separate `benefitsInformation` object, typically with a code of `1` (Active coverage), `CB` (Coverage Benefit), or `D` (Benefit Description).
The following example shows a separate `benefitsInformation` object containing additional information about prior authorization requirements for imaging services:
{/* schema:BenefitsInformation */}
```json
{
"code": "CB",
"name": "Coverage Basis",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable",
"additionalInformation": [
{
"description": "PRECERTIFICATION REQUIRED FOR PET SCANS, CT/CTA SCANS, MRI/MRA SCANS."
}
]
}
```
### Handling `U` (unknown) [#handling-u-unknown]
When the `authOrCertIndicator` property is `U` (unknown), it means the payer can't determine in real time whether prior authorization is required for the service. The payer may require additional details, like diagnosis or place of service, that you can't provide using an eligibility check.
In these cases, do the following:
* Check the `benefitsInformation[].additionalInformation[].description` property for any clarification on prior authorization requirements. Also check for separate `benefitsInformation` objects that may contain `description` properties with additional information.
* Call the payer or use the payer’s provider portal to see if you can get more information. You can use an AI voice agent or screen scraper to do this programmatically.
* Use a third-party prior authorization platform. Stedi's [Platform Partner directory](https://www.stedi.com/platform-partners) includes trusted vendors that can help you get prior authorization details that aren't available through an eligibility check.
* If your payer has implemented the [HL7 Da Vinci Coverage Requirements Discovery (CRD) FHIR API](https://hl7.org/fhir/us/davinci-crd/STU2/), you can query it to determine whether a specific service requires prior authorization. For example, here's the link to [Aetna's Prior Authorization APIs](https://developerportal.aetna.com/fhirapis).
### Gold carding [#gold-carding]
Some payers offer “gold carding” programs that let certain providers skip prior authorization requirements. In some cases, gold carding is required by state law.
Unfortunately, you can't reliably get a provider's gold card status from an eligibility response. If you think a provider may qualify, check directly with the payer or provider.
### Prior authorization status [#prior-authorization-status]
Payers typically don't indicate whether the requesting provider has obtained prior authorization for services that require it. Instead, they indicate whether prior authorization is required for a specific service type code (STC) or procedure code.
If you need to check the status of an existing prior authorization, contact the payer directly or use their provider portal if they have one.
## Is a referral required? [#is-a-referral-required]
A referral is a written or electronic authorization from a primary care physician (PCP) to see a specialist or receive certain services. Some health plans won't cover specialty care without a referral.
Payers aren't required to provide information about whether referrals are required for benefits, and we can't provide a definitive list of payers who do. When this information is included, you can find it in the `benefitsInformation[].additionalInformation[].description` property. You're more likely to receive referral information for members with HMO plans.
# Patient responsibility
Source: https://www.stedi.com/docs/healthcare/eligibility-patient-responsibility-benefits
Some benefits require the patient to pay a portion of the cost of care, also known as patient responsibility. For example, a patient may have a co-payment for in-office visits.
## Where can I find patient responsibility? [#where-can-i-find-patient-responsibility]
You can use `benefitsInformation` objects with `benefitsInformation[].code` values `A`, `B`, `C`, `F`, `G`, and `Y` to determine the patient's financial responsibility for a given service type code (STC). These objects almost always contain either a `benefitAmount` or `benefitPercent` property that indicates the patient's responsibility.
The following example shows a sample response with three different types of patient responsibility:
* **Co-Payment:** The object with the `code` set to `B` shows that the patient's co-payment for pharmacy services is 10 dollars for in-network providers.
* **Deductible:** The object with the `code` set to `C` shows that the patient's deductible for general medical services is 1000 dollars per calendar year for in-network providers.
* **Co-Insurance:** The object with the `code` set to `A` shows that the patient's co-insurance for out-of-network for dental care is 0 percent for a comprehensive oral evaluation. The patient is allowed one visit every 6 months, and their last visit was on April 4, 2024.
{/* schema:BenefitsInformation:unwrapArray */}
```json
"benefitsInformation": [{
"code": "B",
"name": "Co-Payment",
"serviceTypeCodes": ["88"],
"serviceTypes": ["Pharmacy"],
"benefitAmount": "10",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes"
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "1000",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes"
},
{
"code": "A",
"name": "Co-Insurance",
"serviceTypeCodes": ["35"],
"serviceTypes": ["Dental Care"],
"benefitPercent": "0",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No",
"compositeMedicalProcedureIdentifier": {
"productOrServiceIdQualifierCode": "AD",
"procedureCode": "D0150"
},
"benefitsDateInformation": {
"latestVisitOrConsultation": "20240404"
},
"benefitsServiceDelivery": [
{
"quantityQualifierCode": "VS",
"quantityQualifier": "Visits",
"quantity": "1",
"timePeriodQualifierCode": "34",
"timePeriodQualifier": "Month",
"numOfPeriods": "6"
}
]
}]
```
### Service history [#service-history]
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. 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.
To estimate patient cost for these types of benefits, you'll need to look at two additional properties in the `benefitsInformation` object:
* `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 properties show up in responses for dental, vision, and Medicaid. They also apply to some medical services, like annual wellness visits or therapy sessions.
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.
## Types of patient responsibility [#types-of-patient-responsibility]
The following types of benefits indicate patient financial responsibility for care. Note that payers may respond with zero in the `benefitAmount` or `benefitPercent` properties when the patient has no responsibility.
If a particular benefit category is not applicable to a plan, the payer will often send nothing for that category rather than explicitly sending a zero benefit. For example, if a health plan has 20% co-insurance for STC `98` but no co-payment, then typically none of the `benefitsInformation` array entries for that STC will have `benefitsInformation[].code` = `B` (Co-Payment).
### Co-Insurance [#co-insurance]
Co-Insurance is indicated by `benefitsInformation[].code` = `A` and always includes a value for the `benefitsInformation[].benefitPercent` property.
Co-insurance represents the percentage of a benefit patients are responsible for covering themselves. For example, if a patient has met their annual deductible and their co-insurance is 20 percent, they would pay 20 dollars for a treatment that costs 100 dollars. The amount of co-insurance can differ depending on whether a provider is in-network with the health plan.
### Co-Payment [#co-payment]
Co-Payment is indicated by `benefitsInformation[].code` = `B` and always includes a value for the `benefitsInformation[].benefitAmount` property.
Co-Payment represents a fixed dollar amount a patient must pay for a benefit. For example, a patient may have a 10 dollar co-payment for a physician office visit. The amount of co-payment can differ depending on whether the provider is considered in-network with the health plan.
### Cost Containment [#cost-containment]
Cost Containment is indicated by `benefitsInformation[].code` = `J` and always includes a value for the `benefitsInformation[].benefitAmount` property.
Cost Containment refers to rules that a health plan may have in place to control the cost of care. It's typically included in the eligibility response when the patient has Medicaid coverage and represents the total amount the patient will have to pay out of their own pocket before their benefits begin.
### Deductible [#deductible]
Deductible is indicated by `benefitsInformation[].code` = `C` and always includes a value for the `benefitsInformation[].benefitAmount` property.
A deductible represents the total amount the patient will have to pay out of their own pocket before their benefits begin. For example, if a patient's deductible is 1,000 dollars, they will have to pay 1,000 dollars for covered services before the health plan will start to pay. Then, the patient will typically pay part of the cost of services (such as co-payments) until they reach their out-of-pocket maximum.
Though behavior can vary by payer, the deductible `benefitsInformation` object is often included twice in the response for a given coverage level + service type + network status. One iteration contains a `timeQualifier` like `Calendar Year`, which indicates that the `benefitAmount` value is the patient's total annual deductible. In the second instance, the `timeQualifier` is often `Remaining`, which indicates that the `benefitAmount` value is the patient's *remaining* deductible amount (annual deductible minus what they've already spent for the calendar year).
#### No deductible for specific benefits [#no-deductible-for-specific-benefits]
Some health plans list an annual deductible amount while offering a subset of benefits with a zero deductible. The most common case is preventive care benefits, which are usually required to be covered with no deductible or copay by the Affordable Care Act. For example, a High Deductible Health Plan (HDHP) may have a 3,000 dollar annual deductible, but cover an annual wellness visit at no cost.
For benefits with a zero deductible, the patient is not required to pay any amount out of pocket before coverage begins, regardless of whether they've met their annual deductible amount. Note that a zero deductible doesn't necessarily mean that the patient will pay nothing - their health plan may still require a co-payment or co-insurance for the benefit type.
Payers may indicate that a specific benefit has a zero deductible by including a `benefitsInformation` object with `benefitsInformation[].code` = `C` and the `benefitsInformation[].benefitAmount` set to `0`. Alternatively, they may simply send a message in the `benefitsInformation[].additionalInformation[].description` property indicating that the patient has no deductible.
#### No annual deductible [#no-annual-deductible]
If the payer doesn't include a `benefitsInformation` object with `benefitsInformation[].code` = `C`, you can generally assume that the patient has no annual deductible. This behavior is common with group HMO plans, which sometimes rely only on co-insurance or co-payment for cost control, but it can also occur with other types of health plans.
Medical payers are required to return deductible information for service type code `30` (Health Benefit Plan Coverage), so if the first eligibility response for another service type code doesn't include deductible information and you suspect that a deductible may still apply, then we recommend running another eligibility check for service type code `30`.
#### Example [#example]
In the following example:
* The first object shows that the patient has 500 dollars remaining to meet their annual deductible (`timeQualifier` = `Remaining`).
* The second object shows that the patient's annual deductible is 1,000 dollars (`timeQualifier` = `Calendar Year`).
{/* schema:BenefitsInformation:unwrapArray */}
```json
"benefitsInformation": [{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"planCoverage": "GOLDLITE",
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "500",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"benefitsDateInformation": {
"benefit": "20240101-20241231"
}
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"planCoverage": "GOLDLITE",
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "1000",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"benefitsDateInformation": {
"benefit": "20240101-20241231"
}
}]
```
### Limitations [#limitations]
Limitations are indicated by `benefitsInformation[].code` = `F`. Dental and vision plans often use this benefit type to specify an annual maximum benefit amount.
The Affordable Care Act prevents most commercial health plans from imposing limits on annual or lifetime benefit amounts. However, this generally doesn't apply to government health plans and and some commercial health plans may be exempt. So we recommend checking for limitations for all plan types: medical, dental, and vision.
When present, limitations might include a value for the `benefitsInformation[].benefitAmount` property that indicates the maximum benefit amount allocated to the patient. The `description` property is also often (but not always) set to a value like "ANNUAL MAXIMUM".
The following example shows a sample response from a dental payer. The patient has an annual maximum benefit for dental care of 2500 dollars.
{/* schema:BenefitsInformation */}
```json
{
"timeQualifier": "Calendar Year",
"inPlanNetworkIndicator": "Yes",
"timeQualifierCode": "23",
"benefitAmount": "2500",
"code": "F",
"coverageLevel": "Individual",
"inPlanNetworkIndicatorCode": "Y",
"serviceTypeCodes": ["35"],
"additionalInformation": [
{
"description": "ANNUAL MAXIMUM"
}
],
"serviceTypes": ["Dental Care"],
"name": "Limitations",
"coverageLevelCode": "IND"
}
```
### Out of Pocket (Stop Loss) [#out-of-pocket-stop-loss]
This benefits type doesn't apply to most dental plans.
Out of Pocket (Stop Loss) is indicated by `benefitsInformation[].code` = `G` and always includes a value for the `benefitsInformation[].benefitAmount` property.
Out of Pocket (Stop Loss) represents the maximum amount a patient can pay per year. Once the patient reaches this limit, the health plan will pay 100 percent of the allowed amount for covered services unless some other coverage limitation (code `F` [Limitations](#limitations)) applies. For example, if a health plan has a limit of 12 covered mental health visits per year, the patient may still be responsible for covering 100 percent of visits beyond that limit even if they have met their out-of-pocket maximum.
Most health plans are required to set an out-of-pocket maximum, but health plans with provider networks are allowed to have unlimited patient responsibility for out-of-network care. If there is no `benefitsInformation` object in the response that has `benefitsInformation[].code` = `G`, the payer is indicating that the out-of-pocket maximum is unlimited.
### Spend Down [#spend-down]
Spend Down is indicated by `benefitsInformation[].code` = `Y` and always includes a value for the `benefitsInformation[].benefitAmount` property.
Spend Down is a process that allows individuals with high medical expenses to qualify for Medicaid even if their income is above the Medicaid income limit. The Spend Down `benefitAmount` represents the total amount the patient will have to pay out of their own pocket before they can receive Medicaid benefits.
## When do payers return patient responsibility? [#when-do-payers-return-patient-responsibility]
Not all service type codes (STCs) require payers to return patient responsibility information. For example, health plans are required to support inquiries for the following STCs, but aren't required to return patient responsibility information for them.
* `1` - Medical Care
* `30` - Health Plan Benefit Coverage
* `35` - Dental Care
* `88` - Pharmacy
* `AL` - Vision (Optometry)
* `MH` - Mental Health
However, health plans regulated under HIPAA **must** return any applicable patient co-insurance, co-payment, or deductible amounts for the following service type codes.
* `33` - Chiropractic
* `47` - Hospital
* `48` - Hospital Inpatient
* `50` - Hospital Outpatient
* `86` - Emergency Services
* `98` - Professional (Physician) Visit – Office
* `UC` - Urgent Care
These lists don't necessarily extend to dental or vision plans. Some payers may support returning patient responsibility information for additional STCs.
## How much is left (accumulators)? [#how-much-is-left-accumulators]
Benefit types, such as deductibles, usually include accumulator data, which indicates the amount of the benefit remaining for the calendar year. In fact, the [federally mandated](https://www.caqh.org/core/operating-rules#widget_1706047899185__operating_rules_mandate) Phase II CAQH CORE 260: Eligibility & Benefits Data Content (270/271) Rule requires HIPAA-covered health plans to return remaining deductible amounts for many commonly used service type codes (STCs), including `30` (Health Benefit Plan Coverage).
When present, accumulator information is provided in a separate `benefitsInformation` object, with the `timeQualifierCode` set to `29` for `Remaining`.
The following example shows a deductible benefit (`code`: `C`) for health benefit plan coverage (STC `30`). The `timeQualifierCode` of `29` indicates that this is the remaining amount, and the `benefitAmount` of `0` indicates that the patient has already met their deductible for the year. The `inPlanNetworkIndicatorCode` of `W` indicates that this benefit is not specific to in-network or out-of-network providers.
{/* schema:BenefitsInformation */}
```json
{
"code": "C",
"name": "Deductible",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "0",
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable"
}
```
## No Surprises Act [#no-surprises-act]
The No Surprises Act is a federal law that protects patients from surprise medical bills — especially in emergency situations or when they unknowingly receive care from out-of-network providers. Under NSA, patients also have the right to a good faith estimate for non-emergency care if they're uninsured or self-pay.
The No Surprises Act bans surprise billing (also known as balance billing) in these situations:
* **Emergency Services:** Even if patients go to an out-of-network hospital or ER, they only have to pay in-network cost-sharing. This includes services at freestanding ERs and urgent care centers licensed to provide emergency care.
* **Non-Emergency Services at In-Network Facilities:** If patients go to an in-network hospital or surgery center, but an out-of-network provider (like an anesthesiologist or radiologist) treats them, they can't be charged more than their in-network rate.
* **Air Ambulance Services:** Patients are only responsible for their in-network rate.
### Does the NSA apply? [#does-the-nsa-apply]
Payers don't typically note when the NSA applies to a patient's plan in the eligibility response. However, the NSA applies to most health plans, including fully insured and self-funded employer plans. It **doesn't** apply to:
* Ground ambulance services
* Medicare, Medicaid, TRICARE, or VA patients because these programs already have their own strong balance billing protections
* Some people with health care sharing ministries or short-term limited-duration plans
* Some unlicensed or unregulated providers
## Balance Billing Protection Act [#balance-billing-protection-act]
The Balance Billing Protection Act (BBPA) is a Washington state law that protects patients from unexpected medical bills (also known as balance billing) when they receive care from out-of-network providers. It's similar to the No Surprises Act, but it applies specifically to Washington residents with state-regulated plans. It doesn't apply to self-funded employer plans unless they opt in.
The BBPA protects patients from balance billing in the following situations:
* Emergency services, even if patients are treated by an out-of-network provider or at an out-of-network facility.
* Non-emergency services at an in-network hospital or ambulatory surgical center when patients are unknowingly treated by an out-of-network provider (like an anesthesiologist or radiologist).
In these cases, the patient only pays their normal in-network cost-share (deductible, copay, coinsurance), and the provider must work out the rest with their insurer.
### Does the BBPA apply? [#does-the-bbpa-apply]
When the BBPA applies to a patient's health plan, payers are required to note this in `benefitsInformation` objects with a `benefitsInformation[].code` of:
* `1` (Active Coverage)
* `2` (Active - Full Risk Capitation)
* `3` (Active - Services Capitated)
* `4` (Active - Services Capitated to Primary Care Physician)
* `5` (Active - Pending Investigation)
* `6` (Inactive)
* `7` (Inactive - Pending Eligibility Update)
* `8` (Inactive - Pending Investigation)
In these cases, you will see one of the following messages in the `benefitsInformation[].additionalInformation[].description` property:
> Services provided to this patient are subject to the Balance Billing Protection Act. Please see RCW 48.49.020 for details.
> Services provided to this patient are subject to the No Surprises Act. Please see RCW 48.49.020 for details.
The following example shows a `benefitsInformation` object with the BBPA message included in the `additionalInformation` array.
{/* schema:BenefitsInformation */}
```json
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"planCoverage": "Open Access Plus",
"additionalInformation": [
{
"description": "Complete Care Management",
"description": "Services provided to this patient are subject to the Balance Billing Protection Act. Please see RCW 48.49.020 for details."
}
]
}
```
# Eligibility PDF
Source: https://www.stedi.com/docs/healthcare/eligibility-pdf
Stedi generates a PDF for eligibility checks with valid 271 responses. The PDF includes a summary of the request details and a human-readable version of the 271 response.
If the response contains [`AAA` errors](/healthcare/eligibility-troubleshooting#payer-aaa-errors), the PDF displays them with their possible resolutions. When an eligibility check returns benefits information, you can use the PDF to determine:
* whether the patient has active coverage with the health plan.
* whether a patient's health plan covers the requested services.
* patient responsibility amounts, such as co-pays and deductibles.
* whether prior authorization is required for specific services.
Download a [sample PDF](/files/sample-eligibility-check-pdf.pdf) with test data.
## Retrieve the PDF [#retrieve-the-pdf]
You can retrieve the eligibility PDF by:
* Calling the [Retrieve Eligibility PDF](/healthcare/api-reference/get-eligibility-pdf) endpoint with the eligibility check's ID.
* Downloading the PDF from the eligibility check's details page within the [Stedi portal](https://portal.stedi.com/app/healthcare/eligibility). Go to the eligibility check's details page and click **Download PDF**.
## PDF structure [#pdf-structure]
The PDF has the following primary sections.
### Summary [#summary]
For successful eligibility checks, the summary section at the top clearly indicates whether Stedi found *any* service type codes (STCs) or procedure codes with active coverage in the response. You can then check the [benefits tables](#benefits) to determine which specific services are covered.
The summary section also shows details about the subscriber, payer, and provider. This includes plan details such as when coverage starts, the plan dates, and the group name and number.
If the eligibility check response contains errors, the summary section indicates that the check was **Failed** and lists the errors with possible resolutions.
### Benefits [#benefits]
The **Benefits** section contains tables listing all the benefits information returned in the response. Each row in the table corresponds to a specific benefit for a specific service type code (STC) or procedure code.
The benefits are grouped in two ways:
* The first grouping mechanism is the patient's health plan. Many eligibility responses only contain benefits for a single health plan, but some responses include benefits for multiple plans. For example, if the patient has both a primary health plan and a dental plan, the PDF will contain separate sections for each plan.
* Within each health plan section, benefits are further grouped by STC and procedure code.
The following example shows the patient's benefits for STC `30` (Health Benefit Plan Coverage). Note that their plan name **E20** is at the top of the section. The PDF notes that this is **Plan 1 of 1**, meaning that the payer returned information about a single health plan for this patient.
For each STC or procedure code, the columns in the table include:
| Column | Description |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Type** | The type of benefit, such as co-payment, deductible, or prior authorization requirement. |
| **Coverage level** | The level of coverage for the benefit, such as Individual or Family. |
| **Network indicator** | Whether the benefit applies to in-network or out-of-network providers. Note that this column only indicates whether the benefit applies to in-network or out-of-network providers in general. It doesn't indicate whether the requesting provider is in-network or out-of-network for the patient. |
| **Coverage** | The amount or details of the benefit. For rows with the **Statuses** type, this column lists whether the patient has active coverage for that STC or procedure code. For patient responsibility rows, this column lists the amount the patient is responsible for. For example, a co-payment row may list a $20 co-payment amount. |
| **Benefit** | Additional details about the benefit. This column includes the plan type, places of service, whether prior authorization is required, and any messages from the payer about the benefit. For example, a co-payment row may include a message that says "waived if admitted to hospital." |
There may be multiple benefits for the same STC and benefit type. For example, a patient may have different co-insurance amounts for in-network and out-of-network providers or for specific services within a broader STC. The **Messages** field contains notes from the payer, which typically list limitations or conditions that apply to the benefit.
In the following example, the patient has a $200 co-payment for STC `86` (Emergency Services), but the messages indicate that this co-payment is waived if the patient is admitted to the hospital.
### Request [#request]
The final **Request** section provides a human-readable version of the original 270 eligibility check request. This helps you remember what STCs and procedure codes you requested and compare that to the benefits the payer returned in the response.
## Interpret the PDF [#interpret-the-pdf]
You can use the information in the PDF to answer important questions about the patient's coverage and financial responsibility for services.
### Does the patient have coverage? [#does-the-patient-have-coverage]
The PDF indicates at the top in the **Summary** section whether there was a service type code (STC) or procedure code with active coverage returned.
Then, you can check to see if there's a **Statuses** row for the STCs or procedure codes you care about. Typically, only broad STCs (`30` and `35` for general medical and dental coverage) will have a status.
Quick reference:
* The patient has coverage when the status is **Active coverage** for the relevant STC or procedure code. You can also assume the patient has coverage when there is no status, but benefits are listed (such as co-pay or deductible amounts).
* The patient doesn't have coverage when the status is **Inactive** for an STC or procedure code. You can also assume the patient doesn't have coverage if there are no benefits listed or the payer returned a message indicating that the service isn't covered.
### What is the patient's financial responsibility? [#what-is-the-patients-financial-responsibility]
Once you've confirmed that the patient has coverage, you may want to understand their financial responsibility for services. For example, you may want to know their co-pay amount for an in-office visit or whether they've met their deductible.
Within each STC or procedure code section, the PDF includes rows for each type of patient responsibility.
The following example shows that for STC `83` (Infertility), the patient has a yearly out-of-pocket maximum of $7,500 for individual coverage and a $15,000 out-of-pocket maximum for family coverage. They also have a co-payment of $50 for in-office visits for both in and out-of-network providers.
### Is the provider in- or -out-of-network? [#is-the-provider-in--or--out-of-network]
Unfortunately, you can't reliably answer this question from a standard eligibility response. That means you also can't reliably answer this question from the generated PDF.
Payers typically don't explicitly indicate whether the requesting provider is in- or out-of-network for the patient (though there are some exceptions). The Network indicator field in the table only indicates whether the benefit applies to in-network or out-of-network providers in general. It doesn't tell you whether the requesting provider is in- or out-of-network for the patient.
Some payers do provide additional information about whether the requesting provider is in- or out-of-network. They may do this through either freeform messages or selective inclusion of benefits in the response.
For example, some payers only return out-of-network benefits if the requesting provider is out-of-network. Likewise, if the provider is in-network, they only provide in-network benefits. Stedi doesn't have a complete list of payers that selectively include or exclude benefits based on the provider's network status.
**The most reliable way to determine network status is to check directly with the payer or the provider.** Note that payers may have different networks for different health plans, such as employer-sponsored plans versus Medicare Advantage, and these networks may have different contact paths.
### Is prior authorization required? [#is-prior-authorization-required]
Prior authorization (also called pre-authorization or pre-certification) is a requirement that the patient or their provider must get approval before a payer will cover specific services, procedures, medications, or devices. Without it, the payer may deny claims.
If the payer provides prior authorization information in the eligibility response, it will be listed in the **Benefit** column for that service or procedure. The payer may also send messages about prior authorization rules.
If the payer doesn't provide prior authorization information for a service or procedure, you can assume that prior authorization isn't required.
In the following example, the patient requires prior authorization for both STC `A7` (Psychiatric - Inpatient) and STC `A8` (Psychiatric - Outpatient) services. This rule applies to both in-network and out-of-network providers.
# Review benefits in the Stedi portal
Source: https://www.stedi.com/docs/healthcare/eligibility-portal-benefits-view
You can review eligibility check results within the Stedi portal. For successful eligibility checks, you can use our filterable benefits table to determine benefits details such as:
* whether a patient's health plan covers the requested services.
* patient responsibility amounts, such as co-pays and deductibles.
* whether prior authorization is required for specific services.
## Eligibility check results [#eligibility-check-results]
To review an eligibility check's results:
1. Go to the [eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility).
2. Click the eligibility search with the patient information you want to view.
Stedi opens the eligibility search's **Overview** tab.
### Overview tab [#overview-tab]
The **Overview** tab shows details about the latest eligibility check in the eligibility search.
If the eligibility check was successful, the **Overview** tab contains:
* The check's [status](#eligibility-check-statuses)
* Patient information, such as their name, date of birth, and member ID.
* The service type code(s) you requested.
* The requesting provider's information, including their name and NPI.
* The payer's information, including their name and Payer ID.
* The patient's health plan information, including the plan names, group number, and plan begin and end dates.
* Any benefits related entities, which are commonly used to designate the patient's primary care provider (PCP), another organization that handles a specific carveout benefit type (such as telehealth mental health services), or another health plan for the patient (coordination of benefits scenarios).
### Benefits tab [#benefits-tab]
The **Benefits** tab displays the patient's benefits in filterable tables. Information in the table is grouped into sections:
* The first grouping mechanism is the patient's health plan. Many eligibility responses only contain benefits for a single health plan, but some responses include benefits for multiple plans. For example, if the patient has both a primary health plan and a dental plan, the benefits view will contain separate sections listing all of the benefits for each plan.
* Within each health plan section, benefits are further grouped by service type code (STC) and procedure code so that you can easily find and review all of the benefits for a specific set of services.
There may be multiple benefits for the same STC and benefit type. For example, a patient may have different co-insurance amounts for in-network and out-of-network providers or for specific services within a broader STC. The **Message** or **Messages** field contains notes from the payer, which typically list limitations or conditions that apply to the benefit.
In the following example, the patient has a $50 co-pay for Emergency Services (STC `86`), but the messages indicate that this co-pay is waived if the patient is admitted to the hospital.
#### Benefits filters [#benefits-filters]
Payers typically send more benefits information than you requested. You can filter the benefits table by the following criteria to review only the benefits you care about. The options for each filter type depend on the benefits data in the payer's response. For example, if the payer didn't return any family-level benefits, the **Coverage level** filter won't have a `Family` option.
{/* prettier-ignore-start */}
| Filter | Description |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Type | This is the benefit type code, such as `Co-insurance` or `Deductible`. |
| Coverage level | The coverage level. This is typically either `Individual` or `Family`, but the values can vary depending on the patient's plan. |
| Network | Whether the benefit applies to in-network providers, out-of-network providers, or both.- The payer may not send this indicator for every benefit. In these cases, the **Network indicator** field in the benefits table will be `Not set`.
- This field doesn't tell you whether the provider is in or out-of-network for the patient. To determine that, you must check directly with the payer.
|
| Service or procedure | The service type code (STC) or procedure code associated with the benefit. For example, `UC` for Urgent Care or `MH` for Mental Health. |
| Place of service | The names of place of service codes associated with the benefit. For example, `Emergency Room - Hospital` for service type code `23`. |
| Message | Messages from the payer associated with the benefit. For example, `Co-pay waived if admitted`. |
| Plan name | The name of the patient's health plan. |
{/* prettier-ignore-end */}
For example, to determine the patient's co-pay for urgent care visits with in-network providers, you might set the **Type** filter to `Co-payment`, the **Network** filter to `In-Network`, and the **Service or procedure** filter to `UC` or another relevant code.
### Eligibility check statuses [#eligibility-check-statuses]
An eligibility check can have the following statuses:
| Status | Description |
| ----------- | ----------------------------------------- |
| Active | A service with active coverage was found. |
| Failed | Coverage was not determined. |
| Inactive | Active coverage was not found. |
| Investigate | Contact the payer for more information. |
Note that an **Active** status only indicates that there was at least one service type with active coverage in the benefits response. You must check the response details to determine whether the patient has active coverage for the services you care about.
## Does the patient have coverage? [#does-the-patient-have-coverage]
The patient has coverage when the date of service is within the plan's eligibility period, and the patient has active coverage for the relevant services. Here's how to check whether these conditions are met:
1. Go to the **Overview** tab of an eligibility search.
2. Review any available **Plan begin** and/or **Plan end** dates.
If the date of service is within that range, the patient may have coverage.
1. Go to the **Benefits** tab.
2. Filter by **Service / procedure** and choose the STC(s) or procedure code(s) you care about.
The **Status** field in the **Benefit** column may show whether the patient has active coverage for the relevant STC(s) or procedure code(s). Typically, only broad STCs (`30` and `35` for general medical and dental coverage) will have a status.
* The patient has coverage when the status is **Active coverage** for the relevant STC or procedure code. You can also assume the patient has coverage when there is no status, but benefits are listed (such as co-pay or deductible amounts).
* The patient doesn't have coverage when the status is **Inactive** for an STC or procedure code. You can also assume the patient doesn't have coverage if there are no benefits listed or the payer returned a message indicating that the service isn't covered.
Eligibility searches have an **Active** status when the latest eligibility
search in the record returned at least one active benefit type. However, you
must review the benefits table to confirm that the patient has active coverage
for the STCs you care about.
## What is the patient's financial responsibility? [#what-is-the-patients-financial-responsibility]
Once you've confirmed that the patient has coverage, you may want to understand their financial responsibility for services. For example, you may want to know their co-pay amount for an in-office visit or whether they've met their deductible.
You can use the **Type** filter on the **Benefits** tab to narrow the results to specific benefits types (such as co-pay amounts) for each STC or procedure code.
The following example shows that the patient has a 20% co-insurance for Hospital - Inpatient (STC `48`) services performed by in-network providers and a 50% co-insurance for services performed by out-of-network providers. The co-insurance amounts also apply to specific services, which are listed in the **Messages** field.
## Is the provider in- or out-of-network? [#is-the-provider-in--or-out-of-network]
Unfortunately, you can't reliably answer this question from a standard eligibility response.
Payers typically don't explicitly indicate whether the requesting provider is in- or out-of-network for the patient (though there are some exceptions). The **Network indicator** field in the table only indicates whether the benefit applies to in-network or out-of-network providers in general. It doesn't tell you whether the requesting provider is in- or out-of-network for the patient.
Some payers do provide additional information about whether the requesting provider is in- or out-of-network. They may do this through either freeform messages or selective inclusion of benefits in the response.
For example, some payers only return out-of-network benefits if the requesting provider is out-of-network. Likewise, if the provider is in-network, they only provide in-network benefits. Stedi doesn't have a complete list of payers that selectively include or exclude benefits based on the provider's network status.
**The most reliable way to determine network status is to check directly with the payer or the provider.** Note that payers may have different networks for different health plans, such as employer-sponsored plans versus Medicare Advantage, and these networks may have different contact paths.
## Is prior authorization required? [#is-prior-authorization-required]
Prior authorization (also called pre-authorization or pre-certification) is a requirement that the patient or their provider must get approval before a payer will cover specific services, procedures, medications, or devices. Without it, the payer may deny claims.
If the payer provides prior authorization information in the eligibility response, it will be listed in the **Benefit** column for that service or procedure. The payer may also send messages about prior authorization rules.
If the payer doesn't provide prior authorization information for a service or procedure, you can assume that prior authorization isn't required.
# Eligibility searches view
Source: https://www.stedi.com/docs/healthcare/eligibility-searches-view
The [eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility) provides insight into your eligibility check pipeline and helps you identify, diagnose, and fix failed eligibility checks. For example, you can filter for all the eligibility checks that failed during a payer outage and retry once the payer is back online.
In the app, you can:
* Review every eligibility check you submit through the app or Stedi APIs.
* Search and filter historical eligibility checks by status, Payer ID, date, and error code.
* Edit and retry failed eligibility checks and review the details of each attempt. With the [Stedi Agent](#stedi-agent), you can resolve common recoverable errors automatically with the same best practices our Support team uses for troubleshooting.
* Use the Debug view to systematically troubleshoot failed eligibility checks until you receive a successful response from the payer.
## Example troubleshooting workflow [#example-troubleshooting-workflow]
The following example shows how the eligibility searches view can help you track and resolve eligibility check failures:
You submit an eligibility check through Stedi's [Eligibility Check
API](/healthcare/api-reference/post-healthcare-eligibility) for Nick Smith.
Stedi sends it to the payer and creates a new eligibility search record in
the app containing the request details.
The payer returns an [AAA
error](/healthcare/eligibility-troubleshooting#payer-aaa-errors) code `75` -
Subscriber/Insured Not Found. The eligibility searches view shows that the
status for the new eligibility search is `Failed`.
You open the eligibility search, diagnose the error, correct the
subscriber's first name to "Nicholas", and submit the updated eligibility
check. Stedi stores the updated request as another entry in the existing
eligibility search.
The payer returns a successful response showing active insurance coverage
for Nicholas Smith. The status of the Eligibility Search changes to
`Active`, and you can view the request and response details for both
iterations of the eligibility check - the original failure and the
successful retry - within the same eligibility search record.
## Eligibility search [#eligibility-search]
Stedi stores eligibility check requests in groups called eligibility searches.
When you submit an eligibility check through the app or API, Stedi creates a new eligibility search record. Every time you retry that eligibility check, Stedi stores the retry details within the existing eligibility search. This creates a clear timeline of troubleshooting efforts for failed requests.
### Create [#create]
You can create a new eligibility search through the app or Stedi APIs.
* **App:** Go to the [Eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility) and click **+ New eligibility check**.
* **API:** Use the [Eligibility Check API](/healthcare/api-reference/post-healthcare-eligibility) to submit an eligibility check programmatically.
Once you submit the eligibility check, Stedi creates a new eligibility search in the app.
#### External Patient ID [#external-patient-id]
You can optionally add a **External Patient ID** to the request. This should be a unique identifier for the patient in your system. Adding this identifier helps you identify eligibility checks for the same patient over time.
### Filter [#filter]
You can filter eligibility searches by the following criteria:
* **Error code:** By the [AAA code](/healthcare/eligibility-troubleshooting#payer-aaa-errors) returned by the payer. For example, `42` errors indicate a connectivity issue.
* **Payer:** By the Payer ID (62308) or business name (such as Cigna)
* **Status:** By Queued, Started, Failed, Inactive, and Active
* **Date:** A date range for when the initial eligibility check within an eligibility search was submitted. For example, a filter beginning on October 1st would only include eligibility searches with an initial submission on or after October 1st. It would *not* include an eligibility search with an initial submission on September 30th and a retry on October 1st.
* **Provider NPI:** By the National Provider Identifier (NPI) of the requesting provider.
Results are sorted by the date of the original eligibility check within the eligibility search, with the most recent listed first.
### Statuses [#statuses]
The status of an eligibility search is determined by the most recent eligibility check in the record. For example, if the most recent iteration of a check failed, the status of the entire eligibility search is `Failed`, even if a previous version of the request succeeded.
An eligibility search can have one of the following statuses:
* **Queued:** Stedi placed the eligibility check in its internal queue and will send it to the payer when resources are available. This status is common when you schedule batch eligibility check refreshes through the API or perform large bulk retries that exceed your account's concurrency budget. You can typically expect the status to change to `Started` within a few seconds.
* **Started:** Stedi sent your eligibility check to the payer and is waiting for a response.
* **Failed:** The payer returned an error code in the response. Review the error code and retry the eligibility check.
* **Inactive:** The payer's response doesn't contain an active eligibility and benefit type.
* **Active:** The payer's response contains an active eligibility and benefit type (codes 1-5). Visit [Eligibility and benefit type codes](/healthcare/eligibility-active-coverage-benefits#benefit-type-codes) for a complete list.
## Get payer details with the Stedi Agent [#get-payer-details-with-the-stedi-agent]
The Stedi Agent is an AI assistant that can answer your questions about supported payers. To use it, you must be at least an [Operator](/healthcare/accounts-and-billing#members) role within your Stedi account.
The Stedi Agent can help you:
* Determine the correct payer ID for supported payers
* Map your internal payer names to Stedi's supported payers
* Determine which payers require [transaction enrollment](/healthcare/transaction-enrollment)
* Identify which payers support medical, dental, or both use cases
* Get help with other payer-related questions
To start chatting with the Stedi Agent:
1. Go to the [Chats page](https://portal.stedi.com/app/healthcare/chats) in the Stedi portal.
2. Click **New chat** and select **Payer Finder**.
3. Type your question in the chat window and press **Enter.** For example, you could ask "What is the payer ID for Aetna?" or "Does Cigna support dental use cases?" You can also ask more complex questions, like "Which payers support dental use cases and require transaction enrollment?" Talk to Stedi Agent like you would a human support agent.
4. Ask follow-up questions as needed. You can ask multiple questions about different payers in the same chat.
The Stedi Agent will respond to your questions and display its answers in the chat window.
### Review chat history [#review-chat-history]
You can review a list of all past chats with Stedi Agent on the [Chats page](https://portal.stedi.com/app/healthcare/chats). Click any chat to open it and review the conversation. You can restart any previous chat by sending a new message. Note that this page also contains the agent's eligibility recovery attempts, which are read only.
## Review eligibility check errors [#review-eligibility-check-errors]
The [Eligibility check errors page](https://portal.stedi.com/app/healthcare/checks/reports/errors) shows a list of recent eligibility check `AAA` error codes. These are errors the payer returns when they reject your eligibility request. They specify the reasons for rejection and any recommended follow-up actions.
To go to this page, open the **Eligibility** menu in the navigation bar and select **Errors**.
The errors are grouped by error code, and you can filter the list by Payer ID. You can look up any payer's ID in the [Payer Network](https://www.stedi.com/healthcare/network). Click on an error code to review a list of all the instances of that error.
This page helps you identify patterns in eligibility check failures. For example, if you see a large number of errors with code `75` (Subscriber/Insured Not Found) for a specific payer, you might want to investigate whether there are common issues with the patient data being submitted to that payer.
Visit [Payer `AAA` errors](/healthcare/eligibility-troubleshooting#payer-aaa-errors) for a complete list of `AAA` errors and their possible causes and resolutions.
## Retry failed eligibility checks [#retry-failed-eligibility-checks]
When an eligibility check fails, you can edit the request details and resubmit it until you get a successful response. You can either retry the entire eligibility search (the latest iteration of the eligibility check) or select a specific iteration to retry.
There are three ways to retry a failed eligibility check: using the [Stedi Agent](#retry-with-the-stedi-agent), [manually resubmitting](#edit-and-retry) the request, or using [Debug view](#debug-view).
### Retry with the Stedi Agent [#retry-with-the-stedi-agent]
You can use the Stedi Agent to troubleshoot and resolve common recoverable eligibility check errors automatically. To use it, you must be at least an [Operator](/healthcare/accounts-and-billing#members) role within your Stedi account.
To resolve an eligibility check failure with the Stedi Agent:
1. Go to the [Eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility).
2. Click **Resolve with Stedi Agent** next to an eligibility search. This is button is only available next to eligibility searches with common recoverable errors.
3. The Stedi Agent opens a side panel in Debug view.
4. The Stedi Agent analyzes the eligibility request and works through best practice recovery strategies based on the error type. For example, if the payer returned an error code `75` (Subscriber/Insured Not Found), the agent may try different combinations of patient data or adjust the name format to find a match in the payer's system.
Each time the agent retries the eligibility check, it stores the new request in the same eligibility search record and it shows up in Debug view in real time. This allows you to see the history of attempts and the progression of the agent's troubleshooting efforts.
The agent only accesses data from the eligibility search it's working on. It can't access data from other searches, customers, or systems.
You can review past recovery attempts with Stedi Agent from the [Chats page](https://portal.stedi.com/app/healthcare/chats). These attempts are read only - you won't be able to send chat messages to the agent.
### Manually edit and retry [#manually-edit-and-retry]
To manually resubmit an eligibility check:
1. Go to the [Eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility).
2. Click the eligibility search you want to troubleshoot to view its details.
3. Click **Actions > Edit and retry**.
4. Update the request details as needed, and click **Submit**.
You'll know the retry was successful when the [status of the eligibility search](#statuses) is either `Active` or `Inactive`. If the status of the eligibility search is still `Failed`, you may want to try resolving in [Debug view](#debug-view) or using the [Stedi Agent](#stedi-agent), if available.
### Iterate in Debug view [#iterate-in-debug-view]
Debug view is a workspace where you can systematically troubleshoot failed eligibility checks until you receive a successful response from the payer. For example, first you might try swapping the patient's nickname (Dave) for their full name (David) to see if that returns benefits information. In the next iteration, you might try submitting the request with a different service type code or dropping the date of birth.
Debug view shows all past iterations of the eligibility check and highlights the differences between each new version of the request. You can also draft and submit new requests directly from this page. This format helps you understand what you've already tried and quickly iterate on failed requests.
To troubleshoot eligibility checks in Debug view:
1. Go to the [Eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility).
2. Click the eligibility search you want to troubleshoot to view its details.
3. Click **Actions > Debug** to enter Debug view.
4. Click **+ Add draft** to create a new draft request. Stedi pre-populates the draft with the details from the most recent eligibility check in the search.
5. Update the draft request as needed. Use the **Edit columns** list to show or hide specific fields in the request.
6. Click the green arrow when you're ready to submit the updated eligibility check draft.
Stedi runs the check and moves it to the list of **Past checks**. Stedi highlights the differences between it and other past checks so you can see a clear record of your troubleshooting efforts. You can repeat this process as many times as needed to get a successful response.
## Link to specific eligibility checks [#link-to-specific-eligibility-checks]
Stedi assigns a globally unique identifier to each eligibility check, formatted as `ec_`. For example: `ec_f81d4fae-7dec-11d0-a765-00a0c91e6b12`.
The unique eligibility check ID is returned in the following locations:
* **SOAP Eligibility Check endpoint:** `stedi-id` header in the HTTP response
* **JSON and Raw X12 Eligibility Check endpoints** `id` property in the JSON response
* **Poll Batch Checks endpoint:** `items.id` property in the JSON response
* **Retrieve Batch Check Statuses endpoint:** `items[].additionalInfo.eligibility.id` property in the JSON response
You can use the eligibility check ID to link directly to a specific eligibility check's results in the Stedi portal. The format for direct portal links is: `https://portal.stedi.com/app/healthcare/eligibility/{search-id}/inspect/{check-id}`, where `{search-id}` is the eligibility search ID and `{check-id}` is the unique Stedi-assigned eligibility check ID.
You can find the eligibility search ID at the top of an eligibility search's details page. Visit the [Eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility) for a list of your eligibility searches.
## Stedi Agent usage notes [#stedi-agent-usage-notes]
Please note:
* The Stedi Agent is available on all paid Stedi plans at no additional cost beyond those for related API calls.
* The agent is assistive. Outputs can be incorrect or incomplete. Verify all responses before taking any action based on them.
* You are responsible for any actions you instruct or authorize the AI service to take, including generating billable requests on your behalf.
* Your chats with the Stedi Agent aren't private - they're visible to anyone with access to your Stedi account.
# STCs and procedure codes
Source: https://www.stedi.com/docs/healthcare/eligibility-stc-procedure-codes
You're likely running an eligibility check to determine the patient's coverage and financial responsibility for particular medical or dental services, such as chiropractic or hospice care.
You can retrieve specific types of benefits information from the payer by including either a service type code (STC) or a procedure code and qualifier in your request.
However, it's not always clear which STC or procedure code to use for best results. This page explains how to choose the right STC or procedure code for your eligibility check, how to test whether a payer supports a specific STC, and how to map procedure codes to STCs when necessary.
## Should I use STCs or procedure codes? [#should-i-use-stcs-or-procedure-codes]
It depends on the type of benefits information you want to retrieve.
### Medical benefits [#medical-benefits]
You'll almost always need to submit an STC because most medical payers don't support procedure codes (CPT/HCPCS/CDT). Refer to our guidance for [choosing STCs](#choose-the-right-stc).
### Dental benefits [#dental-benefits]
Many (but not all) dental payers support procedure codes. However, we recommend:
1. First try STC `35` - especially if you need information about general dental benefits. Many payers only return comprehensive dental-specific benefits for STC `35`.
2. Try the relevant CDT code if you still need more benefits information for a specific service.
3. If the CDT code still doesn't return what you need, try the STC mapped to that CDT code. Refer to our list of [common mappings](#dental) for dental benefits.
## Choose the right STC [#choose-the-right-stc]
A Service Type Code (STC) is a two-character code that groups similar healthcare services into standard categories, such as `47` (Hospital) and `UC` (Urgent Care). STC support varies by payer:
* Not all payers support all STCs.
* Some payers only respond to the first STC you send and ignore the rest.
* Some payers completely ignore the STCs in the request and always return a default response for STC `30` (Health Benefit Plan Coverage).
* Some payers don't support multiple STCs in a single request.
* Some payers do support multiple STCs, but only a limited number per request.
When choosing an STC, we recommend:
* Send the most specific STC you can for the services you're targeting. You should [test the STCs](#test-payer-stc-support) that seem most appropriate to determine which ones yield the most benefits information. Refer to our list of [STCs for common services](#stcs-for-common-services).
* If no specific STC seems appropriate or if the payer doesn't support it, fall back to a [general benefit check](#general-benefit-checks).
* Include only one STC per request, unless you've tested the payer and confirmed they support multiple STCs in a single request *and* that the response contains better benefits information when you include more than one.
If after testing, no STC produces the benefits information you need, you may need to call the payer or visit the payer portal.
### General benefit checks [#general-benefit-checks]
Use STC `30` for general medical benefits or `35` for general dental benefits. These STCs are supported by all payers and are a good fall back when a payer doesn't support a more specific STC.
When you send STC `30` in an eligibility check, all payers must return benefits information for the following STCs when the patient's plan covers them:
* `1` (Medical Care)
* `33` (Chiropractic)
* `47` (Hospital)
* `86` (Emergency Services)
* `88` (Pharmacy)
* `98` (Professional Physician Visit - Office)
* `AL` (Vision - Optometry)
* `MH` (Mental Health)
* `UC` (Urgent Care)
[CAQH CORE-certified payers](#required-stcs-for-core-certified-payers) are required to support a broader set of STCs.
### STCs for common services [#stcs-for-common-services]
Try the following STCs in the order shown - from the most specific to more general alternatives. We recommend sending only one STC at a time, unless you've [tested the payer](#test-payer-stc-support) and confirmed they support multiple in a single request.
We've also included the mapping to specific procedure codes where possible, to make it easier to determine the right STC for your use case.
You can also try our interactive [Service Type Code Lookup](https://www.stedi.com/cpt-hcpcs-to-stc) tool.
#### Medical [#medical]
Ranges of applicable codes are represented as `rangeStart - rangeEnd`.
{/* prettier-ignore-start */}
| Procedure codes | Type of care | STCs to try |
| ---------------------------------------------------------------------------------------- | -------------------------------------------- | ---------------------------------------------------- |
| `97151 - 97157` | ABA Therapy | `BD`, `MH` |
| `97810`, `97811 - 97814` | Acupuncture | `64`, `1` |
| `96401 - 96549` | Chemotherapy | `ON`, `78`, `87`, `91`, `92` |
| `96493` | Chemotherapy, IV push | `78`, `87`, `91`, `92` |
| `96494` | Chemotherapy, additional infusion | `78`, `87`, `91`, `92` |
| `99490`, `99439`, `99491`, `99437`, `99487` | Chronic Care Management (CCM) services | `A4`, `MH`, `98`, `1` |
| too many to list | Dermatology | `3`, `98` |
| `T1032`, `T1033` | Doula | `BT`, `BU`, `BV`, `1` |
| `E1399` | Durable Medical Equipment | `DM`, `11`, `12`, `18` |
| `96375` | IV push | `92` |
| `96360`, `96365`, `96366` | IV Therapy/Infusion | `92`, `98` |
| too many to list | Maternity (professional) | `BT`, `BU`, `BV`, `69` |
| `97802` | Medical nutrition therapy | `98`, `MH`, `BZ`, `1` |
| `97803` | Medical nutrition follow-up | `98`, `MH`, `BZ`, `1` |
| too many to list | Mental health | `MH`, `96`, `98`, `A4`, `BD`, `CF` |
| `95700 - 96020` | Neurology | `98` |
| `99460`, `99463` | Newborn/facility | `65`, `BI` |
| `97165 - 97168` and `97110`, `97530`, `97112`, `97140`, `97535`, `97116`, `97129` | Occupational therapy | `AD`, `98` |
| `97110`, `97112`, `97116`, `97350`, and several others | Physical therapy | `PT`, `AE` |
| too many to list | Podiatry | `93`, `98` |
| too many to list | Primary care | `96`, `98`, `A4`, `A3`, `99`, `A0`, `A1`, `A2`, `98` |
| `99214` | Physician office visit | `1`, `98`, `BY` |
| `96130 - 96133`, `96136 - 96137` | Psychological testing evaluation | `MH`, `CF`, `A6`, `A8`, `A4`, `98`, `96` |
| `90832 - 90834`, `90836 - 90840`, `90845 - 90847`, `90849`, `90853` | Psychotherapy | `MH`, `CF`, `A6`, `A8`, `A4`, `BD`, `98`, `96` |
| too many to list | Rehabilitation | `A9`, `AA`, `AB`, `AC` |
| `98975`, `98976`, `98977`, `98980`, `98981` | Remote Therapeutic Monitoring (RTM) services | `A4`, `98`, `MH`, `92`, `DM`, `1` |
| `99304-99318` | Skilled Nursing | `AG`, `AH` |
| `92507`, `92508`, `92521`, `92522`, `92523`, `92526`, `92607`, `92609`, `92605`, `92618` | Speech Therapy | `AF`, `98` |
| `90791`, `90832`, `90834`, `90837`, `90853`, `99408`, `99409`, and `H0017-H0019` | Substance Abuse/Addiction | `AI`, `AJ`, `AK`, `MH` |
| `99202-99215`, `99421-99423`, `99441-99443`, `G2010` and `G2012` | Telehealth | `9`, `98` |
| `90867` | Transcranial magnetic stimulation | `A4`, `MH` |
{/* prettier-ignore-end */}
#### Dental [#dental]
Procedure codes are listed in ranges. For example, `D0xxx` represents CDT codes from `D0000` to `D0999`.
{/* prettier-ignore-start */}
| Procedure | Type of care | STCs to try |
| ----------------------------- | ---------------------------------------------------------------------------------------------- | ----------- |
| `D0xxx` | Diagnostic (such as evaluations and radiographs) | `23` |
| `D1xxx` | Preventive (such as prophylaxis, fluoride, and sealants) | `41` |
| `D2xxx` | Restorative (fillings and crowns not tied to implants) | `25` |
| `D3xxx` | Endodontics (such as root canals) | `26` |
| `D4xxx` | Periodontics (such as SRP and perio maintenance) | `24` |
| `D59xx` | Maxillofacial prosthetics (specifically for `D5900–D5999`, all other `D5xxx` use `39` instead) | `27` |
| `D5xxx/D6xxx`, except `D59xx` | Prosthodontics (removable and fixed, such as dentures and bridges) | `39` |
| `D7xxx` | Oral & maxillofacial surgery (such as extractions and osseous surgery) | `40` |
| `D9xxx` | Adjunctive general services (such as palliative, occlusal guards, and anesthesia) | `28` |
{/* prettier-ignore-end */}
### Full STC list [#full-stc-list]
You can include the following STCs in an eligibility check. Not all payers support all STCs, so you should always [test each payer](#test-payer-stc-support) to ensure they support the STCs you plan to use.
* The word physician in service type codes refers to any healthcare provider, including physician assistants, nurse practitioners, and other types of healthcare professionals.
* **Don't send STCs that aren't in this list.** This list is specific to X12 version 005010, the mandated version for eligibility checks. It's different from the [X12 Service Type Codes](https://x12.org/codes/service-type-codes) list, which applies to X12 versions later than 005010. Payers shouldn't accept or send STCs not explicitly listed in version 005010.
- `1` Medical Care
- `2` Surgical
- `3` Consultation
- `4` Diagnostic X-Ray
- `5` Diagnostic Lab
- `6` Radiation Therapy
- `7` Anesthesia
- `8` Surgical Assistance
- `9` Other Medical
- `10` Blood Charges
- `11` Used Durable Medical Equipment
- `12` Durable Medical Equipment Purchase
- `13` Ambulatory Service Center Facility
- `14` Renal Supplies in the Home
- `15` Alternate Method Dialysis
- `16` Chronic Renal Disease (CRD) Equipment
- `17` Pre-Admission Testing
- `18` Durable Medical Equipment Rental
- `19` Pneumonia Vaccine
- `20` Second Surgical Opinion
- `21` Third Surgical Opinion
- `22` Social Work
- `23` Diagnostic Dental
- `24` Periodontics
- `25` Restorative
- `26` Endodontics
- `27` Maxillofacial Prosthetics
- `28` Adjunctive Dental Services
- `30` Health Benefit Plan Coverage - **supported by all payers**
- `32` Plan Waiting Period
- `33` Chiropractic
- `34` Chiropractic Office Visits
- `35` Dental Care
- `36` Dental Crowns
- `37` Dental Accident
- `38` Orthodontics
- `39` Prosthodontics
- `40` Oral Surgery
- `41` Routine (Preventive) Dental
- `42` Home Health Care
- `43` Home Health Prescriptions
- `44` Home Health Visits
- `45` Hospice
- `46` Respite Care
- `47` Hospital
- `48` Hospital - Inpatient
- `49` Hospital - Room and Board
- `50` Hospital - Outpatient
- `51` Hospital - Emergency Accident
- `52` Hospital - Emergency Medical
- `53` Hospital - Ambulatory Surgical
- `54` Long Term Care
- `55` Major Medical
- `56` Medically Related Transportation
- `57` Air Transportation
- `58` Cabulance
- `59` Licensed Ambulance
- `60` General Benefits
- `61` In-vitro Fertilization
- `62` MRI/CAT Scan
- `63` Donor Procedures
- `64` Acupuncture
- `65` Newborn Care
- `66` Pathology
- `67` Smoking Cessation
- `68` Well Baby Care
- `69` Maternity
- `70` Transplants
- `71` Audiology Exam
- `72` Inhalation Therapy
- `73` Diagnostic Medical
- `74` Private Duty Nursing
- `75` Prosthetic Device
- `76` Dialysis
- `77` Otological Exam
- `78` Chemotherapy
- `79` Allergy Testing
- `80` Immunizations
- `81` Routine Physical
- `82` Family Planning
- `83` Infertility
- `84` Abortion
- `85` AIDS
- `86` Emergency Services
- `87` Cancer
- `88` Pharmacy
- `89` Free Standing Prescription Drug
- `90` Mail Order Prescription Drug
- `91` Brand Name Prescription Drug
- `92` Generic Prescription Drug
- `93` Podiatry
- `94` Podiatry - Office Visits
- `95` Podiatry - Nursing Home Visits
- `96` Professional (Physician)
- `97` Anesthesiologist
- `98` Professional (Physician) Visit - Office
- `99` Professional (Physician) Visit - Inpatient
- `A0` Professional (Physician) Visit - Outpatient
- `A1` Professional (Physician) Visit - Nursing Home
- `A2` Professional (Physician) Visit - Skilled Nursing Facility
- `A3` Professional (Physician) Visit - Home
- `A4` Psychiatric
- `A5` Psychiatric - Room and Board
- `A6` Psychotherapy
- `A7` Psychiatric - Inpatient
- `A8` Psychiatric - Outpatient
- `A9` Rehabilitation
- `AA` Rehabilitation - Room and Board
- `AB` Rehabilitation - Inpatient
- `AC` Rehabilitation - Outpatient
- `AD` Occupational Therapy
- `AE` Physical Medicine
- `AF` Speech Therapy
- `AG` Skilled Nursing Care
- `AH` Skilled Nursing Care - Room and Board
- `AI` Substance Abuse
- `AJ` Alcoholism
- `AK` Drug Addiction
- `AL` Vision (Optometry)
- `AM` Frames
- `AN` Routine Exam - Use for Routine Vision Exam only
- `AO` Lenses
- `AQ` Nonmedically Necessary Physical
- `AR` Experimental Drug Therapy
- `B1` Burn Care
- `B2` Brand Name Prescription Drug - Formulary
- `B3` Brand Name Prescription Drug - Non-Formulary
- `BA` Independent Medical Evaluation
- `BB` Partial Hospitalization (Psychiatric)
- `BC` Day Care (Psychiatric)
- `BD` Cognitive Therapy
- `BE` Massage Therapy
- `BF` Pulmonary Rehabilitation
- `BG` Cardiac Rehabilitation
- `BH` Pediatric
- `BI` Nursery
- `BJ` Skin
- `BK` Orthopedic
- `BL` Cardiac
- `BM` Lymphatic
- `BN` Gastrointestinal
- `BP` Endocrine
- `BQ` Neurology
- `BR` Eye
- `BS` Invasive Procedures
- `BT` Gynecological
- `BU` Obstetrical
- `BV` Obstetrical/Gynecological
- `BW` Mail Order Prescription Drug - Brand Name
- `BX` Mail Order Prescription Drug - Generic
- `BY` Physician Visit - Office: Sick
- `BZ` Physician Visit - Office: Well
- `C1` Coronary Care
- `CA` Private Duty Nursing - Inpatient
- `CB` Private Duty Nursing - Home
- `CC` Surgical Benefits - Professional (Physician)
- `CD` Surgical Benefits - Facility
- `CE` Mental Health Provider - Inpatient
- `CF` Mental Health Provider - Outpatient
- `CG` Mental Health Facility - Inpatient
- `CH` Mental Health Facility - Outpatient
- `CI` Substance Abuse Facility - Inpatient
- `CJ` Substance Abuse Facility - Outpatient
- `CK` Screening X-ray
- `CL` Screening Laboratory
- `CM` Mammogram, High Risk Patient
- `CN` Mammogram, Low Risk Patient
- `CO` Flu Vaccination
- `CP` Eyewear and Eyewear Accessories
- `CQ` Case Management
- `DG` Dermatology
- `DM` Durable Medical Equipment
- `DS` Diabetic Supplies
- `GF` Generic Prescription Drug - Formulary
- `GN` Generic Prescription Drug - Non-Formulary
- `GY` Allergy
- `IC` Intensive Care
- `MH` Mental Health
- `NI` Neonatal Intensive Care
- `ON` Oncology
- `PT` Physical Therapy
- `PU` Pulmonary
- `RN` Renal
- `RT` Residential Psychiatric Treatment
- `TC` Transitional Care
- `TN` Transitional Nursery Care
- `UC` Urgent Care
### Test payer STC support [#test-payer-stc-support]
We recommend testing each payer to determine which STC(s) they support and which STC(s) return the most benefits information for the services you care about.
To test whether a payer supports a specific STC:
1. Send a baseline request with just STC `30` for general medical benefits or `35` for general dental benefits.
2. Send a request with the specific STC that best matches the benefit type you want to check. For example, to check mental health benefits, you might send a request with STC `MH` (Mental Health). Use our list of [STCs for common services](#stcs-for-common-services) as a starting point.
3. Compare the baseline response with the response to the specific STC. If they're different, the payer likely supports the specific STC.
You may also want to test whether the payer supports multiple STCs in a single request:
1. Send a baseline request with just STC `30` for general medical benefits or `35` for general dental benefits.
2. Send a request with multiple STCs matching the benefit types you want to check.
3. Compare the responses. If they change based on the number of STCs, the payer likely supports multiple STCs in a single request. If not, the payer may be ignoring or only partially supporting STCs - for example, they may only be returning information for the first STC.
**Developers:** We recommend scripting your requests to speed up the testing process. Specifically, you should loop through candidate STCs and compare the responses against the baseline STC `30` or `35` response for the same patient. You can also save the `benefitsInformation` array for each STC and diff them.
## Map procedure codes to STCs [#map-procedure-codes-to-stcs]
It can be hard to map procedure codes to the right STC. For example, if a provider offers medical nutrition therapy and bills using CPT code 97802, should they use service type code `1` - Medical Care, `3` - Consultation, `MH` - Mental Health, or another option?
Unfortunately, there's no standardized mapping between procedure codes and STCs. In fact, payers themselves often don't have an explicit mapping for their own health plans. Their eligibility check systems aren't necessarily directly integrated with their claims processing systems, so when you ask them which STC to use, they may not always be able to provide a good answer.
Review our list of [STCs for common services](#stcs-for-common-services), which contains mappings to the associated procedure codes. You can also try our interactive [Service Type Code Lookup](https://www.stedi.com/cpt-hcpcs-to-stc) tool.
If you don't find the procedure code you're looking for, use the following approaches to determine the best STC for your use case:
* Review the payers' documentation for eligibility checks. Some payers provide a list of STCs they support and their mappings to procedure codes.
* If you can't find the information in the payer's documentation, contact the payer directly or reach out to [Stedi support](https://www.stedi.com/contact), and we'll contact the payer for you.
* For dental payers that don't support specific CDT codes, you can use either of these sources to map CDT codes to service type codes. You can either purchase a copy of these documents or contact Stedi support for recommendations about specific mappings:
* NDEDIC's [Companion to ASC X12 270/271](https://ndedic.org/Sys/Store/Products/1016)
* Table 6 in the American Dental Association's [Technical Report No. 1102](https://engage.ada.org/p/eg/ada-technical-report-no-1102-electronic-dental-benefits-eligibility-verification-e-book-1390?itm_source=pp-1316\&itm_component=p-related).
* If none of the above methods work, you can ask a medical coder with [AAPC certification](https://www.aapc.com/certifications) for guidance. Their familiarity with billable codes will help them make good recommendations about service type code mappings.
Once you determine the right STC code(s), we recommend maintaining an internal document that contains the mappings for the health plans you most frequently bill.
## Required STCs for CORE-Certified payers [#required-stcs-for-core-certified-payers]
CAQH CORE creates operating rules and frameworks that improve interoperability in healthcare data exchange. CORE requires certified payers to support a broader set of STC codes than those mandated for [general benefits inquiries](#general-benefit-checks).
If the plan covers the service, certified payers must return benefit information for the following STCs. Visit CAQH CORE's website for a complete list of [CORE-Certified Health Plans](https://www.caqh.org/core/core-certified-organizations-pending-and-current).
* `4` Diagnostic X-Ray
* `5` Diagnostic Lab
* `6` Radiation Therapy
* `7` Anesthesia
* `8` Surgical Assistance
* `12` DME Purchase
* `13` Ambulatory Surgery Facility
* `18` DME Rental
* `20` Second Surgical Opinion
* `30` Health Benefit Plan Coverage
* `33` Chiropractic
* `62` MRI/CAT Scan
* `65` Newborn Care
* `68` Well Baby Care
* `78` Chemotherapy
* `80` Immunizations
* `81` Routine Physical
* `82` Family Planning
* `86` Emergency Services
* `93` Podiatry
* `98` Physician Visit - Office
* `99` Physician Visit - Inpatient
* `A0` Physician Visit - Outpatient
* `A3` Physician Visit - Home
* `AD` Occupational Therapy
* `AE` Physical Medicine
* `AF` Speech Therapy
* `AG` Skilled Nursing Care
* `BG` Cardiac Rehabilitation
* `BH` Pediatric
## STCs in the eligibility response [#stcs-in-the-eligibility-response]
To determine whether the payer is returning the benefits information you need, you must check the [`benefitsInformation` array](/healthcare/api-reference/post-healthcare-eligibility#response.benefitsInformation). Each object in this array contains a `serviceTypeCodes` property that lists the applicable STCs.
The payer may send benefits information for additional STCs you didn't request - this is expected. It can also mean that the payer is ignoring the STC you sent, which is why we recommend [testing payers](#test-payer-stc-support) to determine their support for specific STCs.
The following example shows a `benefitsInformation` object that specifies a patient's co-payment ($20) for psychiatric, psychotherapy, and social work in-office visits.
```json
{
"code": "B",
"name": "Co-Payment",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "22"],
"serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
"timeQualifierCode": "27",
"timeQualifier": "Visit",
"benefitAmount": "20",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"industryCode": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"industryCode": "Office"
}
]
}
```
You should review the [STC list](/healthcare/eligibility-stc-procedure-codes#full-stc-list) to determine which STCs are relevant to the benefits you're interested in and check for all of them in the response. This is helpful because the payer may return relevant benefits under a different STC than the one you submitted. For example, mental health benefits are typically returned with STC `MH` (Mental Health), but some payers may use other STCs, such as `BH` (Behavioral Health), `A4` (Psychiatric) or `SA` (Substance Abuse) for related services.
You should also check all `benefitsInformation` objects with relevant `serviceTypeCodes` values because the same STC is typically repeated across multiple `benefitsInformation` objects in the response.
* Each object communicates a different aspect of benefits, such as coverage status, co-pays, or deductibles.
* Payers also use multiple objects 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.
To learn more about interpreting the eligibility response, visit [Determine patient benefits](/healthcare/eligibility-active-coverage-benefits).
# Eligibility troubleshooting
Source: https://www.stedi.com/docs/healthcare/eligibility-troubleshooting
A list of potential errors and possible resolutions when submitting 270/271 eligibility checks.
## Review eligibility check errors [#review-eligibility-check-errors]
The [Eligibility check errors page](https://portal.stedi.com/app/healthcare/checks/reports/errors) shows a list of recent eligibility check `AAA` error codes. These are errors the payer returns when they reject your eligibility request. They specify the reasons for rejection and any recommended follow-up actions.
To go to this page, open the **Eligibility** menu in the navigation bar and select **Errors**.
The errors are grouped by error code, and you can filter the list by Payer ID. You can look up any payer's ID in the [Payer Network](https://www.stedi.com/healthcare/network). Click on an error code to review a list of all the instances of that error.
This page helps you identify patterns in eligibility check failures. For example, if you see a large number of errors with code `75` (Subscriber/Insured Not Found) for a specific payer, you might want to investigate whether there are common issues with the patient data being submitted to that payer.
Visit [Payer `AAA` errors](#payer-aaa-errors) for a complete list of `AAA` errors and their possible causes and resolutions.
## Retry strategy [#retry-strategy]
Implementing the right retry strategy for eligibility check failures saves a lot of time and money.
At a minimum, we **strongly recommend** automatically retrying every request that fails due to payer connectivity issues. Automatic retries resolve a significant portion of these types of failures without manual intervention.
### Payer connectivity issues [#payer-connectivity-issues]
We recommend implementing automatic retries for all of the following [`AAA` error](/healthcare/eligibility-troubleshooting#payer-aaa-errors) cases. These scenarios indicate temporary payer downtime, throttling, or intermittent connectivity issues:
* `42` (Unable to Respond at Current Time)
* `42` (Unable to Respond at Current Time) and `79` (Invalid Participant Identification)
* `80` (No Response received - Transaction Terminated)
Our recommended retry strategy depends on your eligibility check workflow.
#### Real-time eligibility checks [#real-time-eligibility-checks]
For real-time eligibility checks that require a response within a few minutes, we recommend:
* Retry immediately and continue retrying for up to 2 minutes.
* The recommended retry window is based on what's acceptable in real-time human workflows. For example, a patient checking in for an appointment at their doctor's office.
* If the request is still unsuccessful, fail gracefully and escalate as needed.
#### Scheduled eligibility checks [#scheduled-eligibility-checks]
You may want to run scheduled or background eligibility checks to perform periodic refreshes for a patient population or when checking eligibility for upcoming appointments.
If you're using the [Batch Eligibility Check](/healthcare/api-reference/post-healthcare-batch-eligibility) endpoint (recommended), Stedi automatically retries checks that fail due to payer connectivity issues for up to 8 hours.
If you're submitting real-time checks that can tolerate longer wait times, we recommend:
* Wait 1 minute to perform the first retry.
* Then, exponentially increase the wait between subsequent retries to up to 30 minutes between attempts.
* We recommend retrying for at least 8 hours, but the retry window should be based on your business workflows.
### Other common error cases [#other-common-error-cases]
You should also consider the following common error cases when implementing retries:
| AAA error | HTTP status | Reason | Retry Strategy |
| --------- | ----------- | -------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| - | `429` | Request rejected before processing due to temporary capacity limits, typically from exceeding allowed concurrent requests. | Retry immediately. Monitor your open concurrent requests and replace any finished requests under your Stedi account limit. |
| `79` | `200` | Stedi successfully sent your request to the payer, but the payer rejected it. | First, retry as soon as possible with a different member and a different [NPI](/healthcare/national-provider-identifier). This helps determine whether the issue is with the original request or there is a broader issue with the payer. If you determine the issue is with the payer, follow our guidance for [payer connectivity issues](#payer-connectivity-issues). |
| `79` | `400` | Either Stedi doesn't recognize the payer ID you provided, or the payer is not configured for eligibility checks. | **Don't automatically retry.** Fix the payer ID or contact Stedi support to resolve. |
## Payer unable to find patient [#payer-unable-to-find-patient]
Sometimes, a payer can't return benefits information for a patient even when the patient exists in their system. This problem can occur for a couple reasons.
### Multiple matching records [#multiple-matching-records]
Payers can have multiple records of patients with the same name and date of birth. The payer cannot return benefits information unless they are able to identify a unique match within their system.
To avoid this issue, we recommend:
* Include all of the demographic information available for a patient.
* Include the patient's member ID, if available.
### Information discrepancies [#information-discrepancies]
There can be discrepancies between the information the provider has collected from the patient and the record the payer has in their system. These discrepancies can lead to issues returning a patient, even though a match exists. Some examples include differences in spelling the patient's name, using a nickname instead of the full name ("Nick" vs. "Nicolas"), and accidentally transposing numbers in the date of birth.
If a request fails to return the expected member in the response, we recommend progressively sending additional eligibility check requests with fewer patient identity and demographic data elements, or different combinations of those. This allows you to identify and handle cases where there are data errors or discrepancies between payer and provider data.
### Name mismatches [#name-mismatches]
If the payer fails to find a matching plan member due to a name mismatch, the `errors` array in the response typically has the `code` set to one of the following values:
* `65`: Invalid/Missing Patient Name
* `67`: Patient Not Found
* `73`: Invalid/Missing Subscriber/Insured Name
* `75`: Subscriber/Insured Not Found
These error codes are set by the payer, not by Stedi, so it's possible that other error codes could be returned.
Resolving the error may require trying different name variations until the check is successful.
* Replace any nickname or shortened name with the full legal name, for example "Robert" instead of "Bob".
* Replace any non-English or accented characters (letters with diacritical marks) such as "Ñ" or "é" with the closest equivalent within the character restrictions. Stedi automatically replaces most such characters with the usual closest equivalent but this might not match the payer's record. For example, the character "Đ" could be transliterated to "D" or "J" depending on the romanization system used.
* For compound names try using only one or the other part. You can also try try removing the separator, or changing the separator from hyphen to space, or vice versa. Some payers may ignore special or separator characters when performing name searches.
* If the patient has recently changed their name, for example due to marriage, then the name stated by the patient or printed on their ID card might not match the payer's record. Try both the current and previous name.
## CMS attestation required [#cms-attestation-required]
CMS requires providers to complete attestation (also called HETS EDI Enrollment) before running Medicare eligibility checks. This requirement applies to traditional Medicare only, not Medicare Advantage (Part C) or Part D plans.
If you submit a Medicare eligibility check without completing attestation, CMS rejects the request with an [`AAA` error](#payer-aaa-errors) with code `41` (Authorization/Access Restrictions).
To resolve this error, complete the [CMS eligibility enrollment requirement](/healthcare/create-manage-transaction-enrollments#cms-eligibility-enrollment) for the billing NPI. Attestation takes approximately 5-15 minutes per NPI.
## Portal credentials [#portal-credentials]
The following payers are some of the few that require additional credentials to process eligibility checks:
* Medicaid California (Payer ID: `100065`) | [Provider Portal](https://www.medi-cal.ca.gov/)
* Kern Family Health Care (Payer ID: `77039`) | [Provider Portal](https://provider.kernfamilyhealthcare.com/)
* AltaMed (Payer ID: `ALTAM`) | [Provider Portal](https://www.altamed.org/providers)
When submitting eligibility checks to these payers, you must include the Provider Identification Number (PIN) the requesting provider uses for the Medi-Cal program. This PIN will be different for each provider.
* **JSON endpoint**: Set the [`portalPassword`](/healthcare/api-reference/post-healthcare-eligibility#body.portalPassword) property to the provider's PIN. You can omit the [`portalUsername`](/healthcare/api-reference/post-healthcare-eligibility#body.portalUsername).
* **Raw X12 endpoint:** Include the provider's PIN in `Loop 2100B REF02` when `REF01` is set to `4A` (Personal Identification Number (PIN)).
* **Stedi portal:** To add this field to the [New eligibility check form](https://portal.stedi.com/app/healthcare/checks/create), click **Select fields** and check the box next to **Portal password**.
If you don't include the provider's PIN or if the PIN is invalid, you'll receive an [`AAA` error](#payer-aaa-errors) with code `41` (Authorization/Access Restrictions) at the `payer` or `provider` level.
## Missing member ID [#missing-member-id]
Our eligibility check endpoints require submitting at least one of the patient's member ID, date of birth, or last name in the request. However, some payers always require the member ID and reject requests without it.
Stedi tracks which payers require the member ID and returns a warning when you submit an eligibility check to one of those payers without it. The warning appears in the `warnings` array along with the [`AAA` error](#payer-aaa-errors) from the payer in the `errors` array.
```json
{
"warnings": [
{
"code": "request::270::member_id_required",
"description": "This payer requires the patient's member ID to be included in eligibility requests."
}
],
"errors": [
{
"code": "72",
"description": "Invalid/Missing Subscriber/Insured ID",
...
}
],
...
}
```
Eligibility check requirements vary by payer. If we don't know whether a payer requires the member ID for eligibility checks, we don't return a warning.
## Errors [#errors]
You may encounter the following types of errors when submitting eligibility requests.
### Stedi payer errors [#stedi-payer-errors]
Stedi returns errors when it encounters issues with the payer ID you provided.
{/* prettier-ignore-start */}
| Error message | Possible causes and resolutions |
| --------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Payer is not configured for {transaction type}. Please contact Stedi support to resolve.` | Stedi does not yet support this transaction type for this payer, or there is a mis-mapping of payer IDs. Contact us with the name of the payer, and we'll investigate the issue. |
| `Payer connection does not support {transaction type}. Please contact Stedi support to discuss connectivity options.` | Stedi has a connection to this payer, but it doesn't currently support this functionality (real-time eligibility or claim submission). Contact us for a timeline on enabling it. |
| `Payer is not configured. Please check our published payer list or contact Stedi support to resolve.` | Stedi doesn't recognize the payer ID you provided. Double-check the payer ID in the [Stedi Payer Network](https://www.stedi.com/healthcare/network), or contact us with the name of the payer, and we will help you determine the correct payer ID. |
| `Payer is not supported. Please contact Stedi support to discuss connectivity options.` | Stedi doesn't yet have connectivity to this payer. We're likely already working on it - contact us for details about the connectivity timeline. |
{/* prettier-ignore-end */}
The following error resulted from an unrecognized payer ID:
{/* schema:EligibilityCheckResponseContent */}
```json
{
"meta": {
"outboundTraceId": "01KEJ02BRD3H716AP3HRBDM5Y8"
},
"controlNumber": "602859072",
"tradingPartnerServiceId": "AHS",
"errors": [
{
"code": "79",
"description": "Invalid Participant Identification",
"followupAction": "Please Correct and Resubmit",
"location": "2100A",
"possibleResolutions": "Payer AHS is not configured. Please check our published payer list or contact Stedi support to resolve."
}
],
"status": "ERROR",
"eligibilitySearchId": "019ba401-2f01-7262-a2b8-8707b70198c9",
"id": "ec_9d6a4f2b-1c7e-4e9a-b3f8-0a2c5e1d7b84"
}
```
### Validation errors [#validation-errors]
You may receive validation errors from Stedi or, rarely, from the payer.
#### Stedi [#stedi]
Stedi validates the structure of your eligibility request and won't submit your request to the payer if it's missing required fields or if the data is formatted incorrectly. The following Stedi validation error resulted from a missing required property:
```json
{
"message": "Missing required field: provider npi, serviceProviderNumber, payorId, taxId, ssn, pharmacyProcessorNumber, servicesPlanID, or employersId is required",
"code": "BAD_REQUEST",
"eligibilitySearchId": "019ba403-e5ce-7181-8a2f-8cf093dde812",
"id": "ec_9d6a4f2b-1c7e-4e9a-b3f8-0a2c5e1d7b84"
}
```
The following shows an example of a Stedi validation error resulting from an invalid date format:
```json
{
"message": "subscriber.dateOfBirth: Provided date should be valid and in YYYYMMDD format.",
"code": "INVALID_REQUEST_BODY",
"eligibilitySearchId": "019ba405-e1ec-79e2-bde2-830664a901df",
"id": "ec_9d6a4f2b-1c7e-4e9a-b3f8-0a2c5e1d7b84"
}
```
#### Payer (999 rejections) [#payer-999-rejections]
Stedi's validation catches the majority of syntax and structural issues. However, some payers may occasionally return a [999 Implementation Acknowledgment](https://portal.stedi.com/app/guides/view/hipaa/implementation-acknowledgment-x231/01HRF41ES1DVGCA6X1EHSRPFXZ) indicating that the request was rejected.
Stedi can usually translate these 999 rejections into a more user-friendly 271 response with descriptive [`AAA` errors](#payer-aaa-errors) in the `errors` array. When Stedi can't generate a 271, we return the raw 999 in the `x12` property, set the `status` to `ERROR`, and include the number of EDI syntax errors in the `implementationTransactionSetSyntaxError` property. The `errors` array includes a general description indicating that the payer rejected the request due to validation errors.
The following example shows a 999 that resulted from sending the payer more than one STC code in the request:
{/* schema:EligibilityCheckResponseContent */}
```json
{
"id": "ec_019c00bb-2293-7241-b283-9b94642b4ec4",
"transactionSetAcknowledgement": "R",
"tradingPartnerServiceId": "TESTPAYER",
"errors": [
{
"description": "The payer or intermediary clearinghouse rejected the request with validation errors. The original EDI response is returned in the `x12` field. Contact Stedi Support if you need further help."
}
],
"implementationTransactionSetSyntaxError": "5",
"controlNumber": "123456789",
"x12": "ISA*00* *00* *ZZ*STEDI *01*11234567890 *260127*1032*^*00501*000000000*0*P*:~GS*FA*STEDI*11234567890*20260127*1032*0*X*005010X231A1~ST*999*0001*005010X231A1~AK1*HS*1*005010X231A1~AK2*270*0001~IK3*EQ*12**8~IK4*1*0*5*32~IK5*R*5~AK9*R*1*1*0~SE*8*0001~GE*1*0~IEA*1*000000000~",
"meta": {
"outboundTraceId": "01KG0BP8NA69HK7095HE8XG03F"
},
"status": "ERROR",
"eligibilitySearchId": "019c00bb-229e-72c3-8585-8b28f0556a38"
}
```
### Payer AAA errors [#payer-aaa-errors]
When a payer rejects your eligibility check, the 271 response contains one or more [`AAA` Request Validation segments](https://portal.stedi.com/app/guides/view/hipaa/health-care-eligibility-benefit-response-x279a1/01GS66YHZPB37ABF34DBPSR213#properties.detail.properties.information_source_level_HL_loop.items.properties.request_validation_AAA) that specify the reasons for the rejection and any recommended follow-up actions. Stedi includes this information in the `aaaErrors` object in the response JSON.
Common causes for AAA errors include:
* Missing or incorrect information for the subscriber, dependent, provider, or payer. In this case, you should correct any errors before resubmitting.
* Issues with payer [enrollment](/healthcare/credentialing-and-enrollment). Many of these issues require that the provider contact the payer directly to resolve, due to PHI/HIPAA guidelines.
* The payer's system is down or experiencing issues. In this case, the payer may not have actually validated the data in your request. If you receive these types of errors, you should wait a few minutes and resend the request again.
Each error contains a `followupAction`:
* Please Correct and Resubmit
* Resubmission Not Allowed | Note that this code doesn't mean you should never resubmit the request. Intermediary clearinghouses may send this code when they have temporarily lost connection to the payer, so this code indicates that you should wait at least a few minutes before retrying instead of retrying immediately.
* Resubmission Allowed
* Do Not Resubmit; Inquiry Initiated to a Third Party | This code is uncommon
* Please Resubmit Original Transaction
* Please Wait 30 Days and Resubmit | This code is uncommon
* Please Wait 10 Days and Resubmit | This code is uncommon
* Do not resubmit; We Will Hold Your Request and Respond Again Shortly | This code is uncommon
AAA errors can be present at multiple different levels in the response, depending on the type. The following example shows an error at the subscriber level (`subscriber.aaaErrors`):
{/* schema:EligibilityCheckResponseContent */}
```json
{
"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."
}
]
}
}
```
However, all errors at the `payer`, `provider`, `subscriber`, and `dependents` levels are also reported in the top-level `errors` array in the eligibility check response.
Visit [Eligibility mock requests](/healthcare/api-reference/mock-requests-eligibility-checks)
to retrieve more examples of common AAA errors in eligibility responses.
To help with troubleshooting, we include additional strings containing
possible causes and resolutions for each `AAA` error. We periodically update
this guidance, so these strings may change at any time and may differ between
eligibility responses. **Don't build programmatic logic that depends on
matching these strings exactly.**
#### Payer [#payer]
You may receive the following types of errors at the `payer` level.
{/* prettier-ignore-start */}
| Code | Description | Possible causes and resolutions |
| ---- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `04` | Authorized Quantity Exceeded | You included too many patients in the request - you can only request benefits information for one patient at a time. - When the patient is the subscriber, put their details in the `subscriber` object.
- When the patient is the dependent, put the subscriber's details in the `subscriber` object and the patient's details in the `dependents` array.
|
| `41` | Authorization/Access Restrictions | The problem is either:- An issue with the `provider.npi` or `provider.federalTaxpayersIdNumber`. This typically indicates that the provider isn't properly [enrolled](https://www.stedi.com/docs/healthcare/credentialing-and-enrollment) with the payer.
- An issue with the `portalPassword` or `portalUsername` you provided.
|
| `42` | Unable to Respond at Current Time | The payer can't respond to your request. This is typically a temporary issue with the payer's system, such as downtime, but it can also be an extended outage. We recommend retrying immediately and continuing to retry for up to 2 minutes. Learn more about our [recommended retry strategy](/healthcare/eligibility-troubleshooting#payer-connectivity-issues) for payer connectivity issues. |
| `79` | Invalid Participant Identification | There is a problem connecting with this payer. Contact Stedi support. |
| `80` | No Response received - Transaction Terminated | The payer can't respond to your request. This is typically a temporary issue with the payer's system, such as downtime, but it can also be an extended outage. We recommend retrying immediately and continuing to retry for up to 2 minutes. Learn more about our [recommended retry strategy](/healthcare/eligibility-troubleshooting#payer-connectivity-issues) for payer connectivity issues. |
| `T4` | Payer Name or Identifier Missing | The problem is either:- An issue with the `tradingPartnerName` or `tradingPartnerServiceId`. Check the [Payer Network](https://www.stedi.com/healthcare/network) to ensure you're using valid values.
- A payer processing issue. If the issue persists, contact Stedi support to resolve.
|
{/* prettier-ignore-end */}
#### Provider [#provider]
You may receive the following types of errors at the `provider` level.
{/* prettier-ignore-start */}
| Code | Description | Possible causes and resolutions |
| ---- | -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `15` | Required application data missing | The payer needs more information about the provider requesting the eligibility check. Try including the `provider.taxId`, typically their EIN or SSN. |
| `41` | Authorization/Access Restrictions | The problem is either: - An issue with the `provider.npi` or `provider.federalTaxpayersIdNumber`. This typically indicates that the provider isn't properly [enrolled](/healthcare/credentialing-and-enrollment) with the payer.
- An issue with the `portalPassword` or `portalUsername` you provided.
- The payer may require other [credentialing or enrollment processes](/healthcare/credentialing-and-enrollment).
|
| `43` | Invalid/Missing Provider Identification | The problem is either: - The `provider.npi` isn't registered correctly with the payer.
- The payer requires an agreement to begin processing eligibility checks for this provider.
Check the [Payer Network](https://www.stedi.com/healthcare/network) to determine whether this payer requires transaction enrollment for eligibility checks. - If yes, you must submit a [transaction enrollment request](/healthcare/transaction-enrollment) for the provider.
- If not, the payer may still require other [credentialing or enrollment processes](/healthcare/credentialing-and-enrollment).
|
| `44` | Invalid/Missing Provider Name | The provider's NPI is registered with an incorrect name for this payer. - Verify that the `provider.organizationName` or the `provider.firstName` and `provider.lastName` are correct. If so, the provider must contact the payer directly to resolve this issue due to PHI/HIPAA guidelines.
- The payer may require other [credentialing or enrollment processes](/healthcare/credentialing-and-enrollment).
|
| `45` | Invalid/Missing Provider Specialty | The provider's NPI isn't registered with the payer under the correct specialty. The provider must contact the payer directly to resolve this issue due to PHI/HIPAA guidelines. The payer may require other [credentialing or enrollment processes](/healthcare/credentialing-and-enrollment). |
| `46` | Invalid/Missing Provider Phone Number | The provider's phone number doesn't match the one registered with the payer or the one in the NPPES system. The provider must contact the payer directly to resolve this issue because of PHI/HIPAA guidelines. The payer may require other [credentialing or enrollment processes](/healthcare/credentialing-and-enrollment). |
| `47` | Invalid/Missing Provider State | The `provider.address` either doesn't match the address registered with the payer or it doesn't match the provider's address in the NPPES system. - Ensure the information in `provider.address` is correct.
- If so, the provider must contact the payer directly to resolve this issue due to PHI/HIPAA guidelines. The payer may require other [credentialing or enrollment processes](/healthcare/credentialing-and-enrollment).
|
| `48` | Invalid/Missing Referring Provider Identification Number | The referring provider (specified in `subscriber.providerIdentifier`) either: - Isn't enrolled correctly with the payer. Contact Stedi support to resolve.
- Isn't registered with the payer's health plans. The provider must contact the payer directly to complete the registration process.
- Must complete additional [credentialing or enrollment processes](/healthcare/credentialing-and-enrollment) with the payer.
|
| `50` | Provider Ineligible for Inquiries | The provider requesting the eligibility check isn't registered with the payer for the service type in `encounter.serviceTypeCodes`. - Ensure the `provider.npi` and `encounter.serviceTypeCodes` are correct.
- If so, the provider must contact the payer directly to complete the registration process. Contact Stedi support with questions.
|
| `51` | Provider Not on File | The provider isn't registered with the payer. - Ensure the `provider.npi` is correct.
- If so, the provider must contact the payer directly to complete the registration process. This can include [credentialing and/or enrollment](/healthcare/credentialing-and-enrollment). Contact Stedi support with questions.
|
| `79` | Invalid Participant Identification | There is a problem connecting with this payer. Contact Stedi support. |
| `97` | Invalid or Missing Provider Address | The payer requires the address for the provider requesting the eligibility check. Retry with the provider's complete address in the `provider.address` object. |
| `T4` | Payer Name or Identifier Missing | The problem is either: - An issue with the `tradingPartnerName` or `tradingPartnerServiceId`. Check the [Payer Network](https://www.stedi.com/healthcare/network) to ensure you're using valid values.
- A payer processing issue. If the issue persists, contact Stedi support to resolve.
|
{/* prettier-ignore-end */}
#### Subscriber [#subscriber]
You may receive the following types of errors at the `subscriber` level.
{/* prettier-ignore-start */}
| Code | Description | Possible causes and resolutions |
| ---- | ---------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `15` | Required application data missing | - The payer likely needs more information about the subscriber to complete the eligibility check. We recommend providing the subscriber's `memberId`, `dateOfBirth`, `firstName`, and `lastName`. Given this information, all payers must return benefits details as long as they can find a unique match for the member within their system. Visit [patient information](/healthcare/send-eligibility-checks#patient-information) to learn more.
- Try including the `provider.taxId`, typically their EIN or SSN.
|
| `33` | Input Errors | The request doesn't meet the payer’s requirements, which usually means it doesn't contain enough information to identify the patient. We recommend providing the subscriber's `memberId`, `dateOfBirth`, `firstName`, and `lastName`. Given this information, all payers must return benefits details as long as they can find a unique match for the member within their system. Visit [patient information](/healthcare/send-eligibility-checks#patient-information) to learn more. |
| `35` | Out of Network | The subscriber isn't in the provider's network. - Verify that the `provider.npi` is valid.
- If yes, contact the payer for clarification.
|
| `42` | Unable to Respond at Current Time | The payer can't respond to your request. This is typically a temporary issue with the payer's system, such as downtime, but it can also be an extended outage. We recommend retrying immediately and continuing to retry for up to 2 minutes. Learn more about our [recommended retry strategy](/healthcare/eligibility-troubleshooting#payer-connectivity-issues) for payer connectivity issues. |
| `43` | Invalid/Missing Provider Identification | The problem is either: - The `provider.npi` isn't registered correctly with the payer.
- The payer requires an agreement to begin processing eligibility checks for this provider.
Check the [Payer Network](https://www.stedi.com/healthcare/network) to determine whether this payer requires transaction enrollment for eligibility checks. - If yes, you must submit a [transaction enrollment request](/healthcare/transaction-enrollment) for the provider.
- If not, the payer may still require other [credentialing or enrollment processes](/healthcare/credentialing-and-enrollment). Contact Stedi support to determine next steps.
|
| `45` | Invalid/Missing Provider Specialty | The `provider.npi` isn't registered with the payer under the correct specialty. The provider must contact the payer directly to resolve this issue due to PHI/HIPAA guidelines. |
| `47` | Invalid/Missing Provider State | The `provider.address` either doesn't match the address registered with the payer, or it doesn't match the provider's address in the NPPES system. - Ensure the information in `provider.address` is correct.
- If so, the provider must contact the payer directly to resolve this issue due to PHI/HIPAA guidelines.
|
| `48` | Invalid/Missing Referring Provider Identification Number | The referring provider (specified in `subscriber.providerIdentifier`) either: - Isn't enrolled correctly with the payer. Contact Stedi support to resolve.
- Isn't registered with the payer's health plans. The provider must contact the payer directly to complete the registration process. Contact Stedi support with questions.
|
| `49` | Provider is Not Primary Care Physician | The payer doesn’t list the provider as a primary care physician but requires them to be one. The provider or the patient must contact the payer to update their records. |
| `51` | Provider Not on File | The provider isn't registered with the payer. - Ensure the `provider.npi` is correct.
- If so, the provider must contact the payer directly to complete the registration process. This can include [credentialing and/or enrollment](/healthcare/credentialing-and-enrollment). Contact Stedi support with questions.
|
| `52` | Service Dates Not Within Provider Plan Enrollment | The provider wasn't registered with the patient's health plan on the date of service listed in the eligibility check. - Verify that the `provider.npi` and the service dates in the `encounter` object are correct.
- If so, the provider must contact the payer directly to resolve this issue.
|
| `53` | Inquired Benefit Inconsistent with Provider Type Enrollment | The provider isn't registered with the payer to perform the requested benefit type. Some payers only return benefits that match the provider's taxonomy code.- Verify that the `provider.npi` is correct.
- Verify that the `serviceTypeCodes` or the `procedureCode` and `productOrServiceIDQualifier` in the `encounter` object are correct.
- Check the provider taxonomy you sent in `provider.referenceIdentification`. It should match what's recorded in the payer's system.
- If the issue persists, the provider must contact the payer directly to resolve.
|
| `54` | Inappropriate Product/Service ID Qualifier | You provided an invalid `encounter.productOrServiceIDQualifier`. Update the request and resubmit. |
| `55` | Inappropriate Product/Service ID | You provided an invalid `encounter.procedureCode`. Update the request and resubmit. |
| `56` | Inappropriate Date | The service dates in the `encounter` object are incorrect or are formatted incorrectly. . - Dates must be in YYYYMMDD format.
- We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers do support dates further in the future, especially the next calendar month. Check the payer's documentation to determine their specific behavior.
|
| `57` | Invalid/Missing Date(s) of Service | The service dates in the `encounter` object are missing, incorrect, or formatted incorrectly. - Dates must be in YYYYMMDD format.
- We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers do support dates further in the future, especially the next calendar month. Check the payer's documentation to determine their specific behavior.
|
| `58` | Invalid/Missing Date-of-Birth | The payer needs the subscriber's date of birth for identification. - Include `subscriber.dateOfBirth` in the request.
- The date should be in YYYYMMDD format.
|
| `60` | Date of Birth Follows Date(s) of Service | The date(s) of service you provided are earlier than the subscriber's date of birth. - Check the service dates in the `encounter` object.
- Check the `subscriber.dateOfBirth`.
- If this eligibility check is for a newborn, resubmit it with the mother's information instead.
|
| `61` | Date of Death Precedes Date(s) of Service | The date(s) of service you provided are after the patient's date of death. - Check the service dates in the `encounter` object.
- Note that if you don't provide a service date in the request, the payer defaults to using the current date in their timezone.
|
| `62` | Date of Service Not Within Allowable Inquiry Period | The payer doesn't support the date(s) of service you provided.- Check the service dates in the `encounter` object.
- We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers do support dates further in the future, especially the next calendar month. Check the payer's documentation to determine their specific behavior.
|
| `63` | Date of Service in Future | Some payers don't support future date(s) of service.- Check the service dates in the `encounter` object.
- Check the payer's specific requirements.
|
| `69` | Inconsistent with Patient’s Age | The diagnosis codes provided don't match the patient's age. - Check the `subscriber.dateOfBirth`.
- Check any `subscriber.healthCareCodeInformation[].diagnosisCode` values.
|
| `70` | Inconsistent with Patient’s Gender | The procedure codes provided are inconsistent with the patient's gender. - Check `subscriber.gender`.
- Check the values in `encounter.procedureCode` or `encounter.medicalProcedures[].procedureCode`.
|
| `71` | Patient Birth Date Does Not Match That for the Patient on the Database | The subscriber's birth date doesn't match what's in the payer's database. - Check that the `subscriber.dateOfBirth` is correct.
- If so, contact the payer to resolve this issue.
|
| `72` | Invalid/Missing Subscriber/Insured ID | The subscriber's member ID is either missing or invalid.- Check the `subscriber.memberId`.
- Ensure the member ID doesn't include the [Card Issuer Identifier](/healthcare/eligibility-troubleshooting#card-issuer-identifier-80840).
- If you can't locate the correct member ID, try running an [insurance discovery check](/healthcare/insurance-discovery) to retrieve the patient's benefits information instead.
|
| `73` | Invalid/Missing Subscriber/Insured Name | The payer doesn't recognize the subscriber's name. - Verify that the `subscriber.firstName` and `subscriber.lastName` are valid and spelled correctly.
- Enter the patient's name exactly as it appears on their insurance card, if available, including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces. Review our other best practices for [entering patient names](/healthcare/send-eligibility-checks#patient-names).
|
| `74` | Invalid/Missing Subscriber/Insured Gender Code | The payer requires the subscriber's gender code. Ensure `subscriber.gender` is set to a valid value that matches the payer's records. |
| `75` | Subscriber/Insured Not Found | The payer couldn't locate the subscriber in their database. - We recommend providing the subscriber's `memberId`, `dateOfBirth`, `firstName`, and `lastName`. Given this information, all payers must return benefits details as long as they can find a unique match for the member within their system.
- Enter the patient's name exactly as it appears on their insurance card, if available, including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces. Review our other best practices for [entering patient names](/healthcare/send-eligibility-checks#patient-names).
- Sometimes patients provide outdated insurance information for the wrong payer. If the issue persists, try running an [insurance discovery check](/healthcare/insurance-discovery) to retrieve the patient's benefits information instead.
|
| `76` | Duplicate Subscriber/Insured ID Number | The payer found another member with the same member ID in their database. Ensure the `subscriber.memberId` is correct. |
| `78` | Subscriber/Insured Not in Group/Plan identified | The subscriber isn't in the specified health plan. - Verify that the `subscriber.memberId` and `subscriber.groupNumber` are correct.
- If so, contact the payer directly to resolve this issue.
|
| `98` | Experimental Service or Procedure | Contact the payer for guidance. |
| `Aa` | Authorization Number Not Found | The prior authorization number the payer has on file doesn't match the one you sent. Verify that the `encounter.priorAuthorizationOrReferralNumber` is correct. |
| `AE` | Requires Primary Care Physician Authorization | The payer requires a prior authorization number. Add the `encounter.priorAuthorizationOrReferralNumber` to your request and resubmit. |
| `AF` | Invalid/Missing Diagnosis Code(s) | The payer requires one or more diagnosis codes, or the diagnosis codes you provided are invalid. Ensure the information in the `subscriber.healthCareCodeInformation[]` array is correct. |
| `AG` | Invalid/Missing Procedure Code(s) | The payer requires a procedure code or the procedure code you provided is invalid. Ensure `encounter.productOrServiceIDQualifier` and `encounter.procedureCode` are set to valid values. |
| `AO` | Additional Patient Condition Information Required | Contact the payer for guidance. |
| `CI` | Certification Information Does Not Match Patient | The prior authorization number the payer has on file doesn't match the one you sent. Verify that the `encounter.priorAuthorizationOrReferralNumber` is correct. |
| `E8` | Requires Medical Review | Contact the payer for guidance. |
| `IA` | Invalid Authorization Number Format | The `encounter.priorAuthorizationOrReferralNumber` wasn't formatted correctly. |
| `MA` | Missing Authorization Number | You must include a previously issued referral or authorization number in your request. Set the `encounter.referenceIdentificationQualifier` and `encounter.priorAuthorizationOrReferralNumber` properties and resubmit. |
{/* prettier-ignore-end */}
#### Dependents [#dependents]
You may receive the following errors at the `dependents` level.
{/* prettier-ignore-start */}
| Code | Description | Possible causes and resolutions |
| ---- | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `15` | Required application data missing | - The payer needs more information about the dependent to complete the eligibility check. We recommend providing the dependent's `firstName`, `lastName`, and `dateOfBirth`, when possible. Many payers return errors when the dependent's date of birth is missing.
- Some payers don't support dependent eligibility checks. In these cases, submit the dependent as the subscriber with their own member ID.
- Try including the `provider.taxId`, typically their EIN or SSN.
|
| `33` | Input Errors | The request doesn't meet the payer’s requirements, which usually means it doesn't contain enough information to identify the patient. - We recommend providing the subscriber's `memberId`, `dateOfBirth`, `firstName`, and `lastName`.
- We recommend providing the dependent's `firstName`, `lastname`, and `dateOfBirth`.
|
| `35` | Out of Network | The dependent isn't in the provider's network. - Verify that the `provider.npi` is valid.
- If yes, contact the payer for clarification.
|
| `42` | Unable to Respond at Current Time | The payer can't respond to your request. This is typically a temporary issue with the payer's system, such as downtime, but it can also be an extended outage. We recommend retrying immediately and continuing to retry for up to 2 minutes. Learn more about our [recommended retry strategy](/healthcare/eligibility-troubleshooting#retry-strategy) for payer connectivity issues. |
| `43` | Invalid/Missing Provider Identification | The problem is either: - The `provider.npi` isn't registered correctly with the payer.
- The payer requires an agreement to begin processing eligibility checks for this provider.
Check the [Payer Network](https://www.stedi.com/healthcare/network) to determine whether this payer requires transaction enrollment for eligibility checks. - If yes, you must submit a [transaction enrollment request](/healthcare/transaction-enrollment) for the provider.
- If not, the payer may still require other [credentialing or enrollment processes](/healthcare/credentialing-and-enrollment). Contact Stedi support to determine next steps.
|
| `45` | Invalid/Missing Provider Specialty | The `provider.npi` isn't registered with the payer under the correct specialty. The provider must contact the payer directly to resolve this issue due to PHI/HIPAA guidelines. |
| `47` | Invalid/Missing Provider State Specialty | The `provider.address` either doesn't match the address registered with the payer, or it doesn't match the provider's address in the NPPES system. - Ensure the information in `provider.address` is correct.
- If so, the provider must contact the payer directly to resolve this issue due to PHI/HIPAA guidelines.
|
| `48` | Invalid/Missing Referring Provider Identification Number | The referring provider (specified in `dependents[].providerIdentifier`) either: - Isn't enrolled correctly with the payer. Contact Stedi support to resolve.
- Isn't registered with the payer's health plans. The provider must contact the payer directly to complete the registration process. Contact Stedi support with questions.
|
| `49` | Provider is Not Primary Care Physician | The payer doesn't list the provider as a primary care physician, but requires them to be one. The provider or the patient must contact the payer to update their records. |
| `51` | Provider Not on File | The provider isn't registered with the payer. - Ensure the `provider.npi` is correct.
- If so, the provider must contact the payer directly to complete the registration process. This can include [credentialing and/or enrollment](/healthcare/credentialing-and-enrollment). Contact Stedi support with questions.
|
| `52` | Service Dates Not Within Provider Plan Enrollment | The provider wasn't registered with the patient's health plan on the date of service listed in the eligibility check. - Verify that the `provider.npi` and the service dates in the `encounter` object are correct.
- If so, the provider must contact the payer directly to resolve this issue.
|
| `53` | Inquired Benefit Inconsistent with Provider Type Enrollment | The provider isn't registered with the payer to perform the requested benefit type. Some payers only return benefits that match the provider's taxonomy code. - Verify that the `provider.npi` is correct.
- Verify that the `serviceTypeCodes` or `procedureCode` and `productOrServiceIDQualifier` in the `encounter` object are correct.
- Check the provider taxonomy in `provider.referenceIdentification` to ensure it matches what's in the payer's system.
- If the issue persists, the provider must contact the payer directly to resolve.
|
| `54` | Inappropriate Product/Service ID Qualifier | You provided an invalid `encounter.productOrServiceIDQualifier`. Update the request and resubmit. |
| `55` | Inappropriate Product/Service ID | You provided an invalid `encounter.procedureCode`. Update the request and resubmit. |
| `56` | Inappropriate Date | The service dates in the `encounter` object are incorrect or are formatted incorrectly. - Dates must be in YYYYMMDD format.
- We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers do support dates further in the future, especially the next calendar month. Check the payer's documentation to determine their specific behavior.
|
| `57` | Invalid/Missing Date(s) of Service | The service dates in the `encounter` object are missing, incorrect, or formatted incorrectly. - Dates must be in YYYYMMDD format.
- We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers do support dates further in the future, especially the next calendar month. Check the payer's documentation to determine their specific behavior.
|
| `58` | Invalid/Missing Date-of-Birth | The payer needs the dependent's date of birth for identification. - Include `dependents[].dateOfBirth` in the request.
- The date should be in YYYYMMDD format.
|
| `60` | Date of Birth Follows Date(s) of Service | The date(s) of service you provided are earlier than the dependent's date of birth. - Check the service dates in the `encounter` object.
- Check the `dependents[].dateOfBirth`.
- If this eligibility check is for a newborn, resubmit it with the mother's information instead.
|
| `61` | Date of Death Precedes Date(s) of Service | The date(s) of service you provided are after the dependent's date of death. - Check the service dates in the `encounter` object.
- Note that if you don't provide a service date in the request, the payer defaults to using the current date in their timezone.
|
| `62` | Date of Service Not Within Allowable Inquiry Period | The payer doesn't support the date(s) of service you provided. - Check the service dates in the `encounter` object.
- We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers do support dates further in the future, especially the next calendar month. Check the payer's documentation to determine their specific behavior.
|
| `63` | Date of Service in Future | Some payers don't support future date(s) of service. - Check the service dates in the `encounter` object.
- Check the payer's specific requirements.
|
| `64` | Invalid/Missing Patient ID | The payer requires an additional identifier in the `dependents[].additionalIdentification` object. - The required identifier is payer-specific. Check the payer's requirements.
- Don't include the `healthInsuranceClaimNumber` or `medicaidRecipientIdentificationNumber` unless they're different from the member ID.
|
| `65` | Invalid/Missing Patient Name | The payer doesn't recognize the dependent's name. - Ensure that the `dependents[].firstName` and `dependents[].lastName` are valid and spelled correctly.
- Enter the patient's name exactly as it appears on their insurance card, if available, including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces. Review our other best practices for entering [patient names](/healthcare/send-eligibility-checks#patient-names).
|
| `66` | Invalid/Missing Patient Gender Code | The payer requires the dependent's gender code. Ensure `dependents[].gender` is set to a valid value that matches the payer's records. |
| `67` | Patient Not Found | The payer couldn't locate the dependent in their database. - We recommend providing the dependent's `firstName`, `lastName`, and `dateOfBirth`.
- Enter the patient's name exactly as it appears on their insurance card, if available, including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces. Review our other best practices for entering [patient names](/healthcare/send-eligibility-checks#patient-names).
- Sometimes patients provide outdated insurance information for the wrong payer. If the issue persists, try running an [insurance discovery check](/healthcare/insurance-discovery) to retrieve the patient's benefits information instead.
|
| `68` | Duplicate Patient ID Number | The payer found another member with the same member ID in their database. Ensure the `subscriber.memberId` is correct. |
| `69` | Inconsistent with Patient’s Age | The diagnosis codes provided don't match the patient's age. - Check the `dependents[].dateOfBirth`.
- Check any `dependents[].healthCareCodeInformation[].diagnosisCode` values.
|
| `70` | Inconsistent with Patient’s Gender | The procedure codes provided are inconsistent with the patient's gender. - Check `dependents[].gender`.
- Check the values in `encounter.procedureCode` or `encounter.medicalProcedures[].procedureCode`.
|
| `71` | Patient DOB Does Not Match That for the Patient on the Database | The dependent's birth date doesn't match what's in the payer's database. - Check that the `dependents[].dateOfBirth` is correct.
- If so, contact the payer to resolve this issue.
|
| `77` | Subscriber Found, Patient Not Found | The payer identified the subscriber in their database, but not the dependent.- We recommend providing the dependent's `firstName`, `lastName`, and `dateOfBirth`.
- Enter the patient's name exactly as it appears on their insurance card, if available, including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces. Review our other best practices for entering [patient names](/healthcare/send-eligibility-checks#patient-names).
- If the dependent has a unique member ID, you must submit their information in the `subscriber` object instead.
|
| `98` | Experimental Service or Procedure | Contact the payer for guidance. |
| `AA` | Authorization Number Not Found | The payer didn't recognize the prior authorization number you provided. Ensure the `encounter.priorAuthorizationOrReferralNumber` is correct. |
| `AE` | Requires Primary Care Physician Authorization | The payer requires a prior authorization number. Add the `encounter.priorAuthorizationOrReferralNumber` to your request and resubmit. |
| `AF` | Invalid/Missing Diagnosis Code(s) | The payer requires diagnosis codes, or the diagnosis codes you provided were invalid. Ensure the information in the `dependents[].healthCareCodeInformation[]` array is correct. |
| `AG` | Invalid/Missing Procedure Code(s) | The payer requires a procedure code or the procedure code you provided is invalid. Ensure `encounter.productOrServiceIDQualifier` and `encounter.procedureCode` are set to valid values. |
| `AO` | Additional Patient Condition Information Required | Contact the payer for guidance. |
| `CI` | Certification Information Does Not Match Patient | The prior authorization or referral number the payer has on file for the patient doesn't match the one you sent. Verify that the `encounter.priorAuthorizationOrReferralNumber` is correct. |
| `E8` | Requires Medical Review | Contact the payer for guidance. |
| `IA` | Invalid Authorization Number Format | The `encounter.priorAuthorizationOrReferralNumber` wasn't formatted correctly. |
| `MA` | Missing Authorization Number | You must include a previously issued referral or authorization number in your request. Set the `encounter.referenceIdentificationQualifier` and `encounter.priorAuthorizationOrReferralNumber` properties and resubmit. |
{/* prettier-ignore-end */}
### Card Issuer Identifier (80840) [#card-issuer-identifier-80840]
All health plans use (80840) as the first five digits of the Card Issuer Identifier.
This is a placeholder value used for standards compliance only, and you shouldn't pass it in an electronic eligibility check. However, many providers and OCR systems accidentally pass (80840) in other eligibility check fields. For example, they may try to pass this value as a subscriber or dependent ID, causing an [AAA rejection](#payer-aaa-errors) from the payer.
{/* prettier-ignore-start */}
To prevent these types of mistakes, Stedi automatically suppresses any string containing (80840) in the following fields:
| JSON | X12 EDI |
| ----------------------------------------------------- | ----------------------------------------------------- |
| `subscriber.memberId` | Loop 2100C `NM109` Subscriber Primary Identifier |
| Any property in `subscriber.additionalIdentification` | Loop 2100C `REF02` Subscriber Supplemental Identifier |
| Any property in `dependent.additionalIdentification` | Loop 2100D `REF02` Dependent Supplemental Identifier |
{/* prettier-ignore-end */}
If the payer's eligibility response returns an AAA error, Stedi returns the following warning:
```
The field {FIELD} contains the string "(80840)", which is a known
placeholder prefix for a field that should not be provided in {FIELD}.
We have omitted that value in the request, and the request failed.
Please locate the correct value for {FIELD} and resubmit.
```
To correct this error, read the documentation for the corresponding field, locate the correct value, and resubmit the eligibility check.
### SOAP requests [#soap-requests]
Our [Real-Time Eligibility Check SOAP](/healthcare/api-reference/post-healthcare-eligibility-soap) endpoint respects the error handling rules defined in the [CAQH CORE vC2.2.0 Rule](https://www.caqh.org/core/connectivity).
At a high level, you can experience errors in the following categories:
* [Authentication errors](#authentication-errors): Either your API key, your Stedi account ID, or both are invalid.
* [SOAP faults](#soap-faults): Issues with the request `Envelope` or `Header` elements, such as malformed XML.
* [CORE-compliant errors](#core-compliant-errors): The request don't conform to CAQH CORE rules for eligibility checks.
* [X12 EDI validation errors](#x12-edi-validation-errors): The X12 EDI transaction doesn't match the required format.
* [Too many requests errors](#too-many-requests): You've exceeded your concurrency limit.
* [Payer `AAA` errors](#payer-aaa-errors): Errors from the payer indicating issues with processing your request.
#### Authentication errors [#authentication-errors]
If the `wsse:Username` or `wsse:Password` values are incorrect within the `Header` element:
* Stedi returns an HTTP `401` status code.
* The response includes an `ErrorCode` element set to `UnAuthorized`.
The following example shows an authentication error response:
```xml
CoreEnvelopeError
RealTime
01987b7e-56cc-7871-8520-a22721948fb4
2025-08-06T22:23:50Z
2.2.0
UnAuthorized
Invalid username and/or password.
```
#### SOAP faults [#soap-faults]
SOAP faults indicate issues with the request `Envelope` or `Header` elements, such as malformed XML or missing required elements.
When these errors occur:
* Stedi returns an HTTP `400` status code.
* The response includes a `Fault` element that contains details about the error. The `Fault` element always contains a `Code` and `Reason` element. The `Code` element indicates the source of the error and the `Reason` element provides a description.
The following example shows a SOAP fault response:
```xml
soapenv:Sender
Unable to parse payload as CORE SOAP request
```
Visit the [SOAP Fault documentation](https://www.w3.org/TR/soap12-part1/#soapfault) for more details and a complete list of possible error codes.
#### CORE-compliant errors [#core-compliant-errors]
These errors typically indicate issues with the `COREEnvelopeRealTimeRequest` element that contains the request body. However, they can sometimes indicate specific issues with the SOAP `Envelope` or `Header` elements, such as an incorrect SOAP version or invalid credentials.
When these errors occur:
* Stedi returns an HTTP `400` status code.
* The `COREEnvelopeRealTimeResponse` element contains an `ErrorCode` and `ErrorMessage` with a description.
* The `Payload` element is empty because Stedi didn't process the eligibility check.
The following example shows a CORE-compliant error response:
```xml
CoreEnvelopeError
RealTime
01987b70-2b7e-7b40-9875-10d3139dcf2a
2025-08-06T22:23:50Z
TestStedi
Stedi
2.2.0
PayloadIDIllegal
Illegal value provided for PayloadID. Must be a valid UUID
```
The following table lists the possible values for `ErrorCode` and and their causes:
{/* prettier-ignore-start */}
| Error Code | Possible Causes |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `CORERuleVersionIllegal` | The `CORERuleVersion` element is not set to `2.2.0`. |
| `CORERuleVersionRequired` | The `CORERuleVersion` element is missing from the request. Set this to `2.2.0`. |
| `PayloadIDIllegal` | The `PayloadID` element is not a valid UUID. |
| `PayloadIDRequired` | The `PayloadID` element is missing from the request. This must be a valid UUID. |
| `PayloadIllegal` | The `Payload` element is empty or doesn't contain a valid X12 EDI 270 transaction. |
| `PayloadRequired` | The `Payload` element is missing from the request. This must be a valid X12 EDI 270 transaction. |
| `PayloadTypeIllegal` | The `PayloadType` element is invalid. Set this to `X12_270_Request_005010X279A1`. |
| `PayloadTypeRequired` | The `PayloadType` element is missing from the request. Set this to `X12_270_Request_005010X279A1`. |
| `ProcessingModeIllegal` | The `ProcessingMode` element is not set to `RealTime`. |
| `ProcessingModeRequired` | The `ProcessingMode` element is missing from the request. Set this to `RealTime` for real-time eligibility checks. |
| `ReceiverIDIllegal` | The `ReceiverID` exceeds the maximum length of 50 characters. |
| `ReceiverIDRequired` | The `ReceiverID` element is missing from the request. Visit the [Request](/healthcare/api-reference/post-healthcare-eligibility-soap#request) reference documentation for guidance on which identifier to use. |
| `SenderIDIllegal` | The `SenderID` exceeds the maximum length of 50 characters. |
| `SenderIDRequired` | The `SenderID` element is missing from the request. Visit the [Request](/healthcare/api-reference/post-healthcare-eligibility-soap#request) reference documentation for guidance on which identifier to use. |
| `TimeStampIllegal` | The `TimeStamp` element is not in the correct format. It must be in ISO 8601 format, such as `2024-07-28T12:00:00Z`. |
| `TimeStampRequired` | The `TimeStamp` element is missing from the request. |
| `UnAuthorized` | The request is unauthorized. This can happen if the `wsse:UsernameToken` is missing or invalid, or if the API key is incorrect. |
| `VersionMismatch` | The SOAP version in the request does not match the expected version. |
{/* prettier-ignore-end */}
#### X12 EDI validation errors [#x12-edi-validation-errors]
Validation errors occur when the X12 EDI transaction doesn't conform to the expected [270 X12 EDI format](https://portal.stedi.com/app/guides/view/hipaa/health-care-eligibility-benefit-inquiry-x279a1/01GRYB6GTDJ4MEP5Z16CGMQWT6) or contains invalid data.
When there are validation errors, Stedi returns an HTTP `400` status code. There are two possible error cases:
* **Invalid EDI envelope:** There are issues with the `ISA` or `GS` header. The `ErrorCode` element is set to `PayloadIllegal`, and the `Payload` element is empty because Stedi couldn't parse the request.
```xml
CoreEnvelopeError
RealTime
01987c0b-c8b3-71c1-bd6f-8e26725c7110
2025-08-06T22:23:50Z
RECEIVER-ID
SENDER-ID
2.2.0
PayloadIllegal
Error while getting metadata for an X12 file: Error reading EDI: Invalid ISA: ISA-11 must be 'U' for interchange control versions earlier than 00402
```
* **Invalid EDI transaction:** Stedi successfully parsed the EDI envelope, but there are validation issues with the rest of the transaction. The `ErrorCode` element is set to `Success`, and the `Payload` element contains a 999 Implementation Acknowledgment describing the errors. This 999 is usually from Stedi, but it can also be from the payer.
```xml
X12_999_Response_005010X231A1
RealTime
01987c11-ae2e-7f63-801d-cb3529f45952
2025-08-06T22:23:50Z
RECEIVER-ID
SENDER-ID
2.2.0
Success
```
#### Too many requests [#too-many-requests]
If you exceed your [concurrency limit](/healthcare/api-reference#concurrency-limits) for the SOAP endpoint:
* Stedi returns an HTTP `429` status code.
* The X12 EDI transaction inside the `Payload` element contains an `AAA` error with code `42`.
Stedi will continue rejecting additional requests with a `429` status code until one of your previous requests is completed.
The following example shows a too many requests response:
```xml
X12_271_Response_005010X279A1
RealTime
019afed8-aa83-7fe2-a1bf-18dd5942a772
2025-12-08T16:43:23Z
STEDI
686460348755
2.2.0
Success
```
# Overview
Source: https://www.stedi.com/docs/healthcare/eligibility-workflows-overview
Eligibility refers to a patient's qualification to receive specific medical benefits, services, or coverage under their health plan.
Stedi allows you to reliably determine patient eligibility, even when the patient doesn't know or can't provide accurate insurance information. Once you integrate with Stedi, you can use the UI tools in the Stedi portal to test, troubleshoot, and monitor your entire eligibility pipeline.
## Eligibility workflows [#eligibility-workflows]
Here's an overview of the eligibility workflows you can automate with Stedi APIs:
* [Eligibility checks](/healthcare/intro-eligibility-checks): Verify a patient's coverage with a specific payer. Eligibility checks return full benefits information from the payer, so they're helpful when you need to determine a patient's financial responsibilities for medical services, such as co-payments, deductibles, and out-of-pocket maximums.
* [Insurance discovery](/healthcare/insurance-discovery): Find a patient's active health plans using their demographic information, such as their name and date of birth. Insurance discovery checks return the same benefits information as a standard eligibility check, making them a great backup for verifying coverage when eligibility checks fail or aren't possible.
* [Coordination of benefits](/healthcare/coordination-of-benefits): Determine whether a patient has multiple, overlapping coverages and if so, which plan is primarily responsible for payment (primacy). COB checks help you submit claims to the correct payer and avoid claim denials.
## Eligibility searches view [#eligibility-searches-view]
The [Eligibility searches view](/healthcare/eligibility-searches-view) helps you track and manage your entire eligibility pipeline. It provides a centralized view of all your eligibility checks, including real-time and batch requests, and helps you efficiently troubleshoot issues and review patient coverage details. With Stedi Agent, you can resolve common errors automatically with the same best practices our Support team uses for troubleshooting.
Within the Stedi portal, you can also manually submit new eligibility checks and coordination of benefits checks as needed.
## MCP server [#mcp-server]
Our [Model Context Protocol (MCP) server](/healthcare/mcp-server) defines a set of tools that AI agents can use to perform and troubleshoot eligibility checks through Stedi.
When building agents that work with eligibility data, we recommend using our MCP server. It excels at individual eligibility checks, especially when your agent needs to retrieve coverage data in real time.
# Configure and test event destinations
Source: https://www.stedi.com/docs/healthcare/event-destinations-configure
You can configure event destinations that automatically send Stedi events to your endpoint. Events indicate changes to Stedi resources, such as [transaction enrollment](/healthcare/transaction-enrollment) requests.
In each event message, Stedi includes a signature you can use to [verify its authenticity](/healthcare/event-destinations-message-handling#verify-authenticity-and-receipt-time). Stedi also automatically manages retries for event deliveries and sends you notification emails when there are repeated failures.
Currently, you can configure event destinations for Stedi transaction enrollment events. More event types, including transaction processing events, will be available in future releases.
## Create event destinations [#create-event-destinations]
You can create up to 16 event destinations per Stedi account. To create event destinations:
1. Go to the [Event destinations page](https://portal.stedi.com/app/settings/developer/event-destinations) in your **Developer settings**.
2. Click All event destinations.
3. Click **+ New destination**.
4. Enter the following information into the **Create an event destination** form:
1. **Name:** Choose a descriptive, human-readable name for the event destination. Stedi displays this name in the portal for identification.
2. **URL:** Enter the webhook URL where you want Stedi to send events. The URL must use `https://` and must point directly at your webhook receiver. Stedi doesn't follow HTTP redirects - if your endpoint responds with a `3xx` status code, the delivery is recorded as a failure.
3. **Description:** Optionally, describe the intended use for the destination in more detail. This description will be displayed in the Stedi portal.
4. **Events:** Select the event types you want to send to the designated webhook URL.
5. Click **Create destination**. Stedi displays a modal containing the signing secret for this webhook. Save it to a secure location. You'll need it to verify that the events you receive are from Stedi.
You can now begin testing the event destination.
## Trigger test events [#trigger-test-events]
You can manually trigger [`event.ping` events](/healthcare/event-destinations-event-types#eventping) for any configured event destination. To trigger test events:
1. Go to the [Event destinations page](https://portal.stedi.com/app/settings/developer/event-destinations) in your **Developer settings**.
2. Click the event destination you want to test.
3. Click the **Event deliveries** tab.
4. Click the **Ping** button.
Stedi attempts to deliver an `event.ping` to the designated webhook URL. You can review its status and details on the **Event deliveries** tab.
## Secrets [#secrets]
Stedi generates a secret for each event destination. You can use the secret to [verify the authenticity](/healthcare/event-destinations-message-handling#verify-authenticity-and-receipt-time) of the event messages you receive from Stedi.
### Manage secrets [#manage-secrets]
You can review, copy, and rotate an event destination's secret at any time from its **Overview** tab.
### Rotate secret [#rotate-secret]
You can rotate the secret in accordance with your organization's security policies. To rotate the secret for an event destination:
1. Go to the [Event destinations page](https://portal.stedi.com/app/settings/developer/event-destinations) in your **Developer settings**.
2. Click the event destination you want to edit to go to its **Overview** tab.
3. Under **Signing secret**, click the **Rotate secret** icon.
4. Select an **Expiry period**. This is the number of hours the previous secret should remain valid after rotation. Available options are:
* 0 hours (previous secret expires immediately)
* 24 hours
* 720 hours (30 days)
5. Click **Rotate**.
If you specified an expiry period, the event message will contain two signatures until that period has concluded: one matching the previous secret and one matching the new secret. You'll need to run any verification steps with both until the expiry period ends.
Each event destination can have only two active secrets at a time. If you set an expiry period for the rotated secret, you must wait until that expiry period has passed before attempting to rotate the secret again.
## Edit event destinations [#edit-event-destinations]
You can review a list of all configured event destinations from the [Event destinations page](https://portal.stedi.com/app/settings/developer/event-destinations) in your **Developer settings**.
Click the **ellipses (...)** to the right of any destination to view, edit, disable, re-enable, or delete it.
### Disable vs. delete [#disable-vs-delete]
Disabling an event destination causes Stedi to stop sending new events to the webhook. Stedi also attempts to complete any in-progress retry attempts, and then pauses additional retries until the event destination is re-enabled. Once you re-enable the event destination, Stedi resumes retrying undelivered events until the retry limit is reached.
Deleting an event destination stops all event deliveries, including in-progress retry attempts immediately.
# Events and message schema
Source: https://www.stedi.com/docs/healthcare/event-destinations-event-types
You can configure event destinations for Stedi transaction enrollment events.
More event types, including transaction processing events, will be available in future releases. Please contact [Stedi support](https://www.stedi.com/contact) to request event types for your use case.
## Message schema [#message-schema]
Stedi sends relevant events as a `POST` HTTP request to the specified destination URL. Stedi uses the following schema for event destination deliveries.
### Headers [#headers]
Each event delivery includes the following required headers:
| Header | Type | Description |
| ------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `attempt-number` | integer | The delivery attempt number. The initial delivery is `1`. |
| `attempt-type` | enum | Whether the attempt originated from Stedi (`AUTOMATIC`) or was a manual retry (`MANUAL`). |
| `destination-id` | string | The identifier for the event destination,formatted as `dst_{UUID}`. |
| `event-id` | string | The event identifier, formatted as `evt_{UUID}`. |
| `webhook-id` | string | A unique message identifier per the [Standard Webhooks](https://www.standardwebhooks.com/) specification, formatted as `msg_{UUID}`. You can use this to check for duplicate event deliveries. |
| `webhook-signature` | string | A Stedi-generated signature, formatted as `v1,{signature}`. Use this to verify message authenticity. |
| `webhook-timestamp` | integer | A Unix timestamp indicating when the event was created. This is different from when the event was delivered. You can use this to verify the time of receipt. |
The following example headers show that this is the original delivery (`attempt-number: 1`) from Stedi.
```bash
attempt-number: 1
attempt-type: AUTOMATIC
destination-id: dst_019d30e3-5e39-7ab3-9a2e-fcf8218a313d
event-id: evt_b73ae1d2-9128-90b5-60ff-7479ab8b30ac
webhook-id: msg_b73ae1d2-9128-90b5-60ff-7479ab8b30ac
webhook-signature: v1,Z5wMZ2rqRMsnGdfKzOLnRv1SIwivsLFCGQzJH7eCmlU=
webhook-timestamp: 1774641758
```
### Event payload [#event-payload]
Stedi events use a thin event schema. Thin events notify you that a resource has changed but don't include the resource's data. Once you receive an event, verify the resource's state and retrieve details using Stedi's APIs or the Stedi portal.
The event payload schema is available in the [Retrieve Event](/healthcare/api-reference/get-event-destinations-event) endpoint's `eventPayload.v1Event` object.
## Events [#events]
You can subscribe to two types of transaction enrollment events. You can also [trigger a generic test event](/healthcare/event-destinations-configure#trigger-test-events) from within the Stedi portal to test your event destinations.
You can use each enrollment event's `resource.id` to retrieve details about the enrollment request through the [Retrieve Enrollment](/healthcare/api-reference/get-enrollment) endpoint or the [Enrollments page](https://portal.stedi.com/app/healthcare/enrollments) in the Stedi portal.
### enrollment.activated [#enrollmentactivated]
Stedi generates this event when a [transaction enrollment](/healthcare/transaction-enrollment) request is set to `LIVE` status. This indicates that the enrollment process is complete, and the specified provider can begin exchanging the listed transaction types with the payer.
```json
{
"account": "11111111-2222-3333-4444-555555555555",
"created": "2026-03-30T23:19:00.501Z",
"environment": "PRODUCTION",
"id": "evt_a81659f1-16a5-9bec-03e1-0ba8ab5e9652",
"object": "v1.event",
"resource": {
"id": "019bb508-dc63-73a1-8ddc-9d4720299072",
"type": "enrollment"
},
"type": "enrollment.activated"
}
```
### enrollment.rejected [#enrollmentrejected]
Stedi generates this event when a [transaction enrollment](/healthcare/transaction-enrollment) request is set to `REJECTED` status. This indicates that the payer rejected the enrollment. Common reasons for rejection include incorrect details in the request and the provider not being credentialed with the payer. Customer support will contact you with reasons for rejection and next steps.
```json
{
"account": "11111111-2222-3333-4444-555555555555",
"created": "2026-03-30T23:18:52.772Z",
"environment": "PRODUCTION",
"id": "evt_8c28ce2e-5d4f-ae1c-fddb-e2421245a873",
"object": "v1.event",
"resource": {
"id": "019bb4e9-5209-7e83-bc84-0db436be7e00",
"type": "enrollment"
},
"type": "enrollment.rejected"
}
```
### event.ping [#eventping]
A test event you can trigger to validate your event destination.
```json
{
"id": "evt_019d51b6-8d19-71c3-8f5f-cfb55830b618",
"object": "v1.event",
"created": "2026-04-03T05:00:11.417Z",
"environment": "PRODUCTION",
"resource": {
"type": "destination",
"id": "dst_019d51b6-707c-7920-8569-de40061cbe5c"
},
"account": "cd26e999-2cb9-4c64-be13-f7375e640b83",
"type": "event.ping"
}
```
## Data retention [#data-retention]
By default, Stedi returns event data and displays delivery attempts from the past 30 days. Contact us if you need access to older event data.
# Handle event deliveries and retries
Source: https://www.stedi.com/docs/healthcare/event-destinations-message-handling
Stedi begins sending events to your webhook immediately after you [configure an event destination](/healthcare/event-destinations-configure).
## Review events and deliveries [#review-events-and-deliveries]
You can access events and event delivery attempts manually through the Stedi portal or programmatically through Stedi's Events API.
### Stedi portal [#stedi-portal]
You can review all events and attempted event deliveries in the Stedi portal. This allows you to verify your destination is working and helps with troubleshooting.
To review events and event deliveries through the **Events** page:
1. Go to the [Events page](https://portal.stedi.com/app/settings/developer/events) in your **Developer settings**. Stedi displays a list of all events in your account for the past 30 days.
2. Click an event to review its details. Stedi shows key information, including the created date and type, as well as a list of every delivery attempt to configured event destinations.
3. Click a delivery attempt to review its complete details, including the HTTP status code and the full request and response bodies for that attempt.
To review event deliveries for a specific event destination:
1. Go to the [Event destinations page](https://portal.stedi.com/app/settings/developer/event-destinations) in your **Developer settings**.
2. Click an event destination and select its **Event deliveries** tab. Stedi lists all the event delivery attempts and their status for the past 30 days.
3. Click an event delivery to review its details, including the HTTP status code and the full request and response bodies for that attempt.
### Events API [#events-api]
You can also retrieve events programmatically through the following endpoints:
* [List Events](/healthcare/api-reference/get-event-destinations-list-events): Retrieve a list of all events generated in your Stedi account within the last 30 days. You can filter by event type, delivery status, and created date.
* [Retrieve Event](/healthcare/api-reference/get-event-destinations-event): Retrieve the full details of a specific event, including the full event payload Stedi sends to event destinations.
## Delivery failures [#delivery-failures]
When Stedi can't deliver an event to one or more event destinations, Stedi automatically retries each failed delivery for up to 48 hours. If all attempted retries fail, Stedi temporarily disables the associated event destination to prevent more missed deliveries. Once you address the issue, you can [re-enable the event destination](/healthcare/event-destinations-configure#edit-event-destinations) to resume event deliveries.
### What causes failures [#what-causes-failures]
Stedi marks a delivery as failed in the following scenarios:
* **HTTP redirects (3xx status codes)**: Stedi doesn't follow HTTP redirects. If your endpoint responds with a `3xx` status code, the delivery is recorded as a failure. Configure your endpoint to serve webhooks directly instead of redirecting to another URL.
* **Client and server errors (4xx and 5xx status codes)**: Any status code other than `2xx` is treated as a failure.
* **Network errors**: Connection timeouts, DNS failures, or other network-level issues.
Stedi considers only `2xx` status codes as successful deliveries.
### Automatic retries [#automatic-retries]
Stedi automatically retries at the following intervals:
* 5 minutes
* 30 minutes
* 2 hours
* 8 hours
* 24 hours
* 48 hours
You can review all retry attempts from within the Stedi portal.
### Manual retries [#manual-retries]
You can manually retry event deliveries as needed. Manual retries reset Stedi's automated retry process. For example, if you manually retry an event delivery after the second automatic attempt at 2 hours, the next automated retry attempt will occur after 5 minutes and continue according to Stedi's retry schedule for up to 48 hours.
To retry through the **Events** page:
1. Go to the [Events page](https://portal.stedi.com/app/settings/developer/events) in your **Developer settings**. Stedi displays a list of all events in your account.
2. Click an event to review its details. Stedi shows key information, including the created date and source, as well as a list of every delivery attempt to configured event destinations.
3. Click the **Retry** button next to a failed delivery to start a retry attempt. Stedi adds a new delivery row to the event record so you can monitor the progress.
To retry through an event destination's **Event deliveries** tab:
1. Go to the [Event destinations page](https://portal.stedi.com/app/settings/developer/event-destinations) in your **Developer settings**.
2. Click an event destination and select its **Event deliveries** tab. Stedi lists all the event delivery attempts and their status.
3. Click an event delivery to review its details.
4. Click **Retry delivery** to start a retry attempt. Stedi adds a new event delivery row to the **Event deliveries** tab so you can monitor the progress.
### Notification emails [#notification-emails]
When event deliveries to an event destination repeatedly fail, Stedi sends notification emails to every member of the Stedi account. Members receive emails at the following intervals:
1. **After 2 hours:** If retry attempts for all events continue failing for 2 hours, we send an email notifying you that deliveries are failing for the associated event destination. You should log in to your Stedi account and investigate the issue as soon as you can. Stedi will continue automatic retries.
2. **After 24 hours:** If retry attempts for all events associated with an event destination continue failing for 24 hours, we send another email informing you that Stedi's retry limit is approaching.
If all attempts fail, Stedi disables the associated event destination to prevent more missed deliveries.
## Process undelivered events [#process-undelivered-events]
Stedi [automatically retries event deliveries](#delivery-failures) for up to 48 hours before marking them as failed. However, we recommend implementing a strategy to manually process undelivered events in case your endpoint remains unavailable or event delivery is interrupted.
1. Call the [List Events](/healthcare/api-reference/get-event-destinations-list-events) endpoint to retrieve a list of all events with a `FAILED` status. The response includes an `id` for each event.
```json
{
"items": [
{
"id": "evt_a81659f1-16a5-9bec-03e1-0ba8ab5e9652",
"eventType": "enrollment.activated",
"status": "FAILED",
"createdAt": "2026-02-01T12:00:00Z"
}
]
}
```
2. Call the [Retrieve Event](/healthcare/api-reference/get-event-destinations-event) endpoint to get the full payload for each event.
```json
{
"account": "11111111-2222-3333-4444-555555555555",
"created": "2026-03-30T23:19:00.501Z",
"environment": "PRODUCTION",
"id": "evt_a81659f1-16a5-9bec-03e1-0ba8ab5e9652",
"object": "v1.event",
"resource": {
"id": "019bb508-dc63-73a1-8ddc-9d4720299072",
"type": "enrollment"
},
"type": "enrollment.activated"
}
```
3. Process each event. Note that the receipt time will likely be outside your normal tolerance window.
## Message handling best practices [#message-handling-best-practices]
We **strongly recommend** implementing these best practices for event handling.
### Don't rely on event order [#dont-rely-on-event-order]
Stedi attempts to deliver events as soon as possible after they're generated. However, we can't guarantee that your endpoint will receive events in order. Ensure your implementation isn't dependent on event order.
### Verify authenticity and receipt time [#verify-authenticity-and-receipt-time]
We strongly recommend verifying each signed message to ensure it's from Stedi. You should also verify that the message was generated within your expected timeframe for receipt. This helps protect you from replay attacks.
Each event contains two headers you can use to verify a message's authenticity: `webhook-signature` and `webhook-timestamp`.
```bash
webhook-signature: v1,Z5wMZ2rqRMsnGdfKzOLnRv1SIwivsLFCGQzJH7eCmlU=
webhook-timestamp: 1774641758
```
To verify the message authenticity and receipt time:
1. Create a `signed_payload` string by concatenating the timestamp (as a string) with the character `.` and the entire JSON request body.
2. Compute an [HMAC with the SHA256 hash function](https://datatracker.ietf.org/doc/html/rfc4868). Use the event destination secret as the key, and use the `signed_payload` string as the message. This should produce a signature.
3. Split the signature string in the message's `webhook-signature` header from the version (`v1`).
4. Compare the signature from the event message to your computed signature. If they are equivalent, then the message is from Stedi. If not, reject the message.
5. Compute the difference between the timestamp provided in the message and the current timestamp. If the difference is outside your tolerance, reject it.
To protect against timing attacks, use a constant-time string comparison to compare the expected signature to each one you received from Stedi.
Our implementation follows the [Standard Webhooks](https://www.standardwebhooks.com/) specification. The following TypeScript example uses the `standardwebhooks` library for signature verification.
```typescript
import { Webhook } from "standardwebhooks";
import type { CapturedWebhook } from "./types";
export function assertWebhookValid(
webhook: CapturedWebhook,
secret: string,
): void {
const wh = new Webhook(secret);
try {
wh.verify(webhook.request.body, webhook.request.headers);
} catch (err) {
throw new Error(
`Webhook signature verification failed: ${err instanceof Error ? err.message : String(err)}. ` +
`Headers: ${JSON.stringify(webhook.request.headers)}`,
);
}
}
```
### Check the resource record [#check-the-resource-record]
Stedi events use a thin event schema that doesn't include the updated resource's data.
Before taking action based on an event, you should use Stedi APIs to retrieve the resource's details and verify its current state. This approach ensures you're acting on the latest data, even if events arrive out of order.
### Check for duplicates [#check-for-duplicates]
Your webhook may occasionally receive the same event multiple times. For example, your webhook may receive the same event from both automatic retries and a [manual recovery process](#process-undelivered-events).
We strongly recommend logging the IDs for events you've processed, comparing them against new events, and filtering out duplicates.
We recommend using the `webhook-id` header for this purpose. It contains a unique Stedi-generated identifier for the event, formatted as `msg_{UUID}`.
```bash
webhook-id: msg_b73ae1d2-9128-90b5-60ff-7479ab8b30ac
```
### Check for processing errors [#check-for-processing-errors]
We recommend periodically listing events to catch cases where events may have been delivered successfully but your processing logic encountered an error.
1. Call the [List Events](/healthcare/api-reference/get-event-destinations-list-events) endpoint to retrieve events generated in your Stedi account. Use the `created` parameter to filter for events within a specific time range and use the `eventType` parameter to filter for the event types relevant to your use case.
2. Compare the event IDs against the your internal records for processed events.
Note that Stedi sends [notification emails](/healthcare/event-destinations-message-handling#notification-emails) when event deliveries to an event destination fail repeatedly. You should also monitor for these emails to help catch connectivity issues as soon as possible.
# Developer Docs
Source: https://www.stedi.com/docs/healthcare
Integrate with the Stedi clearinghouse. Automate workflows with AI and APIs.
## Eligibility & benefits [#eligibility--benefits]
Reliably determine eligibility and coordination of benefits, even when patients can't provide accurate insurance information.
Submit 270/271 eligibility checks through the Stedi portal or API in either
JSON or X12 EDI.
Identify coverage overlap and determine payer responsibility for claims
(primacy).
Find active health plans using the patient's demographic data.
Full reference for our Eligibility, Coordination of Benefits, and Insurance
Discovery APIs.
## Claims processing [#claims-processing]
Submit 837P professional, 837I institutional, and 837D dental claims and 276/277 real-time claim status checks in both JSON and X12 EDI.
Send claims to payers through the API, an SFTP connection, or the Stedi
portal.
Retrieve processed 277CA claim acknowledgments and 835 ERAs from Stedi.
Determine the processing status of existing claims in real time.
Full reference for our Claims, Claim Status, and Reports (277CA and ERA)
APIs.
# Insurance discovery checks
Source: https://www.stedi.com/docs/healthcare/insurance-discovery
Eligibility checks verify a patient's coverage with a specific payer. But what if you don't know the patient's insurance details or you're not sure whether they have coverage at all? In these situations, you can use an insurance discovery check to search for a patient's active coverage using only their demographic data.
You may need to perform an insurance discovery check when:
* You don't know the payer, such as when a patient doesn't have their insurance card or can't provide insurance details in an urgent care situation.
* One or more eligibility checks failed with an AAA `75` (Subscriber Not Found) or similar error.
* The patient's information is incomplete or outdated, such as when the patient can't provide their member ID.
We recommend using insurance discovery checks as a backup when eligibility checks fail or aren't possible. Because of their limitations, you shouldn't rely on them as your primary method for verifying patient coverage.
## Limitations [#limitations]
Insurance discovery checks have the following limitations:
* **Match rates vary:** Insurance discovery checks aren't guaranteed to return a patient's active health plans 100% of the time - especially when the request doesn't include key demographic information like the patient's address or Social Security Number (SSN).
* **Dental use cases aren't supported:** Insurance discovery checks only reliably identify active medical coverage. Some payers may return dental coverage (service type code `35`) in their response, but insurance discovery checks won't return results for dental-only payers even if the patient has coverage. Don't use insurance discovery for dental use cases.
* **No retroactive or future coverage:** Insurance discovery checks can only return active coverage for the date of service range provided. For example, if a patient recently switched insurance plans and coverage for the previous plan has ended, the insurance discovery check will only return their new, active plan.
* **No payer primacy:** Insurance discovery checks can't determine payer primacy. You must run a [coordination of benefits (COB) check](/healthcare/coordination-of-benefits) to determine whether the patient has active coverage with additional payers and which payer is responsible for paying claims (primacy).
* **Slower response time:** Insurance discovery checks are slower than real-time eligibility checks and can take up to 120 seconds to return results. This is because Stedi performs an average of 13-16 real-time eligibility checks per insurance discovery check.
## How insurance discovery checks work [#how-insurance-discovery-checks-work]
Call the [Insurance Discovery Check](/healthcare/api-reference/post-insurance-discovery) endpoint or submit through the [Create insurance discovery check form](https://portal.stedi.com/app/healthcare/insurance-discovery/create) in the Stedi portal.
You should provide as much patient demographic information as possible to increase the chances of finding matching coverage. You'll also include information like the provider's NPI and the date of service, similar to an eligibility check.
The insurance discovery process involves demographic lookups to enrich partial patient details, comparisons across third-party data sources to determine member IDs, and submitting real-time eligibility checks to payers to detect coverage.
Stedi choose the most probable payers based on the patient's demographic details, resulting in 13-16 real-time eligibility checks. Once all checks are complete, Stedi compiles the results into the response.
Stedi returns an array of potential active coverages along with subscriber details and benefits information. You should always review the results to ensure the returned subscriber information matches the demographic information for the patient.
If there's a match, you can use the benefits information to determine the patient’s eligibility for services. You generally shouldn't need to perform a follow-up eligibility check since the insurance discovery response includes the same benefits information.
## Transaction enrollment [#transaction-enrollment]
[Transaction enrollment](/healthcare/transaction-enrollment) isn't required for insurance discovery, but we do strongly recommend it. Enrollment lets Stedi run [MBI lookups](/healthcare/mbi-lookup) as part of the discovery check, improving your results.
To enroll, submit an enrollment request for the special Stedi insurance discovery payer ([payer ID: `DISCOVERY`](https://www.stedi.com/healthcare/network?page=0\&search=disco\&entry=UQKWC)):
1. Create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step. [Stedi portal](https://portal.stedi.com/app/healthcare/providers) | [API endpoint](/healthcare/api-reference/post-enrollment-create-provider)
2. Submit an enrollment request for **Real-time eligibility checks**. Use `DISCOVERY` as the payer ID (Stedi Insurance Discovery). [Stedi portal](https://portal.stedi.com/app/healthcare/enrollments) | [API endpoint](/healthcare/api-reference/post-enrollment-create-enrollment)
### Medicaid Provider ID [#medicaid-provider-id]
A Medicaid Provider ID is a unique identification number assigned to a healthcare provider when they enroll with a state Medicaid program. It's different than a provider's [National Provider Identifier (NPI)](/healthcare/national-provider-identifier), which is assigned by the federal government. If a provider works in multiple states, they'll have different Medicaid IDs for each state.
Medicaid Provider IDs aren't required for transaction enrollment with Stedi, but they can enhance insurance discovery check results for certain payers. To add Medicaid Provider IDs to transaction enrollment requests, please email [enrollments@stedi.com](mailto:enrollments@stedi.com) with a CSV file containing the NPI and Medicaid ID(s) for each provider.
Many state Medicaid agencies have a provider lookup tool you can use to find a provider's Medicaid Provider ID. For example, for providers who practice in Texas, you can use the [Texas Medicaid & Healthcare Partnership Provider lookup tool](https://opl.tmhp.com/) to search for enrolled providers. You can also call the state Medicaid agency to request a provider's ID.
## Required patient information [#required-patient-information]
You should provide as much patient demographic information as possible when submitting insurance discovery checks. The more information you provide, the more likely Stedi is to find matching coverage.
### Minimum required [#minimum-required]
At a minimum, you must provide the patient's:
* First name
* Last name
* Date of birth (DOB)
However, match rates will be very low with only this basic information. The reason is that the patient information provided must resolve to a single member to return results. Unless the name is extremely uncommon, a name + DOB is likely to match multiple members and result in no matches.
### Recommended [#recommended]
In addition to the patient's name and DOB, we **strongly recommend** providing as much of the following additional information as possible.
* Current address or previous addresses - especially the patient's ZIP code, as this helps narrow down the list of probable payers. ZIP code search isn't an exact match, so even the first 3-4 digits of the patient's current zip code can help improve the results. If the patient's current address isn't available, you can try a full or partial zip code from one of the patient's previous addresses or even one in close proximity.
* Social Security Number (SSN) - The patient's full SSN is preferred, but even the last 4 digits of the SSN can help narrow down matching coverage.
* Gender
## Manual submission [#manual-submission]
You can submit insurance discovery checks through the [Create insurance discovery check](https://portal.stedi.com/app/healthcare/insurance-discovery/create) form in the Stedi portal.
Unlike eligibility checks, Stedi doesn't display historical insurance
discovery checks in the UI for review.{" "}
## API submission [#api-submission]
You can submit an insurance discovery check using the [Insurance Discovery Check](/healthcare/api-reference/post-insurance-discovery) endpoint.
### Request [#request]
The following example shows the payload for an insurance discovery check.
{/* schema:InsuranceDiscoveryCheckRequestContent */}
```json
{
"provider": {
"npi": "1999999984"
},
"encounter": {
"beginningDateOfService": "20250326",
"endDateOfService": "20250328"
},
"subscriber": {
"dateOfBirth": "20010925",
"firstName": "Jane",
"lastName": "Doe",
"address": {
"address1": "1 MAIN ST",
"address2": "UNIT 1",
"city": "ANYTOWN",
"state": "MO",
"postalCode": "12341"
}
}
}
```
### Response [#response]
Stedi's synchronous response to the [Insurance Discovery Check](/healthcare/api-reference/post-insurance-discovery) endpoint can take up to 120 seconds to return, though it's often faster.
The synchronous response can have one of two `status` values:
* `COMPLETE` - Stedi has completed the insurance discovery check for the patient. If Stedi finds coverage for the patient, the `items` array will contain the results. If Stedi doesn't find any coverage for the patient, the `items` array will be empty.
* `PENDING` - Stedi is still processing the insurance discovery check for the patient. You can use the `discoveryId` in the response to [retrieve the results asynchronously](#retrieve-results-asynchronously).
The following example response shows a `PENDING` insurance discovery check. In this case, you would use the `discoveryId` to retrieve the results asynchronously.
{/* schema:InsuranceDiscoveryCheckResponseContent */}
```json Insurance discovery check in progress
{
"discoveryId": "12345678-abcd-4321-efgh-987654321abc",
"meta": {
"applicationMode": "production",
"traceId": "1-abcdef12-123456789abcdef123456789"
},
"status": "PENDING",
"items": []
}
```
The following example response shows a `COMPLETE` insurance discovery check. Stedi found one instance of potential matching coverage for the patient, Jane Doe. Insurance discovery checks only return active coverage for the date of service range provided, so any old plans with expired coverage aren't included in the results.
Information about the potential match is available in the `items` array.
* The `payer` is Aetna.
* The patient in the request, Jane, is a dependent on the Aetna plan because her demographic information appears in the `dependent` object in the response.
* The `confidence.level` is marked as `REVIEW_NEEDED`, because the dependent's last name is slightly different from the patient's last name in the insurance discovery request. However, all of the other demographic details in the dependent object - first name, date of birth, address - match the patient from the request. The two-part last name, Smith Doe, appears to be the complete version of the last name in the request, Doe. Based on this information, we can confirm that this is active coverage for the patient.
* The `benefitsInformation object` (truncated to keep this example concise) contains the patient's benefits details. For example, the patient has active medical coverage under their health plan for the service dates in the request. Visit [Determine patient benefits](/healthcare/eligibility-active-coverage-benefits) to learn more about interpreting the benefits information in the insurance discovery check response.
* Payer names and IDs aren't normalized, so you'll need to handle matching these results to Stedi's Payer Network or your own internal payer list.
{/* schema:InsuranceDiscoveryCheckResponseContent */}
{/* replace:// truncated for brevity: */}
```json Insurance discovery check completed
{
"coveragesFound": 1,
"discoveryId": "e856b480-0b41-11f0-aee6-fc0434004bca",
"items": [
{
"provider": {
"providerName": "THE DOCTORS OFFICE",
"entityType": "Non-Person Entity",
"npi": "1999999984"
},
"subscriber": {
"memberId": "J9606211996",
"firstName": "JOHN",
"lastName": "DOE",
"groupNumber": "012345607890008",
"groupDescription": "SAMPLE HEALTH GROUP",
"insuredIndicator": "Y"
},
"dependent": {
"firstName": "JANE",
"lastName": "SMITH DOE",
"gender": "F",
"dateOfBirth": "20010925",
"planNumber": "0123654",
"relationToSubscriber": "Child",
"relationToSubscriberCode": "19",
"address": {
"address1": "1 MAIN ST",
"address2": "UNIT 1",
"city": "ANYTOWN",
"state": "MO",
"postalCode": "12341"
}
},
"payer": {
"entityIdentifier": "Payer",
"entityType": "Non-Person Entity",
"lastName": "Aetna",
"name": "Aetna",
"payorIdentification": "100003"
},
"planInformation": {
"planNumber": "0123654"
},
"planDateInformation": {
"planBegin": "20250101",
"eligibilityBegin": "20250101",
"service": "20250327"
},
"benefitsInformation": [
{
"code": "1",
"name": "Active Coverage",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"insuranceTypeCode": "PS",
"insuranceType": "Point of Service (POS)",
"planCoverage": "Aetna Choice POS II",
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable"
},
// truncated for brevity
{
"code": "W",
"name": "Other Source of Data",
"benefitsRelatedEntities": [
{
"entityIdentifier": "Payer",
"entityType": "Non-Person Entity",
"entityName": "AETNA",
"address": {
"address1": "PO BOX 981106",
"city": "EL PASO",
"state": "TX",
"postalCode": "79998"
}
}
]
}
],
"confidence": {
"level": "REVIEW_NEEDED",
"reason": "This record was identified as a low confidence match due to a last name mismatch."
}
}
],
"meta": {
"applicationMode": "production",
"traceId": "1-67e5a730-75011daa6caebf3c6595bf7c"
},
"status": "COMPLETE"
}
```
### Concurrency limit [#concurrency-limit]
Visit [Concurrency limits](/healthcare/api-reference#concurrency-limits) for more information.
### Recommended API clients [#recommended-api-clients]
You may want to use an API client to make testing and debugging easier.
We **don't recommend** using Postman for requests containing Protected Health Information (PHI) because Postman defaults to storing request history - including full request payloads - on its cloud servers. You can’t turn this feature off without impractical workarounds.
Visit [API clients](/healthcare/api-reference#api-clients) for a list of recommended clients you can use instead.
## Retrieve results asynchronously [#retrieve-results-asynchronously]
If the synchronous insurance discovery response indicates that the search is still `PENDING`, you can use the `discoveryId` to retrieve the complete results asynchronously from the [Insurance Discovery Check Results](/healthcare/api-reference/get-insurance-discovery-results) endpoint.
You can begin polling immediately after receiving the `PENDING` status response from the synchronous endpoint. Like the synchronous endpoint, the Insurance Discovery Check Results endpoint can take up to 120 seconds to return a response.
It's unlikely for the insurance discovery process to take more than a few minutes, so it's rare to have to poll the asynchronous endpoint more than once. However, if you receive a `PENDING` status, you can poll the endpoint immediately again, and continue this polling process until the status changes to `COMPLETE`.
Note that you should only expect to retrieve checks submitted within the last 24 hours. After 24 hours, the results may no longer be available.
## No matches [#no-matches]
Insurance discovery checks can return zero matches for a patient even when they have active coverage.
```json
{
"coveragesFound": 0,
"discoveryId": "0197a79a-ed75-77c3-af58-8ece597ea0be",
"items": [],
"meta": {
"applicationMode": "production",
"traceId": "1-685c0f14-1b559a954f0bd0127110d161"
},
"status": "COMPLETE"
}
```
Common reasons for zero matches include:
* Recommended demographic data, like SSN or ZIP code, was missing from the request. You should provide as much [patient demographic information](#required-patient-information) as possible to increase the chances of finding matching coverage.
* The patient's data doesn't exactly match what the payer has on file. For example, the patient isn't using their legal name, or their address has changed.
* The payer doesn't support real-time eligibility checks, which makes it impossible for Stedi to determine coverage.
* The patient is covered under a different name, spelling, or demographic variation.
If you think the patient has coverage, try again with corrections or more data. Even small changes like using a partial SSN or legal name can make a difference.
## Coordination of benefits (COB) checks [#coordination-of-benefits-cob-checks]
Insurance discovery checks aren't guaranteed to return all of a patient's active health plans, so a follow-up COB check can help you determine whether the patient has active coverage with additional payers and which payer is responsible for paying claims (primacy).
Once you receive the results of an insurance discovery check, we recommend performing [COB checks](/healthcare/coordination-of-benefits) for the patient using one of their active commercial plans.
# Overview
Source: https://www.stedi.com/docs/healthcare/integrated-account-overview
Integrated accounts are Stedi accounts on the [Basic plan](https://www.stedi.com/pricing) that your providers create and link to your product through a Stedi app. They're a great option when you want to:
* Extend your product with the features in the Stedi portal.
* Simplify multi-tenant claim workflows by scoping credentials and activity per provider or practice.
## How integrated accounts work [#how-integrated-accounts-work]
Instead of using a single Stedi account to manage transactions and enrollments across all providers, you can set up an integrated account for each provider or practice.
1. Each provider or practice creates their own Stedi account on the Basic plan.
2. Providers install your app in their account. As part of the installation, you receive an invite to join their account as a support user.
3. You log into each integrated account to generate API or SFTP credentials that you'll use to link the account to your system. These credentials are scoped to that provider or practice. You can also configure webhooks to monitor claim processing events.
4. Providers log into their integrated accounts to access the Stedi portal, which acts as a co-branded extension of your product.
For example, an Electronic Health Record (EHR) system might build eligibility checks and claim submission directly into its product UI using Stedi's APIs and SFTP. With integrated accounts, their providers can also log into the Stedi portal to submit enrollments, review submitted claims, perform claim status checks, resubmit claims, and more.
## Why use integrated accounts? [#why-use-integrated-accounts]
Integrated accounts have several benefits:
* **Extended functionality:** Offer providers additional features through the Stedi portal. Stedi apps provide this access as a co-branded experience, and providers automatically get new features as soon as we release them.
* **Lower development effort:** Focus on building UIs for the workflows you care about. Avoid building and maintaining custom routing, tenancy, and attribution logic for claims workflows.
* **Built-in tenancy:** Integrated accounts scope API and SFTP credentials to each provider or practice, so you can attribute, monitor, and isolate enrollments and transactions. This model also simplifies usage tracking and billing by provider or practice.
* **Support access:** Your support team can log into integrated accounts to troubleshoot issues directly.
## Stedi apps [#stedi-apps]
Stedi apps are prebuilt integrations between Stedi and your system. After you publish your app to the Stedi app directory, your providers can install it from within their Stedi accounts. Then, you can log into each integrated account to generate credentials and configure webhooks to link the account to your system.
As an app developer, you can offer your app for free on the Basic plan or require a paid upgrade. Visit [Publish your app](/healthcare/integrated-account-setup#step-1-publish-your-app) for more details.
# Set up integrated accounts
Source: https://www.stedi.com/docs/healthcare/integrated-account-setup
Integrated accounts allow your providers to create their own Stedi accounts that act as a co-branded extension of your product's functionality.
This guide explains how to set up integrated accounts for your providers.
## Step 1: Publish your app [#step-1-publish-your-app]
Your providers will install a Stedi app to link their Stedi account to your product. [Contact us](https://www.stedi.com/contact) to discuss adding your business to the Stedi app directory. The process is simple and typically takes 1-2 days:
1. Meet with our team to align on how your customers' accounts will map to Stedi organizations. During this process, you can request to automatically add one or more support users (members) with a [Developer role](/healthcare/accounts-and-billing#assign-member-roles) to accounts that install your app. This allows your support team to troubleshoot issues directly within customer accounts and help with implementation.
2. Confirm that existing services contracts and a partner or platform integration agreement are in place.
3. Supply your company logo, URL, support email, and description.
4. We publish your app listing to the directory and make it discoverable to customers.
Once your app is published, your providers can install it from within their Stedi accounts.
## Step 2: Your providers create Stedi accounts [#step-2-your-providers-create-stedi-accounts]
Once your app is listed in the directory, Stedi generates a custom signup link for your providers. The link takes providers through a signup flow that creates an integrated account, a Stedi account on the Basic plan that's linked to your app. The signup page is branded with your app's name and logo.
To get the signup link for your Stedi app, contact us in your Slack or Microsoft Teams channel. You can also email us or use our [contact form](https://www.stedi.com/contact).
Providers will:
1. Go to the custom signup link for your app.
2. Follow the signup process, which includes:
* Filling out the signup form.
* Setting up Multi-Factor Authentication (MFA).
* Naming their Stedi account.
* Choosing the **Basic** plan option.
* Agreeing to a Business Associate Agreement (BAA).
After completing these steps, Stedi begins provisioning the account. This process takes approximately 20-30 minutes, and your providers will need to wait until it's complete before proceeding to Step 3.
## Step 3: Your providers install your app [#step-3-your-providers-install-your-app]
Providers will be able to install your app once their Stedi accounts are fully provisioned (20-30 minutes). To install your app, providers will:
1. Click **Apps** in the navigation bar to go to the [Apps page](https://portal.stedi.com/app/settings/apps) in their **Account settings**.
2. Find and click on your app from the available list.
3. Click **Install** to begin the installation process.
4. Read the installation details and then click **Confirm and install**. This action sends an email invitation to the support email you specified for your Stedi app.
Stedi displays new API and SFTP credentials that the provider can copy and paste into your system to complete the integration. We generally recommend that providers ignore these credentials during installation - you will generate and manage credentials for them in Step 4.
5. (Optional) Check the box next to **I've added these details to my \[Your Company Name] account** and click **Done**.
You'll get invited to the integrated account as a support regardless of whether the provider completes this final step.
The app is now installed, and the provider can start using the functionality within Stedi's portal.
## Step 4: You configure each integrated account [#step-4-you-configure-each-integrated-account]
After your providers install your app, you can use the Stedi portal to manage each integrated account.
### Accept email invitation [#accept-email-invitation]
Stedi automatically invites the specified support email to the integrated account when providers install your app. Accept the email invitation and log in to complete the setup.
This process also allows your support team to troubleshoot issues directly as needed.
### Generate API or SFTP credentials [#generate-api-or-sftp-credentials]
You can generate credentials manually at any time within each integrated account. You can also revoke or rotate credentials as needed, without reinstalling the app.
To generate credentials:
1. Log in to the integrated account using your support email.
2. Click **Apps** in the navigation bar. Stedi opens a side panel with a list of installed apps.
3. Click **Settings** next to your app to open the app settings page.
4. Generate new API or SFTP credentials.
### Create webhooks to monitor processed transactions [#create-webhooks-to-monitor-processed-transactions]
We strongly recommend setting up webhooks in each integrated account to monitor claim processing events.
These events contain the information you need to retrieve 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA) responses through Stedi APIs. They can also help you monitor your claims pipeline when submitting claims through Stedi SFTP.
To configure webhooks:
1. Log in to the integrated account using your support email.
2. Click **Apps** in the navigation bar. Stedi opens a side panel with a list of installed apps.
3. Click **Settings** next to your app to open the app settings page.
4. Scroll to the **Webhooks** section and click **Configure webhooks**.
Stedi takes you to the webhooks configuration page, where you can create and manage webhooks for the integrated account. Our [Configure webhooks](/healthcare/configure-webhooks) docs explain how to set up webhooks and which events to monitor for your use case.
## Next steps [#next-steps]
We maintain a separate set of [Provider docs](https://www.stedi.com/docs/providers) that you can share with your providers to help them get started with Stedi. You can also use our docs as a starting point for your own documentation about how to use Stedi. The docs include information on:
* Managing a Stedi account
* Running eligibility checks
* Submitting and managing claims
* Accessing 277CA claim acknowledgments and 835 Electronic Remittance Advice (ERAs)
* Running claim status checks
* Other helpful Stedi UI features
You may want to refer to the following resources as you build your integration with Stedi:
* [Developer guides](https://www.stedi.com/docs/healthcare)
* [API reference](https://www.stedi.com/docs/healthcare/api-reference)
# Overview
Source: https://www.stedi.com/docs/healthcare/intro-eligibility-checks
An eligibility check is the process of verifying whether a patient has coverage for specific medical benefits under their health insurance plan. This process allows patients and healthcare providers to determine a patient's financial responsibilities for medical services.
You can send either real-time or batch eligibility checks through Stedi. With real-time checks, you receive the response from the payer in seconds. With batch checks, you can submit up to 10,000 eligibility checks in a single request for Stedi to process asynchronously.
Eligibility checks verify coverage with a specific payer. If you don't know
the payer, you can perform an [insurance discovery
check](/healthcare/insurance-discovery) instead to find a patient's coverage
using their demographic data.
## Real-time eligibility checks [#real-time-eligibility-checks]
Real-time eligibility checks are ideal for in-person patient visits, telehealth appointments, and other scenarios where you need immediate information about a patient's coverage.
We recommend always starting with real-time checks when integrating with a new payer. This approach allows you to quickly test and refine your pipeline through fast feedback loops. Once you're comfortable with real-time checks, you may also want to start sending asynchronous batch checks to perform periodic refreshes for all or a subset of patients.
Stedi supports sending real-time eligibility checks to payers, in either
JSON or X12 EDI format. You can submit requests manually through the Stedi
portal or programmatically through the API.
Stedi routes requests to the payer using the most reliable connection. Stedi
receives payer responses in X12 EDI and transforms them into JSON to make
them easier to ingest into your business systems.
Stedi returns the payer's synchronous response. It contains details about a
patient's medical coverage, including the start and end date of the
coverage, covered benefits and services, copayments, deductibles, and
out-of-pocket maximums.
Learn more about [Real-time eligibility checks](/healthcare/send-eligibility-checks).
## Batch eligibility checks [#batch-eligibility-checks]
Batch eligibility checks are a great option as your volume grows. Stedi handles complexity like queuing and retries according to established best practices, so you don't have to build this logic yourself. We recommend using batch checks for bulk workflows that aren't time sensitive, including:
* Monthly or weekly coverage refreshes
* Upcoming appointments
* Sets of thousands or millions of checks that can run in the background
However, batch checks have a longer feedback cycle than real-time checks because you don't receive the payer's response immediately. That's why we strongly recommend starting with [real-time checks](/healthcare/api-reference/post-healthcare-eligibility) when integrating with a new payer or working with eligibility checks for the first time. This approach allows you to ensure that your pipeline is working smoothly before you begin staging batch checks.
You can submit batch eligibility checks manually by uploading CSV files to
the Stedi portal or programmatically by sending a request to the [Batch Eligibility Check](/healthcare/api-reference/post-healthcare-batch-eligibility)
endpoint. Each batch can contain up to 10,000 eligibility checks.
Stedi processes these batch checks asynchronously, implementing best practices
to avoid payer throttling. Stedi routes requests to the payer using the most
reliable connection.
The API's synchronous response contains a `batchId` that you can use to
retrieve the results of the batch checks using the [Poll Batch Eligibility Checks](/healthcare/api-reference/get-healthcare-polling-eligibility)
endpoint. You can also review the results of batch eligibility checks from
the [Eligibility check batches page](https://portal.stedi.com/app/healthcare/checks/batch) in the Stedi
portal.
Learn more about [Batch eligibility checks](/healthcare/batch-refresh-eligibility-checks).
## Patient benefits [#patient-benefits]
The payer's 271 response includes detailed information about the patient's coverage and benefits. You can use this information to determine:
* whether the patient has active coverage with the health plan.
* whether a patient's health plan covers the requested services.
* patient responsibility amounts, such as co-pays and deductibles.
* whether prior authorization is required for specific services.
You can review this benefits information in multiple ways, depending on your use case.
| Method | Description | Docs |
| ------------------- | -------------------------------------------------------- | ----------------------------------------------------------------- |
| **API responses** | Lossless responses in JSON or X12 EDI | [API responses](/healthcare/eligibility-active-coverage-benefits) |
| **Stedi portal** | A user-friendly, filterable table | [Stedi portal UI](/healthcare/eligibility-portal-benefits-view) |
| **Eligibility PDF** | A PDF that you can download or retrieve programmatically | [Eligibility PDF](/healthcare/eligibility-pdf) |
## X12 HIPAA format [#x12-hipaa-format]
The Health Insurance Portability and Accountability Act (HIPAA) mandates that eligibility checks be submitted in a standardized format: X12 HIPAA. X12 HIPAA is a type of Electronic Data Interchange (EDI), a data format developed in the 1970s to allow businesses to exchange documents electronically.
While some healthcare institutions can submit eligibility checks directly in X12 HIPAA, many of today's software applications are built to use more modern data formats like JSON. That's why Stedi offers two types of APIs for eligibility checks: one that accepts JSON and automatically converts it to X12 HIPAA behind the scenes, and another that accepts X12 HIPAA directly.
## Billing for eligibility checks [#billing-for-eligibility-checks]
Transactions are billable at the usage rates specified in your contract unless they fall into one of the following non-billable categories:
1. All eligibility checks you send in [Test Mode](/healthcare/test-mode).
2. All eligibility checks that return `AAA` = `42` or `AAA` = `80` errors, which indicate that the payer is down.
3. All eligibility checks that return `AAA` = `79` errors, which indicate there was a problem connecting to this payer.
4. All API calls that return `4xx` or `5xx` errors.
# Overview
Source: https://www.stedi.com/docs/healthcare/intro-to-claim-submission
A claim is a request for payment submitted to an insurance company or health plan. It details the medical services rendered to a patient, including information about the diagnosis, treatment, and any procedures performed. The claim is used to determine the reimbursement amount that the submitter (typically a medical provider) should receive from the insurance company.
Payers sometimes require additional documentation to process claims, such as medical records, treatment plans, radiographs, photographs, itemized bills, and letters from providers. These documents are submitted as claim attachments.
You can submit claims and claim attachments through Stedi APIs, SFTP, and the Stedi portal.
## API claim submission [#api-claim-submission]
You can submit claims and attachments to Stedi APIs in either JSON or X12 EDI format. We recommend this approach when you want to submit claims and attachments programmatically without dealing with the complexities of the X12 EDI format.
Stedi supports sending the following transactions to payers:
* 837P professional claim |
[JSON API](/healthcare/api-reference/post-healthcare-claims) | [X12 EDI API](/healthcare/api-reference/post-healthcare-claims-raw-x12)
* 837I institutional claim | [JSON API](/healthcare/api-reference/post-healthcare-institutional-claims) | [X12 EDI API](/healthcare/api-reference/post-healthcare-institutional-claims-raw-x12)
* 837D dental claim | [JSON API](/healthcare/api-reference/post-healthcare-dental-claims) | [X12 EDI API](/healthcare/api-reference/post-healthcare-dental-claims-raw-x12)
* 275 attachments | [JSON API](/healthcare/api-reference/post-healthcare-create-claim-attachment) | [X12 EDI API](/healthcare/api-reference/post-healthcare-submit-claim-attachment-raw-x12)
Stedi translates JSON requests into X12 EDI and validates the data using our growing library of [claim edits](/healthcare/claim-edits-and-repairs) to ensure claims comply with HIPAA and the payer's specifications.
Stedi routes requests to the payer. Stedi receives payer responses in X12 EDI and transforms them into JSON to make them easier to ingest into your business systems.
You can either poll or listen for event-driven webhooks to discover new 277CA claim acknowledgments and 835 Electronic Remittance Advice (ERAs). Then, you can use Stedi APIs to retrieve these responses in JSON format.
Learn more about API submission for [professional](/healthcare/submit-professional-claims), [institutional](/healthcare/submit-institutional-claims), [dental](/healthcare/submit-dental-claims), and [workers' compensation](/healthcare/submit-workers-comp-auto-liability-claims) claims, as well as [unsolicited claim attachments](/healthcare/submit-claim-attachments).
## SFTP claim submission [#sftp-claim-submission]
We recommend Stedi SFTP when you have an existing system that generates X12 EDI files, and you want to send them through Stedi without completing an API integration.
You can create both test and production SFTP users. Test users can only send
claims to Stedi’s test clearinghouse, which helps ensure you never
accidentally send test claims to payers while you’re getting up and running.
Connect to Stedi’s server and drop compliant X12 EDI professional,
institutional, or dental claim files, as well as unsolicited 275
attachments, into the `to-stedi` directory.
Stedi automatically validates claims using our growing library of [claim
edits](/healthcare/claim-edits-and-repairs) to ensure they comply with HIPAA
and the payer's specifications. Then, Stedi routes claims to the test or
production clearinghouse.
Stedi places claim responses - 277CA claim acknowledgments and 835 ERAs -
into the `from-stedi` directory in X12 EDI format. You can retrieve these
responses from the directory at your preferred cadence.
Learn more about [SFTP claim and attachment submission](/healthcare/submit-claims-sftp-connection).
## X12 HIPAA format [#x12-hipaa-format]
The Health Insurance Portability and Accountability Act (HIPAA) mandates that claims and claim attachments be submitted in a standardized format: X12 HIPAA. X12 HIPAA is a type of Electronic Data Interchange (EDI), a data format developed in the 1970s to allow businesses to exchange documents electronically.
While some healthcare institutions can submit claims and claim attachments directly in X12 HIPAA, many of today's software applications are built to use more modern data formats like JSON. That's why Stedi offers two types of APIs for claims processing: one that accepts JSON and automatically converts it to X12 HIPAA behind the scenes, and another that accepts X12 HIPAA directly.
## Billing for 837 claims and 275 attachments [#billing-for-837-claims-and-275-attachments]
Transactions are billable at the usage rates specified in your contract, except for API calls that return 4xx or 5xx errors. For example, you won't be charged when a request fails because the payer isn't supported - in this case, Stedi returns a `400` HTTP status code.
# Medicare Beneficiary Identifier (MBI) lookup
Source: https://www.stedi.com/docs/healthcare/mbi-lookup
A [Medicare Beneficiary Identifier (MBI)](https://www.cms.gov/training-education/partner-outreach-resources/new-medicare-card/medical-beneficiary-identifiers-mbis) is a unique, randomly-generated identifier assigned to individuals enrolled in Medicare. You must include the patient's MBI in every eligibility check you submit to the Centers for Medicare and Medicaid Services ([payer ID: CMS](https://www.stedi.com/healthcare/network/cms)).
When patients don't know their MBI, you can use Stedi's eligibility APIs to perform an MBI lookup instead of a standard eligibility check. Stedi returns a complete eligibility response containing the patient’s coverage status and their MBI for future reference.
There is an additional cost to perform MBI lookups with Stedi's eligibility
check APIs. Visit [pricing](https://www.stedi.com/pricing) for details.
## Types of MBI lookups [#types-of-mbi-lookups]
There are two types of MBI lookups you can perform with Stedi. For each, you'll use a special payer ID that tells Stedi to perform an MBI lookup for the patient in addition to a standard eligibility check.
| Type | What's required | Payer ID |
| -------- | ------------------------------------------------------------------ | ------------ |
| With SSN | first name, last name, date of birth, Social Security Number (SSN) | `MBILU` |
| No SSN | first name, last name, date of birth, U.S. state | `MBILUNOSSN` |
When running an MBI lookup without SSN using our [raw
X12](/healthcare/api-reference/post-healthcare-eligibility-raw-x12) or
[SOAP](/healthcare/api-reference/post-healthcare-eligibility-soap) endpoints,
you must include a city, in addition to a U.S. state, in `Loop 2100C N4`. You
can use a dummy city value, such as `DUMMY`, if needed. If you omit the city
value, you'll receive an X12 validation error.
We recommend running MBI lookups **with** the patient's SSN whenever possible. When the SSN is present, the MBI lookup has a higher likelihood of successfully returning their MBI. MBI lookups with no SSN are a fallback option when the patient's SSN isn't available.
You don't need to include more patient demographic information than what's required, such as additional address data. It doesn’t improve MBI lookup success rates.
## Transaction enrollment [#transaction-enrollment]
[Transaction enrollment](/healthcare/transaction-enrollment) is the process of registering a provider to exchange specific healthcare transactions with a payer.
Unlike standard eligibility checks, MBI lookups **always** require transaction enrollment. This is because MBI lookups involve sending requests to special Stedi payers that tell Stedi to perform the MBI lookup in addition to a standard eligibility check. The provider must be enrolled with Stedi's MBI lookup payers to use these services.
To enroll, complete the following steps:
1. Create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step. [Stedi portal](https://portal.stedi.com/app/healthcare/providers) | [API endpoint](/healthcare/api-reference/post-enrollment-create-provider)
2. Submit an enrollment request for **Real-time eligibility checks**. [Stedi portal](https://portal.stedi.com/app/healthcare/enrollments) | [API endpoint](/healthcare/api-reference/post-enrollment-create-enrollment)
Select the payer ID based on the type of MBI lookup you want to perform:
* **With SSN:** [`MBILU` (CMS MBI Lookup)](https://www.stedi.com/healthcare/network?page=0\&search=MBIL\&entry=ASKVB)
* **No SSN:** [`MBILUNOSSN` (CMS MBI Lookup Without SSN)](https://www.stedi.com/healthcare/network?page=0\&search=MBIL\&entry=APSMC)
If you want to perform both types of MBI lookups, you must submit separate enrollment requests for each payer ID.
When MBI lookups with SSN (Payer ID: `MBILU`) fail because the provider isn't enrolled, Stedi automatically submits the required transaction enrollment request. [Learn more](/healthcare/create-manage-transaction-enrollments#automatic-enrollment-requests)
## Run MBI lookups [#run-mbi-lookups]
You can run MBI lookups with and without SSN using the following endpoints:
* [Real-Time Eligibility Check JSON](/healthcare/api-reference/post-healthcare-eligibility)
* [Real-Time Eligibility Check Raw X12](/healthcare/api-reference/post-healthcare-eligibility-raw-x12)
* [Real-Time Eligibility Check SOAP](/healthcare/api-reference/post-healthcare-eligibility-soap)
* [Batch Eligibility Check](/healthcare/api-reference/post-healthcare-batch-eligibility)
You can also run MBI lookups with and without SSN through the [New eligibility check form](https://portal.stedi.com/app/healthcare/checks/create) in the Stedi portal and through [bulk CSV uploads](/healthcare/batch-refresh-eligibility-checks#manual-submission).
### Request [#request]
Construct an eligibility check request that includes the required patient demographic data:
* **With SSN:** first name, last name, date of birth, Social Security Number (SSN)
* **No SSN:** first name, last name, date of birth, U.S. state
When running an MBI lookup without SSN using our [raw
X12](/healthcare/api-reference/post-healthcare-eligibility-raw-x12) or
[SOAP](/healthcare/api-reference/post-healthcare-eligibility-soap) endpoints,
you must include a city, in addition to a U.S. state, in `Loop 2100C N4`. You
can use a dummy city value, such as `DUMMY`, if needed. If you omit the city
value, you'll receive an X12 validation error.
Set the `tradingPartnerServiceId` to:
* **With SSN:** `MBILU`
* **No SSN:** `MBILUNOSSN`
These are special payer IDs that tell Stedi to perform an MBI lookup for the patient in addition to a standard eligibility check.
You don't need to include other patient information, such as additional address data. It doesn’t improve lookup success rates.
The following sample requests show how to perform an MBI lookup for a patient named Jane Doe.
{/* schema:EligibilityCheckRequestContent */}
```bash Example MBI Lookup request
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3 \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "MBILU",
"externalPatientId": "UAA111222333",
"encounter": {
"serviceTypeCodes": [
"30"
]
},
"provider": {
"organizationName": "ACME Health Services",
"npi": "1999999984"
},
"subscriber": {
"dateOfBirth": "19000101",
"firstName": "Jane",
"lastName": "Doe",
"ssn": "123456789"
}
}'
```
```bash Example MBI Lookup request
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3 \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "MBILUNOSSN",
"externalPatientId": "UAA111222333",
"encounter": {
"serviceTypeCodes": [
"30"
]
},
"provider": {
"organizationName": "ACME Health Services",
"npi": "1999999984"
},
"subscriber": {
"dateOfBirth": "19000101",
"firstName": "Jane",
"lastName": "Doe",
"address": {
"state": "WV"
}
}
}'
```
### Response [#response]
Stedi uses the patient’s demographic data and SSN to perform an MBI lookup. If there is a match, Stedi submits an eligibility check to CMS. The response shape is the same for both the SSN and no SSN lookup types.
Stedi returns a complete eligibility response from CMS for the patient and places the patient's MBI in the `subscriber.memberId` property.
Visit [Determine patient benefits](/healthcare/eligibility-active-coverage-benefits) for details about how you can use the eligibility response to determine a patient's coverage status and benefits.
The following example shows a CMS eligibility response returned from an MBI lookup. In this scenario, the patient's MBI is `1AA2CC3DD45`.
{/* schema:EligibilityCheckResponseContent */}
```json Example MBI Lookup response
{
"meta": {
"senderId": "STEDI",
"submitterId": "117151744",
"applicationMode": "production",
"traceId": "11112222333344445555666677",
"outboundTraceId": "11112222333344445555666677"
},
"controlNumber": "112233445",
"id": "ec_01234567-89ab-cdef-0123-456789abcdef",
"reassociationKey": "112233445",
"tradingPartnerServiceId": "CMS",
"provider": {
"providerName": "ACME HEALTH SERVICES",
"entityIdentifier": "Provider",
"entityType": "Non-Person Entity",
"npi": "1999999984"
},
"subscriber": {
"memberId": "1AA2CC3DD45",
"firstName": "JANE",
"lastName": "DOE",
"middleName": "A",
"gender": "F",
"entityIdentifier": "Insured or Subscriber",
"entityType": "Person",
"dateOfBirth": "19000101",
"address": {
"address1": "1234 FIRST ST",
"city": "NEW YORK",
"state": "WV",
"postalCode": "123451111"
}
},
"payer": {
"entityIdentifier": "Payer",
"entityType": "Non-Person Entity",
"name": "CMS",
"payorIdentification": "CMS"
},
"planDateInformation": {
"eligibility": "20241025"
},
"planStatus": [
{
"statusCode": "1",
"status": "Active Coverage",
"serviceTypeCodes": ["88"]
},
{
"statusCode": "1",
"status": "Active Coverage",
"serviceTypeCodes": [
"30",
"42",
"45",
"48",
"49",
"69",
"76",
"83",
"A5",
"A7",
"AG",
"BT",
"BU",
"BV"
]
},
{
"statusCode": "1",
"status": "Active Coverage",
"serviceTypeCodes": [
"30",
"2",
"23",
"24",
"25",
"26",
"27",
"28",
"3",
"33",
"36",
"37",
"38",
"39",
"40",
"42",
"50",
"51",
"52",
"53",
"67",
"69",
"73",
"76",
"83",
"86",
"98",
"A4",
"A6",
"A8",
"AI",
"AJ",
"AK",
"AL",
"BT",
"BU",
"BV",
"DM",
"UC"
]
}
],
"benefitsInformation": [
{
"code": "I",
"name": "Non-Covered",
"serviceTypeCodes": ["41", "54"],
"serviceTypes": ["Routine (Preventive) Dental", "Long Term Care"],
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable"
},
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": ["88"],
"serviceTypes": ["Pharmacy"],
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable"
},
{
"code": "R",
"name": "Other or Additional Payor",
"insuranceTypeCode": "QM",
"insuranceType": "Qualified Medicare Beneficiary",
"planCoverage": "CA QMB Plan",
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable",
"benefitsDateInformation": {
"coordinationOfBenefits": "20230101"
}
},
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": [
"30",
"42",
"45",
"48",
"49",
"69",
"76",
"83",
"A5",
"A7",
"AG",
"BT",
"BU",
"BV"
],
"serviceTypes": [
"Health Benefit Plan Coverage",
"Home Health Care",
"Hospice",
"Hospital - Inpatient",
"Hospital - Room and Board",
"Maternity",
"Dialysis",
"Infertility",
"Psychiatric - Room and Board",
"Psychiatric - Inpatient",
"Skilled Nursing Care",
"Gynecological",
"Obstetrical",
"Obstetrical/Gynecological"
],
"insuranceTypeCode": "MA",
"insuranceType": "Medicare Part A",
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable",
"benefitsDateInformation": {
"plan": "20190101"
},
"additionalInformation": [
{
"description": "0-Beneficiary insured due to age OASI"
}
]
},
{
"code": "C",
"name": "Deductible",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"insuranceTypeCode": "QM",
"insuranceType": "Qualified Medicare Beneficiary",
"planCoverage": "Medicare Part A",
"timeQualifierCode": "26",
"timeQualifier": "Episode",
"benefitAmount": "0",
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable",
"benefitsDateInformation": {
"plan": "20240101-20241231"
}
},
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": [
"30",
"2",
"23",
"24",
"25",
"26",
"27",
"28",
"3",
"33",
"36",
"37",
"38",
"39",
"40",
"42",
"50",
"51",
"52",
"53",
"67",
"69",
"73",
"76",
"83",
"86",
"98",
"A4",
"A6",
"A8",
"AI",
"AJ",
"AK",
"AL",
"BT",
"BU",
"BV",
"DM",
"UC"
],
"serviceTypes": [
"Health Benefit Plan Coverage",
"Surgical",
"Diagnostic Dental",
"Periodontics",
"Restorative",
"Endodontics",
"Maxillofacial Prosthetics",
"Adjunctive Dental Services",
"Consultation",
"Chiropractic",
"Dental Crowns",
"Dental Accident",
"Orthodontics",
"Prosthodontics",
"Oral Surgery",
"Home Health Care",
"Hospital - Outpatient",
"Hospital - Emergency Accident",
"Hospital - Emergency Medical",
"Hospital - Ambulatory Surgical",
"Smoking Cessation",
"Maternity",
"Diagnostic Medical",
"Dialysis",
"Infertility",
"Emergency Services",
"Professional (Physician) Visit - Office",
"Psychiatric",
"Psychotherapy",
"Psychiatric - Outpatient",
"Substance Abuse",
"Alcoholism",
"Drug Addiction",
"Vision (Optometry)",
"Gynecological",
"Obstetrical",
"Obstetrical/Gynecological",
"Durable Medical Equipment",
"Urgent Care"
],
"insuranceTypeCode": "MB",
"insuranceType": "Medicare Part B",
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable",
"benefitsDateInformation": {
"plan": "20190101"
},
"additionalInformation": [
{
"description": "0-Beneficiary insured due to age OASI"
}
]
},
{
"code": "C",
"name": "Deductible",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"insuranceTypeCode": "QM",
"insuranceType": "Qualified Medicare Beneficiary",
"planCoverage": "Medicare Part B",
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "0",
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable",
"benefitsDateInformation": {
"plan": "20240101-20241231"
}
},
{
"code": "A",
"name": "Co-Insurance",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"insuranceTypeCode": "QM",
"insuranceType": "Qualified Medicare Beneficiary",
"planCoverage": "Medicare Part B",
"timeQualifierCode": "27",
"timeQualifier": "Visit",
"benefitPercent": "0",
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable",
"benefitsDateInformation": {
"plan": "20240101-20241231"
}
},
{
"code": "R",
"name": "Other or Additional Payor",
"serviceTypeCodes": ["88"],
"serviceTypes": ["Pharmacy"],
"insuranceTypeCode": "OT",
"insuranceType": "Other",
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable",
"benefitsAdditionalInformation": {
"planNumber": "A0505",
"planNetworkIdNumber": "555"
},
"benefitsDateInformation": {
"benefit": "20230101"
},
"benefitsRelatedEntity": {
"entityIdentifier": "Payer",
"entityType": "Non-Person Entity",
"entityName": "UHC OF CALIFORNIA",
"address": {
"address1": "202 Main St",
"city": "Sacramento",
"state": "CA",
"postalCode": "94203"
},
"contactInformation": {
"contacts": [
{
"communicationMode": "Telephone",
"communicationNumber": "8006446644"
},
{
"communicationMode": "Uniform Resource Locator (URL)",
"communicationNumber": "UHC.com/Medicare"
}
]
}
},
"benefitsRelatedEntities": [
{
"entityIdentifier": "Payer",
"entityType": "Non-Person Entity",
"entityName": "UHC OF CALIFORNIA",
"address": {
"address1": "202 Main St",
"city": "Sacramento",
"state": "CA",
"postalCode": "94203"
},
"contactInformation": {
"contacts": [
{
"communicationMode": "Telephone",
"communicationNumber": "8006446644"
},
{
"communicationMode": "Uniform Resource Locator (URL)",
"communicationNumber": "UHC.com/Medicare"
}
]
}
}
]
},
{
"code": "U",
"name": "Contact Following Entity for Eligibility or Benefit Information",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"insuranceTypeCode": "HN",
"insuranceType": "Health Maintenance Organization (HMO) - Medicare Risk",
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable",
"benefitsAdditionalInformation": {
"planNumber": "A0505",
"planNetworkIdNumber": "555"
},
"benefitsDateInformation": {
"coordinationOfBenefits": "20230101"
},
"benefitsRelatedEntity": {
"entityIdentifier": "Primary Payer",
"entityType": "Non-Person Entity",
"entityName": "UHC OF CALIFORNIA",
"address": {
"address1": "202 Main St",
"city": "Sacramento",
"state": "CA",
"postalCode": "94203"
},
"contactInformation": {
"contacts": [
{
"communicationMode": "Telephone",
"communicationNumber": "8006446644"
},
{
"communicationMode": "Uniform Resource Locator (URL)",
"communicationNumber": "UHC.com/Medicare"
}
]
}
},
"benefitsRelatedEntities": [
{
"entityIdentifier": "Primary Payer",
"entityType": "Non-Person Entity",
"entityName": "UHC OF CALIFORNIA",
"address": {
"address1": "202 Main St",
"city": "Sacramento",
"state": "CA",
"postalCode": "94203"
},
"contactInformation": {
"contacts": [
{
"communicationMode": "Telephone",
"communicationNumber": "8006446644"
},
{
"communicationMode": "Uniform Resource Locator (URL)",
"communicationNumber": "UHC.com/Medicare"
}
]
}
}
],
"additionalInformation": [
{
"description": "MA Bill Option Code - A"
}
]
}
],
"errors": [],
"x12": ""
}
```
### Concurrency limit [#concurrency-limit]
MBI lookups you perform using real-time eligibility check endpoints (JSON and Raw X12) share a concurrency pool with other real-time healthcare APIs. For more information, visit [Concurrency limits](/healthcare/api-reference#concurrency-limits).
MBI lookups you perform using the [Batch Eligibility Check](/healthcare/api-reference/post-healthcare-batch-eligibility) endpoint don't count toward your Stedi account concurrency limit.
## Mock request [#mock-request]
When you submit the following mock MBI lookup request to the eligibility check endpoints with a [test API key](/healthcare/api-reference#api-key-types), Stedi returns mock benefits data you can use for testing. The mock request works with Stedi's [JSON](/healthcare/api-reference/post-healthcare-eligibility), [Raw X12](/healthcare/api-reference/post-healthcare-eligibility-raw-x12), and [SOAP](/healthcare/api-reference/post-healthcare-eligibility-soap) endpoints.
This mock request is for an MBI lookup with SSN.
Mock requests are free for testing purposes and won't incur any charges in
your Stedi account.
Request Notes:
* `encounter`: Only service type code 30 is supported.
* `provider`: You can use any organization name and any NPI, as long as it passes check digit validation. To generate a dummy NPI, you can use this [free tool](https://jsfiddle.net/alexdresko/cLNB6).
* `subscriber`: You must use the exact values in the test request. Other birth dates, first names, last names, and Social Security Numbers return errors.
{/* schema:EligibilityCheckRequestContent */}
```bash test request for CMS MBI Lookup
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key ' \
--header 'Content-Type: application/json' \
--data '{
"controlNumber": "112233445",
"tradingPartnerServiceId": "MBILU",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"lastName": "Doe",
"dateOfBirth": "19550505",
"ssn": "123456789"
},
"encounter": {
"serviceTypeCodes": [
"30"
]
}
}'
```
```bash test request for CMS MBI Lookup
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key ' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*CMS MBI Lookup*****PI*MBILU~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*****MI*123456789~REF*SY*123456789~DMG*D8*19550505~EQ*30~SE*13*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for CMS MBI Lookup
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*CMS MBI Lookup*****PI*MBILU~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*****MI*123456789~REF*SY*123456789~DMG*D8*19550505~EQ*30~SE*13*0001~GE*1*1~IEA*1*000000001~]]>
'
```
## Health Insurance Claim Number (HICN) [#health-insurance-claim-number-hicn]
Some payers return the patient's MBI in one of the following properties of the standard eligibility response:
* [`benefitsInformation[].benefitsAdditionalInformation.hicNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.benefitsInformation.benefitsAdditionalInformation.hicNumber)
* [`planInformation.hicNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.planInformation.hicNumber)
If the value in either of these properties matches the format specified in the [Medicare Beneficiary Identifier documentation](https://www.cms.gov/training-education/partner-outreach-resources/new-medicare-card/medical-beneficiary-identifiers-mbis), the number is likely an MBI. In these cases, you don't need to perform an MBI lookup - you can use this value in a standard eligibility check to CMS.
You're most likely to receive an MBI in eligibility responses from commercial Medicare Advantage plans, but they can also be present in responses from Medicaid plans for dual-eligible patients.
## Medicare Advantage plans [#medicare-advantage-plans]
A Medicare Advantage plan (also known as Medicare Part C) is a type of health insurance plan offered by private companies that contract with Medicare to provide all of a patient's Part A (hospital insurance) and Part B (medical insurance) benefits.
Medicare Advantage plans have their own unique member ID, which **isn't** returned in the MBI lookup response. However, the MBI lookup response will include the patient's Medicare Advantage plan name in the [`benefitsInformation[].benefitsRelatedEntities[].entityName`](/healthcare/api-reference/post-healthcare-eligibility#response.benefitsInformation.benefitsRelatedEntities.entityName) property when available. Please note that you shouldn't submit eligibility checks for Medicare Advantage plans to CMS (HETS) - you should submit them to the actual Medicare Advantage plan payer instead.
Many Medicare Advantage plans allow you to submit [eligibility checks](/healthcare/send-eligibility-checks) with just the patient's name and date of birth. However, if that approach is unsuccessful and you don't have the patient's member ID, you can use [Insurance Discovery](/healthcare/insurance-discovery) to retrieve benefits information with the patient's demographic information instead.
### HETS Rules of Behavior [#hets-rules-of-behavior]
You must abide by the HIPAA Eligibility Transaction System (HETS) [Rules of Behavior](https://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/hetshelp/downloads/eligibilitytransactionsysteminquiriesrulesofbehavior.pdf) when you use MBI lookup. HETS is intended to support original Medicare fee-for-service (FFS) activities, such as preparing and submitting FFS claims.
If you have no intention of submitting claims to Medicare, using MBI lookup to identify whether a patient is enrolled in a Medicare Advantage plan is likely outside the scope of permitted HETS use. You should consult your own legal counsel to determine what's permissible for your specific situation.
Stedi can't make this determination on your behalf or provide consultation about what may or may not be permitted.
## Outdated MBI error [#outdated-mbi-error]
Stedi's MBI lookup may rarely retrieve an outdated MBI for a patient. CMS may rotate an MBI for a member for various reasons at any time, such as to help protect against identity theft.
In these cases, the response will contain an [`AAA` error](/healthcare/eligibility-troubleshooting#payer-aaa-errors) with code `72` (Invalid/Missing Subscriber/Insured ID) *and* return the `subscriber.memberId` containing the outdated MBI.
```json
{
"warnings": [
{
"code": "request::270::member_id_required",
"description": "This payer requires the patient's member ID to be included in eligibility requests."
}
],
"errors": [
{
"code": "72",
"description": "Invalid/Missing Subscriber/Insured ID",
"field": "AAA",
"followupAction": "Please Correct and Resubmit",
"location": "2100C",
"possibleResolutions": "The subscriber's member ID is either missing or invalid.\n• Check the `subscriber.memberId`.\n• Ensure the member ID doesn't include the [Card Issuer Identifier](https://www.stedi.com/docs/healthcare/eligibility-troubleshooting#card-issuer-identifier-80840).\n• If you can't locate the correct member ID, try running an [insurance discovery check](https://www.stedi.com/docs/healthcare/insurance-discovery) to retrieve the patient's benefits information instead."
}
],
"subscriber": {
"aaaErrors": [
{
"code": "72",
"followupAction": "Please Correct and Resubmit",
"description": "Invalid/Missing Subscriber/Insured ID",
"possibleResolutions": "The subscriber's member ID is either missing or invalid.\n• Check the `subscriber.memberId`.\n• Ensure the member ID doesn't include the [Card Issuer Identifier](https://www.stedi.com/docs/healthcare/eligibility-troubleshooting#card-issuer-identifier-80840).\n• If you can't locate the correct member ID, try running an [insurance discovery check](https://www.stedi.com/docs/healthcare/insurance-discovery) to retrieve the patient's benefits information instead.",
"location": "Loop 2100C",
"field": "AAA"
}
],
"memberId": "1AA2CC3DD45", // Outdated MBI
"firstName": "JANE",
"lastName": "DOE",
...
},
...
}
```
## Recommended retry strategy [#recommended-retry-strategy]
Implementing the right retry strategy for eligibility check failures saves a lot of time and money.
At a minimum, we **strongly recommend** automatically retrying every request that fails due to payer connectivity issues. Automatic retries resolve a significant portion of these types of failures without manual intervention. Visit [Retry strategy](/healthcare/eligibility-troubleshooting#retry-strategy) for details.
## CMS traceability requirements [#cms-traceability-requirements]
All parties involved in HETS eligibility transactions must comply with the [HETS Rules of Behavior](https://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/hetshelp/downloads/eligibilitytransactionsysteminquiriesrulesofbehavior.pdf). Compliance is also required under our terms. Review the Rules of Behavior before sending eligibility checks to CMS.
Starting November 8, 2025, the Centers for Medicare & Medicaid Services (CMS) requires submitters to include the entire chain of network hops for every eligibility request sent to CMS's eligibility system, HETS.
Specifically, requests must include an `X-Forwarded-For` HTTP header containing the network IP addresses from the point of origin through receipt by the HETS system. CMS expects `X-Forwarded-For` to list each IP, comma-separated, starting with the originating system and continuing through every intermediary.
To comply with this requirement:
* You must collect all IP addresses for upstream requests and pass them in the standard `X-Forwarded-For` header when calling Stedi's API. If you are yourself an intermediary – for example, an RCM, EHR, or PMS system – you'll need to coordinate with your providers and any third-party organizations to ensure they include the Network IP details as part of the `X-Forwarded-For` header. This enables CMS to receive a complete list of all IPs, including the original initiator of the request (typically, the provider).
* Stedi records the IP address you use when you call our API, as well as all the IP addresses listed in the `X-Forwarded-For` header. We include these IP addresses in the list submitted to CMS.
You only need to include the `X-Forwarded-For` header in eligibility requests when there are upstream IP addresses.
The following examples illustrate when and how to include the header:
| Scenario | `X-Forwarded-For` required? | Result |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------- |
| A provider (IP `2.2.2.2`) connects directly to Stedi without intermediaries. | No. | CMS ultimately receives `X-Forwarded-For: 2.2.2.2` |
| A provider (IP `2.2.2.2`) routes through an RCM platform's transactional system (IP `3.3.3.3`) that calls Stedi's API using a separate integration backend (IP `4.4.4.4`). | Yes. The RCM platform sets `X-Forwarded-For: 2.2.2.2, 3.3.3.3`. Stedi records the IP address of the API caller (`4.4.4.4` ) and sends it to CMS. | CMS ultimately receives `X-Forwarded-For: 2.2.2.2, 3.3.3.3, 4.4.4.4`. |
| A provider network (IP `2.2.2.2`) passes through an office firewall (IP `4.4.4.4`) and then an RCM platform (IP `3.3.3.3`), which calls Stedi's API. | Yes. The RCM platform sets `X-Forwarded-For: 2.2.2.2, 4.4.4.4`. Stedi records the IP address of the API caller (`3.3.3.3`) and sends it to CMS. | CMS ultimately receives `X-Forwarded-For: 2.2.2.2, 4.4.4.4, 3.3.3.3`. |
### U.S. IP address requirement [#us-ip-address-requirement]
Stedi blocks eligibility requests to CMS when any IP address in the chain – the originating IP address or any in the X-Forwarded-For header – is located outside the United States.
# Model Context Protocol (MCP)
Source: https://www.stedi.com/docs/healthcare/mcp-server
Our Model Context Protocol (MCP) server defines a set of tools that AI agents can use to perform and troubleshoot eligibility checks through Stedi.
When building agents that work with eligibility data, we recommend using our MCP server. It excels at individual eligibility checks, especially when your agent needs to retrieve coverage data in real time. For example:
* A voice agent can use the MCP server to quickly verify benefits in a few seconds instead of calling payers over the phone. It can then place follow-up calls to payers only as needed - for example, to collect additional benefit details.
* A Revenue Cycle Management (RCM) workflow agent can use the MCP server to validate a patient's coverage before scheduling an appointment or submitting a claim.
You can also use the MCP server to perform individual checks with MCP clients. This is useful for testing your integration during development and for enabling operations teams to run ad-hoc checks or troubleshoot issues. Be sure to put measures in place to stay compliant with your organization's data-handling policies, HIPAA, and other applicable requirements.
## Why use the MCP server? [#why-use-the-mcp-server]
Performing eligibility checks successfully requires more than just calling Stedi's APIs. In addition to determining the right payer, you must know the required and recommended properties, know how to interpret errors, and build out a robust retry strategy for various failure cases.
The troubleshooting process can be complex. For example, if your check fails due to a payer connectivity issue, you should retry immediately. If it fails due to a `Subscriber Not Found` error, you must systematically diagnose the issue in order to successfully retrieve benefits information. We have best practices for entering [patient data](/healthcare/send-eligibility-checks#patient-information), [troubleshooting](/healthcare/eligibility-troubleshooting), and [retries](/healthcare/eligibility-troubleshooting#retry-strategy) in our docs - you'd typically need to implement this logic in your product and then maintain it over time.
The MCP server is helpful because it comes with all of this logic built in.
### Features [#features]
The MCP server allows agents to:
* **Find the correct payer:** The MCP server has a tool for searching Stedi's payer database. This allows agents to access information like payer IDs and supported transaction types as needed when answering questions or running eligibility checks.
* **Run eligibility checks:** The MCP server has a tool for constructing and submitting eligibility requests using available patient and provider data. If the first attempt fails, the server provides instructions about how to adjust inputs, retry, and move forward.
* **Troubleshoot rejection codes:** The MCP server provides instructions on what to do in these scenarios - for example, remove the member ID, adjust the name, or try alternate, related payer IDs. These are the same tactics our support team uses internally to resolve issues.
In essence, the MCP server allows you to tell your agent to "run an eligibility check" at the appropriate times during its workflow. You can focus on building your agent's core functionality, while the MCP server handles the complexities of eligibility checks.
### Limitations [#limitations]
The MCP server is designed for an agent that is performing and troubleshooting a single eligibility check. It's not intended for bulk eligibility checks, or for interpreting the benefits in an eligibility response.
* For bulk eligibility checks, use Batch Eligibility Check API directly. Visit [batch refresh checks](/healthcare/batch-refresh-eligibility-checks) for details.
* To interpret the eligibility response, you'll need to layer your own logic on top of the MCP server. For example, you'll need custom logic for tasks like determining whether a patient has active coverage for a particular service or retrieving the patient's copay. Visit [determine patient benefits](/healthcare/eligibility-active-coverage-benefits) for complete details.
### Data security and compliance [#data-security-and-compliance]
The MCP server uses TLS encryption for all connections. You can authenticate to the MCP server using one of the following methods:
* API key authentication (standard Stedi production key)
* OAuth 2.x authentication (OAuth required for Claude integrations)
If you're using our MCP server with 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.
## How the MCP server works [#how-the-mcp-server-works]
Your AI agent connects to the server using an MCP client. Once connected, the server gives your agent access to the available [tools](#tools) and [prompts](#prompts) for running eligibility checks.
The MCP server adds minimal overhead - you'll get the same fast response times from our APIs with added intelligence for your agents.
### Tools [#tools]
Tools interact with Stedi's APIs to perform tasks. The MCP server provides the following tools for your agent to use:
{/* prettier-ignore-start */}
| Tool Name | Description |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `search_for_payer` | Calls the [Search Payers](/healthcare/api-reference/get-search-payers) endpoint to find a Stedi payer based on a provided payer ID or name. It even works with partial names or typos. For example, `cig` finds Cigna. |
| `eligibility_check` | Runs an eligibility check using the [Real-Time Eligibility Check JSON](/healthcare/api-reference/post-healthcare-eligibility) endpoint. The JSON format provides the most reliable results for AI agents. |
{/* prettier-ignore-end */}
### Prompts [#prompts]
The MCP server includes prompts to help your agent recover from common eligibility errors. They 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.
Many LLM clients don't automatically read prompt definitions. You must
explicitly instruct them to “read the prompts” or use a client-specific
command. Otherwise, the model may never access prompt content.
## Install the MCP server [#install-the-mcp-server]
The eligibility MCP server is a Streamable HTTP MCP server. We support two authentication methods:
* **API key authentication** (standard usage)
* **OAuth 2.x authentication** (required for Claude integrations)
### API Key Authentication [#api-key-authentication]
Endpoint:
```
https://mcp.us.stedi.com/2025-07-11/mcp
```
To connect your agent:
* Create a [production API key](/healthcare/api-reference#api-key-types) for authentication.
* Add the following configuration to your agent's MCP client:
```json
{
"mcpServers": {
"stedi-healthcare": {
"type": "http",
"url": "https://mcp.us.stedi.com/2025-07-11/mcp",
"headers": {
"Authorization": "STEDI_PROD_API_KEY"
}
}
}
}
```
### OAuth Authentication [#oauth-authentication]
We recommend using API key authentication when possible for simplicity. If you need to use OAuth authentication, contact Stedi support, and we'll enable it for your account.
Endpoint:
```
https://mcp.us.stedi.com/mcp2
```
This flow doesn't require an API key in the MCP configuration. To connect your agent, add the following configuration to your agent's MCP client:
```json
{
"mcpServers": {
"healthcare-mcp": {
"type": "http",
"url": "https://mcp.us.stedi.com/mcp2"
}
}
}
```
#### Claude Code [#claude-code]
OAuth authentication is required when adding Stedi's MCP server to Claude Code. Run this command to install the MCP server:
```bash
claude mcp add --transport http stedi-eligibility-mcp https://mcp.us.stedi.com/mcp2
```
To use the MCP server:
1. Run `/mcp` inside Claude Code.
2. Begin the authentication process for `stedi-eligibility-mcp`. A browser window opens where you can sign in to your Stedi account.
3. Sign in using your Stedi account credentials.
OAuth completes and the MCP server becomes available for you to use.
## Example use [#example-use]
Here are some examples of how you might use the MCP server in different scenarios.
### Search for a payer [#search-for-a-payer]
You can instruct your agent to retrieve the correct payer ID before running an eligibility check.
**Example prompt**
> Determine the correct payer ID for Cigna and confirm whether eligibility checks are supported.
**What happens**
The MCP server:
* Invokes the `search_for_payer` tool.
* Matches "Cigna".
* Returns the correct payer ID and supported transaction types.
* Confirms whether eligibility (270/271) transactions are supported.
### Run an eligibility check [#run-an-eligibility-check]
You can instruct your agent to use the MCP server to check patient eligibility before scheduling appointments.
**Example prompt**
> Run an eligibility check for this patient before scheduling their appointment.
**What happens**
The MCP server:
* Invokes the `eligibility_check` tool.
* Constructs a properly formatted JSON eligibility request using available patient and provider data.
* Submits the request to the payer in real time.
* Returns structured eligibility response data.
* Provides retry guidance if the request fails due to a recoverable issue.
### Recover from failures [#recover-from-failures]
The MCP server can help your agent recover from common errors when running eligibility checks.
**Example prompt**
> Read the prompts from Stedi's MCP server. Then use Stedi's MCP server to troubleshoot and retry the eligibility check for patients with "Subscriber Not Found" errors.
**What happens**
The MCP server:
* Analyzes the rejection reason.
* Provides structured retry guidance based on best practices for that error type. For example, if the error is `Subscriber Not Found`, the MCP server may recommend removing the member ID or adjusting the name details.
* After the agent updates the request, the MCP server re-runs the eligibility check and returns the updated results.
## MCP server vs. Stedi Agent [#mcp-server-vs-stedi-agent]
The Stedi Agent and the Model Context Protocol (MCP) server can both help you resolve failed eligibility checks and find payer information, but they serve different use cases.
* The [Stedi Agent](/healthcare/stedi-agent) is a Stedi-controlled, AI assistant within the Stedi portal. It's ready to use whenever you need it. Unlike the MCP server, you can't manage or invoke the Stedi Agent programmatically - you can only use it within the Stedi portal. The Stedi Agent is built on top of the MCP server, meaning it uses the MCP server's exposed tools to perform actions.
* The [MCP Server](/healthcare/mcp-server) provides a set of tools, which are a wrapper around Stedi's APIs, that AI agents can use to find payer information and perform and troubleshoot eligibility checks. The MCP server includes the same retry logic (in a prompt) that the Stedi Agent uses to automatically resolve eligibility check failures.
You can use the MCP server to build your own AI agents tailored to your use case. Unlike the Stedi Agent, you'll need to install and configure the MCP server for your preferred AI agent.
## Pricing [#pricing]
The MCP server is available on all [paid Stedi plans](https://www.stedi.com/pricing). There is no charge for using the MCP server itself - you'll only be charged for related API requests.
Note that for eligibility checks, there's no charge for non-billable requests, such as those that return errors indicating that the payer is down. Visit [billing for eligibility checks](/healthcare/intro-eligibility-checks#billing-for-eligibility-checks) for details.
We encourage you to contact us with questions, feedback, or for help using our products.
## Contact us [#contact-us]
We make every effort to respond as soon as possible, particularly to urgent requests. For both general support requests and billing inquiries, you can contact us through the following methods:
* [Website](https://www.stedi.com/contact) for all request types
* Email [support@stedi.com](mailto:support@stedi.com) for support requests, billing questions, and/or set up a dedicated Slack or Teams channel
When you report an issue, please include the following:
* A description of the issue, including the current behavior and the expected behavior
* Your Stedi account ID, if you submit through our website
* Screenshots showing the problem, when possible
## Privacy Policy [#privacy-policy]
Refer to our [Privacy Notice](https://legal.stedi.com/legal/privacy-notice-b91ef9d6) for details on how we handle your data.
# National Provider Identifier (NPI)
Source: https://www.stedi.com/docs/healthcare/national-provider-identifier
Learn what a National Provider Identifier (NPI) is, the two NPI types – and how to find, validate, or apply for an NPI.
The National Provider Identifier (NPI) is a unique identification number assigned to healthcare providers. It’s used to identify providers in healthcare transactions, like billing, referrals, and insurance claims, and it's required when processing administrative and financial transactions adopted under HIPAA (the Health Insurance Portability and Accountability Act).
If a provider has an NPI, it's required when completing [transaction enrollment](/healthcare/transaction-enrollment) and when sending any healthcare transaction through Stedi, including eligibility checks and claims. In certain rare circumstances, payers may allow providers who don't have an NPI to submit transactions using another identifier, such as their Social Security Number (SSN) instead. Providers who don't have an NPI are typically non-medical providers, such as social workers, home health aides, or transportation services.
In practice, alternative identifiers to the NPI are almost never supported, and using alternative identifiers typically requires a special agreement with the payer. We don't recommend attempting to send an alternative identifier in any transaction unless the payer has explicitly instructed you to do so.
## NPI types [#npi-types]
There are two types of NPIs:
* **Type 1 - Individual:** This type of NPI is for individual healthcare providers, such as doctors, dentists, nurse practitioners, physical therapists, and chiropractors. Note that providers who run their own practice likely still need to obtain an individual NPI to use when billing services under their own name.
* **Type 2 - Organization:** This type of NPI is for healthcare organizations or group practices, such as hospitals, clinics, labs, nursing homes, and home health agencies. This type of NPI is used when billing services under the organization’s name, not an individual person. Unlike individual NPIs, a single organization can have multiple organization NPIs for different locations, divisions, or services.
## Find a provider's NPI [#find-a-providers-npi]
You can use the [NPPES NPI Registry](https://npiregistry.cms.hhs.gov/search) to look up a provider's NPI. The registry allows you to search for NPIs by name, organization, or NPI number. You can also verify the status of an NPI and view the provider's information, including their taxonomy codes and practice locations.
## Find a provider by NPI [#find-a-provider-by-npi]
You can use Stedi's [NPI Registry](https://www.stedi.com/npi-registry) to look up a provider's information using their NPI. The registry provides access to over 9.3 million records, and search results include the provider's name, practice address, phone number, specialty, taxonomy codes, and credential information.
## Generate a dummy NPI [#generate-a-dummy-npi]
You can generate a dummy NPI for test transactions using this [free online tool](https://jsfiddle.net/alexdresko/cLNB6). Note that these dummy NPIs aren't valid for production transactions.
## Apply for an NPI [#apply-for-an-npi]
You can obtain an NPI from the [National Plan and Provider Enumeration System (NPPES)](https://nppes.cms.hhs.gov/webhelp/nppeshelp/NPPES%20FAQS.html#how-do-i-apply-for-an-npi). The process includes the following steps:
You'll be required to provide the following in your application:
* Personal information, such as your name, address, and phone number
* Type of provider (individual or organization)
* Provider specialty (taxonomy code)
* Practice location and contact information
* Other information, such as your state license number and the name of your state licensing board
Most online applications are processed within 10 business days; paper applications may take longer. Once approved, you'll receive your 10-digit NPI number through email or mail, depending on how you applied.
## NPI format and validation [#npi-format-and-validation]
The NPI is a 10-position, intelligence-free numeric identifier (10-digit number). This means that the numbers do not carry other information about healthcare providers, such as the state in which they live or their medical specialty.
The NPI format consists of 9 numeric digits followed by one numeric check digit. The check digit is calculated using the Luhn formula. When you submit a transaction such as an eligibility check or claim to Stedi, we validate the NPI before submitting it to the upstream payer. At a minimum, we validate that the submitted number passes check digit validation. For example, NPIs in test eligibility checks submitted with a test API key must pass check digit validation. In certain cases, we also validate that the NPI exists in the NPPES database.
### Calculate the check digit manually [#calculate-the-check-digit-manually]
Assume the 9-position identifier part of the NPI is 123456789. Using the Luhn formula on the identifier portion, you would calculate the check digit as follows:
1. Double the value of alternate digits, beginning with the rightmost digit:
2 6 10 14 18
2. Add a constant 24 (to account for the 80840 prefix that would be present on a card issuer identifier), plus the individual digits of the products of doubling, plus unaffected digits:
24 + 2 + 2 + 6 + 4 + 1 + 0 + 6 + 1 + 4 + 8 + 1 + 8 = 67
3. Subtract the sum from the next higher number ending in zero:
70 - 67 = 3
The check digit is 3. So, the final NPI with check digit is 1234567893.
# Get, correlate, and interpret 277CAs and ERAs
Source: https://www.stedi.com/docs/healthcare/receive-claim-responses
After you submit a professional, dental, or institutional claim, you may receive asynchronous [277CA claim acknowledgment](/healthcare/claim-responses-overview#277ca-claim-acknowledgment) and [835 Electronic Remittance Advice (ERA)](/healthcare/claim-responses-overview#835-electronic-remittance-advice-era) responses.
If you submitted the claims through the API or UI, there are two steps to retrieve claim responses from Stedi:
1. Discover responses by polling for processed transactions or listening for event-driven webhooks.
2. Call Stedi APIs to retrieve processed responses from Stedi.
Once you have the responses, you can correlate them with the original claim and specific service lines.
If you're using a [Stedi SFTP connection](/healthcare/submit-claims-sftp-connection), you don't need to poll or call Stedi APIs to retrieve responses. Instead, you can download them from the `from-stedi` directory.
## Generate test responses [#generate-test-responses]
You can send test claims that generate test 277CA and 835 ERA responses. This approach helps you validate your integration and ensure your claims workflow is working smoothly from end to end. Visit [Test claims workflow](/healthcare/test-claims-workflow) for instructions.
## 277CAs in API responses [#277cas-in-api-responses]
Our claim submission APIs return an initial 277CA in the `x12` property of the response body that indicates whether the claim has passed Stedi's claim edits. This 277CA is in X12 EDI format.
When the claim fails one or more edits, the 277CA contains information about each error. These are the same error codes that appear in the `errors` array.
Note that this initial 277CA only indicates whether Stedi has accepted or rejected the claim submission. You may receive additional 277CA acceptances or rejections as the claim is routed to the payer. You'll need to monitor for and retrieve those additional 277CAs through webhooks or polling.
```json
{
"status": "SUCCESS",
"controlNumber": "1",
"tradingPartnerServiceId": "6400",
"claimReference": {
"correlationId": "01KHC8Y4HNP0GVQ5NSVTPZBC0F",
"patientControlNumber": "111222333",
"timeOfResponse": "2026-02-13T19:51:51.496Z",
"payerId": "6400",
"formatVersion": "5010",
"rhclaimNumber": "01KHC8Y4HNP0GVQ5NSVTPZBC0F",
"serviceLines": [
{
"lineItemControlNumber": "111222333"
}
]
},
"meta": {
"traceId": "d61ca4bc-e9e7-4d0f-93d0-6f7ff810b0e6"
},
"payer": {
"payerName": "Cigna",
"payerId": "6400"
},
"x12": "ISA*00* *00* *ZZ*STEDITEST *ZZ*574183004559 *260213*1951*^*00501*980180479*0*T*`~GS*HN*STEDITEST*574183004559*20260213*195151*1*X*005010X214~ST*277*0001*005010X214~BHT*0085*08*01KHC8YJE8EY6A5HFR00Z5H305*20260213*195151*TH~HL*1**20*1~NM1*AY*2*STEDI INC*****46*117151744~TRN*1*01KHC8YJE8EY6A5HFR00Z5H305~DTP*050*D8*20260213~DTP*009*D8*20260213~HL*2*1*21*1~NM1*41*2*Test Data Health Services, Inc.*****46*123456~TRN*2*01KHC8Y4HNP0GVQ5NSVTPZBC0F~STC*A0`17`AY*20260213*WQ*109.2~QTY*90*1~AMT*YU*109.2~HL*3*2*19*1~NM1*85*2*Therapy Associates*****XX*1234567890~TRN*1*0~REF*TJ*123456789~QTY*QA*1~AMT*YU*109.2~HL*4*3*PT*0~NM1*QC*1*Anon*John****MI*U7777788888~TRN*2*111222333~STC*A1`20*20260213*WQ*109.2~DTP*472*RD8*20240101-20240101~SE*25*0001~GE*1*1~IEA*1*980180479~",
"httpStatusCode": "200 OK"
}
```
## Discover processed responses [#discover-processed-responses]
When submitting claims through Stedi's APIs or UI, you can discover processed responses programmatically by either listening for webhooks or polling for transactions. All claim responses are also available in the Stedi portal.
### Listen for webhooks [#listen-for-webhooks]
Instead of polling for transactions, you can set up [webhooks](/healthcare/configure-webhooks) that automatically send events for processed 277CAs and 835 ERAs to your endpoint. You can either create a single webhook for all inbound transactions or create a separate webhook for each transaction type.
These webhooks are triggered by the processing events Stedi emits after it successfully receives and processes a response from the payer or intermediary clearinghouse.
processed 277CA
processed 835 ERA
```json
{
"event": {
"version": "0",
"id": "f972fb53-653a-1747-ce30-bed15fc04f5c",
"detail-type": "transaction.processed.v2",
"source": "stedi.core",
"account": "",
"time": "2024-07-18T16:21:24Z",
"region": "us-east-1",
"resources": [
"https://core.us.stedi.com/2023-08-01/transactions/f0d3f790-0bc9-432b-93kd-e4b7ece67946"
],
"detail": {
"transactionId": "f0d4f780-0ec9-432b-93gd-e4b7ece93946",
"direction": "INBOUND",
"mode": "test",
"fileExecutionId": "9f76b485-6hca-43bf-917e-d5b54bec6234",
"processedAt": "2024-07-18T16:21:24.658Z",
"fragments": null,
"artifacts": [
{
"artifactType": "application/edi-x12",
"usage": "input",
"url": "https://core.us.stedi.com/2023-08-01/transactions/f0d9f790-0ec9-431b-93fd-e4h7ece63946/input",
"sizeBytes": 1313,
"model": "transaction"
},
{
"artifactType": "application/json",
"usage": "output",
"url": "https://core.us.stedi.com/2023-08-01/transactions/f0d3f740-0ec9-432b-98fd-e4b7ece63946/output",
"sizeBytes": 5602,
"model": "transaction"
}
],
"partnership": {
"partnershipId": "local-clearinghouse-test",
"partnershipType": "x12",
"sender": {
"profileId": "clearinghouse-test"
},
"receiver": {
"profileId": "local"
}
},
"x12": {
"transactionSetting": {
"guideId": "01J1M50C1Q44KYDZY8V7R1TPBW",
"transactionSettingId": "01J1M50P9623BFE0FFT5Q2BR49"
},
"metadata": {
"interchange": {
"acknowledgmentRequestedCode": "0",
"controlNumber": 11
},
"functionalGroup": {
"controlNumber": 11,
"release": "005010X214",
"date": "2024-07-18",
"time": "16:20:47",
"functionalIdentifierCode": "HN"
},
"transaction": {
"controlNumber": "1001",
"transactionSetIdentifier": "277"
},
"receiver": {
"applicationCode": "001690149382",
"isa": {
"qualifier": "ZZ",
"id": "001690149382"
}
},
"sender": {
"applicationCode": "STEDITEST",
"isa": {
"qualifier": "ZZ",
"id": "STEDITEST"
}
}
}
},
"connectionId": "01J1M5124B2HWMNN91Q3Z6AM61"
}
}
}
```
```json
{
"event": {
"version": "0",
"id": "5d1bcb90-cb0b-1844-5b93-86d5e5b9c4a8",
"detail-type": "transaction.processed.v2",
"source": "stedi.core",
"account": "",
"time": "2025-07-14T20:43:39Z",
"region": "us-east-1",
"resources": [
"https://core.us.stedi.com/2023-08-01/transactions/95e7786c-7066-4494-b83a-b1f300624902"
],
"detail": {
"transactionId": "95e7786c-7066-4494-b83a-b1f300624902",
"direction": "INBOUND",
"mode": "test",
"fileExecutionId": "5d30f0a0-63af-4aeb-b96c-353b4b25c99a",
"processedAt": "2025-07-14T20:43:39.808Z",
"fragments": null,
"artifacts": [
{
"artifactType": "application/edi-x12",
"usage": "input",
"url": "https://core.us.stedi.com/2023-08-01/transactions/95e7786c-7066-4494-b83a-b1f300624902/input",
"sizeBytes": 2016,
"model": "transaction"
},
{
"artifactType": "application/json",
"usage": "output",
"url": "https://core.us.stedi.com/2023-08-01/transactions/95e7786c-7066-4494-b83a-b1f300624902/output",
"sizeBytes": 13864,
"model": "transaction"
}
],
"partnership": {
"partnershipId": "local-clearinghouse-test",
"partnershipType": "x12",
"sender": {
"profileId": "clearinghouse-test"
},
"receiver": {
"profileId": "local"
}
},
"x12": {
"transactionSetting": {
"guideId": "01J8JH1SGTB2FYKN2PG4MH84RP",
"transactionSettingId": "01J8JH23VA3G2X8GENVVE6XZB9"
},
"metadata": {
"interchange": {
"acknowledgmentRequestedCode": "0",
"controlNumber": 1
},
"functionalGroup": {
"controlNumber": 1,
"release": "005010X221A1",
"date": "2025-07-14",
"time": "20:43:21",
"functionalIdentifierCode": "HP"
},
"transaction": {
"controlNumber": "0001",
"transactionSetIdentifier": "835"
},
"receiver": {
"applicationCode": "599264680681",
"isa": {
"qualifier": "ZZ",
"id": "599264680681"
}
},
"sender": {
"applicationCode": "STEDITEST",
"isa": {
"qualifier": "ZZ",
"id": "STEDITEST"
}
}
}
},
"connectionId": "01JE9257XJ4G4YFMXCHJPFR434"
}
}
}
```
As these events are emitted, you can:
* Determine the transaction type from the `x12.transactionSetIdentifier` property: `277` (277CA) or `835` (ERA).
* Use either the `transactionId` to retrieve the transaction in JSON format or the `fileExecutionId` to retrieve the transaction in X12 EDI format. Visit [Retrieve responses from Stedi](#retrieve-responses-from-stedi) for more information.
If your webhook doesn't respond within 5 seconds, Stedi marks that as a
failure and then automatically retries up to 5 times. This can result in
duplicate deliveries, so we strongly recommend implementing ways to manage
duplicates delivered through webhooks.
### Poll for transactions [#poll-for-transactions]
Call the [Poll Transactions](/healthcare/api-reference/get-poll-transactions) endpoint to return a list of transactions in your Stedi account.
You must include the following information in the request:
* Your Stedi API key as the `Authorization` header.
* Either the `startDateTime` or `pageToken` query parameters. To retrieve a list of transactions after a specific date, use `startDateTime`. To retrieve the next page of transactions, use `pageToken` (you can find this value in the `nextPageToken` field in the response).
The following example shows an API call to retrieve transactions after a specific date:
```bash
curl --request GET -L \
--url https://core.us.stedi.com/2023-08-01/polling/transactions?startDateTime=2023-08-28T00:00:00Z \
--header "Authorization: ${STEDI_API_KEY}"
```
**Filter for 277CA and 835 ERA transactions**
The response includes all transactions that have been sent or received, including all 837 claims you have submitted and all 277CA and 835 ERA responses you have received from payers. You must filter for transactions that match the following criteria:
* `direction`: `INBOUND` - This indicates that the transaction came from the payer or intermediary clearinghouse.
* `x12.transactionSetIdentifier`: `277` or `835`
The following example shows a response containing a processed 277CA transaction:
```json
{
"items": [
{
"direction": "INBOUND",
"mode": "production",
"fileExecutionId": "f75168e4-e682-4410-bfec-b5b1541c7f21",
"transactionId": "a15b68ca-fae0-42de-b8a3-f436668b8604",
"processedAt": "2023-08-28T09:00:28.354Z",
"artifacts": [
{
"artifactType": "application/edi-x12",
"sizeBytes": 490,
"usage": "input",
"url": "https://core.us.stedi.com/2023-08-01/transactions/a15b68ca-fae0-42de-b8a3-f436668b8604/input"
},
{
"artifactType": "application/json",
"sizeBytes": 51,
"usage": "output",
"url": "https://core.us.stedi.com/2023-08-01/transactions/a15b68ca-fae0-42de-b8a3-f436668b8604/output"
}
],
"partnership": {
"partnershipId": "customer_availity",
"partnershipType": "x12",
"sender": {
"profileId": "availity_sender"
},
"receiver": {
"profileId": "availity_receiver"
}
},
"x12": {
"metadata": {
"interchange": {
"acknowledgmentRequestedCode": "0",
"controlNumber": 2
},
"functionalGroup": {
"controlNumber": 2,
"release": "008010",
"date": "2023-08-28",
"time": "09:00:20",
"functionalIdentifierCode": "HN"
},
"transaction": {
"controlNumber": "1",
"transactionSetIdentifier": "277"
},
"receiver": {
"applicationCode": "AV01101957",
"isa": {
"qualifier": "ZZ",
"id": "AV01101957"
}
},
"sender": {
"applicationCode": "030240928",
"isa": {
"qualifier": "01",
"id": "030240928"
}
}
},
"transactionSetting": {
"guideId": "01H8PSWG4ZD6QPKC9VSD42PQX3",
"transactionSettingId": "01H8PSWG4ZD6QPKC9VSD42PQX3"
}
}
}
],
"nextPageToken": "945ff6de213d3ef481d028065d4c12fb996a166a3a90ef98564318decfae50ce4b36d74b7e9d9bafa6e1d169"
}
```
For each matching transaction, extract the `x12.transactionSetIdentifier` type and either the `transactionId` or the `fileExecutionId` to use when mapping the data. You'll use the `transactionId` to retrieve the transaction in JSON format or the `fileExecutionId` to retrieve the transaction in X12 EDI format. Visit [Retrieve responses from Stedi](#retrieve-responses-from-stedi) for more information.
Stedi does not allow you to delete transactions, so make sure you track which
transaction and/or file execution IDs you've already processed.
### Stedi portal [#stedi-portal]
You can review claim responses in the Stedi portal through the claims view or the transactions view (classic).
#### Claims view [#claims-view]
You can review 277CAs from the [claims view](https://portal.stedi.com/app/healthcare/claims).
1. Click a claim to view a timeline of its processing activity.
2. Click an **Acknowledgment** (277CA) to review its details page.
Stedi displays key information about the 277CA, including the billing provider's information and status codes.
#### Transactions view [#transactions-view]
You can review both 277CAs and 835 ERAs from the [transactions view](https://portal.stedi.com/app/healthcare/transactions). Click any transaction to view its details.
You can also access responses through the **Related transactions** tab of the original claim submission.
1. Go to the [transactions view](https://portal.stedi.com/app/healthcare/transactions).
2. Click the claim to review its details.
3. Click **Related transactions** to go to a list of related transactions, including 277CA and 835 ERA responses.
## Retrieve responses from Stedi [#retrieve-responses-from-stedi]
You can retrieve the 277CA and 835 ERA responses from Stedi in either JSON format or X12 EDI format.
### JSON format [#json-format]
Follow these steps to retrieve responses in JSON format:
1. Either [set up webhooks](/healthcare/receive-claim-responses#listen-for-webhooks) to listen for transaction processed events or [poll for transactions](/healthcare/receive-claim-responses#poll-for-transactions). This step allows you to discover when a new 277CA or 835 ERA is ready for retrieval.
2. Retrieve the transaction ID from the configured webhook or the Poll Transactions response. This value is available in the `transactionId` property.
3. Call the following endpoints to retrieve 277CA and 835 ERA responses from Stedi. In each request, you must include your Stedi API key in the `Authorization` header and the `transactionId` query parameter containing the ID of the transaction you want to retrieve.
* [Get 277CA Report](/healthcare/api-reference/get-healthcare-reports-277): Retrieve 277CA responses
* [Get 835 ERA Report](/healthcare/api-reference/get-healthcare-reports-835): Retrieve 835 ERA responses
### X12 EDI format [#x12-edi-format]
Follow these steps to retrieve the responses in X12 EDI format:
1. Either [set up webhooks](/healthcare/receive-claim-responses#listen-for-webhooks) to listen for transaction processed events or [poll for transactions](/healthcare/receive-claim-responses#poll-for-transactions). This step allows you to discover when a new 277CA or 835 ERA is ready for retrieval.
2. Retrieve the file execution ID from the configured webhook or the Poll Transactions response. This value is available in the `fileExecutionId` property.
3. Call the [Retrieve File Execution Input](/healthcare/api-reference/get-execution-input) endpoint to retrieve the 277CA or 835 ERA in X12 EDI format. In the request, you must include your Stedi API key in the `Authorization` header and the `executionId` query parameter containing the file execution ID for the response you want to retrieve. You can find this value on the file's details page in the Stedi portal.
### 835 ERA PDF [#835-era-pdf]
Stedi autogenerates a PDF version of each processed 835 ERA. To download the PDF from the Stedi portal:
1. Go to the [transactions view](https://portal.stedi.com/app/healthcare/transactions).
2. Click the 835 ERA transaction you want to download.
3. On the **Overview** tab, click **Download 835 ERA PDF**.
You can also retrieve the PDF programmatically by calling the [835 ERA PDF](/healthcare/api-reference/get-era-pdf) endpoint.
The PDF contains a human-readable version of the ERA, including payment details, adjustments, and explanations for each service line. It resembles the Standard Paper Remittance (SPR) format that the Centers for Medicare and Medicaid Services (CMS) uses for ERA PDFs, regardless of which payer sent the ERA.
This is a PDF representation of the 835 ERA - it's not the same as an Explanation of Benefits (EOB) that you may receive from the payer.
* **EOB:** A statement from a payer explaining how a medical claim was processed, including what was covered, denied, and the remaining patient responsibility. The patient receives an EOB after a claim has been adjudicated.
* **EOP:** A version of the EOB for the provider. It contains more information related to how the payer has adjudicated the claim. The provider receives the EOP after claim adjudication and payment are sent.
* **ERA:** An electronic file that details payment and claim adjustment information. The provider receives the ERA after the payer has adjudicated the claim and issued payment, typically at the same time the funds are deposited electronically.
## Determine 277CA sender [#determine-277ca-sender]
To determine whether a 277CA is from a clearinghouse or the payer:
* **JSON:** Check the [`transactions[].payers` array](https://www.stedi.com/docs/healthcare/api-reference/get-healthcare-reports-277#response.transactions.payers) in the report (`Loop 2100A`). The `organizationName` property contains the name of the sender (for example, CIGNA or STEDI).
* **X12 EDI:** Check `Loop 2100A NM103` (Information Source Name).
You can also find this information in the Stedi portal:
1. Go to the [claims view](https://portal.stedi.com/app/healthcare/claims).
2. Find the associated claim and click it to view the claim timeline.
3. Find the 277CA in the timeline view. The **From** field indicates whether the acknowledgment is from Stedi or the payer.
## Correlate 277CA [#correlate-277ca]
Use the following properties to correlate the 277CA with the original claim.
### Entire Claim [#entire-claim]
**Option 1: Patient Control Number**
You can use the claim's `claimInformation.patientControlNumber`, if you provided one in the claim submission.
It's returned in two locations in the 277CA's `transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].patientClaimStatusDetails.claims[].claimStatus` object:
* `patientAccountNumber`
* `referencedTransactionTraceNumber`
You can use either of these properties to correlate the 277CA with the original claim, but we recommend using the `referencedTransactionTraceNumber`. When matching transactions, treat the patient control number as case-insensitive, even if the submitted value included both lower and uppercase characters.
Some payers batch acknowledgments for multiple claims into a single 277CA. In these cases, the 277CA will contain multiple `patientClaimStatusDetails` objects, each with its own `referencedTransactionTraceNumber`.
**Option 2: Stedi's Correlation ID**
If you didn't supply a patient control number, you can use the tracking number Stedi assigns to the claim when it's submitted. It's returned as the `claimReference.correlationId` property in the claim submission response.
In the 277CA, it's returned in the `transactions[].payers[].claimStatusTransactions[].claimTransactionBatchNumber` property.
### Service line [#service-line]
Different claim types use different names for the same identifier:
* For professional and dental claims, use `claimInformation.serviceLines.providerControlNumber`.
* For institutional claims, use `claimInformation.serviceLines.lineItemControlNumber`.
This identifier is **sometimes** returned as the `transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].patientClaimStatusDetails.claims[].serviceLines[].lineItemControlNumber` in the 277CA. It's not always present because a 277CA only contains a `serviceLines` object when the claim was rejected because of issues with the information provided for the service line. If the `lineItemControlNumber` isn't present, you can only correlate the 277CA at the claim level.
The following example shows a `serviceLines` object for a rejected claim containing the `lineItemControlNumber` property.
{/* schema:ClaimAcknowledgmentServiceLines:unwrapArray */}
```json
"serviceLines": [
{
"beginServiceLineDate": "20250101",
"lineItemControlNumber": "ABCD1234",
"service": {
"chargeAmount": "379.39",
"procedureCode": "97153",
"serviceIdQualifierCode": "HC",
"serviceIdQualifierCodeValue": "Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes",
"submittedUnits": "11"
},
"serviceClaimStatuses": [
{
"serviceStatuses": [
{
"entityIdentifierCode": "IL",
"entityIdentifierCodeValue": "Insured or Subscriber",
"healthCareClaimStatusCategoryCode": "A3",
"healthCareClaimStatusCategoryCodeValue": "Acknowledgement/Returned as unprocessable claim - The claim/encounter has been rejected and has not been entered into the adjudication system.",
"statusCode": "164",
"statusCodeValue": "Entity's contract/member number."
}
]
}
]
}
]
```
## Interpret 277CA claim status [#interpret-277ca-claim-status]
The 277CA response helps you understand whether a claim was accepted or rejected. These statuses don't indicate whether the claim was or will be approved or denied, only whether it was accepted or rejected for processing.
### Status overview [#status-overview]
For a high-level overview of the claim's acceptance/rejection status, examine the following array:
[`transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].serviceProviderClaimStatuses`](/healthcare/api-reference/get-healthcare-reports-277#response.transactions.payers.claimStatusTransactions.claimStatusDetails.serviceProviderClaimStatuses).
This array typically only includes basic status information like "accepted for processing" or "denied". It's helpful for quickly determining the overall status of the claim. The following example shows a `providerClaimStatuses` object indicating that the claim was accepted for processing.
```json
"providerClaimStatuses": [
{
"providerStatuses": [
{
"healthCareClaimStatusCategoryCode": "A1",
"healthCareClaimStatusCategoryCodeValue": "Acknowledgement/Receipt - The claim/encounter has been received. This does not mean that the claim has been accepted for adjudication.",
"statusCode": "20",
"statusCodeValue": "Accepted for processing."
}
],
"statusInformationEffectiveDate": "20240702"
}
]
```
### Status details [#status-details]
For more detailed acceptance and rejection information for the entire claim, examine the following array:
[`transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].patientClaimStatusDetails[].claims[].claimStatus`](/healthcare/api-reference/get-healthcare-reports-277#response.transactions.payers.claimStatusTransactions.claimStatusDetails.patientClaimStatusDetails.claims.claimStatus).
This array contains more detailed information about acceptance or rejection, including:
* Payer-specific rejection reasons
* Claim charge amount details
* The `patientControlNumber` from the claim (returned as `patientAccountNumber`)
The following example shows a `claimStatus` object indicating that the claim was rejected as unprocessable due to missing or invalid information.
```json
"claimStatus": {
"claimServiceBeginDate": "20250101",
"claimServiceEndDate": "20250109",
"clearinghouseTraceNumber": "NA",
"informationClaimStatuses": [
{
"informationStatuses": [
{
"healthCareClaimStatusCategoryCode": "A3",
"healthCareClaimStatusCategoryCodeValue": "Acknowledgement/Returned as unprocessable claim - The claim/encounter has been rejected and has not been entered into the adjudication system.",
"statusCode": "21",
"statusCodeValue": "Missing or invalid information."
}
],
"statusInformationEffectiveDate": "20250201",
"totalClaimChargeAmount": "3459.3"
}
],
"patientAccountNumber": "AAA11111",
"referencedTransactionTraceNumber": "AAA11111"
}
```
Not all payers send detailed accepted and rejection data for individual service lines. When available, this information will be in the following array:
[`transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].patientClaimStatusDetails[].claims[].serviceLines[].serviceClaimStatuses`](/healthcare/api-reference/get-healthcare-reports-277#response.transactions.payers.claimStatusTransactions.claimStatusDetails.patientClaimStatusDetails.claims.serviceLines.serviceClaimStatuses).
This can help you better identify the errors that caused the rejection. The following example shows a `serviceClaimStatuses` object from the same claim indicating that the service line was rejected as unprocessable and highlights the subscriber's member ID. Combined with the previous example, this indicates that the claim was rejected due to a missing or invalid member ID.
```json
"serviceClaimStatuses": [
{
"serviceStatuses": [
{
"entityIdentifierCode": "IL",
"entityIdentifierCodeValue": "Insured or Subscriber",
"healthCareClaimStatusCategoryCode": "A3",
"healthCareClaimStatusCategoryCodeValue": "Acknowledgement/Returned as unprocessable claim - The claim/encounter has been rejected and has not been entered into the adjudication system.",
"statusCode": "164",
"statusCodeValue": "Entity's contract/member number."
}
]
}
]
```
## Correlate 835 ERA [#correlate-835-era]
Use the following properties to correlate the 835 ERA with the original claim.
Sometimes, payers send [duplicate ERAs](#duplicate-eras) for the same claim.
You should have logic in place to identify and manage these duplicates.
### Entire claim [#entire-claim-1]
Use the claim's `claimInformation.patientControlNumber`. It's returned as the `transactions[].detailInfo[].paymentInfo[].claimPaymentInfo.patientControlNumber` in the 835 ERA.
When matching transactions, treat the patient control number as case-insensitive, even if the submitted value included both lower and uppercase characters.
### Service line [#service-line-1]
Different claim types use different names for the same identifier:
* For professional and dental claims, use `claimInformation.serviceLines[].providerControlNumber`.
* For institutional claims, use `claimInformation.serviceLines[].lineItemControlNumber`.
This identifier is always returned as the `transactions[].detailInfo[].paymentInfo[].serviceLines[].lineItemControlNumber` in the 835 ERA.
{/* schema:ClaimPaymentAdviceServiceLines:unwrapArray */}
```json
"serviceLines": [
{
"lineItemControlNumber": "111222333",
"serviceAdjustments": [
{
"adjustmentAmount1": "300",
"adjustmentReasonCode1": "1",
"claimAdjustmentGroupCode": "PR",
"claimAdjustmentGroupCodeValue": "Patient Responsibility"
}
],
"serviceDate": "20190301",
"servicePaymentInformation": {
"adjudicatedProcedureCode": "99211",
"lineItemChargeAmount": "800",
"lineItemProviderPaymentAmount": "500",
"productOrServiceIDQualifier": "HC",
"productOrServiceIDQualifierValue": "Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes"
},
"serviceSupplementalAmounts": {
"allowedActual": "800"
}
}
]
```
### Duplicate ERAs [#duplicate-eras]
Payers typically only send one ERA per claim. However, they may occasionally retransmit another identical 835 ERA, so you should have logic in place to handle these duplicates.
You can assume an ERA is a duplicate if the Check or EFT Trace Number is the same. This is the `transactions[].paymentAndRemitReassociationDetails.checkOrEFTTraceNumber` property in a processed 835 ERA from Stedi. In X12 EDI, this is available in segment `TRN` (Reassociation Trace Number), element `TRN02` (Check or EFT Trace Number).
## Crossover claims [#crossover-claims]
A claim is called a crossover claim when it is adjudicated by one payer and then forwarded to another payer for additional processing. This is common in coordination of benefits (COB) situations, where a patient has multiple insurance policies. For example, a patient may have coverage through both Medicare and private supplemental insurance. Once Medicare adjudicates the claim, it "crosses over" electronically to the secondary payer. This process helps reduce paperwork for providers and ensures the patient is billed correctly for any remaining balance.
You'll know a claim has been sent to a crossover payer when you receive an 835 ERA with the [`transactions[].detailInfo[].paymentInfo[].claimPaymentInfo.claimStatusCode`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.claimPaymentInfo.claimStatusCode) property set to either `19`, `20`, or `21`. The ERA should also include information about the crossover payer in the [`transactions[].detailInfo[].paymentInfo[].crossoverCarrier`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.crossoverCarrier) object.
Sometimes, the different payers are separate legal entities within the same parent corporation. If not, you'll need to [enroll](/healthcare/transaction-enrollment) the provider separately with the crossover payer before they can process the claim. The payer may pause claim processing until the enrollment is complete or reject the claim. If the claim is rejected, you'll need to manually resubmit it once the enrollment is live. [Stedi support](https://www.stedi.com/contact) can help you determine when you need to enroll with a crossover payer and determine the status of crossover claims while the enrollment is in progress.
You may receive an additional 835 ERA and/or 277CAs from the crossover payer. You may also be able to use the information from any 277CAs to submit real-time claim status requests for the crossover claim.
# Resubmit or cancel claims
Source: https://www.stedi.com/docs/healthcare/resubmit-cancel-claims
You'll need to resubmit claims when they're rejected due to correctable errors, such as:
* Invalid or missing data.
* Incorrect patient or provider details.
* Incorrect billing codes or modifiers.
* Missing documentation or attachments the payer requires.
You may also need to cancel duplicate claims or claims that were submitted in error, such as accidentally billing for the wrong provider or patient.
## Pre-adjudication vs. adjudication [#pre-adjudication-vs-adjudication]
When resubmitting claims, you need to know whether your claim is pre-adjudication or in adjudication.
| Stage | Definition | How you'll know |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Pre-adjudication | The claim hasn't entered the payer's adjudication system. This includes claims the payer has received and then rejected based on front-end edits. | - You received a 277CA claim acknowledgment from Stedi or the payer. Payer rejections may include a message, such as "returned as unprocessable" or "not entered into processing system."
- The payer's 277CA doesn't contain a [Payer Claim Control Number (PCCN)](#payer-claim-control-number-pccn).
|
| Adjudication | The claim has entered the payer's adjudication system. This includes claims that were rejected during adjudication, claims still in progress (for example, in **Pending** status), and claims that completed adjudication (resulting in an 835 ERA). | - The payer's 277CA contains a [Payer Claim Control Number (PCCN)](#payer-claim-control-number-pccn), indicating it has entered the payer's system. OR
- You ran a real-time claim status check that included a PCCN in the response. OR
- You received an 835 Electronic Remittance Advice (ERA) from the payer with adjudication details. All 835 ERAs include a PCCN.
|
The following diagram illustrates the claim submission lifecycle and the responses you can expect to receive at each stage.
## Preparing claim resubmissions or cancellations [#preparing-claim-resubmissions-or-cancellations]
Stedi's guidance for resubmissions varies depending on three factors:
* **Whether the claim has entered the payer's adjudication system** - Visit [Pre-adjudication vs. adjudication](#pre-adjudication-vs-adjudication) to determine where your claim is in the lifecycle.
* **Whether you're resubmitting to Medicare** - Medicare Part A and Part B (processed through MACs) have different requirements than other payers. Visit [Medicare resubmission](#medicare-resubmission) for details.
* **Claim type** - Institutional claims have different requirements than professional or dental claims. Visit [Institutional claims](#institutional-claims) for details.
These factors determine which codes and identifiers to include in the resubmission:
* The proper [Claim Frequency Code (CFC)](#claim-frequency-code-cfc) - indicates the type of submission
* The [Payer Claim Control Number (PCCN)](#payer-claim-control-number-pccn), if appropriate - the payer's unique identifier for your claim
* The appropriate [Patient Control Number (PCN)](#patient-control-number-pcn) - your unique identifier for the claim
You'll also need to include any necessary corrections to the claim data.
### Claim Frequency Code (CFC) [#claim-frequency-code-cfc]
The Claim Frequency Code (CFC) indicates the type of claim submission. It's what tells the payer the claim is an original, a replacement, or a cancellation.
| Scenario | CFC Guidance |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Pre-adjudication (all payers) | - **Professional/Dental:** `1` (Admit thru Discharge Claim)
- **Institutional:** CFC from original submission
|
| Adjudication, non-Medicare | - **All claim types:** `7` (Replacement of Prior Claim) or `8` (Void/Cancel of Prior Claim)
- Resubmission requirements can vary by payer. Always confirm this guidance with the payer's companion guide.
|
| Adjudication, Medicare | - **Professional/Dental:** `1` (Admit thru Discharge Claim)
- **Institutional:** CFC from original submission
|
#### Set the CFC [#set-the-cfc]
You can set the Claim Frequency Code (CFC) in the following locations:
* **JSON:** `claimInformation.claimFrequencyCode` property
* **X12 EDI:** `Loop 2300 CLM05-03` (Claim Frequency Code) component
* **CMS-1500 claim form UI:** Set the **Qualifier** in **Box 22** (Resubmission code)
#### Institutional claims [#institutional-claims]
Institutional claims support a broader set of Claim Frequency Code (CFC) values than professional or dental claims.
For example, in long term care settings, facilities commonly submit interim claims every 30 days to receive partial payments while the patient is still admitted, rather than waiting until the end of the patient's stay. The CFC codes for these interim claims are `2` (Interim - First Claim), `3` (Interim - Continuing Claims), or `4` (Interim - Last Claim).
Therefore, the guidance for institutional claim CFCs is different from professional and dental claims. Specifically, for claims in pre-adjudication or Medicare claims in adjudication, you should resubmit with the same CFC you used in the original submission.
### Payer Claim Control Number (PCCN) [#payer-claim-control-number-pccn]
The Payer Claim Control Number (PCCN) is the unique identifier the payer assigns when your claim enters their adjudication system. It's different from the [Patient Control Number](#patient-control-number-pcn) you sent in the original claim and the Stedi-generated `controlNumber` returned in the API response.
| Scenario | PCCN Guidance |
| ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Pre-adjudication (all payers) | Don't include a PCCN. The claim hasn't entered the payer's adjudication system yet, so no PCCN exists. |
| Adjudication, non-Medicare | Include the PCCN the payer returned in [one or more responses](#find-existing-pccn) to the original claim. Without the PCCN, the payer won't know which claim to replace or cancel. |
| Adjudication, Medicare | Don't include the PCCN. Medicare explicitly instructs providers to omit it when resubmitting claims. Visit [Medicare resubmission](#medicare-resubmission) for details. |
#### Set the PCCN [#set-the-pccn]
You can supply the Payer Claim Control Number (PCCN) in the following locations:
* **JSON:** `claimInformation.claimSupplementalInformation.claimControlNumber`
* **X12 EDI:** `Loop 2300 REF02`, where `REF01` = `F8` (Original Reference Number)
* **CMS-1500 claim form UI:** Set the **Original reference number** in **Box 22** (Resubmission code)
#### Find existing PCCN [#find-existing-pccn]
You can retrieve the Payer Claim Control Number (PCCN) from the following transactions.
**277CA claim acknowledgment from the payer**
* **JSON:** [`transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].patientClaimStatusDetails[].claims[].claimStatus.tradingPartnerClaimNumber`](https://www.stedi.com/docs/healthcare/api-reference/get-healthcare-reports-277#response.transactions.payers\[].claimStatusTransactions\[].claimStatusDetails\[].patientClaimStatusDetails\[].claims\[].claimStatus.tradingPartnerClaimNumber)
* **X12 EDI:** `Loop 2200D REF02`, where `REF01` = `1K` (Payor's Claim Number)
* **Stedi portal:** Go to the [claims view](https://portal.stedi.com/app/healthcare/claims), click the claim to open its timeline, and click **See more detail** on the 277CA. The PCCN is listed under **Payer claim control number** if available.
**277 real-time claim status response**
* **JSON:** [`claims[].claimStatus.tradingPartnerClaimNumber`](https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-claim-status#response.claims.claimStatus.tradingPartnerClaimNumber)
* **X12 EDI:** `Loop 2200D` or `Loop 2200E` in `REF02`, where `REF01` = `1K` (Payor's Claim Number)
**835 Electronic Remittance Advice (ERA)**
* **JSON:** [`transactions[].detailInfo[].paymentInfo[].claimPaymentInfo.payerClaimControlNumber`](https://www.stedi.com/docs/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo\[].paymentInfo\[].claimPaymentInfo.payerClaimControlNumber)
* **X12 EDI:** `Loop 2100 CLP07` (Payer Claim Control Number)
### Patient Control Number (PCN) [#patient-control-number-pcn]
The Patient Control Number (PCN) is a unique identifier you assign to the claim. The payer returns this value in related transactions, such as the 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA), so you can correlate responses with the original claim.
| Scenario | PCN Guidance |
| ----------------------------- | ------------------------------- |
| Pre-adjudication (all payers) | Same PCN as original submission |
| Adjudication, Medicare | Same PCN as original submission |
| Adjudication, non-Medicare | New, unique PCN |
Reuse the same PCN from the original submission for pre-adjudication resubmissions and adjudication Medicare resubmissions. Stedi uses the PCN to match claims and resubmissions in the claims view, so reusing the PCN allows Stedi to show the original claim and resubmissions within a unified claim timeline. Reusing the PCN also helps you track the claim throughout the resubmission process.
Use a new, unique PCN for adjudication non-Medicare resubmissions. In this scenario, a new PCN helps you avoid potential duplicate claim errors from the payer. A new PCN also helps you differentiate between the 835 Electronic Remittance Advice (ERAs) for the original submission and the resubmission.
#### Set the PCN [#set-the-pcn]
You can set the PCN in the following locations:
* **JSON:** `claimInformation.patientControlNumber`
* **X12 EDI:** `Loop 2300 CLM01` (Patient Control Number)
* **CMS-1500 claim form UI:** Set **Box 26** (Patient account number)
#### PCN format [#pcn-format]
When assigning a PCN, follow these best practices:
* Use a unique PCN for each claim. The identifier should be more complex than a simple sequential number and should be hard to guess.
* Use random strings. Formats with patient initials or the date of service in them can create duplicates. We recommend using [nanoid](https://www.npmjs.com/package/nanoid) or a similar library configured with the characters available in the [basic character set](#character-set) to create a strong, unique 17-character PCN for each claim.
* Keep it 17 characters or less. Some payers cut off values longer than 17 characters in ERAs and claim acknowledgments, which makes it hard to match them with the original claim.
* Use only characters available in the [basic character set](#character-restrictions), and avoid special characters that are only available in the extended character set. Payers are permitted to return data using the basic character set. Using other characters may result in data loss or mismatches when correlating claims with responses.
* Treat PCN values as case-insensitive when matching transactions, even if the submitted value included both lower and uppercase characters.
## Resubmit or cancel claims [#resubmit-or-cancel-claims]
Ensure that the updated claim includes:
* [Claim Frequency Code](#claim-frequency-code-cfc) according to the claim's processing status and your use case
* [Payer Claim Control Number (PCCN)](#payer-claim-control-number-pccn), if applicable
* [Patient Control Number](#patient-control-number-pcn) (recommended)
* Any other necessary corrections to the claim
Once you've prepared the updated claim, you can resubmit it through the Stedi API, an SFTP connection, or the Stedi portal. The resubmission process is the same for both corrections and cancellations - the Claim Frequency Code indicates which action you want to take.
### API resubmission [#api-resubmission]
Resubmit through one of Stedi's claim submission endpoints:
* [Professional Claims JSON](/healthcare/api-reference/post-healthcare-claims)
* [Professional Claims Raw X12](/healthcare/api-reference/post-healthcare-claims-raw-x12)
* [Institutional Claims JSON](/healthcare/api-reference/post-healthcare-institutional-claims)
* [Institutional Claims Raw X12](/healthcare/api-reference/post-healthcare-institutional-claims-raw-x12)
* [Dental Claims JSON](/healthcare/api-reference/post-healthcare-institutional-claims-raw-x12)
* [Dental Claims Raw X12](/healthcare/api-reference/post-healthcare-dental-claims-raw-x12)
### SFTP resubmission [#sftp-resubmission]
Visit [SFTP submission](/healthcare/submit-claims-sftp-connection) for details on how to format and submit X12 EDI claims through SFTP.
### CMS-1500 form (professional) [#cms-1500-form-professional]
Stedi's CMS-1500 claim form UI is mostly limited to the CMS-1500 form fields. It may not be able to successfully resubmit complex claims originally submitted through our APIs or SFTP.
To resubmit a professional claim through Stedi's interactive CMS-1500 form:
1. Go to the [claims view](https://portal.stedi.com/app/healthcare/claims) and click the claim you want to resubmit to open its timeline.
2. Click **See more detail** above the claim submission to review its details page.
3. Click **Edit and resubmit** and select **CMS-1500 resubmission**. Stedi opens the interactive CMS-1500 form prepopulated with the claim's information.
4. Make any necessary changes to the claim.
* Make sure to update the Claim Frequency Code, the Payer Claim Control Number, and the Patient Control Number according to best practices.
* Click **Claims timeline** to open a side panel with the claim's activity. You can review related 277CA claim acknowledgments containing the errors you need to address before resubmitting. Hover over a transaction and click **See more detail** to review its details.
5. Click **Submit claim** to resubmit the updated claim to the payer.
The updated claim will appear on the [claims view](https://portal.stedi.com/app/healthcare/claims) within a few minutes. The claim timeline will reflect that this claim is a resubmission along with the original claim and any associated responses.
You'll receive new 277CA claim acknowledgments indicating whether the resubmitted claim was accepted or rejected.
### X12 EDI editor [#x12-edi-editor]
To resubmit a professional, dental, or institutional claim through Stedi's X12 EDI editor:
1. Go to the [claims view](https://portal.stedi.com/app/healthcare/claims) and click the claim you want to resubmit to open its timeline.
2. Click **See more detail** above the claim submission to review its details page.
3. Click **Edit and resubmit** and select **X12 transaction resubmission**. Stedi opens the claim in an interactive editor with the X12 EDI on the left and the EDI specification on the right.
As you hover over different parts of the EDI, Stedi highlights the corresponding part of the specification on the right to help you understand what each part of the EDI means and how to edit it correctly.
4. Make changes to the claim EDI.
* You can type directly in the EDI editor or copy and paste updated EDI from another source.
* Make sure to update the Claim Frequency Code, the Payer Claim Control Number, and the Patient Control Number according to best practices.
* Click **Claims timeline** to open a side panel with the claim's activity. You can review related 277CA claim acknowledgments containing the errors you need to address before resubmitting. Hover over a transaction and click **See more detail** to review its details.
5. Click **Review and submit**. Stedi shows a comparison of the original claim and the new claim containing your changes.
6. Click **Resubmit claim** to send the updated claim to the payer.
The updated claim will appear on the [claims view](https://portal.stedi.com/app/healthcare/claims) within a few minutes. The claim timeline will reflect that this claim is a resubmission along with the original claim and any associated responses.
You'll receive new 277CA claim acknowledgments indicating whether the resubmitted claim was accepted or rejected.
## Medicare resubmission [#medicare-resubmission]
Medicare Part A and Part B (processed through MACs) have different requirements for resubmissions and cancellations than non-Medicare payers. Non-Medicare includes all other payers, such as commercial insurance and Medicaid.
* Medicare does not accept Claim Frequency Codes `7` or `8` for resubmissions. For professional and dental claims, resubmit with Claim Frequency Code `1`. For institutional claims, resubmit with the same Claim Frequency Code as the original submission.
* Don't include the original claim's Payer Claim Control Number (PCCN) when resubmitting, even if one is available.
## Determine 277CA sender [#determine-277ca-sender]
To determine whether a 277CA is from a clearinghouse or the payer:
* **JSON:** Check the [`transactions[].payers` array](https://www.stedi.com/docs/healthcare/api-reference/get-healthcare-reports-277#response.transactions.payers) in the report (`Loop 2100A`). The `organizationName` property contains the name of the sender (for example, CIGNA or STEDI).
* **X12 EDI:** Check `Loop 2100A NM103` (Information Source Name).
You can also find this information in the Stedi portal:
1. Go to the [claims view](https://portal.stedi.com/app/healthcare/claims).
2. Find the associated claim and click it to view the claim timeline.
3. Find the 277CA in the timeline view. The **From** field indicates whether the acknowledgment is from Stedi or the payer.
## Character restrictions [#character-restrictions]
Only use the X12 Basic and Extended character sets in request data. Using characters outside these sets may cause errors.
The X12 Basic character set includes uppercase letters, digits, space, and some special characters. Lowercase letters and special language characters like `ñ` are not included.
The following special characters are included:
The Extended character set includes the characters listed in Basic, plus lowercase letters and additional special characters, such as `@`.
The following additional special characters are included:
In addition, the following characters are reserved for delimiters in the final X12 EDI transaction to the payer: `~`, `*`, `:` and `^`. X12 doesn't support using escape sequences to represent delimiters or special characters. Stedi returns a `400` error if you use these restricted characters improperly.
* **JSON and CMS-1500 form:** Don't include delimiter characters anywhere in your request data.
* **Raw X12:** You can use these characters as delimiters, but not in the body of the request data.
# Submit eligibility checks - Manual
Source: https://www.stedi.com/docs/healthcare/send-eligibility-checks-ui
You can submit real-time eligibility checks manually through the Stedi portal. Manual eligibility checks are useful for testing and for situations when you need to do a one-time eligibility check.
Eligibility checks verify coverage with a specific payer. If you don't know
the payer, you can perform an [insurance discovery
check](/healthcare/insurance-discovery) instead to find a patient's coverage
using their demographic data.
## Transaction enrollment [#transaction-enrollment]
[Transaction enrollment](/healthcare/transaction-enrollment) is the process of registering a provider to exchange specific healthcare transactions with a payer.
Most payers don't require transaction enrollment for eligibility checks. Those that do, such as the Centers for Medicare & Medicaid Services (CMS), typically allow multiple enrollments with different clearinghouses. That means enrolling through Stedi shouldn't cancel or interfere with any existing enrollments you have through other clearinghouses.
Enrolling through Stedi for real-time eligibility checks also doesn't affect your existing enrollments for other transaction types. For example, enrolling with Stedi won't unenroll the provider from receiving transactions like Electronic Remittance Advices (ERAs) through other clearinghouses.
You can check whether a specific payer requires enrollment for eligibility checks in the [Payer Network](https://www.stedi.com/healthcare/network) or through the [Payers API](/healthcare/api-reference/get-payer).
To enroll, complete the following steps:
1. Create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step. [Stedi portal](https://portal.stedi.com/app/healthcare/providers) | [API endpoint](/healthcare/api-reference/post-enrollment-create-provider)
2. Submit an enrollment request for real-time eligibility checks. [Stedi portal](https://portal.stedi.com/app/healthcare/enrollments) | [API endpoint](/healthcare/api-reference/post-enrollment-create-enrollment)
## Testing [#testing]
The best way to test real-time eligibility checks is through mock requests. When you submit specific mock requests in test mode, Stedi returns mock benefits data from the specified payer.
To submit mock requests through the Stedi portal:
1. Toggle **Test mode** to **ON** in the Stedi portal.
2. Go to the [eligibility check form](https://portal.stedi.com/app/healthcare/checks/create).
3. Choose from predefined mock requests for well-known payers, including Aetna, Cigna, UnitedHealthcare, and the Centers for Medicare & Medicaid Services (CMS).
For each mock request, Stedi returns a realistic mock benefits response for that payer so you can get a sense for the kinds of data you'll receive in production. The benefits responses include examples of copays, deductibles, and other patient payment responsibilities, as well as active coverage.
Visit [Test mode](/healthcare/test-mode) to learn more about testing in the Stedi portal.
Mock transactions you send in test mode are free for testing purposes and won't incur any charges from Stedi.
### Don't send fake data [#dont-send-fake-data]
Some payers, particularly CMS (HETS), prohibit sending test eligibility checks for fake patients or providers to their production systems. Payers may block your access if you send these types of test transactions.
You can send as many [mock requests](/healthcare/api-reference/mock-requests-eligibility-checks) to Stedi as you need, but if you need to send test data to payers in production, you must contact [Stedi support](https://www.stedi.com/contact) to coordinate with the payer and obtain approval. For example, some payers require that you use specific test credentials.
## Run eligibility checks [#run-eligibility-checks]
Real-time eligibility checks provide a response in seconds. They're ideal for in-person patient visits, telehealth appointments, and other scenarios where you need immediate information about a patient's coverage.
To run a new eligibility check:
1. Go to the [Eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility).
2. Click **+ New eligibility check**. Stedi opens the simplified eligibility check form, which we recommend for most use cases.
If you need to submit a check with additional information, click **Swap to advanced form**. On the advanced form, click **Select fields** on the top right of the window. The **Select fields** modal opens, where you can add additional form fields, such as the provider's Social Security Number (SSN) or procedure codes.
Check the boxes next to the fields you want to add to each section and click **Save selection**.
3. Complete the form. Review [eligibility request fields](#eligibility-request-fields) for detailed instructions and tips for required fields. We especially recommend reviewing how to choose the right service type code (STC) or procedure code. This is **very** important for getting the best results from the payer.
4. Click **Submit**.
Stedi opens the **Overview** page for the eligibility check. If the check was successful, you can click **Benefits** to review the patient's benefits information.
### Eligibility request fields [#eligibility-request-fields]
For the best chance of success, start by sending the smallest possible set of fields in your eligibility checks. Adding extra data can lead to unnecessary rejections.
We recommend starting with the following information. Only include more if the payer requires it.
{/* prettier-ignore-start */}
| Form section | Instructions | | | |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | - | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Payer**, or trading partner service ID | Select your payer from the provided list. Hover over **view details** to review a summary of the payer's various identifiers and open the full payer record in Stedi's [Payer Network](https://www.stedi.com/healthcare/network). | | | |
| **Provider** | Most eligibility requests require the provider's name - either their first and last name (individual) or business name (organization) - and their National Provider Identifier (NPI). If you need to provide additional information, such as the provider's Social Security Number (SSN), click **Swap to advanced form** and then click **Select fields** to add additional fields to the request form. | | | |
| **Subscriber** | - At a minimum, you must supply at least the subscriber's **Member ID**, **Date of birth**, or **Last name**. However, each payer has different requirements, so you should supply the fields necessary for each payer to identify the subscriber in their system.
- When you supply the subscriber's member ID, first name, last name, and date of birth, payers are required to return a response if the member is in their database. That's why these are the default form fields.
- If you need to run an MBI lookup with the subscriber's Social Security Number (SSN), click **Select fields** and check the box next to **Social Security Number (SSN)** under the **Subscriber** section. This adds the SSN field to the form.
| | | |
| **Dependent** | A patient qualifies as a dependent for eligibility checks when they are listed as a dependent on the subscriber's insurance plan and the payer cannot uniquely identify the patient through information outside the subscriber's policy. If the patient has their own member ID (even if it only differs by a suffix like `0`), you must identify them in the **Subscriber** section instead. - To add a dependent to the real-time eligibility check form, click **Select fields** and select **Dependents**.
- You can only submit one dependent per eligibility check.
- Most Medicaid plans don't support dependents - you'll almost always need to submit the child as a subscriber in the **Subscriber** section. Sending dependent information here for payers that don't support dependents will either cause an error, or the payer may return results for the subscriber instead.
- We strongly recommend including the dependent's date of birth in the request when available because many payers return errors without it.
- Enter the dependent's name exactly as written on their insurance card, if available, including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces.
| | **Trading partner service ID** | You must specify the payer.- For real-time eligibility checks, select the payer from the dropdown list.
- For MBI lookups, you must select **CMS MBI Lookup** from the dropdown list.
|
| **Encounter**, service or procedure codes | You must include either a service type code (STC) or a procedure code and qualifier. This tells the payer what kinds of benefits information you're requesting. Most medical payers don't support procedure codes. Some dental payers do, but we recommend trying an STC first.- We recommend STC `30` (Health Benefit Plan Coverage) to retrieve a patient's general medical benefits and `35` to retrieve a patient's general dental benefits.
- We recommend submitting one STC per request, unless you've tested and are certain that the payer supports multiple.
- When requesting benefits for specific services, you should test the STCs that seem most appropriate to determine which ones yield the most benefits information. Our STCs and procedure codes docs explain how.
- By default, the real-time eligibility check form allows you to choose a **Service type code**. If you want to include a procedure code instead, click **Swap to advanced form** and then click **Select fields**. Select the boxes for the **Procedure code** and **Product or service ID qualifier** to add them to the form. Note that you can submit either an STC or a procedure code and qualifier - not both.
| | | |
| **Encounter**, service dates | Stedi populates today's date as the date of service by default.- To add a date range, click **Swap to advanced form** and click **Select fields**. Under **Encounter**, select both the **Beginning date of service** and **End date of service** (date range).
- We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers such as the Centers for Medicare and Medicaid Services (CMS) do support requests for dates further in the future - especially the next calendar month. Check the payer's documentation to determine their specific behavior.
| | | |
{/* prettier-ignore-end */}
## Patient information [#patient-information]
Follow this guidance to help payers find the patient in their system.
### Payer search requirements [#payer-search-requirements]
All payers are required to be able to search for patients using the following "bare minimum" subsets of information. They will return benefits information as long as they can find a unique match for the patient within their system.
For a subscriber:
* Member ID, first name, last name, date of birth
* Member ID, last name, date of birth
* Member ID, first name, last name
For a dependent:
* Subscriber member ID, first name, last name, date of birth
* Subscriber member ID, last name, date of birth
* Subscriber member ID, first name, last name
Of course, not all of this patient information is always available. For example, a patient may forget their ID card. In these instances, some payers may still be able to search with even less information, such as the patient's first name, last name, and date of birth. Contact us if you have questions about alternative search options for a particular payer.
### Dependents [#dependents]
The patient qualifies as a dependent for eligibility checks when:
1. The patient is listed as a dependent on the subscriber's insurance plan.
2. The payer cannot uniquely identify the patient through information outside the subscriber's policy.
When the patient meets these criteria, you should submit their information in the **Dependent** section of the form. Otherwise, you must submit their information in the **Subscriber** section instead.
For example, if the dependent has their own member ID number in the payer's database, you must identify them as a subscriber. This includes member IDs that differ only by a suffix, such as `01`, because the patient can still be uniquely identified.
#### Medicaid dependents [#medicaid-dependents]
Most Medicaid plans don't support dependents. However, some state Medicaid plans support eligibility inquiries for newborn children under 12 months old.
Children typically must be enrolled in Medicaid as a separate subscriber with their own unique member ID, even if they are legally the dependent of a parent who is a Medicaid plan member. Therefore, you'll almost always need to submit the child as a subscriber in the **Subscriber** section.
Sending dependent information to payers that don't support dependents will either cause an error, or the payer may ignore the information and return results for the subscriber instead.
### Patient names [#patient-names]
Note the following information and best practices when entering patient names:
* Enter the name exactly as written on the patient's insurance ID card (if available), including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces. If the patient's insurance ID card isn't available, enter the name exactly as written on a government-issued ID card. If a government ID card isn't available, enter the name exactly as given by the patient.
* Don't include a name prefix, title, rank, honorific, or academic degree in any field. These include Mrs., Dr., Hon., and PhD.
* Don't include a suffix or generation such as Jr. or III in the **First name** or **Last name** field. Put it in the separate **Suffix** field instead. Payers are supposed to automatically parse suffixes out of the last name, but Stedi can't guarantee that all payers will do this correctly.
* You can populate a middle name (or names) or initial in the **Middle name** field, but most payers ignore it when searching for the patient.
* Case doesn't matter. For example, JANE is equivalent to Jane.
The following are supported for patient names:
* Compound last and first names separated by spaces or hyphens such as Jean‐Claude or Smith Jones
* Apostrophized or elided names such as O'Connor or D'Amore
* Numbers like 3, however this typically indicates a data entry error
Some payers may have more specific requirements or restrictions that we don't cover in our docs. If you're receiving errors for a specific payer, we recommend consulting that payer's documentation for eligibility checks for additional guidance.
## CMS HETS Rules of Behavior [#cms-hets-rules-of-behavior]
All parties involved in eligibility transactions sent to the Centers for Medicare & Medicaid Services (CMS) eligibility system, called HETS, must comply with the [HETS Rules of Behavior](https://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/hetshelp/downloads/eligibilitytransactionsysteminquiriesrulesofbehavior.pdf). Compliance is also required under our terms.
Review the Rules of Behavior before sending eligibility checks to CMS.
# Submit eligibility checks - API
Source: https://www.stedi.com/docs/healthcare/send-eligibility-checks
You can send real-time eligibility checks programmatically through the API. API submission is ideal for integrating eligibility checks into your application workflows and automating patient coverage verification.
The synchronous response includes the patient's complete benefits information, such as coverage status, co-pays, and deductibles.
Eligibility checks verify coverage with a specific payer. If you don't know
the payer, you can perform an [insurance discovery
check](/healthcare/insurance-discovery) instead to find a patient's coverage
using their demographic data.
## Transaction enrollment [#transaction-enrollment]
[Transaction enrollment](/healthcare/transaction-enrollment) is the process of registering a provider to exchange specific healthcare transactions with a payer.
Most payers don't require transaction enrollment for eligibility checks. Those that do, such as the Centers for Medicare & Medicaid Services (CMS), typically allow multiple enrollments with different clearinghouses. That means enrolling through Stedi shouldn't cancel or interfere with any existing enrollments you have through other clearinghouses.
Enrolling through Stedi for real-time eligibility checks also doesn't affect your existing enrollments for other transaction types. For example, enrolling with Stedi won't unenroll the provider from receiving transactions like Electronic Remittance Advices (ERAs) through other clearinghouses.
You can check whether a specific payer requires enrollment for eligibility checks in the [Payer Network](https://www.stedi.com/healthcare/network) or through the [Payers API](/healthcare/api-reference/get-payer).
To enroll, complete the following steps:
1. Create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step. [Stedi portal](https://portal.stedi.com/app/healthcare/providers) | [API endpoint](/healthcare/api-reference/post-enrollment-create-provider)
2. Submit an enrollment request for real-time eligibility checks. [Stedi portal](https://portal.stedi.com/app/healthcare/enrollments) | [API endpoint](/healthcare/api-reference/post-enrollment-create-enrollment)
## Testing [#testing]
The best way to test real-time eligibility checks is through mock requests. When you submit specific mock requests, Stedi returns mock benefits data from the specified payer. You can submit mock requests through the:
* **API endpoints:** Visit [Eligibility mock requests](/healthcare/api-reference/mock-requests-eligibility-checks) for a complete list. All mock requests work with Stedi's JSON, Raw X12, and SOAP endpoints.
* **Stedi portal:** Visit [Test mode](/healthcare/test-mode) to learn how to enable **Test mode** in your account and manually submit mock requests.
### Don't send fake data [#dont-send-fake-data]
Some payers, particularly CMS (HETS), prohibit sending test eligibility checks for fake patients or providers to their production systems. Payers may block your access if you send these types of test transactions.
You can send as many [mock requests](/healthcare/api-reference/mock-requests-eligibility-checks) to Stedi as you need, but if you need to send test data to payers in production, you must contact [Stedi support](https://www.stedi.com/contact) to coordinate with the payer and obtain approval. For example, some payers require that you use specific test credentials.
## Submit eligibility checks [#submit-eligibility-checks]
Call one of the following endpoints to send real-time 270/271 eligibility checks to payers:
* [Eligibility Check](/healthcare/api-reference/post-healthcare-eligibility) to send requests in JSON
* [Eligibility Check Raw X12](/healthcare/api-reference/post-healthcare-eligibility-raw-x12) to send requests in X12 EDI
* [Eligibility Check SOAP](/healthcare/api-reference/post-healthcare-eligibility-soap) to send SOAP requests using the CAQH CORE vC2.2.0 XML Schema. The XML document contains an eligibility check in X12 EDI format.
Stedi automatically applies various repairs to help your requests meet X12 HIPAA specifications, resulting in fewer payer rejections.
### Headers - required [#headers---required]
JSON and Raw X12 endpoints:
* **`Authorization`:** [Generate an API key](/healthcare/api-reference#authentication) to use for authentication.
* **`Content-Type`:** Set to `application/json`.
SOAP endpoint:
* **`Content-Type`:** Set to `application/soap+xml`. You'll include authentication details in the XML document, so you don't need to set the `Authorization` header.
### Headers - situational [#headers---situational]
JSON, Raw X12, and SOAP endpoints:
* When sending eligibility checks to the Centers for Medicare & Medicaid Services (CMS), you may need to include the `X-Forwarded-For` header set to a comma-separated list of any upstream IP addresses. Visit [CMS traceability requirements](#cms-traceability-requirements) for details and examples.
### Body - JSON [#body---json]
The information you provide to the payer in an eligibility check can vary, depending on the circumstances. We recommend starting with a basic eligibility request.
#### Basic eligibility request [#basic-eligibility-request]
Each eligibility check must include at least the following information in the request body:
| Information | Description |
| ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tradingPartnerServiceId` | - This is the payer ID. You can send requests using the primary payer ID, the Stedi payer ID, or any alias listed in the payer record. If you don't already have payer IDs you use today, we recommend using the primary Payer ID. Visit the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list.
- You must include leading `0` characters in payer IDs. For example, use `00540` for SISCO, not `540`.
- If you don't know the payer, try submitting an [insurance discovery check](/healthcare/insurance-discovery) instead.
|
| `provider` object, name and identifier | - You must include the provider's name - either the `firstName` and `lastName` of a specific provider within a practice or the `organizationName`.
- You must include an identifier - this is typically the provider's [National Provider Identifier](https://www.stedi.com/docs/healthcare/national-provider-identifier) (`npi`). If the provider doesn't have an NPI, you can supply an alternative, such as their `taxId` or `ssn`.
|
| `subscriber` and/or `dependents` objects | - The `dependents` object is optional - refer to the scenarios when the [patient qualifies as a dependent](/healthcare/send-eligibility-checks#dependents).
- At a minimum, our API requires that you supply at least one of these fields in the request: `memberId`, `dateOfBirth`, or `lastName`. However, each payer has different requirements, so you should supply the fields necessary for each payer to identify the subscriber in their system.
- When all four of `memberId`, `dateOfBirth`, `firstName`, and `lastName` are provided, payers are required to return a response if the member is in their database. Some payers may be able to search with less information, but this varies by payer.
- We recommend always including the patient's member ID when possible. Learn more about [patient information](/healthcare/send-eligibility-checks#patient-information).
|
| `encounter` object, service dates | - You can specify either a single `dateOfService` or a `beginningDateOfService` and `endDateOfService`. The payer defaults to using the current date in their timezone if you don't include one.
- When checking eligibility for today, omit the `dateOfService` property to ensure consistent behavior across payers.
- We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers such as the Centers for Medicare and Medicaid Services (CMS) do support requests for dates further in the future - especially the next calendar month. Check the payer's documentation to determine their specific behavior.
|
| `encounter` object, service or procedure codes | - Specify `serviceTypeCodes` and/or a `procedureCode` and `productOrServiceIDQualifier` to request specific types of benefits information.
- We recommend including no more than one service type code in each request.
- If you don't include any service type code or procedure code information, Stedi defaults to using `30` (Plan coverage and general benefits) as the only `serviceTypeCodes` value.
- Learn more about [STCs and procedure codes](/healthcare/eligibility-stc-procedure-codes).
|
The following example shows the bare minimum request body for an eligibility check. Because the `dateOfService` is not specified, the payer will use the current date in their timezone (default) to retrieve benefits information.
{/* schema:EligibilityCheckRequestContent */}
```json
{
"tradingPartnerServiceId": "AHS",
"encounter": {
"serviceTypeCodes": ["78"]
},
"provider": {
"organizationName": "ACME Health Services",
"npi": "1999999984"
},
"subscriber": {
"dateOfBirth": "19000101",
"firstName": "Jane",
"lastName": "Doe",
"memberId": "1234567890"
}
}
```
#### Conditional requirements [#conditional-requirements]
Note that objects marked as **required** are required for all requests, while others are conditionally required depending on the circumstances. When you include a conditionally required object, you must include all of its required properties.
For example, you must always include the `provider` object in your request, but you only need to include the `dependents` object when you need to request benefits information for a dependent on the subscriber's insurance plan.
### Body - X12 EDI [#body---x12-edi]
When sending real-time eligibility checks through the Raw X12 or SOAP endpoints, you must send the eligibility check [270 X12 EDI format](https://portal.stedi.com/app/guides/view/hipaa/health-care-eligibility-benefit-inquiry-x279a1/01GRYB6GTDJ4MEP5Z16CGMQWT6?__hstc=181257784.360aac417a3f93a63ca63bf29197fe1f.1727971380232.1752174670420.1752250096430.449&__hssc=181257784.244.1752250096430&__hsfp=1923652471). The information you send can vary, depending on the circumstances. We recommend starting with a basic eligibility request.
#### Basic eligibility request [#basic-eligibility-request-1]
Each eligibility check must also include at least the following information:
| Information | Description |
| ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `BHT03` (Submitter Transaction Identifier) | - This identifier must be 1-50 characters long and different from the value you choose for `ST02`.
- We also strongly recommend using a unique value. [Learn more](/healthcare/send-eligibility-checks#submitter-transaction-identifier)
|
| `Loop 2100A` (Information Source) | - This loop contains the payer's information. Notably, you must include the payer's name (`NM103`) and identifier (`NM109`).
- The payer's identifier **must** be a payer ID or payer ID alias listed in the [Payer Network](https://www.stedi.com/healthcare/network). For example, you could use `60054`, `HPQRS`, `AETNA`, or any other listed payer ID alias for Aetna.
- You must include leading `0` characters in payer IDs. For example, use `00540` for SISCO, not `540`.
|
| `Loop 2000B` (Information Receiver) | - This loop contains information about the provider requesting the benefits information.
- You must include the provider's name (`NM103`) and an identifier (`NM109`). Most often this is the [National Provider Identifier (NPI)](/healthcare/national-provider-identifier).
|
| `Loop 2000C` (Subscriber) and `Loop 2000D` (Dependent) | - `Loop 2000D` is optional - refer to the scenarios when the [patient qualifies as a dependent](/healthcare/send-eligibility-checks#dependents).
- At a minimum, you must supply at least one of these fields in the appropriate loop to identify the patient: `NM109` (member ID), `DMG02` (birth date), or `NM103` (last name). However, each payer has different requirements, so you should supply the fields necessary for each payer to identify the patient in their system.
- When all four of member ID, first name, last name, and date of birth are provided, payers are required to return a response if the member is in their database. Some payers may be able to search with less information, but this varies by payer.
- We recommend always including the patient's member ID when possible. Learn more about [patient information](/healthcare/send-eligibility-checks#patient-information).
|
| `Loop 2110C` or `Loop 2100D DTP` (Eligibility/Benefit Date) | - You can specify either a single date of service or a range of service dates. The payer defaults to using the current date in their timezone if you don't include one.
- When checking eligibility for today, omit the service date from the request to ensure consistent behavior across payers.
- We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers such as the Centers for Medicare and Medicaid Services (CMS) do support requests for dates further in the future - especially the next calendar month. Check the payer's documentation to determine their specific behavior.
|
| `Loop 2110C` or `Loop 2100D EQ` (Eligibility or Benefit Inquiry) | - You must specify a service type code and/or a procedure code and qualifier to request specific types of benefits information.
- We recommend including no more than one service type code in each request. Learn more about [STCs and procedure codes](/healthcare/eligibility-stc-procedure-codes).
|
#### Envelope and header [#envelope-and-header]
Stedi generates its own `ISA` and `GS` headers and `IEA` and `GE` trailers before sending your eligibility check to the payer. You can submit your check to Stedi with any values in these segments, as long as they conform to the X12 EDI specification.
However, you must set `ST03` (Implementation Convention Reference) to `005010X279A1`.
#### Submitter Transaction Identifier [#submitter-transaction-identifier]
The `BHT03` (Submitter Transaction Identifier) element is **required** when submitting real-time eligibility checks in X12 EDI. The identifier you choose must be:
* An alphanumeric string from 1-50 characters long.
* Different from the value you choose for `ST02` (Transaction Set Control Number).
We also **strongly recommend** using a unique value. This approach makes it easier for Stedi to troubleshoot eligibility checks in your account.
The payer returns the identifier in the `BHT03` element of the 271 eligibility response, and Stedi returns it in the `meta.traceId` JSON property.
If you don't include `BHT03` in the request, Stedi returns a `200` with the `status` property set to `ERROR` and the `implementationTransactionSetSyntaxError` property set to `5`. The response also includes a negative [999 Implementation Acknowledgment](https://www.stedi.com/edi/x12/transaction-set/999) in the `x12` property.
{/* schema:EligibilityCheckResponseContent */}
```json
{
"controlNumber": "138549672",
"tradingPartnerServiceId": "STEDI",
"errors": [
{
"description": "The payer or clearinghouse rejected the request with validation errors. The original edi response is returned in the x12 field, please contact Stedi Support if you need further help."
}
],
"status": "ERROR",
"transactionSetAcknowledgement": "R",
"implementationTransactionSetSyntaxError": "5",
"x12": "ISA*00* *00* *ZZ*STEDI *01*117151744 *250523*1304*^*00501*000000000*0*P*:~GS*FA*STEDI*117151744*20250523*1304*000000000*X*005010X231A1~ST*999*0001*005010X231A1~AK1*HS*9872*005010X279A1~AK2*270*0001*005010X279A1~IK3*BHT*2**8~IK4*3*127*2~CTX*SITUATIONAL TRIGGER*BHT*2**3~IK5*R*5~AK9*R*1*1*0~SE*9*0001~GE*1*000000000~IEA*1*000000000~"
}
```
#### Trace Number [#trace-number]
You may want to include a trace number in your request to help you track eligibility checks. Stedi always generates a trace number for internal tracking, and you can optionally supply your own trace number of up to 50 characters in a `TRN` segment.
You can send the trace number in **one** of the following locations (not both):
* If the subscriber is the patient, send it in `Loop 2000C TRN02` (Trace Number).
* If the dependent is the patient, send it in `Loop 2000D TRN02` (Dependent Trace Number).
Stedi returns both its internal trace number and your trace number (if provided) in the [`subscriberTraceNumbers` array](/healthcare/api-reference/post-healthcare-eligibility-raw-x12#response.subscriberTraceNumbers).
### Character restrictions [#character-restrictions]
Only use the X12 Basic and Extended character sets in request data. Using characters outside these sets may cause errors.
The X12 Basic character set includes uppercase letters, digits, space, and some special characters. Lowercase letters and special language characters like `ñ` are not included.
The following special characters are included:
The Extended character set includes the characters listed in Basic, plus lowercase letters and additional special characters, such as `@`.
The following additional special characters are included:
In addition, the following characters are reserved for delimiters in the final X12 EDI transaction to the payer: `~`, `*`, `:` and `^`. X12 doesn't support using escape sequences to represent delimiters or special characters. Stedi returns a `400` error if you use these restricted characters improperly.
* **JSON endpoint:** Don’t include delimiter characters anywhere in your request data.
* **Raw X12 endpoint:** You can use these characters as delimiters, but not in the body of the request data.
#### Autocorrection for backticks [#autocorrection-for-backticks]
Stedi automatically replaces backticks (`` ` ``), also known as backquotes or grave accents, with an apostrophe (`'`) in `subscriber` and `dependents` first and last names. These corrections prevent errors when submitting your request. Stedi returns a message in the response's `warnings` array when it makes this replacement.
### Sample request and response [#sample-request-and-response]
The following request and response examples show a basic eligibility check for a patient named Jane Doe. The request uses the `MH` service type code to check for mental health benefits.
The response contains the patient's benefits information. Visit [Determine patient benefits](/healthcare/eligibility-active-coverage-benefits) for detailed explanations of how to determine the patient's active coverage, financial responsibility, whether referrals and authorizations are required, and more.
#### JSON endpoint [#json-endpoint]
{/* schema:EligibilityCheckRequestContent */}
```bash
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3 \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "ABDCE",
"encounter": {
"serviceTypeCodes": ["MH"]
},
"provider": {
"organizationName": "ACME Health Services",
"npi": "1999999984"
},
"subscriber": {
"dateOfBirth": "19000101",
"firstName": "Jane",
"lastName": "Doe",
"memberId": "1234567890"
}
}'
```
{/* schema:EligibilityCheckResponseContent */}
```json
{
"meta": {
"senderId": "030240928",
"submitterId": "117151744",
"applicationMode": "production",
"traceId": "01J2VZA127GH93JT74HJU",
"outboundTraceId": "01J2VZA127GH93JT74HJU"
},
"controlNumber": "214976898",
"id": "ec_01234567-89ab-cdef-0123-456789abcdef",
"reassociationKey": "123456789",
"tradingPartnerServiceId": "123456789",
"provider": {
"providerName": "ACME HEALTH SERVICES",
"entityIdentifier": "Provider",
"entityType": "Non-Person Entity",
"npi": "1999999984"
},
"subscriber": {
"memberId": "123456789",
"firstName": "JANE",
"lastName": "DOE",
"middleName": "A",
"gender": "F",
"entityIdentifier": "Insured or Subscriber",
"entityType": "Person",
"dateOfBirth": "19000101",
"groupNumber": "123456789",
"address": {
"address1": "1234 FIRST ST",
"city": "NEW YORK",
"state": "WV",
"postalCode": "123451111"
}
},
"payer": {
"entityIdentifier": "Payer",
"entityType": "Non-Person Entity",
"name": "ABCDE",
"federalTaxpayersIdNumber": "123412345",
"contactInformation": {
"contacts": [
{
"communicationMode": "Telephone",
"communicationNumber": "1234567890"
},
{
"communicationMode": "Uniform Resource Locator (URL)",
"communicationNumber": "website.company.com"
}
]
}
},
"planInformation": {
"groupNumber": "12341234",
"groupDescription": "ABCDE",
"priorIdNumber": "1234567890"
},
"planDateInformation": {
"planBegin": "20240101",
"planEnd": "20241231",
"eligibilityBegin": "20220102"
},
"planStatus": [
{
"statusCode": "1",
"status": "Active Coverage",
"planDetails": "Open Access Plus",
"serviceTypeCodes": ["30"]
},
{
"statusCode": "1",
"status": "Active Coverage",
"serviceTypeCodes": [
"A7",
"BC",
"A8",
"A4",
"A5",
"A6",
"7",
"4",
"BB",
"22"
]
},
{
"statusCode": "1",
"status": "Active Coverage",
"serviceTypeCodes": ["MH"]
}
],
"benefitsInformation": [
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"planCoverage": "Open Access Plus",
"additionalInformation": [
{
"description": "Complete Care Management"
}
]
},
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "6000",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "500",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
]
},
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "3000",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "250",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "15000",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No"
},
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "30000",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No",
"additionalInformation": [
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"benefitPercent": "0.1",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes"
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "7500",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No"
},
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "15000",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No",
"additionalInformation": [
{
"description": "Deductible does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"benefitPercent": "0.5",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No"
},
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": [
"A7",
"BC",
"A8",
"A4",
"A5",
"A6",
"7",
"4",
"BB",
"22"
],
"serviceTypes": [
"Psychiatric - Inpatient",
"Day Care (Psychiatric)",
"Psychiatric - Outpatient",
"Psychiatric",
"Psychiatric - Room and Board",
"Psychotherapy",
"Anesthesia",
"Diagnostic X-Ray",
"Partial Hospitalization (Psychiatric)",
"Social Work"
],
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable"
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["BC", "A4", "A6", "4", "22"],
"serviceTypes": [
"Day Care (Psychiatric)",
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
],
"benefitAmount": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "22",
"industry": "Outpatient Hospital"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "22",
"industry": "Outpatient Hospital"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A8"],
"serviceTypes": ["Psychiatric - Outpatient"],
"benefitAmount": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "4", "22"],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
],
"benefitAmount": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "22"],
"serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
"benefitAmount": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
}
]
},
{
"code": "B",
"name": "Co-Payment",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "22"],
"serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
"timeQualifierCode": "27",
"timeQualifier": "Visit",
"benefitAmount": "20",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "4", "22"],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
],
"benefitPercent": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
}
]
},
{
"code": "B",
"name": "Co-Payment",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "22"],
"serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
"timeQualifierCode": "27",
"timeQualifier": "Visit",
"benefitAmount": "20",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Included For Specific Services"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "22"],
"serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
"benefitPercent": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Included For Specific Services"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "22"],
"serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
"benefitPercent": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "4", "22"],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
],
"benefitPercent": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
}
]
},
{
"code": "B",
"name": "Co-Payment",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "22"],
"serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
"timeQualifierCode": "27",
"timeQualifier": "Visit",
"benefitAmount": "20",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
}
]
},
{
"code": "B",
"name": "Co-Payment",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "22"],
"serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
"timeQualifierCode": "27",
"timeQualifier": "Visit",
"benefitAmount": "20",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["7"],
"serviceTypes": ["Anesthesia"],
"benefitPercent": "0",
"authOrCertIndicator": "Y",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
}
]
},
{
"code": "CB",
"name": "Coverage Basis",
"serviceTypeCodes": ["7", "BB"],
"serviceTypes": ["Anesthesia", "Partial Hospitalization (Psychiatric)"],
"authOrCertIndicator": "Y",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes"
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["7"],
"serviceTypes": ["Anesthesia"],
"benefitAmount": "0",
"authOrCertIndicator": "Y",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["7"],
"serviceTypes": ["Anesthesia"],
"benefitPercent": "0",
"authOrCertIndicator": "Y",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["4"],
"serviceTypes": ["Diagnostic X-Ray"],
"benefitPercent": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "22",
"industry": "Outpatient Hospital"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "22",
"industry": "Outpatient Hospital"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["4"],
"serviceTypes": ["Diagnostic X-Ray"],
"benefitPercent": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "22",
"industry": "Outpatient Hospital"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "22",
"industry": "Outpatient Hospital"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["BB"],
"serviceTypes": ["Partial Hospitalization (Psychiatric)"],
"benefitAmount": "0",
"authOrCertIndicator": "Y",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
]
},
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": ["MH"],
"serviceTypes": ["Mental Health"],
"additionalInformation": [
{
"description": " Provider is out of network based on NPI ID provided in request."
}
]
},
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "5760",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "500",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
]
},
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "2760",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "250",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "15000",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No"
},
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "30000",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No",
"additionalInformation": [
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "7500",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No"
},
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "15000",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No",
"additionalInformation": [
{
"description": "Deductible does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
}
]
}
],
"errors": [],
"x12": "ISA*00* *00* *ZZ*STEDI *01*117151744 *111111*1234*^*00501*123456782*0*P*>~GS*HB*STEDI*117151744*20240326*111000*1*X*005010X279A1~ST*271*1001*005010X279A1~BHT*0022*11*01J2VZA127GH93JT74HJU*20240326*1514~HL*1**20*1~NM1*PR*2*ABCDE*****FI*111000123~PER*IC**TE*123456789*UR*website.company.com~HL*2*1*21*1~NM1*1P*2*ACME HEALTH SERVICES*****XX*1999999984~HL*3*2*22*0~NM1*IL*1*DOE*JANE*A***MI*123456789~REF*6P*123456789*ABCDE~REF*Q4*123456789~N3*1234 FIRST ST~N4*NEW YORK*WV*123451111~DMG*D8*19000101*F~INS*Y*18*001*25~DTP*356*D8*20220102~DTP*346*D8*20240101~DTP*347*D8*20241231~EB*1**30**Open Access Plus~MSG*Complete Care Management~EB*G*FAM*30***23*6000.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*FAM*30***23*500.00*****Y~MSG*Includes services provided by Client Specific Network~EB*G*IND*30***23*3000.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***23*250.00*****Y~MSG*Includes services provided by Client Specific Network~EB*C*FAM*30***23*15000.00*****N~EB*G*FAM*30***23*30000.00*****N~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*A*IND*30*****.10****Y~EB*C*IND*30***23*7500.00*****N~EB*G*IND*30***23*15000.00*****N~MSG*Deductible does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~EB*A*IND*30*****.50****N~EB*1**A7^BC^A8^A4^A5^A6^7^4^BB^22*********W~EB*C*IND*BC^A4^A6^4^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*22~EB*C*IND*A8****0.00****N*Y~MSG*Includes services provided by Client Specific Network~EB*C*IND*A4^A6^4^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*11~EB*C*IND*A4^A6^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*02~EB*B*IND*A4^A6^22***27*20.00****N*Y~III*ZZ*11~EB*A*IND*A4^A6^4^22*****.00***N*Y~III*ZZ*11~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Included For Specific Services~III*ZZ*02~EB*A*IND*A4^A6^22*****.00***N*Y~MSG*Included For Specific Services~III*ZZ*02~EB*A*IND*A4^A6^22*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*02~EB*A*IND*A4^A6^4^22*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*02~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*A*IND*7*****.00***Y*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*CB**7^BB********Y*Y~EB*C*IND*7****0.00****Y*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*11~EB*A*IND*7*****.00***Y*Y~III*ZZ*11~EB*A*IND*4*****.00***N*Y~III*ZZ*22~EB*A*IND*4*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*22~EB*C*IND*BB****0.00****Y*Y~MSG*Includes services provided by Client Specific Network~EB*1**MH~MSG* Provider is out of network based on NPI ID provided in request.~EB*G*FAM*30***29*5760.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*FAM*30***29*500.00*****Y~MSG*Includes services provided by Client Specific Network~EB*G*IND*30***29*2760.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***29*250.00*****Y~MSG*Includes services provided by Client Specific Network~EB*C*FAM*30***29*15000.00*****N~EB*G*FAM*30***29*30000.00*****N~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***29*7500.00*****N~EB*G*IND*30***29*15000.00*****N~MSG*Deductible does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~SE*119*1001~GE*1*1~IEA*1*123456782~"
}
```
#### Raw X12 endpoint [#raw-x12-endpoint]
```bash
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12 \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*SENDER *ZZ*RECEIVER *231106*1406*^*00501*000000001*0*T*>~GS*HS*SENDERGS*RECEIVERGS*20231106*140631*000000001*X*005010X279A1~ST*270*123456789*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*1234567890~DMG*D8*19000101~DTP*291*D8*20240108~EQ*MH~SE*13*123456789~GE*1*000000001~IEA*1*000000001~"
}'
```
{/* schema:EligibilityCheckResponseContent */}
```json
{
"meta": {
"senderId": "030240928",
"submitterId": "117151744",
"applicationMode": "production",
"traceId": "01J2VZA127GH93JT74HJU",
"outboundTraceId": "01J2VZA127GH93JT74HJU"
},
"controlNumber": "214976898",
"id": "ec_01234567-89ab-cdef-0123-456789abcdef",
"reassociationKey": "123456789",
"tradingPartnerServiceId": "123456789",
"provider": {
"providerName": "ACME HEALTH SERVICES",
"entityIdentifier": "Provider",
"entityType": "Non-Person Entity",
"npi": "1999999984"
},
"subscriber": {
"memberId": "123456789",
"firstName": "JANE",
"lastName": "DOE",
"middleName": "A",
"gender": "F",
"entityIdentifier": "Insured or Subscriber",
"entityType": "Person",
"dateOfBirth": "19000101",
"groupNumber": "123456789",
"address": {
"address1": "1234 FIRST ST",
"city": "NEW YORK",
"state": "WV",
"postalCode": "123451111"
}
},
"payer": {
"entityIdentifier": "Payer",
"entityType": "Non-Person Entity",
"name": "ABCDE",
"federalTaxpayersIdNumber": "123412345",
"contactInformation": {
"contacts": [
{
"communicationMode": "Telephone",
"communicationNumber": "1234567890"
},
{
"communicationMode": "Uniform Resource Locator (URL)",
"communicationNumber": "website.company.com"
}
]
}
},
"planInformation": {
"groupNumber": "12341234",
"groupDescription": "ABCDE",
"priorIdNumber": "1234567890"
},
"planDateInformation": {
"planBegin": "20240101",
"planEnd": "20241231",
"eligibilityBegin": "20220102"
},
"planStatus": [
{
"statusCode": "1",
"status": "Active Coverage",
"planDetails": "Open Access Plus",
"serviceTypeCodes": ["30"]
},
{
"statusCode": "1",
"status": "Active Coverage",
"serviceTypeCodes": [
"A7",
"BC",
"A8",
"A4",
"A5",
"A6",
"7",
"4",
"BB",
"22"
]
},
{
"statusCode": "1",
"status": "Active Coverage",
"serviceTypeCodes": ["MH"]
}
],
"benefitsInformation": [
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"planCoverage": "Open Access Plus",
"additionalInformation": [
{
"description": "Complete Care Management"
}
]
},
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "6000",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "500",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
]
},
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "3000",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "250",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "15000",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No"
},
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "30000",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No",
"additionalInformation": [
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"benefitPercent": "0.1",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes"
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "7500",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No"
},
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "23",
"timeQualifier": "Calendar Year",
"benefitAmount": "15000",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No",
"additionalInformation": [
{
"description": "Deductible does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"benefitPercent": "0.5",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No"
},
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": [
"A7",
"BC",
"A8",
"A4",
"A5",
"A6",
"7",
"4",
"BB",
"22"
],
"serviceTypes": [
"Psychiatric - Inpatient",
"Day Care (Psychiatric)",
"Psychiatric - Outpatient",
"Psychiatric",
"Psychiatric - Room and Board",
"Psychotherapy",
"Anesthesia",
"Diagnostic X-Ray",
"Partial Hospitalization (Psychiatric)",
"Social Work"
],
"inPlanNetworkIndicatorCode": "W",
"inPlanNetworkIndicator": "Not Applicable"
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["BC", "A4", "A6", "4", "22"],
"serviceTypes": [
"Day Care (Psychiatric)",
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
],
"benefitAmount": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "22",
"industry": "Outpatient Hospital"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "22",
"industry": "Outpatient Hospital"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A8"],
"serviceTypes": ["Psychiatric - Outpatient"],
"benefitAmount": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "4", "22"],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
],
"benefitAmount": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "22"],
"serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
"benefitAmount": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
}
]
},
{
"code": "B",
"name": "Co-Payment",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "22"],
"serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
"timeQualifierCode": "27",
"timeQualifier": "Visit",
"benefitAmount": "20",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "4", "22"],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
],
"benefitPercent": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
}
]
},
{
"code": "B",
"name": "Co-Payment",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "22"],
"serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
"timeQualifierCode": "27",
"timeQualifier": "Visit",
"benefitAmount": "20",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Included For Specific Services"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "22"],
"serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
"benefitPercent": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Included For Specific Services"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "22"],
"serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
"benefitPercent": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "4", "22"],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
],
"benefitPercent": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
}
]
},
{
"code": "B",
"name": "Co-Payment",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "22"],
"serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
"timeQualifierCode": "27",
"timeQualifier": "Visit",
"benefitAmount": "20",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "02",
"industry": "Telehealth Provided Other than in Patient’s Home"
}
]
},
{
"code": "B",
"name": "Co-Payment",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["A4", "A6", "22"],
"serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
"timeQualifierCode": "27",
"timeQualifier": "Visit",
"benefitAmount": "20",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["7"],
"serviceTypes": ["Anesthesia"],
"benefitPercent": "0",
"authOrCertIndicator": "Y",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
}
]
},
{
"code": "CB",
"name": "Coverage Basis",
"serviceTypeCodes": ["7", "BB"],
"serviceTypes": ["Anesthesia", "Partial Hospitalization (Psychiatric)"],
"authOrCertIndicator": "Y",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes"
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["7"],
"serviceTypes": ["Anesthesia"],
"benefitAmount": "0",
"authOrCertIndicator": "Y",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["7"],
"serviceTypes": ["Anesthesia"],
"benefitPercent": "0",
"authOrCertIndicator": "Y",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "11",
"industry": "Office"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["4"],
"serviceTypes": ["Diagnostic X-Ray"],
"benefitPercent": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "22",
"industry": "Outpatient Hospital"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "22",
"industry": "Outpatient Hospital"
}
]
},
{
"code": "A",
"name": "Co-Insurance",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["4"],
"serviceTypes": ["Diagnostic X-Ray"],
"benefitPercent": "0",
"authOrCertIndicator": "N",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"eligibilityAdditionalInformation": {
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "22",
"industry": "Outpatient Hospital"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifierCode": "ZZ",
"codeListQualifier": "Mutually Defined",
"industryCode": "22",
"industry": "Outpatient Hospital"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["BB"],
"serviceTypes": ["Partial Hospitalization (Psychiatric)"],
"benefitAmount": "0",
"authOrCertIndicator": "Y",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
]
},
{
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": ["MH"],
"serviceTypes": ["Mental Health"],
"additionalInformation": [
{
"description": " Provider is out of network based on NPI ID provided in request."
}
]
},
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "5760",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "500",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
]
},
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "2760",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "250",
"inPlanNetworkIndicatorCode": "Y",
"inPlanNetworkIndicator": "Yes",
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "15000",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No"
},
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "FAM",
"coverageLevel": "Family",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "30000",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No",
"additionalInformation": [
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
]
},
{
"code": "C",
"name": "Deductible",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "7500",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No"
},
{
"code": "G",
"name": "Out of Pocket (Stop Loss)",
"coverageLevelCode": "IND",
"coverageLevel": "Individual",
"serviceTypeCodes": ["30"],
"serviceTypes": ["Health Benefit Plan Coverage"],
"timeQualifierCode": "29",
"timeQualifier": "Remaining",
"benefitAmount": "15000",
"inPlanNetworkIndicatorCode": "N",
"inPlanNetworkIndicator": "No",
"additionalInformation": [
{
"description": "Deductible does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
}
]
}
],
"errors": [],
"x12": "ISA*00* *00* *ZZ*STEDI *01*117151744 *111111*1234*^*00501*123456782*0*P*>~GS*HB*STEDI*117151744*20240326*111000*1*X*005010X279A1~ST*271*1001*005010X279A1~BHT*0022*11*01J2VZA127GH93JT74HJU*20240326*1514~HL*1**20*1~NM1*PR*2*ABCDE*****FI*111000123~PER*IC**TE*123456789*UR*website.company.com~HL*2*1*21*1~NM1*1P*2*ACME HEALTH SERVICES*****XX*1999999984~HL*3*2*22*0~NM1*IL*1*DOE*JANE*A***MI*123456789~REF*6P*123456789*ABCDE~REF*Q4*123456789~N3*1234 FIRST ST~N4*NEW YORK*WV*123451111~DMG*D8*19000101*F~INS*Y*18*001*25~DTP*356*D8*20220102~DTP*346*D8*20240101~DTP*347*D8*20241231~EB*1**30**Open Access Plus~MSG*Complete Care Management~EB*G*FAM*30***23*6000.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*FAM*30***23*500.00*****Y~MSG*Includes services provided by Client Specific Network~EB*G*IND*30***23*3000.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***23*250.00*****Y~MSG*Includes services provided by Client Specific Network~EB*C*FAM*30***23*15000.00*****N~EB*G*FAM*30***23*30000.00*****N~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*A*IND*30*****.10****Y~EB*C*IND*30***23*7500.00*****N~EB*G*IND*30***23*15000.00*****N~MSG*Deductible does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~EB*A*IND*30*****.50****N~EB*1**A7^BC^A8^A4^A5^A6^7^4^BB^22*********W~EB*C*IND*BC^A4^A6^4^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*22~EB*C*IND*A8****0.00****N*Y~MSG*Includes services provided by Client Specific Network~EB*C*IND*A4^A6^4^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*11~EB*C*IND*A4^A6^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*02~EB*B*IND*A4^A6^22***27*20.00****N*Y~III*ZZ*11~EB*A*IND*A4^A6^4^22*****.00***N*Y~III*ZZ*11~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Included For Specific Services~III*ZZ*02~EB*A*IND*A4^A6^22*****.00***N*Y~MSG*Included For Specific Services~III*ZZ*02~EB*A*IND*A4^A6^22*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*02~EB*A*IND*A4^A6^4^22*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*02~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*A*IND*7*****.00***Y*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*CB**7^BB********Y*Y~EB*C*IND*7****0.00****Y*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*11~EB*A*IND*7*****.00***Y*Y~III*ZZ*11~EB*A*IND*4*****.00***N*Y~III*ZZ*22~EB*A*IND*4*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*22~EB*C*IND*BB****0.00****Y*Y~MSG*Includes services provided by Client Specific Network~EB*1**MH~MSG* Provider is out of network based on NPI ID provided in request.~EB*G*FAM*30***29*5760.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*FAM*30***29*500.00*****Y~MSG*Includes services provided by Client Specific Network~EB*G*IND*30***29*2760.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***29*250.00*****Y~MSG*Includes services provided by Client Specific Network~EB*C*FAM*30***29*15000.00*****N~EB*G*FAM*30***29*30000.00*****N~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***29*7500.00*****N~EB*G*IND*30***29*15000.00*****N~MSG*Deductible does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~SE*119*1001~GE*1*1~IEA*1*123456782~"
}
```
#### SOAP endpoint [#soap-endpoint]
Note that the HTTP response must also include two additional headers:
* `stedi-id`: The Stedi-assigned unique identifier for the eligibility check, formatted as `ec_`. For example: `id: ec_f81d4fae-7dec-11d0-a765-00a0c91e6b12`.
* `stedi-eligibility-search-id`: A Stedi-assigned identifier that allows Stedi to group eligibility checks for the same patient into a unified record in the Stedi portal called an [eligibility search](/healthcare/eligibility-searches-view). For example: `stedi-eligibility-search-id: 01997873-bebb-7b33-81ef-f408866dfb2cb`.
The response body is a SOAP message, and its structure is similar to the request.
```bash
curl --request POST \
--url "https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core" \
--header "Content-Type: application/soap+xml" \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
YOUR-PAYLOAD-ID
2024-07-29T12:00:00Z
SENDER-ID
RECEIVER-ID
2.2.0
~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~]]>
'
```
```xml
X12_271_Response_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2024-07-28T12:01:22.000Z
RECEIVER_ID
STEDI
2.2.0
~GS*HB*STEDI*117151744*20240326*111000*1*X*005010X279A1~ST*271*1001*005010X279A1~BHT*0022*11*01J2VZA127GH93JT74HJU*20240326*1514~HL*1**20*1~NM1*PR*2*ABCDE*****FI*111000123~PER*IC**TE*123456789*UR*website.company.com~HL*2*1*21*1~NM1*1P*2*ACME HEALTH SERVICES*****XX*1999999984~HL*3*2*22*0~NM1*IL*1*DOE*JANE*A***MI*123456789~REF*6P*123456789*ABCDE~REF*Q4*123456789~N3*1234 FIRST ST~N4*NEW YORK*WV*123451111~DMG*D8*19000101*F~INS*Y*18*001*25~DTP*356*D8*20220102~DTP*346*D8*20240101~DTP*347*D8*20241231~EB*1**30**Open Access Plus~MSG*Complete Care Management~EB*G*FAM*30***23*6000.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*FAM*30***23*500.00*****Y~MSG*Includes services provided by Client Specific Network~EB*G*IND*30***23*3000.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***23*250.00*****Y~MSG*Includes services provided by Client Specific Network~EB*C*FAM*30***23*15000.00*****N~EB*G*FAM*30***23*30000.00*****N~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*A*IND*30*****.10****Y~EB*C*IND*30***23*7500.00*****N~EB*G*IND*30***23*15000.00*****N~MSG*Deductible does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~EB*A*IND*30*****.50****N~EB*1**A7^BC^A8^A4^A5^A6^7^4^BB^22*********W~EB*C*IND*BC^A4^A6^4^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*22~EB*C*IND*A8****0.00****N*Y~MSG*Includes services provided by Client Specific Network~EB*C*IND*A4^A6^4^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*11~EB*C*IND*A4^A6^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*02~EB*B*IND*A4^A6^22***27*20.00****N*Y~III*ZZ*11~EB*A*IND*A4^A6^4^22*****.00***N*Y~III*ZZ*11~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Included For Specific Services~III*ZZ*02~EB*A*IND*A4^A6^22*****.00***N*Y~MSG*Included For Specific Services~III*ZZ*02~EB*A*IND*A4^A6^22*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*02~EB*A*IND*A4^A6^4^22*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*02~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*A*IND*7*****.00***Y*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*CB**7^BB********Y*Y~EB*C*IND*7****0.00****Y*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*11~EB*A*IND*7*****.00***Y*Y~III*ZZ*11~EB*A*IND*4*****.00***N*Y~III*ZZ*22~EB*A*IND*4*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*22~EB*C*IND*BB****0.00****Y*Y~MSG*Includes services provided by Client Specific Network~EB*1**MH~MSG* Provider is out of network based on NPI ID provided in request.~EB*G*FAM*30***29*5760.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*FAM*30***29*500.00*****Y~MSG*Includes services provided by Client Specific Network~EB*G*IND*30***29*2760.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***29*250.00*****Y~MSG*Includes services provided by Client Specific Network~EB*C*FAM*30***29*15000.00*****N~EB*G*FAM*30***29*30000.00*****N~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***29*7500.00*****N~EB*G*IND*30***29*15000.00*****N~MSG*Deductible does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~SE*119*1001~GE*1*1~IEA*1*123456782~]]>
Success
```
### Delimiter normalization [#delimiter-normalization]
Stedi normalizes delimiters in both the JSON and raw X12 responses you receive to ensure consistency and prevent parsing issues. When the following delimiter characters appear within data values - meaning they are used as content - Stedi replaces them as shown:
| Delimiter type | Original | Replaced with |
| --------------------------- | -------- | ------------- |
| Element separator | `*` | `\|` |
| Repetition separator | `^` | `\|` |
| Component element separator | `` ` `` | `'` |
| Segment terminator | `~` | `\|` |
**Examples:**
* `O*CONNOR` becomes `O|CONNOR`
* `CODE^01` becomes `CODE|01`
* ``O`CONNOR`` becomes `O'CONNOR`
* `MSG~HELLO` becomes `MSG|HELLO`
If you parse raw X12 EDI responses, ensure your parser reads delimiters from the `ISA` segment instead of assuming fixed delimiters.
### Retries [#retries]
Implementing the right retry strategy for eligibility check failures saves a lot of time and money.
At a minimum, we **strongly recommend** automatically retrying every request that fails due to payer connectivity issues. Automatic retries resolve a significant portion of these types of failures without manual intervention. Visit [Retry strategy](/healthcare/eligibility-troubleshooting#retry-strategy) for details.
### Timeout [#timeout]
Insurance payers may take up to 60 seconds to respond to a request, but Stedi holds real-time eligibility check requests open for up to 120 seconds before timing out. During this period, Stedi attempts multiple retries to payers in an effort to complete your request.
Canceling and retrying requests before Stedi's automatic retry period ends may create multiple ongoing requests to payers and increase your concurrency usage.
#### Request hedging [#request-hedging]
When eligibility responses are taking too long, you can use request hedging to try to get results faster. To implement request hedging, send a second request at some internal duration cutoff (for example, 30 seconds) without cancelling the first request. Then, you can use whichever result comes back first. If one of the requests fails, you can wait for the second request to see if it's successful.
### Concurrency limit [#concurrency-limit]
Our real-time eligibility check endpoints share a concurrency pool with other real-time healthcare APIs. For more information, visit [Concurrency Limits](/healthcare/api-reference#concurrency-limits).
### Recommended API clients [#recommended-api-clients]
You may want to use an API client to make testing and debugging easier.
We **don't recommend** using Postman for requests containing Protected Health Information (PHI) because Postman defaults to storing request history - including full request payloads - on its cloud servers. You can’t turn this feature off without impractical workarounds.
Visit [API clients](/healthcare/api-reference#api-clients) for a list of recommended clients you can use instead.
## Eligibility check ID [#eligibility-check-id]
Stedi assigns a globally unique identifier to each eligibility check, formatted as `ec_`. For example: `ec_f81d4fae-7dec-11d0-a765-00a0c91e6b12`.
The unique eligibility check ID is returned in the following locations:
* **SOAP:** `stedi-id` header in the HTTP response
* **JSON and Raw X12:** `id` property in the JSON response
You can use this eligibility check ID to debug failures, correlate retries, and link directly to an eligibility check's results in the Stedi portal. The format for direct portal links is: `https://portal.stedi.com/app/healthcare/eligibility/{search-id}/inspect/{check-id}`, where `{search-id}` is the [eligibility search ID](/healthcare/api-reference/post-healthcare-eligibility#response.eligibilitySearchId) and `{check-id}` is the unique Stedi-assigned eligibility check ID.
You can find the eligibility search ID at the top of an eligibility search's details page in the portal. Visit [Eligibility searches](https://portal.stedi.com/app/healthcare/eligibility) to review a list of your eligibility searches.
## Patient information [#patient-information]
Follow this guidance to help payers find the patient in their system.
### Payer search requirements [#payer-search-requirements]
All payers are required to be able to search for patients using the following "bare minimum" subsets of information. They will return benefits information as long as they can find a unique match for the patient within their system.
For a subscriber:
* Member ID, first name, last name, date of birth
* Member ID, last name, date of birth
* Member ID, first name, last name
For a dependent:
* Subscriber member ID (in the `subscriber` object), first name, last name, date of birth
* Subscriber member ID, last name, date of birth
* Subscriber member ID, first name, last name
Of course, not all of this patient information is always available. For example, a patient may forget their ID card. In these instances, some payers may still be able to search with even less information, such as the patient's first name, last name, and date of birth. Contact us if you have questions about alternative search options for a particular payer.
### Dependents [#dependents]
The patient qualifies as a dependent for eligibility checks when:
1. The patient is listed as a dependent on the subscriber's insurance plan.
2. The payer cannot uniquely identify the patient through information outside the subscriber's policy.
When the patient meets these criteria, you should submit their information in the `dependents` array (JSON) or `Loop 2000D` (X12 EDI). Otherwise, you must submit their information in the `subscriber` object (JSON) or `Loop 2000C` (X12 EDI) instead.
For example, if the dependent has their own member ID number in the payer's database, you must identify them as a subscriber. This includes member IDs that differ only by a suffix, such as `01`, because the patient can still be uniquely identified.
#### Medicaid dependents [#medicaid-dependents]
Most Medicaid plans don't support dependents. However, some state Medicaid plans support eligibility inquiries for newborn children under 12 months old.
Children typically must be enrolled in Medicaid as a separate subscriber with their own unique member ID, even if they are legally the dependent of a parent who is a Medicaid plan member. Therefore, you'll almost always need to submit the child as a subscriber in the `subscriber` object (JSON) or `Loop 2000C` (X12 EDI).
Sending the `dependents` array (JSON) or `Loop 2000D` (X12 EDI) to payers that don't support dependents will either cause an error, or the payer may ignore the information and return results for the subscriber instead.
### Patient names [#patient-names]
Note the following information and best practices when entering patient names:
* Enter the name exactly as written on the patient's insurance ID card (if available), including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces. If the patient's insurance ID card isn't available, enter the name exactly as written on a government-issued ID card. If a government ID card isn't available, enter the name exactly as given by the patient.
* Don't include a name prefix, title, rank, honorific, or academic degree in any property. These include Mrs., Dr., Hon., and PhD.
* Don't include a suffix or generation such as Jr. or III in the `firstName` or `lastName` property. Put it in the separate `suffix` property instead. Payers are supposed to automatically parse suffixes out of the last name, but Stedi can't guarantee that all payers will do this correctly.
* You can populate a middle name (or names) or initial in the `middleName` property, but most payers ignore it when searching for the patient.
* Case doesn't matter. For example, JANE is equivalent to Jane.
The following are supported for patient names:
* Compound last and first names separated by spaces or hyphens such as Jean‐Claude or Smith Jones
* Apostrophized or elided names such as O’Connor or D’Amore
* Numbers like 3, however this typically indicates a data entry error
Some payers may have more specific requirements or restrictions that we don't cover in our docs. If you're receiving errors for a specific payer, we recommend consulting that payer's documentation for eligibility checks for additional guidance.
### MBI for CMS checks [#mbi-for-cms-checks]
A Medicare Beneficiary Identifier (MBI) is a unique, randomly-generated identifier assigned to individuals enrolled in Medicare. You must include the patient's MBI in every eligibility check to the Centers for Medicare and Medicaid Services (payer ID: CMS).
Some payers return the patient's MBI in one of the following properties of the standard eligibility response:
* [`benefitsInformation[].benefitsAdditionalInformation.hicNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.benefitsInformation.benefitsAdditionalInformation.hicNumber)
* [`planInformation.hicNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.planInformation.hicNumber)
If the value in either of these properties matches the format specified in the [Medicare Beneficiary Identifier documentation](https://www.cms.gov/training-education/partner-outreach-resources/new-medicare-card/medical-beneficiary-identifiers-mbis), the number is likely an MBI, and we recommend sending a follow-up eligibility check to CMS for additional benefits data. You're most likely to receive an MBI in eligibility check responses from commercial Medicare Advantage plans, but they can also be present in responses from Medicaid plans for dual-eligible patients.
When you don't know a patient's MBI, you can use Stedi's eligibility check APIs to perform an MBI lookup instead of a standard eligibility check. Stedi returns a complete benefits response from CMS with the patient's MBI in the `subscriber` object for future reference. Visit [Medicare Beneficiary Identifier (MBI) lookup](/healthcare/mbi-lookup) for complete details.
**Don't** submit eligibility checks for Medicare Advantage plans to CMS (HETS)
– you should submit them to the actual Medicare Advantage plan payer
instead.
## CMS traceability requirements [#cms-traceability-requirements]
All parties involved in HETS eligibility transactions must comply with the [HETS Rules of Behavior](https://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/hetshelp/downloads/eligibilitytransactionsysteminquiriesrulesofbehavior.pdf). Compliance is also required under our terms. Review the Rules of Behavior before sending eligibility checks to CMS.
Starting November 8, 2025, the Centers for Medicare & Medicaid Services (CMS) requires submitters to include the entire chain of network hops for every eligibility request sent to CMS's eligibility system, HETS.
Specifically, requests must include an `X-Forwarded-For` HTTP header containing the network IP addresses from the point of origin through receipt by the HETS system. CMS expects `X-Forwarded-For` to list each IP, comma-separated, starting with the originating system and continuing through every intermediary.
To comply with this requirement:
* You must collect all IP addresses for upstream requests and pass them in the standard `X-Forwarded-For` header when calling Stedi's API. If you are yourself an intermediary – for example, an RCM, EHR, or PMS system – you'll need to coordinate with your providers and any third-party organizations to ensure they include the Network IP details as part of the `X-Forwarded-For` header. This enables CMS to receive a complete list of all IPs, including the original initiator of the request (typically, the provider).
* Stedi records the IP address you use when you call our API, as well as all the IP addresses listed in the `X-Forwarded-For` header. We include these IP addresses in the list submitted to CMS.
You only need to include the `X-Forwarded-For` header in eligibility requests when there are upstream IP addresses.
The following examples illustrate when and how to include the header:
| Scenario | `X-Forwarded-For` required? | Result |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------- |
| A provider (IP `2.2.2.2`) connects directly to Stedi without intermediaries. | No. | CMS ultimately receives `X-Forwarded-For: 2.2.2.2` |
| A provider (IP `2.2.2.2`) routes through an RCM platform's transactional system (IP `3.3.3.3`) that calls Stedi's API using a separate integration backend (IP `4.4.4.4`). | Yes. The RCM platform sets `X-Forwarded-For: 2.2.2.2, 3.3.3.3`. Stedi records the IP address of the API caller (`4.4.4.4` ) and sends it to CMS. | CMS ultimately receives `X-Forwarded-For: 2.2.2.2, 3.3.3.3, 4.4.4.4`. |
| A provider network (IP `2.2.2.2`) passes through an office firewall (IP `4.4.4.4`) and then an RCM platform (IP `3.3.3.3`), which calls Stedi's API. | Yes. The RCM platform sets `X-Forwarded-For: 2.2.2.2, 4.4.4.4`. Stedi records the IP address of the API caller (`3.3.3.3`) and sends it to CMS. | CMS ultimately receives `X-Forwarded-For: 2.2.2.2, 4.4.4.4, 3.3.3.3`. |
### U.S. IP address requirement [#us-ip-address-requirement]
Stedi blocks eligibility requests to CMS when any IP address in the chain – the originating IP address or any in the X-Forwarded-For header – is located outside the United States.
# Stedi Agent
Source: https://www.stedi.com/docs/healthcare/stedi-agent
The Stedi Agent is an AI assistant that helps you resolve common issues with eligibility checks and answers questions about supported payers.
The Stedi Agent is available in the Stedi portal for all plans. To use it, you must be at least an [Operator](/healthcare/accounts-and-billing#members) role within your Stedi account.
## Resolve failed eligibility checks [#resolve-failed-eligibility-checks]
You can use the Stedi Agent to troubleshoot and resolve common recoverable eligibility check errors automatically.
To resolve an eligibility check failure with the Stedi Agent:
1. Go to the [Eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility).
2. Click **Resolve with Stedi Agent** next to an eligibility search. This is button is only available next to eligibility searches with common recoverable errors.
3. The Stedi Agent opens a side panel in Debug view.
4. The Stedi Agent analyzes the eligibility request and works through best practice recovery strategies based on the error type. For example, if the payer returned an error code `75` (Subscriber/Insured Not Found), the agent may try different combinations of patient data or adjust the name format to find a match in the payer's system.
Each time the agent retries the eligibility check, it stores the new request in the same eligibility search record and it shows up in Debug view in real time. This allows you to see the history of attempts and the progression of the agent's troubleshooting efforts.
The agent only accesses data from the eligibility search it's working on. It can't access data from other searches, customers, or systems.
## Get payer details [#get-payer-details]
The Stedi Agent can answer your questions about supported payers. It can help you:
* Find the payer ID for supported payers.
* Map your internal payer names to Stedi's supported payers.
* Determine which payers require [transaction enrollment](/healthcare/transaction-enrollment).
* Identify which payers support medical, dental, or both use cases.
* Get help with other payer-related questions.
To start chatting with the Stedi Agent:
1. Go to the [Chats page](https://portal.stedi.com/app/healthcare/chats) in the Stedi portal.
2. Click **New chat** and select **Payer Finder**.
3. Type your question in the chat window and press **Enter.** For example, you could ask "What is the payer ID for Aetna?" or "Does Cigna support dental use cases?" You can also ask more complex questions, like "Which payers support dental use cases and require transaction enrollment?" Talk to Stedi Agent like you would a human support agent.
4. Ask follow-up questions as needed. You can ask multiple questions about different payers in the same chat.
The Stedi Agent will respond to your questions and display its answers in the chat window.
## Review chat history [#review-chat-history]
You can review a list of all past chats with the Stedi Agent on the [Chats page](https://portal.stedi.com/app/healthcare/chats) in the Stedi portal. Click any chat to open it and review the conversation history. You can restart any previous chat by sending a new message.
The chat history contains both your conversations about payer details and any recovery attempts the agent made while troubleshooting eligibility check failures.
## Usage notes [#usage-notes]
Please note:
* The Stedi Agent is available on all paid Stedi plans at no additional cost beyond those for related API calls.
* The agent is assistive. Outputs can be incorrect or incomplete. Verify all responses before taking any action based on them.
* You are responsible for any actions you instruct or authorize the AI service to take, including generating billable requests on your behalf.
* Your chats with the Stedi Agent aren't private - they're visible to anyone with access to your Stedi account.
## Stedi Agent vs. MCP server [#stedi-agent-vs-mcp-server]
The Stedi Agent and the Model Context Protocol (MCP) server can both help you resolve failed eligibility checks and find payer information, but they serve different use cases.
* The [Stedi Agent](/healthcare/stedi-agent) is a Stedi-controlled, AI assistant within the Stedi portal. It's ready to use whenever you need it. Unlike the MCP server, you can't manage or invoke the Stedi Agent programmatically - you can only use it within the Stedi portal. The Stedi Agent is built on top of the MCP server, meaning it uses the MCP server's exposed tools to perform actions.
* The [MCP Server](/healthcare/mcp-server) provides a set of tools, which are a wrapper around Stedi's APIs, that AI agents can use to find payer information and perform and troubleshoot eligibility checks. The MCP server includes the same retry logic (in a prompt) that the Stedi Agent uses to automatically resolve eligibility check failures.
You can use the MCP server to build your own AI agents tailored to your use case. Unlike the Stedi Agent, you'll need to install and configure the MCP server for your preferred AI agent.
# Claim attachments
Source: https://www.stedi.com/docs/healthcare/submit-claim-attachments
Claim attachments are additional documents that help justify or validate a claim. They're typically required when the claim alone doesn't provide enough information for the payer to make a decision, such as when a procedure is unusual, high-cost, or uses an unlisted code.
Attachments can include medical records, treatment plans, radiographs, photographs, itemized bills, and letters from providers - the type required for each claim depends on the services listed and the payer's rules. For example, a claim for a dental crown may require X-rays, while a claim for a surgery may require an operative report.
You can submit [unsolicited 275 claim attachments](#solicited-vs-unsolicited-attachments) for professional, dental, and institutional claims in either JSON or X12 EDI format. For professional claims you can also submit attachments through the Stedi portal.
## Supported payers [#supported-payers]
You can check which payers support 275 claim attachments using the [Payer Network](https://www.stedi.com/healthcare/network) or the [Payers API](/healthcare/api-reference/get-payer). If you try to submit claim attachments to a payer that doesn't support them, Stedi blocks the submission before it reaches the payer:
* **APIs:** When you submit a claim with attachments to an unsupported payer, Stedi returns a `400` HTTP error with an explanatory error message. For example:
```json
{
"code": "TRANSACTION_TYPE_NOT_SUPPORTED",
"message": "Payer 62308 (Stedi Payer ID HGJLR) is not configured for Unsolicited Claim Attachment (275). Please check our published payer list or contact Stedi support to resolve."
}
```
* **SFTP:** When you submit a claim with attachments to an unsupported payer, Stedi rejects it with a [277CA claim acknowledgment](/healthcare/claim-responses-overview#277ca-claim-acknowledgment) explaining the issue. For example:
```
STC*A7:N21*[DATE]*PR*[AMOUNT]********Payer 62308 (Stedi Payer ID HGJLR) is not configured for Unsolicited Claim Attachment (275). Please check our published payer list or contact Stedi support to resolve.~
```
When Stedi doesn't support attachments, you can submit them outside of Stedi - for example, directly to the payer's portal. Then, you can reference them in the claims you submit through Stedi. Contact [Stedi Support](https://www.stedi.com/contact) with questions about supported payers or for help optimizing your attachments workflow.
## Transaction enrollment [#transaction-enrollment]
[Transaction enrollment](/healthcare/transaction-enrollment) is the process of registering a provider to exchange specific healthcare transactions with a payer. Some payers require enrollment before allowing providers to submit 275 claim attachments. When required, this enrollment process is separate from the transaction enrollment process for 837 claims.
You can check whether a specific payer requires transaction enrollment for 275 attachments in the [Payer Network](https://www.stedi.com/healthcare/network) or through the [Payers API](/healthcare/api-reference/get-payer).
To enroll, complete the following steps:
1. Create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step. [Stedi portal](https://portal.stedi.com/app/healthcare/providers) | [API endpoint](/healthcare/api-reference/post-enrollment-create-provider)
2. Submit an enrollment request for the type of claim attachments you plan to send (solicited or unsolicited). [Stedi portal](https://portal.stedi.com/app/healthcare/enrollments) | [API endpoint](/healthcare/api-reference/post-enrollment-create-enrollment)
## Submit claim attachments [#submit-claim-attachments]
Unsolicited 275 claim attachments are a separate transaction type from 837 claims. They're linked to the claim through [specific identifiers](#reference-attachments-in-a-claim) that indicate an attachment will follow the claim submission.
The submission methods available for 275 claim attachments depend on the claim type:
* **Professional claim attachments:** [claim form UI](#claim-form-ui), [JSON APIs](#json-apis), [X12 EDI APIs](#x12-edi-apis), and [SFTP](#sftp)
* **Dental claim attachments:** [JSON APIs](#json-apis), [X12 EDI APIs](#x12-edi-apis), and [SFTP](#sftp)
* **Institutional claim attachments:** [JSON APIs](#json-apis), [X12 EDI APIs](#x12-edi-apis), and [SFTP](#sftp)
### Claim form UI [#claim-form-ui]
You can submit attachments through the Stedi portal at the same time you are manually submitting a professional claim. The claim submission UI is based on the CMS-1500 Claim Form. Visit [Submit professional claims](/healthcare/submit-professional-claims#ui-submission) for instructions.
UI attachment submission isn't supported for dental or institutional claims.
### JSON APIs [#json-apis]
You can submit [unsolicited claim attachments](#solicited-vs-unsolicited-attachments) through Stedi JSON APIs for all claim types. Submitting claim attachments in JSON requires three steps:
Call the [Create Claim Attachment (275) JSON](/healthcare/api-reference/post-healthcare-create-claim-attachment) endpoint to receive a pre-signed URL that you can use to upload the attachment file to Stedi.
The response also contains an `attachmentId` that you'll include in the claim submission.
Use a `PUT` request to upload the attachment file to the pre-signed URL (`uploadUrl`) in the response. The request must include a `Content-Type` header that matches the MIME type you specified for the attachment file.
The following example shows how to upload a JPEG attachment:
```bash
curl --request PUT \
--url "" \
--header "Content-Type: image/jpeg" \
--upload-file /path/to/file.jpeg
```
We recommend limiting attachments to 64MB each, but some payers may have different size requirements. When in doubt, check the payer's documentation to determine their specific limits. Stedi stores uploaded files for 45 days. After that, you must reupload the attachment file before you can submit it to the payer.
Call one of the following claim submission endpoints:
* [Professional Claims JSON](/healthcare/api-reference/post-healthcare-claims)
* [Dental Claims JSON](/healthcare/api-reference/post-healthcare-dental-claims)
* [Institutional Claims JSON](/healthcare/api-reference/post-healthcare-institutional-claims)
You must include [specific properties](#reference-attachments-in-a-claim) in your request to identify the attachment and tell Stedi which attachment file to use. These properties are `attachmentReportTypeCode`, `attachmentTransmissionCode`, and `attachmentId`.
Stedi sends the claim and the claim attachment to the payer and then returns summary information about the claim submission.
The payer processes the claim and attachment together, and sends back [277CA and 835 ERA responses](/healthcare/submit-claim-attachments#payer-responses).
### X12 EDI APIs [#x12-edi-apis]
You can submit [unsolicited claim attachments](#solicited-vs-unsolicited-attachments) through Stedi X12 EDI APIs for all claim types. This approach is useful when you have an existing system that generates X12 EDI files and you want to send them through Stedi.
With X12 EDI submissions, you don't need to upload the attachment file to Stedi first - you can send the entire 275 transaction directly to the payer. Submitting claim attachments through our X12 EDI APIs requires two steps:
Call one of the following endpoints:
* [Professional Claims Raw X12](/healthcare/api-reference/post-healthcare-claims-raw-x12)
* [Dental Claims Raw X12](/healthcare/api-reference/post-healthcare-dental-claims-raw-x12)
* [Institutional Claims Raw X12](/healthcare/api-reference/post-healthcare-institutional-claims-raw-x12)
In addition to the claim information, you must include [specific elements](#reference-attachments-in-a-claim) in either `Loop 2300` or `Loop 2400` (professional claims only) to identify the attachment. These elements are `PWK01`, `PWK02`, and `PWK06`.
Only include attachment details when you plan to submit an attachment. Some payers stall claim processing indefinitely if you include a `PWK` segment without sending an associated attachment.
Call the [Submit Claim Attachment (275) X12 EDI](/healthcare/api-reference/post-healthcare-submit-claim-attachment-raw-x12) endpoint. Stedi sends the 275 transaction to the payer and returns summary information about the submission.
* **Payer ID:** You must submit a payer identifier in `Loop 1000A NM109` so Stedi can route the attachment to the correct payer. This identifier **must** be a payer ID or payer ID alias listed in the [Payer Network](https://www.stedi.com/healthcare/network). For example, you could use `60054`, `HPQRS`, `AETNA`, or any other listed payer ID alias for Aetna.
* **Attachment Control Number:** You must also submit the attachment control number in `Loop 2000A TRN02` (Attachment Control Number). It should match the value you submitted in the claim's `Loop 2300` or `Loop 2400` `PWK06` element. This is how Stedi and the payer match the attachment with the claim.
The size limit for attachments submitted in a single API request is 6MB. If you need to submit larger attachment files, you must submit them through Stedi SFTP or the JSON endpoints.
Once received, the payer processes the claim and attachment together and sends back [277CA and 835 ERA responses](/healthcare/submit-claim-attachments#payer-responses).
### SFTP [#sftp]
You can submit [unsolicited claim attachments](#solicited-vs-unsolicited-attachments) in X12 EDI format through SFTP for all claim types.
SFTP submission is ideal if you need to send institutional claim attachments or you have attachments that are larger than 6MB.
Submitting claim attachments through SFTP requires sending two transactions to the payer. You can send these transactions as separate files or together in the same file as long as the claim and the attachment are within the same interchange (`ISA`/`IEA`) envelope:
Submit an 837 professional, dental, or institutional claim to the payer through [Stedi SFTP](/healthcare/submit-claims-sftp-connection#837-claims).
You must include specific elements in either `Loop 2300` or `Loop 2400` (professional claims only) to identify the attachment. These elements are `PWK01`, `PWK02`, and `PWK06`.
Only include attachment details when you plan to submit an attachment. Some payers stall claim processing indefinitely if you include a `PWK` segment without sending an associated attachment.
Submit a 275 claim attachment to the payer through [Stedi SFTP](/healthcare/submit-claims-sftp-connection#275-claim-attachments).
* **Payer ID:** You must submit a payer identifier in `Loop 1000A NM109` so Stedi can route the attachment to the correct payer. This identifier **must** be a payer ID or payer ID alias listed in the [Payer Network](https://www.stedi.com/healthcare/network). For example, you could use `60054`, `HPQRS`, `AETNA`, or any other listed payer ID alias for Aetna.
* **Attachment Control Number:** You must also submit the attachment control number in `Loop 2000A TRN02` (Attachment Control Number). It should match the value you submitted in the claim's `Loop 2300` or `Loop 2400` `PWK06` element. This is how Stedi and the payer match the attachment with the claim.
We recommend limiting attachments to 64MB each, but some payers may have different size requirements. When in doubt, check the payer's documentation to determine their specific limits.
Once received, the payer processes the claim and attachment together and sends back [277CA and 835 ERA responses](/healthcare/submit-claim-attachments#payer-responses).
## Reference attachments in a claim [#reference-attachments-in-a-claim]
To submit an unsolicited claim attachment, you must submit a claim that references the attachment(s) in the appropriate location. When submitting claims through Stedi APIs or SFTP, include the following properties or elements to identify the attachment(s).
If you're submitting claims manually, visit [Submit professional claims](/healthcare/submit-professional-claims#ui-submission) for instructions.
### Attachment level [#attachment-level]
You can specify attachments that relate to the entire claim or to a specific service line.
#### Entire claim [#entire-claim]
For professional, dental, and institutional claims, you can specify claim-level attachments in the `claimInformation.claimSupplementalInformation.reportInformation` object or the `claimInformation.claimSupplementalInformation.reportInformations` array (for multiple attachments). These structures correspond to segment `PWK` in `Loop 2300`.
API reference docs: [professional](/healthcare/api-reference/post-healthcare-claims#body.claimInformation.claimSupplementalInformation.reportInformation) | [dental](/healthcare/api-reference/post-healthcare-dental-claims#body.claimInformation.claimSupplementalInformation.reportInformation) | [institutional](/healthcare/api-reference/post-healthcare-institutional-claims#body.claimInformation.claimSupplementalInformation.reportInformation)
#### Service line [#service-line]
* **Professional claim attachments:** Specify service line attachments in the `claimInformation.serviceLines[].serviceLineSupplementalInformation` array. This array corresponds to segment `PWK` in `Loop 2400`.
API reference docs: [professional](/healthcare/api-reference/post-healthcare-claims#body.claimInformation.serviceLines.serviceLineSupplementalInformation)
* **Institutional claim attachments:** For institutional claims, you can specify service line attachments in the `claimInformation.serviceLines[].serviceLineSupplementalInformation` object or the `claimInformation.serviceLines[].serviceLineSupplementalInformations` array (for multiple attachments). These structures correspond to segment `PWK` in `Loop 2400`.
API reference docs: [institutional](/healthcare/api-reference/post-healthcare-institutional-claims#body.claimInformation.serviceLines.serviceLineSupplementalInformation)
### Required properties [#required-properties]
Both claim and service line attachments require the following properties to inform the payer that an attachment will follow the claim submission.
Only include attachment details when you plan to submit an attachment. Some payers stall claim processing indefinitely if you include attachment details but don't send an associated attachment.
{/* prettier-ignore-start */}
| JSON property | X12 EDI | Description |
| ---------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `attachmentReportTypeCode` | `PWK01` | This code identifies the type of report or document you plan to submit as an attachment. Visit [Code lists](/healthcare/claims-code-lists#attachment-report-type-codes) for a complete list of valid codes. |
| `attachmentTransmissionCode` | `PWK02` | Set to `EL` when submitting attachments through Stedi. This property indicates the attachment will be sent in a separate, electronic 275 transaction. |
{/* prettier-ignore-end */}
You must also include **one** of the following properties, depending on your use case. Specifically, you should only include the attachment control number when you're not submitting the attachment file through Stedi (for example, you submitted the attachment directly through a payer's portal). Otherwise, include the attachment ID.
{/* prettier-ignore-start */}
| JSON property | X12 EDI | Description |
| ------------------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `attachmentControlNumber` | `PWK06` | A unique identifier for the attachment. The payer uses this value to match the attachment to the claim. We recommend using a ULID or UUID of up to 50 characters.- X12 EDI submissions: This property is **required**.
- JSON submissions: Only include this property when you aren't submitting the attachment file through Stedi's API. For example, you submitted the attachment directly through a payer's portal.
|
| `attachmentId` | - | The attachment ID you received in the [Create Claim Attachment (275) JSON](/healthcare/api-reference/post-healthcare-create-claim-attachment) response. It tells Stedi which file to use when generating the 275 transaction for the payer. This property is **required** if you're submitting attachments through a JSON endpoint. |
{/* prettier-ignore-end */}
## Reference the claim in attachments [#reference-the-claim-in-attachments]
275 attachment transactions must include an identifier that allows the payer to match it with the associated 837 claim.
{/* prettier-ignore-start */}
| Submission method | Identifier | Description |
| ----------------- | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| JSON APIs | - | You don't need to supply your own identifier. The [Create Claim Attachment (275) JSON](/healthcare/api-reference/post-healthcare-create-claim-attachment) endpoint returns an `attachmentId` that you include in the claim submission. |
| X12 EDI and SFTP | `Loop 2000A TRN02` (Attachment Control Number) | The `TRN02` value must match the `PWK06` (Attachment Control Number) in the claim. |
{/* prettier-ignore-end */}
## Solicited vs. unsolicited attachments [#solicited-vs-unsolicited-attachments]
There are two types of claim attachments:
* **Solicited:** The payer requests attachments for a submitted claim in a Request for Additional Information (277 RFA) transaction. In these cases, you must submit the attachment(s) in a separate 275 transaction that references the 277 RFA.
* **Unsolicited:** The provider proactively sends attachments at their discretion without a prior request from the payer. In these cases, you must [reference the attachment(s) in the claim submission](/healthcare/submit-claim-attachments#reference-attachments-in-a-claim).
You can only submit unsolicited claim attachments through Stedi APIs and SFTP. Check the [Payer Network](https://www.stedi.com/healthcare/network?query=eyIyNzAiOnt9LCIyNzYiOnt9LCI4MzUiOnt9LCI4MzdQIjp7fSwiODM3SSI6e30sIjgzN0QiOnt9LCJDT0IiOnt9LCIyNzVTIjp7ImlzU3VwcG9ydGVkIjp0cnVlfSwiMjc1VSI6eyJpc1N1cHBvcnRlZCI6dHJ1ZX19\&page=0) to determine which payers support attachments.
## Payer responses [#payer-responses]
The payer processes claims and claim attachments together. When you submit a claim attachment, you'll receive the same [277CA and 835 ERA responses](/healthcare/receive-claim-responses#retrieve-responses-from-stedi) for the claim as you would for a regular claim submission.
If a claim is rejected, pended, or denied due to issues with attachments, you'll likely receive error codes in the 277CA response that indicate the issue. However, the exact error codes used depend on the payer's system and how they handle attachments.
## Concurrency limit [#concurrency-limit]
Claim attachment endpoints share a concurrency pool with other claim endpoints. For more information, visit [Concurrency limits](/healthcare/api-reference#concurrency-limits).
# Submit claims through SFTP
Source: https://www.stedi.com/docs/healthcare/submit-claims-sftp-connection
You can use Stedi's fully-managed SFTP server to submit claims - including 275 claim attachments - to payers and retrieve responses without calling Stedi APIs.
You must submit claims and attachments in X12 EDI format, and Stedi returns claim responses through the SFTP connection in X12 EDI format. This makes Stedi SFTP a good option if you have an existing system that generates X12 EDI files and you want to send them through Stedi without completing an API integration.
## How SFTP connections work [#how-sftp-connections-work]
Use the following process to submit claims to Stedi:
1. Create SFTP users through the [SFTP setup](https://portal.stedi.com/app/settings/sftp) page in your account. You'll use these credentials to connect to Stedi's SFTP server.
2. Connect to Stedi's server and drop X12 EDI claim files into the `to-stedi` directory.
3. Stedi automatically validates the claim data and uses the Interchange Usage Indicator field (`T` or `P`) to determine whether each file contains a test or a production claim. If there are no validation errors, Stedi routes your claims to the test or production clearinghouse accordingly.
4. Stedi places claim responses - 277CA claim acknowledgments and 835 Electronic Remittance Advice (ERAs) - into the `from-stedi` directory in X12 EDI format. You can retrieve these responses from the directory at your preferred cadence without setting up webhooks or calling Stedi APIs.
Stedi shows all claims and claim responses sent through the SFTP connection on the [Files](https://portal.stedi.com/app/core/file-executions) and [Transactions](https://portal.stedi.com/app/core/transactions) pages in the UI. This allows you to review your claim submissions, quickly find related responses, and download transaction data.
## Before sending claims [#before-sending-claims]
You may need to complete the following steps before sending claims.
### Transaction enrollment [#transaction-enrollment]
[Transaction enrollment](/healthcare/transaction-enrollment) is the process of registering a provider to exchange specific healthcare transactions with a payer. Some payers require enrollment before allowing providers to submit 837 claims through a new clearinghouse.
Enrolling through Stedi may cancel existing claims enrollments you have through other clearinghouses. We can help you determine whether this applies to your specific payers. However, enrolling through Stedi for 837 claims doesn't affect your existing enrollments for other transaction types. For example, enrolling with Stedi won't unenroll the provider from receiving transactions like Electronic Remittance Advices (ERAs) through other clearinghouses.
You can check whether a specific payer requires transaction enrollment for 837 claims in the [Payer Network](https://www.stedi.com/healthcare/network) or through the [Payers API](/healthcare/api-reference/get-payer).
To enroll, complete the following steps:
1. Create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step. [Stedi portal](https://portal.stedi.com/app/healthcare/providers) | [API endpoint](/healthcare/api-reference/post-enrollment-create-provider)
2. Submit an enrollment request for the claim type. [Stedi portal](https://portal.stedi.com/app/healthcare/enrollments) | [API endpoint](/healthcare/api-reference/post-enrollment-create-enrollment)
### Coordination of benefits check [#coordination-of-benefits-check]
We recommend running a coordination of benefits (COB) check to ensure you submit claims to the correct payer. COB checks can help you determine:
* If a patient is covered by more than one health plan
* Whether coverage overlap requires coordination of benefits
* Each payer’s responsibility for payment (primacy) in coordination of benefits scenarios
Visit [Coordination of benefits (COB) checks](/healthcare/coordination-of-benefits) for more information.
## Create SFTP users [#create-sftp-users]
Go to the [SFTP setup](https://portal.stedi.com/app/settings/sftp) page in your account settings to create SFTP users.
You can create either test or production users.
* Test users can only send claims with the Usage Indicator Code set to `T` (test). These claims are only sent to Stedi's test clearinghouse and not to the payer. Note that you will receive a 277 Claim Acknowledgment for test claims, but you will not receive an 835 ERA.
* Production users can only send claims with the Usage Indicator Code set to `P` (production). These claims are sent through Stedi's production clearinghouse to the payer.
## Connect to Stedi's server [#connect-to-stedis-server]
Use your user credentials to connect to Stedi's SFTP server at `transfer.us.stedi.com` using Port 22.
### Static IPs [#static-ips]
You can use these static IP addresses to allowlist Stedi's server:
`18.119.51.218` and `18.206.132.233`
## Format X12 EDI files [#format-x12-edi-files]
You must drop claims and claim attachments into the `to-stedi` directory in X12 EDI format. Stedi validates the claims and routes them to the appropriate clearinghouse based on the `ISA15` Interchange Usage Indicator element.
### 837 claims [#837-claims]
Claims must adhere to the following X12 HIPAA claim specifications:
* [837 Claim: Professional (X222A1)](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-professional-x222a1/01HR60MDFAGCSEJNKY8J38867Y)
* [837 Claim: Institutional (X223A2)](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-institutional-x223a2/01JBHW2YXMN2F9KXK2PS0BFP9F)
* [837 Claim: Dental (X224A2)](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-dental-x224a2/01JCJZ46AEK835RYV1BXQNBPK8)
We recommend submitting one claim per file to make troubleshooting easier. However, an EDI Interchange can contain multiple transactions, so you can submit multiple claims within a single file if needed. Regardless of how many claims you submit in a file, Stedi processes each claim individually and returns each claim response as a separate file.
#### Payer ID [#payer-id]
You must submit a payer identifier in `Loop 2010BB` (Payer Name) `NM109` so Stedi can route your claim to the correct payer. This identifier **must** be a payer ID or payer ID alias listed in the [Payer Network](https://www.stedi.com/healthcare/network). If you don't already have payer IDs you use today, we recommend using the primary Payer ID.
You must include leading `0` characters in payer IDs. For example, use `00540` for SISCO, not `540`.
#### Group Control Number [#group-control-number]
Each claim should have a unique value in `GS06` (Group Control Number), so you can correlate [999 Implementation Acknowledgments](#999-implementation-acknowledgment) with the original claim submission.
Stedi returns an error 999 when it rejects a claim due to X12 EDI validation errors. Without a unique `GS06`, you won't be able to determine which claim was rejected.
#### Patient Control Number [#patient-control-number]
We recommend including a unique value in `CLM01` (Patient Control Number) for each claim. This value is returned in both the 277 Claim Acknowledgment and 835 ERA responses, so you can use it to correlate responses with the original claim.
#### Bulk claims [#bulk-claims]
You can submit multiple claims in the same 837 transaction by including multiple instances of the following loops:
* `Loop 2000A` (Billing Provider)
* `Loop 2000B` (Subscriber)
* `Loop 2300` (Claim Information)
After submission, Stedi separates your bulk 837 transaction into individual claims and sends each claim separately to the payer. This includes multiple claims going to the same payer - all claims within a bulk submission are sent individually to maintain consistency.
The following example would produce 12 separate claims (2 x 3 x 2 = 12):
* 837 transaction contains information for two billing providers (2x `Loop 2000A`)
* Each billing provider has three subscribers (3x `Loop 2000B`)
* Each subscriber has two claims (2x `Loop 2300`)
By default, Stedi returns one 999 Implementation Acknowledgment when one or more transactions in the bulk 837 fail validation. 999s for fully accepted bulk transactions are opt-in only - visit [Monitor for 999 rejections](#monitor-for-999-rejections-strongly-recommended) for details.
Then, you'll typically receive separate 277CA claim acknowledgments *for each claim*. Note that Stedi sends accepted claims to the payer, even if other claims within the batch fail our validation. You should monitor for [277CA rejections](#277ca-claim-acknowledgment) and resubmit those claims accordingly.
Each claim will also receive its own test ERA from Stedi's test clearinghouse if the payer was `STEDITEST`. Visit [Test claims workflow](/healthcare/test-claims-workflow#generate-test-eras) for details.
You'll be billed per claim submitted, not per bulk 837 transaction. For
example, if you submit a bulk 837 transaction with 10 claims, you'll be billed
for 10 claims.
### 275 claim attachments [#275-claim-attachments]
Before you can submit an attachment, you must first submit a claim that references the attachment(s) in the appropriate location. Visit [Claim attachments](/healthcare/submit-claim-attachments) for complete instructions.
Claim attachments must adhere to the [275 Patient Information (X210)](https://portal.stedi.com/app/guides/view/hipaa/patient-information-x210/01HQ4HZ8ZBY2CZGPCVVM8JTK22) X12 HIPAA specification.
* **Payer ID:** You must submit a payer identifier in `Loop 1000A NM109` so Stedi can route the attachment to the correct payer. This identifier **must** be a payer ID or payer ID alias listed in the [Payer Network](https://www.stedi.com/healthcare/network). For example, you could use `60054`, `HPQRS`, `AETNA`, or any other listed payer ID alias for Aetna. You must include leading `0` characters - for example, use `00540` for SISCO, not `540`.
* **Attachment Control Number:** You must also submit the attachment control number in `Loop 2000A TRN02` (Attachment Control Number). It should match the value you submitted in the claim's `PWK06` element. This is how Stedi and the payer match the attachment with the claim.
We recommend limiting attachments to 64MB each, but some payers may have different size requirements. When in doubt, check the payer's documentation to determine their specific limits. This limit is per attachment file - you can submit multiple attachment files in each 275 transaction.
### Envelope and header [#envelope-and-header]
You can submit transactions with any values in the `ISA` and `GS` envelope, as long as they conform to the X12 EDI specification.
However, you must set `ST03` to the appropriate value for the transaction type:
* 837P professional claims: `005010X222A1`
* 837I institutional claims: `005010X223A2`
* 837D dental claims: `005010X224A2`
* 275 claim attachments: `005010X210`
If your system requires you to send unique values in the `ISA` and `GS`
envelope, you can find suggested configurations for each transaction type on
the [SFTP setup page](https://portal.stedi.com/app/settings/sftp) under **ISA
settings**.
## Send claims and attachments [#send-claims-and-attachments]
You can drop claim and attachment files into the `to-stedi` directory. Stedi automatically validates the claim data and then routes each claim to the appropriate clearinghouse (test or production).
Stedi deletes files from the `to-stedi` directory after processing them to avoid duplicate claim submissions.
## Monitor for 999 rejections (strongly recommended) [#monitor-for-999-rejections-strongly-recommended]
When one or more transactions fail Stedi's validation, Stedi returns a [999 Implementation Acknowledgment](https://portal.stedi.com/app/guides/view/hipaa/implementation-acknowledgment-x231a1/01HMRQV0N8SPHG58M4ZG1CRHH0) within minutes of the file submission. The 999 indicates that at least one transaction in the file was rejected for processing; other transactions in the same file may still be accepted and sent to the payer.
We strongly recommend monitoring for these error 999s that indicate rejections. Otherwise, your claim and attachment submissions may silently fail because Stedi doesn't send rejected transactions to the payer.
By default, you'll only receive 999s when Stedi rejects one or more transactions in a functional group. You can opt in to receive 999s for fully accepted functional groups as well. To update your 999 settings in the Stedi portal:
1. Go to the [SFTP setup page](https://portal.stedi.com/app/settings/sftp) in your account settings.
2. Under **999 settings**, select **All 999s**.
A 999 doesn't indicate whether the payer accepted or rejected your claim. For that information, check the [277CA claim acknowledgment](#277ca-claim-acknowledgment) response from the payer.
#### Interpret 999s [#interpret-999s]
Check `AK901` (Functional Group Acknowledge Code). The 999 will contain one `AK901` element for each functional group in the file.
* **Receipt acknowledgment 999:** `AK901` is set to `A` for Accepted. Stedi accepted all transactions in the functional group for processing and sent them to the payer.
* **Error 999:** `AK901` is set to either `R` for Rejected or `P` for Partially Accepted. Stedi rejected at least one transaction in the functional group due to X12 EDI validation errors. For each transaction, the 999 will include `Loop 2000` (Transaction Set Response Header). Within that loop, check `IK501` (Transaction Set Acknowledgment Code).
* Accepted transactions have `IK501` set to `A`. Stedi sends accepted transactions to the payer, so you only need to correct and resubmit the rejected ones.
* Rejected transactions have `IK501` set to `R`. For rejected transactions, Stedi lists the validation errors in `Loop 2100` (Error Identification). You must correct the errors and resubmit.
#### Correlate 999s with claim [#correlate-999s-with-claim]
Use `AK102` (Group Control Number) to correlate the 999 with the original claim. It contains the same value you supplied in the claim's `GS06` (Group Control Number). For this reason, you should always use a unique value in `GS06` for each claim.
## Set up webhooks [#set-up-webhooks]
Stedi emits events when it processes claims and claim responses.
* **File delivered:** Emitted when Stedi successfully processes your claim and delivers it to our connection with the payer. Note that this event doesn’t indicate whether the payer received the claim or whether they have accepted or rejected it.
* **Transaction processed:** Emitted when Stedi successfully receives and processes a payer or intermediary clearinghouse response, such as an 835 ERA. These events are also emitted when Stedi successfully processes claims you submit through the SFTP connection.
You can set up [webhooks](/healthcare/configure-webhooks) for these events to get real-time notifications when Stedi processes your claims and claim responses.
## Retrieve claim responses [#retrieve-claim-responses]
You can retrieve claim responses at your preferred cadence from the `from-stedi` directory. These responses are in X12 EDI format.
* You'll first receive a 999 Implementation Acknowledgment from Stedi if any transaction in your submission was rejected (including partial rejections). We strongly recommend [monitoring 999s for rejections](#monitor-for-999-rejections-strongly-recommended).
* Once Stedi accepts your claim, you may receive 277 Claim Acknowledgment and 835 Health Care Claim Payment/Advice (ERA) responses.
X12 EDI specifications: [999](https://portal.stedi.com/app/guides/view/hipaa/implementation-acknowledgment-x231a1/01HMRQV0N8SPHG58M4ZG1CRHH0) | [277](https://portal.stedi.com/app/guides/view/hipaa/claim-acknowledgment-x214/01HACJ4MNFWR3GV3BCVAMG04PK) | [835](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-paymentadvice-x221a1/01GRYB6DS30MGXWBPFZCM3695E)
### 277CA claim acknowledgment [#277ca-claim-acknowledgment]
The 277CA indicates whether a claim was accepted for processing or rejected due to correctable errors, such as invalid data, missing information, or failure to comply with payer-specific rules.
A rejection is different from a denial. Claims are denied during adjudication, so you'll only see denial statuses in the 835 Electronic Remittance Advice (ERA). A 277CA rejection indicates that the claim never made it to the adjudication step. In these cases, the 277CA will include error codes and descriptions to help you correct the issues before resubmitting the claim.
You may receive multiple 277CAs for each claim you submit. You should monitor these 277CAs to track the claim's status as it moves through Stedi and the payer's systems:
* **Clearinghouse:** You'll receive the first 277CA from Stedi within about 30 minutes of submitting the claim to indicate whether we have accepted or rejected it. You may receive additional 277CAs as we route the claim to the payer.
* **Payer:** You may receive one or more 277CAs from the payer. Typically, there is one 277CA that indicates receipt of the claim and a second 277CA that contains summary counts of transactions received, information about accepted transactions, and details for rejected transactions.
Each 277CA typically correlates to one 837 claim. However:
* Some payers may send a single 277CA that [references multiple claims](/healthcare/receive-claim-responses#correlate-277ca).
* Payers sometimes split a single claim into multiple claims during processing. In these cases, you may receive multiple 277CAs from the payer for the original claim you submitted.
* Payers may send another 277CA when they forward a claim to a secondary payer in a coordination of benefits scenario.
* (SFTP only) When you submit a [bulk claim](/healthcare/submit-claims-sftp-connection#bulk-claims), you'll typically receive one 277CA per claim. For example, if you submit a bulk transaction containing information for 10 claims, you'll typically receive 10 separate 277CAs.
#### Determine sender [#determine-sender]
To determine whether a 277CA is from a clearinghouse or the payer:
* **JSON:** Check the [`transactions[].payers` array](https://www.stedi.com/docs/healthcare/api-reference/get-healthcare-reports-277#response.transactions.payers) in the report (`Loop 2100A`). The `organizationName` property contains the name of the sender (for example, CIGNA or STEDI).
* **X12 EDI:** Check `Loop 2100A NM103` (Information Source Name).
You can also find this information in the Stedi portal:
1. Go to the [claims view](https://portal.stedi.com/app/healthcare/claims).
2. Find the associated claim and click it to view the claim timeline.
3. Find the 277CA in the timeline view. The **From** field indicates whether the acknowledgment is from Stedi or the payer.
#### 277CA vs. claim status check [#277ca-vs-claim-status-check]
The 277CA contains different information than a real-time claim status check. Specifically:
* **277CAs**: Tell you whether the payer has received a claim and accepted it for processing. If the claim was rejected, 277CAs tell you why so you can resubmit. They don't indicate whether the claim has been adjudicated or paid.
* **Real-time claim status checks**: Tell you the status of a claim that's already been accepted into the payer's system. They provide information about whether the claim has been adjudicated, paid, denied, or is pending further review.
That's why claim status checks can return more [Claim Status Category Codes](https://x12.org/codes/claim-status-category-codes) than a 277CA. Specifically, they can return codes in the `P` range for pending claims and codes in the `F` range for final claim statuses.
If you're waiting for an ERA, you should first check the related 277CA to confirm that the claim was accepted for processing. If the claim was rejected, you won't receive an ERA because the payer didn't adjudicate the claim.
Then, you can run a real-time claim status check to get updates about the claim's adjudication and payment status.
### 835 Electronic Remittance Advice (ERA) [#835-electronic-remittance-advice-era]
Processing ERAs always requires [transaction
enrollment](/healthcare/transaction-enrollment) with the payer.
The ERA contains details about payments for specific services and explanations for any adjustments or denials. The payer only sends ERAs for claims they have accepted for adjudication. If a claim is rejected in a 277CA, there's no adjudication or payment information to report.
#### Duplicate ERAs [#duplicate-eras]
Payers typically only send one ERA per claim. However, they may occasionally retransmit another identical 835 ERA, so you should have logic in place to handle these duplicates.
You can assume an ERA is a duplicate if the Check or EFT Trace Number is the same. This is the `transactions[].paymentAndRemitReassociationDetails.checkOrEFTTraceNumber` property in a processed 835 ERA from Stedi. In X12 EDI, this is available in segment `TRN` (Reassociation Trace Number), element `TRN02` (Check or EFT Trace Number).
## Correlate responses with claim [#correlate-responses-with-claim]
You can use the following identifiers from the original claim to correlate the 277CA and 835 ERA responses.
### Entire claim [#entire-claim]
Use `Loop 2300 CLM01` (Patient Control Number) from the original claim, if provided.
* In the 277CA, this number is returned as `Loop 2200D TRN02` (Patient Control Number).
Some payers batch acknowledgments for multiple claims into a single 277CA. This is more likely if you submitted multiple claims within a single 837 claim envelope. In these cases, the 277CA will contain multiple iterations of `Loop 2200D` (Claim Status Tracking Number). You can use each `TRN02` (Patient Control Number) value in the 277CA to correlate it with the original claim.
* In the 835 ERA, this number is returned as `Loop 2100 CLP01` (Patient Control Number).
### Specific service lines [#specific-service-lines]
Use `Loop 2400 REF02` (Line Item Control Number) from the original claim, if provided.
Location in responses:
* In the 277CA, this number is sometimes returned as `Loop 2220D REF02` (Line Item Control Number), but not always. This is because a 277CA only contains `Loop 2220D` (Service Line Information) when the claim was rejected because of issues with the information provided for the service line.
* In the 835 ERA this number is returned as `Loop 2110 REF02` (Line Item Control Number).
# Submit dental claims
Source: https://www.stedi.com/docs/healthcare/submit-dental-claims
You can send 837D dental claims to payers through the Stedi API or SFTP connection.
Once you send a claim, Stedi automatically receives and processes 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA) responses.
Dental payers typically require attachments to support most claims. Stedi's support for unsolicited 275 claim attachments is currently limited to a subset of available dental payers. [Learn more](#275-claim-attachments).
## Before sending claims [#before-sending-claims]
You may need to complete the following steps before sending claims.
### Transaction enrollment [#transaction-enrollment]
[Transaction enrollment](/healthcare/transaction-enrollment) is the process of registering a provider to exchange specific healthcare transactions with a payer. Some payers require enrollment before allowing providers to submit 837 claims through a new clearinghouse.
Enrolling through Stedi may cancel existing claims enrollments you have through other clearinghouses. We can help you determine whether this applies to your specific payers. However, enrolling through Stedi for 837 claims doesn't affect your existing enrollments for other transaction types. For example, enrolling with Stedi won't unenroll the provider from receiving transactions like Electronic Remittance Advices (ERAs) through other clearinghouses.
You can check whether a specific payer requires transaction enrollment for 837 claims in the [Payer Network](https://www.stedi.com/healthcare/network) or through the [Payers API](/healthcare/api-reference/get-payer).
To enroll, complete the following steps:
1. Create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step. [Stedi portal](https://portal.stedi.com/app/healthcare/providers) | [API endpoint](/healthcare/api-reference/post-enrollment-create-provider)
2. Submit an enrollment request for the claim type. [Stedi portal](https://portal.stedi.com/app/healthcare/enrollments) | [API endpoint](/healthcare/api-reference/post-enrollment-create-enrollment)
### Coordination of benefits check [#coordination-of-benefits-check]
We recommend running a coordination of benefits (COB) check to ensure you submit claims to the correct payer. COB checks can help you determine:
* If a patient is covered by more than one health plan
* Whether coverage overlap requires coordination of benefits
* Each payer’s responsibility for payment (primacy) in coordination of benefits scenarios
Visit [Coordination of benefits (COB) checks](/healthcare/coordination-of-benefits) for more information.
## UI submission [#ui-submission]
You can submit dental claims in X12 EDI format through the Stedi portal. Manual claim submission can be useful for testing, QA, and debugging your pipeline.
Your X12 EDI claim data must adhere to the [837 Claim: Dental (X224A2)](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-dental-x224a2/01JCJZ46AEK835RYV1BXQNBPK8) specification.
To manually submit an X12 EDI claim:
1. Go to the [transactions view](https://portal.stedi.com/app/healthcare/transactions).
2. Click **Submit claim** and choose **Upload EDI file** from the menu.
3. Do one of the following:
* Click **Upload X12 EDI** and select an existing `.edi` file to add.
* Select the transaction type and then paste the X12 EDI content into the text area.
4. Configure the settings to send a test or a production claim. Production claims are sent to payers. Test claims aren't sent to payers - Stedi's test clearinghouse processes them and returns test 277CA acknowledgments so you can evaluate your claim processing pipeline.
1. Select either **Test** or **Production** in the menu at the top of the text area.
2. Set `ISA15` (Interchange Usage Indicator) to `T` (Test Data) or `P` (Production Data), accordingly.
5. Fix any validation errors that appear after adding the claim X12 EDI content. Stedi highlights errors in red and displays the specification for the claim type you selected on the right side of the screen to make it easier to identify and fix issues.
6. Click **Submit claim** to submit the claim to Stedi.
Stedi processes the claim and takes you to the claim's details page. Stedi also displays the claim on the [claims view](https://portal.stedi.com/app/healthcare/claims) and the [transactions view](https://portal.stedi.com/app/healthcare/transactions).
## SFTP submission [#sftp-submission]
You can use Stedi’s fully-managed SFTP server to submit claims to to payers and retrieve claim responses without calling Stedi’s APIs.
You must submit claims in X12 EDI format, and Stedi returns claim responses through the SFTP connection in X12 EDI format. This makes Stedi SFTP a good option if you have an existing system that generates X12 EDI files and you want to send them through the Stedi clearinghouse without completing an API integration. Visit [SFTP connection](/healthcare/submit-claims-sftp-connection) for more information.
## API submission [#api-submission]
Call one of the following endpoints to submit 837D dental claims:
* [Dental Claims](/healthcare/api-reference/post-healthcare-dental-claims) to send requests in JSON
* [Dental Claims Raw X12](/healthcare/api-reference/post-healthcare-dental-claims-raw-x12) to send requests in X12 EDI
Both endpoints return a synchronous response from Stedi in JSON format. Later, the payer will respond with a 277CA claim acknowledgment.
### Headers [#headers]
When constructing the request, you must include the following information in HTTP headers:
* **`Authorization`:** [Generate an API key](https://portal.stedi.com/app/settings/api-keys) to use for authentication.
* **`Content-Type`:** Set to `application/json`.
#### Idempotency key [#idempotency-key]
We **strongly recommend** including an [idempotency key](/healthcare/api-reference#idempotency-keys) in the `Idempotency-Key` header to prevent sending duplicate claims to payers in the case of network errors or other intermittent failures. You can safely retry requests with the same idempotency key as many times as necessary within 24 hours after making the first request.
### Body - JSON [#body---json]
The information you submit for a claim depends on your use case. Refer to the [Dental Claims](/healthcare/api-reference/post-healthcare-dental-claims) endpoint for a complete list of properties. However, all claims require the following high-level information:
{/* prettier-ignore-start */}
| Information | Description |
| --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tradingPartnerServiceId` | This is the payer ID. You can send requests using the primary payer ID, the Stedi payer ID, or any alias listed in the payer record. If you don't already have payer IDs you use today, we recommend using the primary Payer ID. Visit the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list. |
| `tradingPartnerName` | This is the payer's business name, like Cigna or Aetna. |
| `submitter` object | Information about the entity submitting the claim. This can be either an individual or an organization, such as a doctor, hospital, or insurance company. |
| `receiver` object | Information about the payer, such as an insurance company or government agency. |
| `subscriber` and/or `dependent` objects | Information about the patient who received the medical services. Note that if a dependent has their own, unique member ID for their health plan, you should submit their information in the `subscriber` object and omit the `dependent` object from the request. You can check whether the dependent has a unique member ID by submitting an [Eligibility Check](/healthcare/api-reference/post-healthcare-eligibility) to the payer for the dependent. The payer will return the member ID in the `dependents.memberId` field, if present. |
| `claimInformation` object | Information about the claim, such as the [patient control number](#patient-control-number-pcn), claim charge amount, and place of service code. It also includes information about each individual service line included in the claim. |
| `billing` object | Information about the billing provider, such as the [NPI](/healthcare/national-provider-identifier), taxonomy code, and organization name. |
{/* prettier-ignore-end */}
#### Patient Control Number [#patient-control-number]
You must submit a Patient Control Number (PCN) with each claim in [`claimInformation.patientControlNumber`](/healthcare/api-reference/post-healthcare-dental-claims#body.claimInformation.patientControlNumber). The payer returns this value in related transactions, such as the 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA), so you can correlate responses and real-time claim status checks with the original claim.
When assigning a PCN, follow these best practices:
* Use a unique PCN for each claim. The identifier should be more complex than a simple sequential number and should be hard to guess.
* Use random strings. Formats with patient initials or the date of service in them can create duplicates. We recommend using [nanoid](https://www.npmjs.com/package/nanoid) or a similar library configured with the characters available in the [basic character set](#character-set) to create a strong, unique 17-character PCN for each claim.
* Keep it 17 characters or less. Some payers cut off values longer than 17 characters in ERAs and claim acknowledgments, which makes it hard to match them with the original claim.
* Use only characters available in the [basic character set](#character-restrictions), and avoid special characters that are only available in the extended character set. Payers are permitted to return data using the basic character set. Using other characters may result in data loss or mismatches when correlating claims with responses.
* Treat PCN values as case-insensitive when matching transactions, even if the submitted value included both lower and uppercase characters.
#### Service line identification [#service-line-identification]
A claim can contain multiple service lines. Since the payer may accept, reject, or pay a subset of those lines, you can receive an 835 ERA that references a `patientControlNumber`, but only pertains to some of the service lines.
However, the `claimInformation.serviceLines[].providerControlNumber` serves as a unique identifier for each service line in your claim submission. This value appears in the 277CA claim acknowledgment and 835 ERA as the `lineItemControlNumber`, allowing you to correlate these responses to specific service lines from the original claim. If you don't set the `providerControlNumber` for a service line, Stedi uses a random UUID.
Stedi returns service line identifiers in the `claimReference.serviceLines` array of the synchronous API response.
#### Conditional requirements [#conditional-requirements]
Note that objects marked as **required** are required for all requests, while others are conditionally required depending on the circumstances. When you include a conditionally required object, you must include all of its required properties.
For example, you must always include the `subscriber` object in your request, but you only need to include the `supervising` object when the rendering provider is supervised by a physician.
### Body - X12 EDI [#body---x12-edi]
You must send a payload in [837 X12 EDI format](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-dental-x224a3/01GRYB6G91ZX6R1XAFGBMRTBBW).
Note the following requirements and behavior when sending dental claims through the raw X12 endpoint.
#### Envelope and header [#envelope-and-header]
Stedi generates its own `ISA` and `GS` headers and `IEA` and `GE` trailers before sending your claim to the payer. You can submit your claim to Stedi with any values in these segments, as long as they conform to the X12 EDI specification.
However, you must set `ST03` (Implementation Guide Version Name) to `005010X224A2`.
#### Payer ID [#payer-id]
You must submit a payer identifier in `Loop 2010BB` (Payer Name) `NM109` so Stedi can route your claim to the correct payer. This identifier **must** be a payer ID or payer ID alias listed in the [Payer Network](https://www.stedi.com/healthcare/network). If you don't already have payer IDs you use today, we recommend using the primary Payer ID.
You must include leading `0` characters in payer IDs. For example, use `00540` for SISCO, not `540`.
#### `CLM01` (Patient Control Number) [#clm01-patient-control-number]
We **strongly recommend** submitting a unique value for `Loop 2300` (Claim Information) `CLM01` (Patient Control Number). The payer returns this value in related transactions, such as the 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA), so you can correlate responses and real-time claim status checks with the original claim.
When assigning a PCN, follow these best practices:
* Use a unique PCN for each claim. The identifier should be more complex than a simple sequential number and should be hard to guess.
* Use random strings. Formats with patient initials or the date of service in them can create duplicates. We recommend using [nanoid](https://www.npmjs.com/package/nanoid) or a similar library configured with the characters available in the [basic character set](#character-set) to create a strong, unique 17-character PCN for each claim.
* Keep it 17 characters or less. Some payers cut off values longer than 17 characters in ERAs and claim acknowledgments, which makes it hard to match them with the original claim.
* Use only characters available in the [basic character set](#character-restrictions), and avoid special characters that are only available in the extended character set. Payers are permitted to return data using the basic character set. Using other characters may result in data loss or mismatches when correlating claims with responses.
* Treat PCN values as case-insensitive when matching transactions, even if the submitted value included both lower and uppercase characters.
#### Service line identification [#service-line-identification-1]
A claim can contain multiple service lines. Since the payer may accept, reject, or pay a subset of those lines, you can receive an 835 response that references a patient control number, but only pertains to some of the service lines.
However, the line item control number serves as a unique identifier for each service line in your claim submission.
* You can set the line item control number in `Loop 2400 REF02`, when `REF01` = `6R`. The line item control number appears in the 277CA and 835 ERA responses as the `lineItemControlNumber`, allowing you to correlate these responses to specific service lines from the original claim.
* If you don’t set the line item control number for a service line, Stedi uses a ULID.
### Character restrictions [#character-restrictions]
Only use the X12 Basic and Extended character sets in request data. Using characters outside these sets may cause errors.
The X12 Basic character set includes uppercase letters, digits, space, and some special characters. Lowercase letters and special language characters like `ñ` are not included.
The following special characters are included:
The Extended character set includes the characters listed in Basic, plus lowercase letters and additional special characters, such as `@`.
The following additional special characters are included:
In addition, the following characters are reserved for delimiters in the final X12 EDI transaction to the payer: `~`, `*`, `:` and `^`. X12 doesn't support using escape sequences to represent delimiters or special characters. Stedi returns a `400` error if you use these restricted characters improperly.
* **JSON endpoint:** Don’t include delimiter characters anywhere in your request data.
* **Raw X12 endpoint:** You can use these characters as delimiters, but not in the body of the request data.
### Sample request and response [#sample-request-and-response]
The following examples send a dental claim. The response shape is the same for both the JSON and X12 EDI endpoints. It contains summary information from Stedi about the claim submission and whether it was successful.
The response also includes an initial [277CA claim acknowledgment](/healthcare/claim-responses-overview#277ca-claim-acknowledgment) from Stedi in the `x12` property, which indicates whether the claim passed Stedi's claim edits.
{/* schema:DentalClaimsSubmissionRequestContent */}
```bash
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/dental-claims/submission \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--header 'Idempotency-Key: ' \
--data '{
"usageIndicator": "T",
"tradingPartnerServiceId": "52133",
"tradingPartnerName": "United HealthCare Dental",
"subscriber": {
"paymentResponsibilityLevelCode": "P",
"memberId": "123412345",
"firstName": "John",
"lastName": "Doe",
"groupNumber": "1234567890",
"gender": "F",
"address": {
"address1": "1234 Some St",
"city": "Buckeye",
"state": "AZ",
"postalCode": "85326"
},
"dateOfBirth": "20180615"
},
"submitter": {
"organizationName": "ABA Inc",
"submitterIdentification": "",
"contactInformation": {
"phoneNumber": "3131234567",
"name": "BILLING DEPARTMENT"
}
},
"rendering": {
"npi": "1999999992",
"taxonomyCode": "106S00000X",
"providerType": "RenderingProvider",
"lastName": "Doe",
"firstName": "Jane"
},
"receiver": {
"organizationName": "United HealthCare Dental"
},
"payerAddress": {
"address1": "PO Box 7000",
"city": "Camden",
"state": "SC",
"postalCode": "29000"
},
"claimInformation": {
"signatureIndicator": "Y",
"toothStatus": [
{
"toothNumber": "3",
"toothStatusCode": "E"
}
],
"serviceLines": [
{
"serviceDate": "20230428",
"renderingProvider": {
"npi": "1999999992",
"taxonomyCode": "122300000X",
"lastName": "Doe",
"firstName": "Jane"
},
"providerControlNumber": "a0UDo000000dd2dMAA",
"dentalService": {
"procedureCode": "D7140",
"lineItemChargeAmount": "832.00",
"placeOfServiceCode": "12",
"oralCavityDesignation": [
"1",
"2"
],
"prosthesisCrownOrInlayCode": "I",
"procedureCount": 2,
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": [
"1"
]
}
},
"teethInformation": [
{
"toothCode": "3",
"toothSurfaceCodes": [
"M",
"O"
]
}
]
}
],
"serviceFacilityLocation": {
"phoneNumber": "3131234567",
"organizationName": "ABA Inc",
"npi": "1999999992",
"address": {
"address1": "ABA Inc 123 Some St",
"city": "Denver",
"state": "CO",
"postalCode": "802383100"
}
},
"releaseInformationCode": "Y",
"planParticipationCode": "A",
"placeOfServiceCode": "12",
"patientControlNumber": "",
"healthCareCodeInformation": [
{
"diagnosisTypeCode": "ABK",
"diagnosisCode": "K081"
}
],
"claimSupplementalInformation": {
"priorAuthorizationNumber": "20231010012345678"
},
"claimFrequencyCode": "1",
"claimFilingCode": "FI",
"claimChargeAmount": "832.00",
"benefitsAssignmentCertificationIndicator": "Y"
},
"billing": {
"taxonomyCode": "106S00000X",
"providerType": "BillingProvider",
"organizationName": "ABA Inc",
"npi": "1999999992",
"employerId": "123456789",
"contactInformation": {
"phoneNumber": "3134893157",
"name": "ABA Inc"
},
"address": {
"address1": "ABA Inc 123 Some St",
"city": "Denver",
"state": "CO",
"postalCode": "802383000"
}
}
}'
```
```bash
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/dental-claims/raw-x12-submission \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--header 'Idempotency-Key: ' \
--data '{
"x12": "ISA*00* *00* *ZZ*574183004559 *ZZ*STEDITEST *260213*2050*^*00501*000000042*0*T*`~GS*HC*574183004559*STEDITEST*20260213*205048*42*X*005010X224A2~ST*837*0001*005010X224A2~BHT*0019*00*01KHCCA4V6K00NFPX588G859SJ*20260213*2050*CH~NM1*41*2*ABA Inc*****46*1234567~PER*IC*BILLING DEPARTMENT*TE*3131234567~NM1*40*2*United HealthCare Dental*****46*52133~HL*1**20*1~PRV*BI*PXC*106S00000X~NM1*85*2*ABA Inc*****XX*1999999992~N3*ABA Inc 123 Some St~N4*Denver*CO*802383000~REF*EI*123456789~PER*IC*ABA Inc*TE*3134893157~HL*2*1*22*0~SBR*P*18*1234567890******FI~NM1*IL*1*Doe*John****MI*123412345~N3*1234 Some St~N4*Buckeye*AZ*85326~DMG*D8*20180615*F~NM1*PR*2*United HealthCare Dental*****PI*52133~N3*PO Box 7000~N4*Camden*SC*29000~CLM*12345*832***12`B`1*Y*A*Y*Y~DN2*3*E****JP~REF*G1*20231010012345678~HI*ABK`K081~NM1*82*1*Doe*Jane****XX*1999999992~PRV*PE*PXC*106S00000X~LX*1~SV3*AD`D7140*832**1`2*I*2*****1~TOO*JP*3*M`O~DTP*472*D8*20230428~REF*6R*a0UDo000000dd2dMAA~NM1*82*1*Doe*Jane****XX*1999999992~PRV*PE*PXC*122300000X~SE*35*0001~GE*1*42~IEA*1*000000042~"
}'
```
{/* schema:DentalClaimsSubmissionResponseContent */}
```json
{
"status": "SUCCESS",
"controlNumber": "1",
"tradingPartnerServiceId": "52133",
"claimReference": {
"correlationId": "01KHC96GBNYA14YRBRJGFR13P7",
"patientControlNumber": "12345",
"timeOfResponse": "2026-02-13T19:56:13.575Z",
"payerId": "52133",
"formatVersion": "5010",
"rhclaimNumber": "01KHC96GBNYA14YRBRJGFR13P7",
"serviceLines": [
{
"lineItemControlNumber": "a0UDo000000dd2dMAA"
}
]
},
"meta": {
"traceId": "4564629a-930d-4287-aceb-ca9a1f1a2d7d"
},
"payer": {
"payerName": "United HealthCare Dental",
"payerId": "52133"
},
"x12": "ISA*00* *00* *ZZ*574183004559 *ZZ*STEDITEST *260213*2045*^*00501*000000033*0*T*`~GS*HC*574183004559*STEDITEST*20260213*204524*33*X*005010X224A2~ST*837*0001*005010X224A2~BHT*0019*00*01KHC96GBNYA14YRBRJGFR13P7*20260213*1956*CH~NM1*41*2*ABA Inc*****46*123456789~PER*IC*BILLING DEPARTMENT*TE*3131234567~NM1*40*2*United HealthCare Dental*****46*52133~HL*1**20*1~PRV*BI*PXC*106S00000X~NM1*85*2*ABA Inc*****XX*1999999992~N3*ABA Inc 123 Some St~N4*Denver*CO*802383000~REF*EI*123456789~PER*IC*ABA Inc*TE*3134893157~HL*2*1*22*0~SBR*P*18*1234567890******FI~NM1*IL*1*Doe*John****MI*123412345~N3*1234 Some St~N4*Buckeye*AZ*85326~DMG*D8*20180615*F~NM1*PR*2*United HealthCare Dental*****PI*52133~N3*PO Box 7000~N4*Camden*SC*29000~CLM*12345*832***12`B`1*Y*A*Y*Y~DN2*3*E****JP~REF*G1*20231010012345678~HI*ABK`K081~NM1*82*1*Doe*Jane****XX*1999999992~PRV*PE*PXC*106S00000X~LX*1~SV3*AD`D7140*832**1`2*I*2*****1~TOO*JP*3*M`O~DTP*472*D8*20230428~REF*6R*a0UDo000000dd2dMAA~NM1*82*1*Doe*Jane****XX*1999999992~PRV*PE*PXC*122300000X~SE*35*0001~GE*1*33~IEA*1*000000033~",
"httpStatusCode": "200 OK"
}
```
### Test claims [#test-claims]
All claims you submit through the API are sent to the payer as production claims unless you explicitly designate them as test data.
To send test claims:
* **JSON endpoint:** Set the `usageIndicator` property in the test claim body to `T`.
* **X12 EDI endpoint:** Set `ISA15` (Interchange Usage Indicator) to `T` (Test Data) instead of `P` (Production Data).
When you send a test claim, Stedi doesn't send it to the payer. Instead, it processes the claim as if it were sent to the payer and returns a 277CA claim acknowledgment indicating whether the claim was successfully processed.
Designating a claim as test data also allows you to filter for test claims on the [Transactions](https://portal.stedi.com/app/core/transactions) page in the Stedi portal.
You'll receive a 277CA claim acknowledgment in response to test claims, but you won't receive a test 835 Electronic Remittance Advice (ERA) response unless you send the claim to the [Stedi Test Payer](https://www.stedi.com/healthcare/network?search=StediTest\&entry=FRCPB). Visit [Test claims workflow](/healthcare/test-claims-workflow) to learn how generate test ERAs.
### Concurrency limit [#concurrency-limit]
Dental claim submission endpoints share a concurrency pool with other claim endpoints. For more information, visit [Concurrency limits](/healthcare/api-reference#concurrency-limits).
### Recommended API clients [#recommended-api-clients]
You may want to use an API client to make testing and debugging easier.
We **don't recommend** using Postman for requests containing Protected Health Information (PHI) because Postman defaults to storing request history - including full request payloads - on its cloud servers. You can’t turn this feature off without impractical workarounds.
Visit [API clients](/healthcare/api-reference#api-clients) for a list of recommended clients you can use instead.
## View submitted claims [#view-submitted-claims]
You can view the files that Stedi sends and receives in the [Files](https://portal.stedi.com/app/core/file-executions) page of the Stedi portal.
On the [Transactions](https://portal.stedi.com/app/core/transactions) page, you can review and filter claims by **Usage** - production or test. Click any claim submission to review its details, including the full request and response payload and processing events.
## 275 claim attachments [#275-claim-attachments]
Dental payers typically require attachments to support most claims, such as X-rays and treatment plans. Stedi's support for unsolicited 275 claim attachments is currently limited to a [subset of available dental payers](https://www.stedi.com/healthcare/network?filter=eyJ0cmFuc2FjdGlvbkZpbHRlcnMiOnsiMjcwIjp7fSwiMjc2Ijp7fSwiODM1Ijp7fSwiODM3UCI6e30sIjgzN0kiOnt9LCI4MzdEIjp7ImlzU3VwcG9ydGVkIjp0cnVlfSwiQ09CIjp7fSwiMjc1VSI6eyJpc1N1cHBvcnRlZCI6dHJ1ZX19LCJjb3ZlcmFnZVR5cGVzIjpbXSwib3BlcmF0aW5nU3RhdGVzIjpbXX0%3D).
When Stedi doesn't support attachments, you can submit them outside of Stedi - for example, directly to the payer's portal. Then, you can reference them in the dental claims you submit through Stedi. Contact [Stedi Support](https://www.stedi.com/contact) with questions about supported payers or for help optimizing your attachments workflow.
When a claim requires attachments, you must must reference them in the [`claimInformation.claimSupplementalInformation.reportInformation`](/healthcare/api-reference/post-healthcare-dental-claims#body.claimInformation.claimSupplementalInformation.reportInformation) object or the [`claimInformation.claimSupplementalInformation.reportInformations`](/healthcare/api-reference/post-healthcare-dental-claims#body.claimInformation.claimSupplementalInformation.reportInformations) array (multiple attachments).
Visit [Claim attachments](/healthcare/submit-claim-attachments) to learn more about submitting attachments through Stedi and referencing attachments in claims.
## Worker's compensation, auto, and liability claims [#workers-compensation-auto-and-liability-claims]
You can submit workers' compensation, automobile medical, and liability claims through Stedi's UI, claim submission APIs, and SFTP. Visit [Worker's compensation, auto, and liability claims](/healthcare/submit-workers-comp-auto-liability-claims) for details.
## Submit claims to a secondary or tertiary payer [#submit-claims-to-a-secondary-or-tertiary-payer]
In [coordination of benefits (COB)](/healthcare/coordination-of-benefits) scenarios, you'll need to submit a claim to multiple payers.
You must set the `subscriber.paymentResponsibilityLevelCode` to either `S` (when submitting to the secondary payer) or `T` (when submitting to the tertiary payer).
You must also include the following information about how prior payers have adjudicated the claim. For example, if a patient's private insurance plan (primary payer) adjusted the requested reimbursement amount and paid for its portion of the services, you must include that information in the claim you submit to Medicare (secondary payer). You can find these details in 835 ERA responses from prior payers.
### Claim information [#claim-information]
You must submit one object in the `claimInformation.otherSubscriberInformation` array for each prior payer. Supply all the required properties in the object plus the following additional information:
* `claimLevelAdjustments`: Provide if the prior payer made adjustments at the claim level. Codes and their associated amounts must come from ERAs sent by the prior payers. You can find these codes in the ERA's [`transactions[].detailInfo[].paymentInfo[].claimAdjustments`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.claimAdjustments) array.
* `medicareInpatientAdjudication` (institutional claims only): You must include this if Medicare was one of the prior payers and reported inpatient adjudication information on the ERA.
* `medicareOutpatientAdjudication`: You must include this if Medicare was one of the prior payers and reported outpatient adjudication information on the ERA.
* `otherPayerName.otherPayerAdjudicationOrPaymentDate`: The date the payer adjudicated or paid the claim. You must provide this if you aren't providing a value in the `claimInformation.serviceLines[].lineAdjudicationInformation[].adjudicationOrPaymentDate` property.
* `payerPaidAmount`: This is the total amount in dollars the payer paid on this claim.
### Service line information [#service-line-information]
You must submit `serviceLines[].lineAdjudicationInformation` objects when the prior payers provided line-level adjudication information. Submit one object for each prior payer. For each object, you should include the following properties.
* `adjudicationOrPaymentDate`: The date the payer adjudicated or paid the claim. Don't include this if you're providing a date in the `otherPayerName.otherPayerAdjudicationOrPaymentDate` property.
* `claimAdjustmentInformation`: You can find this information in the ERA's [`transactions[].detailInfo[].paymentInfo[].serviceLines[].serviceAdjustments`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.serviceLines.serviceAdjustments) array.
* `otherPayerPrimaryIdentifier`: The identifier for the other payer. This value should match the identifier you supplied for the payer in the `claimInformation.otherSubscriberInformation[].otherPayerName.otherPayerIdentifier` property.
* `procedureCode`: The adjudicated procedure code for the service line.
* `serviceIdQualifier`: A code identify the type of procedure code. Visit [Claims code lists](/healthcare/claims-code-lists#composite-medical-procedure---product-or-service-id-qualifier-codes) for a complete list.
* `serviceLinePaidAmount`: The total amount in dollars the prior payer paid on this service line.
* `paidServiceUnitCount`: The number of paid units for the service line. When paid units are not present on the remittance advice, use the original billed units.
* `remainingPatientLiability`: The amount of the service line the patient is responsible for paying.
## Claim Filing Indicator Code [#claim-filing-indicator-code]
The Claim Filing Indicator Code indicates how a claim was filed with a payer, such as `MC` (Medicaid) or `CI` (Commercial Insurance Co.).
Choosing the correct claim filing indicator code is important for successful claim submission. Visit the [Claims code lists](/healthcare/claims-code-lists#choosing-the-right-code) documentation for best practices for selecting the appropriate code.
# Submit institutional claims
Source: https://www.stedi.com/docs/healthcare/submit-institutional-claims
You can send 837I institutional claims to payers through the Stedi API or SFTP connection.
Once you send a claim, Stedi automatically receives and processes 277CA claim acknowledgments and 835 Electronic Remittance Advice (ERA) responses.
## Before sending claims [#before-sending-claims]
You may need to complete the following steps before sending claims.
### Transaction enrollment [#transaction-enrollment]
[Transaction enrollment](/healthcare/transaction-enrollment) is the process of registering a provider to exchange specific healthcare transactions with a payer. Some payers require enrollment before allowing providers to submit 837 claims through a new clearinghouse.
Enrolling through Stedi may cancel existing claims enrollments you have through other clearinghouses. We can help you determine whether this applies to your specific payers. However, enrolling through Stedi for 837 claims doesn't affect your existing enrollments for other transaction types. For example, enrolling with Stedi won't unenroll the provider from receiving transactions like Electronic Remittance Advices (ERAs) through other clearinghouses.
You can check whether a specific payer requires transaction enrollment for 837 claims in the [Payer Network](https://www.stedi.com/healthcare/network) or through the [Payers API](/healthcare/api-reference/get-payer).
To enroll, complete the following steps:
1. Create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step. [Stedi portal](https://portal.stedi.com/app/healthcare/providers) | [API endpoint](/healthcare/api-reference/post-enrollment-create-provider)
2. Submit an enrollment request for the claim type. [Stedi portal](https://portal.stedi.com/app/healthcare/enrollments) | [API endpoint](/healthcare/api-reference/post-enrollment-create-enrollment)
### Coordination of benefits check [#coordination-of-benefits-check]
We recommend running a coordination of benefits (COB) check to ensure you submit claims to the correct payer. COB checks can help you determine:
* If a patient is covered by more than one health plan
* Whether coverage overlap requires coordination of benefits
* Each payer’s responsibility for payment (primacy) in coordination of benefits scenarios
Visit [Coordination of benefits (COB) checks](/healthcare/coordination-of-benefits) for more information.
## UI submission [#ui-submission]
You can submit institutional claims in X12 EDI format through the Stedi portal. Manual claim submission can be useful for testing, QA, and debugging your pipeline.
You can submit institutional claims in X12 EDI format. Your X12 EDI claim data must adhere to the [837 Claim: Institutional (X223A2)](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-institutional-x223a2/01JBHW2YXMN2F9KXK2PS0BFP9F) specification.
To manually submit an X12 EDI claim:
1. Go to the [transactions view](https://portal.stedi.com/app/healthcare/transactions).
2. Click **Submit claim** and choose **Upload EDI file** from the menu.
3. Do one of the following:
* Click **Upload X12 EDI** and select an existing `.edi` file to add.
* Select the transaction type and then paste the X12 EDI content into the text area.
4. Configure the settings to send a test or a production claim. Production claims are sent to payers. Test claims aren't sent to payers - Stedi's test clearinghouse processes them and returns test 277CA acknowledgments so you can evaluate your claim processing pipeline.
1. Select either **Test** or **Production** in the menu at the top of the text area.
2. Set `ISA15` (Interchange Usage Indicator) to `T` (Test Data) or `P` (Production Data), accordingly.
5. Fix any validation errors that appear after adding the claim X12 EDI content. Stedi highlights errors in red and displays the specification for the claim type you selected on the right side of the screen to make it easier to identify and fix issues.
6. Click **Submit claim** to submit the claim to Stedi.
Stedi processes the claim and takes you to the claim's details page. Stedi also displays the claim on the [claims view](https://portal.stedi.com/app/healthcare/claims) and the [transactions view](https://portal.stedi.com/app/healthcare/transactions).
## SFTP submission [#sftp-submission]
You can use Stedi’s fully-managed SFTP server to submit claims to to payers and retrieve claim responses without calling Stedi’s APIs.
You must submit claims in X12 EDI format, and Stedi returns claim responses through the SFTP connection in X12 EDI format. This makes Stedi SFTP a good option if you have an existing system that generates X12 EDI files and you want to send them through the Stedi clearinghouse without completing an API integration. Visit [SFTP connection](/healthcare/submit-claims-sftp-connection) for more information.
## API submission [#api-submission]
Call one of the following endpoints to submit 837I institutional claims:
* [Institutional Claims](/healthcare/api-reference/post-healthcare-institutional-claims) to send requests in JSON
* [Institutional Claims Raw X12](/healthcare/api-reference/post-healthcare-institutional-claims-raw-x12) to send requests in X12 EDI
Both endpoints return a synchronous response from Stedi in JSON format. Later, the payer will respond with a 277CA claim acknowledgment.
### Headers [#headers]
When constructing the request, you must include the following information in HTTP headers:
* **`Authorization`:** [Generate an API key](https://portal.stedi.com/app/settings/api-keys) to use for authentication.
* **`Content-Type`:** Set to `application/json`.
#### Idempotency key [#idempotency-key]
We **strongly recommend** including an [idempotency key](/healthcare/api-reference#idempotency-keys) in the `Idempotency-Key` header to prevent sending duplicate claims to payers in the case of network errors or other intermittent failures. You can safely retry requests with the same idempotency key as many times as necessary within 24 hours after making the first request.
### Body - JSON [#body---json]
The information you submit for a claim depends on your use case. Refer to the [Institutional Claims](/healthcare/api-reference/post-healthcare-institutional-claims) endpoint for a complete list of properties. However, all claims require the following high-level information:
{/* prettier-ignore-start */}
| Information | Description |
| --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tradingPartnerServiceId` | This is the payer ID. You can send requests using the primary payer ID, the Stedi payer ID, or any alias listed in the payer record. If you don't already have payer IDs you use today, we recommend using the primary Payer ID. Visit the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list. |
| `submitter` object | Information about the entity submitting the claim. This is an organization, such as a hospital or other treatment center. |
| `receiver` object | Information about the entity responsible for the payment of the claim, such as an insurance company or government agency. |
| `subscriber` and/or `dependent` objects | Information about the patient who received the medical services. Note that if a dependent has their own, unique member ID for their health plan, you should submit their information in the `subscriber` object and omit the `dependent` object from the request. You can check whether the dependent has a unique member ID by submitting an [Eligibility Check](/healthcare/api-reference/post-healthcare-eligibility) to the payer for the dependent. The payer will return the member ID in the `dependents.memberId` field, if present. |
| `claimInformation` object | Information about the claim, such as the [Patient Control Number](#patient-control-number-pcn), claim filing code (identifies the type of claim), claim charge amount, and place of service code. It also includes information about each individual service line included in the claim. |
| Billing provider | You **must** supply information about the billing provider in either the `providers` or `billing` object. This includes the provider's [NPI](/healthcare/national-provider-identifier), name, and other information. |
{/* prettier-ignore-end */}
#### Patient Control Number [#patient-control-number]
You must submit a Patient Control Number (PCN) with each claim in [`claimInformation.patientControlNumber`](/healthcare/api-reference/post-healthcare-institutional-claims#body.claimInformation.patientControlNumber). The payer returns this value in related transactions, such as the 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA), so you can correlate responses and real-time claim status checks with the original claim.
When assigning a PCN, follow these best practices:
* Use a unique PCN for each claim. The identifier should be more complex than a simple sequential number and should be hard to guess.
* Use random strings. Formats with patient initials or the date of service in them can create duplicates. We recommend using [nanoid](https://www.npmjs.com/package/nanoid) or a similar library configured with the characters available in the [basic character set](#character-set) to create a strong, unique 17-character PCN for each claim.
* Keep it 17 characters or less. Some payers cut off values longer than 17 characters in ERAs and claim acknowledgments, which makes it hard to match them with the original claim.
* Use only characters available in the [basic character set](#character-restrictions), and avoid special characters that are only available in the extended character set. Payers are permitted to return data using the basic character set. Using other characters may result in data loss or mismatches when correlating claims with responses.
* Treat PCN values as case-insensitive when matching transactions, even if the submitted value included both lower and uppercase characters.
#### Service line identification [#service-line-identification]
A claim can contain multiple service lines. Since the payer may accept, reject, or pay a subset of those lines, you can receive an 835 ERA that references a `patientControlNumber`, but only pertains to some of the service lines.
However, the `claimInformation.serviceLines[].lineItemControlNumber` serves as a unique identifier for each service line in your claim submission. This value appears in the 277CA claim acknowledgment and 835 ERA as the `lineItemControlNumber`, allowing you to correlate these responses to specific service lines from the original claim. We strongly recommend setting the `lineItemControlNumber` to a ULID or other unique identifier for each service line. We recommend using a ULID instead of a UUID because the property has a max of 30 characters.
#### Admission source code [#admission-source-code]
The admission source code tells you where the patient came from, such as the emergency room (ER), a doctor’s referral, or another facility. Most institutional claims require the admission source code. The one exception is non-patient lab services, where no patient is present.
You must include the admission source code in the [`claimInformation.claimCodeInformation.admissionSourceCode`](/healthcare/api-reference/post-healthcare-institutional-claims#body.claimInformation.claimCodeInformation.admissionSourceCode) property for all institutional claims **except** when the `claimInformation.placeOfServiceCode` contains `14` (Non-Patient Laboratory).
Stedi rejects claims that don't meet this requirement.
#### Conditional requirements [#conditional-requirements]
Note that objects marked as **required** are required for all requests, while others are conditionally required depending on the circumstances. When you include a conditionally required object, you must include all of its required properties.
For example, you must always include the `subscriber` object in your request, but you only need to include the `supervising` object when the rendering provider is supervised by a physician.
## Body - X12 EDI [#body---x12-edi]
You must send a payload in [837 X12 EDI format](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-institutional-x223a2/01JBHW2YXMN2F9KXK2PS0BFP9F).
Note the following requirements and behavior when sending institutional claims through the raw X12 endpoint.
#### Envelope and header [#envelope-and-header]
Stedi generates its own `ISA` and `GS` headers and `IEA` and `GE` trailers before sending your claim to the payer. You can submit your claim to Stedi with any values in these segments, as long as they conform to the X12 EDI specification.
However, you must set `ST03` (Version, Release, or Industry Identifier) to `005010X223A2`.
#### Payer ID [#payer-id]
You must submit a payer identifier in `Loop 2010BB` (Payer Name) `NM109` so Stedi can route your claim to the correct payer. This identifier **must** be a payer ID or payer ID alias listed in the [Payer Network](https://www.stedi.com/healthcare/network). If you don't already have payer IDs you use today, we recommend using the primary Payer ID.
You must include leading `0` characters in payer IDs. For example, use `00540` for SISCO, not `540`.
#### `CLM01` (Patient Control Number) [#clm01-patient-control-number]
We **strongly recommend** submitting a unique value for `Loop 2300` (Claim Information) `CLM01` (Patient Control Number). The payer returns this value in related transactions, such as the 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA), so you can correlate responses and real-time claim status checks with the original claim.
When assigning a PCN, follow these best practices:
* Use a unique PCN for each claim. The identifier should be more complex than a simple sequential number and should be hard to guess.
* Use random strings. Formats with patient initials or the date of service in them can create duplicates. We recommend using [nanoid](https://www.npmjs.com/package/nanoid) or a similar library configured with the characters available in the [basic character set](#character-set) to create a strong, unique 17-character PCN for each claim.
* Keep it 17 characters or less. Some payers cut off values longer than 17 characters in ERAs and claim acknowledgments, which makes it hard to match them with the original claim.
* Use only characters available in the [basic character set](#character-restrictions), and avoid special characters that are only available in the extended character set. Payers are permitted to return data using the basic character set. Using other characters may result in data loss or mismatches when correlating claims with responses.
* Treat PCN values as case-insensitive when matching transactions, even if the submitted value included both lower and uppercase characters.
#### Service line identification [#service-line-identification-1]
A claim can contain multiple service lines. Since the payer may accept, reject, or pay a subset of those lines, you can receive an 835 response that references a patient control number, but only pertains to some of the service lines.
However, the line item control number serves as a unique identifier for each service line in your claim submission.
* You can set the line item control number in `Loop 2400 REF02`, when `REF01` = `6R`. The line item control number appears in the 277CA and 835 ERA responses as the `lineItemControlNumber`, allowing you to correlate these responses to specific service lines from the original claim.
* If you don’t set the line item control number for a service line, Stedi uses a ULID.
#### Admission source code [#admission-source-code-1]
The admission source code tells you where the patient came from, such as the emergency room (ER), a doctor’s referral, or another facility. Most institutional claims require the admission source code. The one exception is non-patient lab services, where no patient is present.
You must include the admission source code in `Loop 2300 CLI02` (Admission Source Code) for all institutional claims **except** when `Loop 2300 C02301` (Facility Type Code) is `14` (Non-Patient Laboratory).
Stedi rejects claims that don't meet this requirement.
### Character restrictions [#character-restrictions]
Only use the X12 Basic and Extended character sets in request data. Using characters outside these sets may cause errors.
The X12 Basic character set includes uppercase letters, digits, space, and some special characters. Lowercase letters and special language characters like `ñ` are not included.
The following special characters are included:
The Extended character set includes the characters listed in Basic, plus lowercase letters and additional special characters, such as `@`.
The following additional special characters are included:
In addition, the following characters are reserved for delimiters in the final X12 EDI transaction to the payer: `~`, `*`, `:` and `^`. X12 doesn't support using escape sequences to represent delimiters or special characters. Stedi returns a `400` error if you use these restricted characters improperly.
* **JSON endpoint:** Don’t include delimiter characters anywhere in your request data.
* **Raw X12 endpoint:** You can use these characters as delimiters, but not in the body of the request data.
### Sample request and response [#sample-request-and-response]
The following example sends an institutional claim. The response shape contains summary information from Stedi about the claim submission and whether it was successful.
The response also includes an initial [277CA claim acknowledgment](/healthcare/claim-responses-overview#277ca-claim-acknowledgment) from Stedi in the `x12` property, which indicates whether the claim passed Stedi's claim edits.
{/* schema:InstitutionalClaimsSubmissionRequestContent */}
```bash
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/institutionalclaims/v1/submission \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--header 'Idempotency-Key: ' \
--data '{
"usageIndicator": "T",
"tradingPartnerName": "UnitedHealthcare",
"tradingPartnerServiceId": "87726",
"submitter": {
"organizationName": "Test Facility",
"contactInformation": {
"name": "Test Facility",
"phoneNumber": "2225551234"
},
"taxId": "123456789"
},
"receiver": {
"organizationName": "UnitedHealthcare"
},
"subscriber": {
"memberId": "98765",
"paymentResponsibilityLevelCode": "P",
"firstName": "JANE",
"lastName": "DOE",
"gender": "F",
"dateOfBirth": "19000101",
"address": {
"address1": "1234 Some St",
"city": "Buckeye",
"state": "AZ",
"postalCode": "85326"
}
},
"claimInformation": {
"claimFilingCode": "ZZ",
"patientControlNumber": "",
"claimChargeAmount": "500.00",
"placeOfServiceCode": "11",
"claimFrequencyCode": "0",
"planParticipationCode": "C",
"benefitsAssignmentCertificationIndicator": "Y",
"releaseInformationCode": "Y",
"principalDiagnosis": {
"qualifierCode": "ABK",
"principalDiagnosisCode": "R45851"
},
"serviceLines": [
{
"assignedNumber": "0",
"serviceDate": "20241015",
"serviceDateEnd": "20241015",
"lineItemControlNumber": "111222333",
"institutionalService": {
"serviceLineRevenueCode": "0800",
"lineItemChargeAmount": "500.00",
"measurementUnit": "UN",
"serviceUnitCount": "1",
"procedureIdentifier": "HC",
"procedureCode": "H0001"
}
}
],
"claimCodeInformation": {
"admissionTypeCode": "3",
"admissionSourceCode": "9",
"patientStatusCode": "30"
},
"claimDateInformation": {
"admissionDateAndHour": "202409091000",
"statementBeginDate": "20241015",
"statementEndDate": "20241015"
}
},
"providers": [
{
"providerType": "BillingProvider",
"npi": "1999999976",
"employerId": "123456789",
"organizationName": "Test Facility",
"address": {
"address1": "123 Mulberry Street",
"city": "Seattle",
"state": "WA",
"postalCode": "111135272"
},
"contactInformation": {
"name": "Test Facility",
"phoneNumber": "2065551234"
}
},
{
"providerType": "AttendingProvider",
"npi": "1999999976",
"firstName": "Doctor",
"lastName": "Provider",
"contactInformation": {
"name": "name"
}
}
]
}'
```
```bash
curl --request POST \
--url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/institutionalclaims/v1/raw-x12-submission" \
--header "Authorization: " \
--header "Content-Type: application/json" \
--header "Idempotency-Key: " \
--data '{
"x12": "ISA*00* *00* *ZZ*574183004559 *ZZ*STEDITEST *260213*2004*^*00501*000000035*0*T*>~GS*HC*574183004559*STEDITEST*20260213*200422*35*X*005010X223A2~ST*837*0001*005010X223A2~BHT*0019*00*01KHC9KCMYMA7YSW4K1ZM774ZA*20260213*2003*CH~NM1*41*2*Test Facility*****46*123456789~PER*IC**TE*2225551234~NM1*40*2*UnitedHealthcare*****46*87726~HL*1**20*1~NM1*85*2*Test Facility*****XX*1999999976~N3*123 Mulberry Street~N4*Seattle*WA*111135272~REF*EI*123456789~HL*2*1*22*0~SBR*P*18*******ZZ~NM1*IL*1*DOE*JANE****MI*98765~N3*1234 Some St~N4*Buckeye*AZ*85326~DMG*D8*19000101*F~NM1*PR*2*UnitedHealthcare*****PI*87726~CLM*55556666777888*500***11>A>0**C*Y*Y~DTP*434*RD8*20241015-20241015~DTP*435*DT*202409091000~CL1*3*9*30~HI*ABK>R45851~NM1*71*1*Provider*Doctor****XX*1999999976~LX*1~SV2*0800*HC>H0001*500*UN*1~DTP*472*RD8*20241015-20241015~REF*6R*111222333~SE*28*0001~GE*1*35~IEA*1*000000035~"
}'
```
{/* schema:InstitutionalClaimsSubmissionResponseContent */}
```json
{
"status": "SUCCESS",
"controlNumber": "1",
"tradingPartnerServiceId": "87726",
"claimReference": {
"correlationId": "01KHC9G8FMGZ6CA9TQT704RAMB",
"patientControlNumber": "12345",
"timeOfResponse": "2026-02-13T20:01:34.919Z",
"formatVersion": "5010",
"rhClaimNumber": "01KHC9G8FMGZ6CA9TQT704RAMB",
"payerId": "87726",
"serviceLines": [
{
"lineItemControlNumber": "111222333"
}
]
},
"meta": {
"traceId": "65602add-af9c-4aec-9b8f-9fed3badab3c"
},
"payer": {
"payerName": "UnitedHealthcare",
"payerID": "87726"
},
"x12": "ISA*00* *00* *ZZ*STEDITEST *ZZ*574183004559 *260213*2001*^*00501*929135779*0*T*`~GS*HN*STEDITEST*574183004559*20260213*200134*1*X*005010X214~ST*277*0001*005010X214~BHT*0085*08*01KHC9GC66KDRVHEJC42Q103EQ*20260213*200134*TH~HL*1**20*1~NM1*AY*2*STEDI INC*****46*117151744~TRN*1*01KHC9GC66KDRVHEJC42Q103EQ~DTP*050*D8*20260213~DTP*009*D8*20260213~HL*2*1*21*1~NM1*41*2*Test Facility*****46*123456789~TRN*2*01KHC9G8FMGZ6CA9TQT704RAMB~STC*A0`17`AY*20260213*WQ*500.0~QTY*90*1~AMT*YU*500.0~HL*3*2*19*1~NM1*85*2*Test Facility*****XX*1999999976~TRN*1*0~REF*TJ*123456789~QTY*QA*1~AMT*YU*500.0~HL*4*3*PT*0~NM1*QC*1*DOE*JANE****MI*98765~TRN*2*12345~STC*A1`20*20260213*WQ*500.0~DTP*472*RD8*20241015-20241015~SE*25*0001~GE*1*1~IEA*1*929135779~",
"httpStatusCode": "200 OK"
}
```
### Test claims [#test-claims]
All claims you submit through the API are sent to the payer as production claims unless you explicitly designate them as test data.
To send test claims:
* **JSON endpoint:** Set the `usageIndicator` property in the test claim body to `T`.
* **X12 EDI endpoint:** Set `ISA15` (Interchange Usage Indicator) to `T` (Test Data) instead of `P` (Production Data).
When you send a test claim, Stedi doesn't send it to the payer. Instead, it processes the claim as if it were sent to the payer and returns a 277CA claim acknowledgment indicating whether the claim was successfully processed.
Designating a claim as test data also allows you to filter for test claims on the [Transactions](https://portal.stedi.com/app/core/transactions) page in the Stedi portal.
You'll receive a 277CA claim acknowledgment in response to test claims, but you won't receive a test 835 Electronic Remittance Advice (ERA) response unless you send the claim to the [Stedi Test Payer](https://www.stedi.com/healthcare/network?search=StediTest\&entry=FRCPB). Visit [Test claims workflow](/healthcare/test-claims-workflow) to learn how generate test ERAs.
### Concurrency limit [#concurrency-limit]
Institutional claim submission endpoints share a concurrency pool with other claim endpoints. For more information, visit [Concurrency limits](/healthcare/api-reference#concurrency-limits).
### Recommended API clients [#recommended-api-clients]
You may want to use an API client to make testing and debugging easier.
We **don't recommend** using Postman for requests containing Protected Health Information (PHI) because Postman defaults to storing request history - including full request payloads - on its cloud servers. You can’t turn this feature off without impractical workarounds.
Visit [API clients](/healthcare/api-reference#api-clients) for a list of recommended clients you can use instead.
## View submitted claims [#view-submitted-claims]
You can view the files that Stedi sends and receives in the [Transactions](https://portal.stedi.com/app/core/transactions) page of the Stedi portal.
On the [Transactions](https://portal.stedi.com/app/core/transactions) page, you can review and filter claims by **Usage** - production or test. Click any claim submission to review its details, including the full request and response payload.
## Worker's compensation, auto, and liability claims [#workers-compensation-auto-and-liability-claims]
You can submit workers' compensation, automobile medical, and liability claims through Stedi's UI, claim submission APIs, and SFTP. Visit [Worker's compensation, auto, and liability claims](/healthcare/submit-workers-comp-auto-liability-claims) for details.
## Submit claims to a secondary or tertiary payer [#submit-claims-to-a-secondary-or-tertiary-payer]
In [coordination of benefits (COB)](/healthcare/coordination-of-benefits) scenarios, you'll need to submit a claim to multiple payers.
You must set the `subscriber.paymentResponsibilityLevelCode` to either `S` (when submitting to the secondary payer) or `T` (when submitting to the tertiary payer).
You must also include the following information about how prior payers have adjudicated the claim. For example, if a patient's private insurance plan (primary payer) adjusted the requested reimbursement amount and paid for its portion of the services, you must include that information in the claim you submit to Medicare (secondary payer). You can find these details in 835 ERA responses from prior payers.
### Claim information [#claim-information]
You must submit one object in the `claimInformation.otherSubscriberInformation` array for each prior payer. Supply all the required properties in the object plus the following additional information:
* `claimLevelAdjustments`: Provide if the prior payer made adjustments at the claim level. Codes and their associated amounts must come from ERAs sent by the prior payers. You can find these codes in the ERA's [`transactions[].detailInfo[].paymentInfo[].claimAdjustments`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.claimAdjustments) array.
* `medicareInpatientAdjudication` (institutional claims only): You must include this if Medicare was one of the prior payers and reported inpatient adjudication information on the ERA.
* `medicareOutpatientAdjudication`: You must include this if Medicare was one of the prior payers and reported outpatient adjudication information on the ERA.
* `otherPayerName.otherPayerAdjudicationOrPaymentDate`: The date the payer adjudicated or paid the claim. You must provide this if you aren't providing a value in the `claimInformation.serviceLines[].lineAdjudicationInformation[].adjudicationOrPaymentDate` property.
* `payerPaidAmount`: This is the total amount in dollars the payer paid on this claim.
### Service line information [#service-line-information]
You must submit `serviceLines[].lineAdjudicationInformation` objects when the prior payers provided line-level adjudication information. Submit one object for each prior payer. For each object, you should include the following properties.
* `adjudicationOrPaymentDate`: The date the payer adjudicated or paid the claim. Don't include this if you're providing a date in the `otherPayerName.otherPayerAdjudicationOrPaymentDate` property.
* `claimAdjustmentInformation`: You can find this information in the ERA's [`transactions[].detailInfo[].paymentInfo[].serviceLines[].serviceAdjustments`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.serviceLines.serviceAdjustments) array.
* `otherPayerPrimaryIdentifier`: The identifier for the other payer. This value should match the identifier you supplied for the payer in the `claimInformation.otherSubscriberInformation[].otherPayerName.otherPayerIdentifier` property.
* `procedureCode`: The adjudicated procedure code for the service line.
* `serviceIdQualifier`: A code identify the type of procedure code. Visit [Claims code lists](/healthcare/claims-code-lists#composite-medical-procedure---product-or-service-id-qualifier-codes) for a complete list.
* `serviceLinePaidAmount`: The total amount in dollars the prior payer paid on this service line.
* `paidServiceUnitCount`: The number of paid units for the service line. When paid units are not present on the remittance advice, use the original billed units.
* `remainingPatientLiability`: The amount of the service line the patient is responsible for paying.
## Claim Filing Indicator Code [#claim-filing-indicator-code]
The Claim Filing Indicator Code indicates how a claim was filed with a payer, such as `MC` (Medicaid) or `CI` (Commercial Insurance Co.).
Choosing the correct claim filing indicator code is important for successful claim submission. Visit the [Claims code lists](/healthcare/claims-code-lists#choosing-the-right-code) documentation for best practices for selecting the appropriate code.
# Submit professional claims
Source: https://www.stedi.com/docs/healthcare/submit-professional-claims
You can send 837P professional claims to payers through the Stedi portal, the Professional Claims API, or an SFTP connection.
Once you send a claim, Stedi automatically receives and processes 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA) responses.
## Before sending claims [#before-sending-claims]
You may need to complete the following steps before sending claims.
### Transaction enrollment [#transaction-enrollment]
[Transaction enrollment](/healthcare/transaction-enrollment) is the process of registering a provider to exchange specific healthcare transactions with a payer. Some payers require enrollment before allowing providers to submit 837 claims through a new clearinghouse.
Enrolling through Stedi may cancel existing claims enrollments you have through other clearinghouses. We can help you determine whether this applies to your specific payers. However, enrolling through Stedi for 837 claims doesn't affect your existing enrollments for other transaction types. For example, enrolling with Stedi won't unenroll the provider from receiving transactions like Electronic Remittance Advices (ERAs) through other clearinghouses.
You can check whether a specific payer requires transaction enrollment for 837 claims in the [Payer Network](https://www.stedi.com/healthcare/network) or through the [Payers API](/healthcare/api-reference/get-payer).
To enroll, complete the following steps:
1. Create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step. [Stedi portal](https://portal.stedi.com/app/healthcare/providers) | [API endpoint](/healthcare/api-reference/post-enrollment-create-provider)
2. Submit an enrollment request for the claim type. [Stedi portal](https://portal.stedi.com/app/healthcare/enrollments) | [API endpoint](/healthcare/api-reference/post-enrollment-create-enrollment)
### Coordination of benefits check [#coordination-of-benefits-check]
We recommend running a coordination of benefits (COB) check to ensure you submit claims to the correct payer. COB checks can help you determine:
* If a patient is covered by more than one health plan
* Whether coverage overlap requires coordination of benefits
* Each payer’s responsibility for payment (primacy) in coordination of benefits scenarios
Visit [Coordination of benefits (COB) checks](/healthcare/coordination-of-benefits) for more information.
## UI submission [#ui-submission]
You can submit professional claims through the Stedi portal. Manual claim submission can be useful for testing, QA, and debugging your pipeline.
You can submit professional claims either through our interactive claim form or by uploading X12 EDI claim data.
### CMS-1500 claim form [#cms-1500-claim-form]
You can only submit claims to the patient's primary health plan through our interactive CMS-1500 form. You must submit secondary or tertiary claims through X12 EDI upload, API, or SFTP instead.
To submit a professional claim: Open the **Claims** menu and select **+ Submit professional claim**.
The submission form is based on the CMS-1500 Claim Form.
Enter the required information for your professional claim. Notably:
| Field | Instructions and Notes |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Stedi payer | Select a **Payer** from the dropdown list. Start typing to filter the list. |
| EDI mode | Select whether you want to submit a **Production** or **Test** claim.- Production claims are sent to the payer.
- Test claims aren't sent to the payer. Stedi validates them and displays them in the portal so you can get familiar with Stedi's claim processing workflow. Stedi responds to test claims with a 277CA claim acknowledgment, but you won't receive an 835 Electronic Remittance Advice (ERA).
|
| Patient account number | We strongly recommend submitting a unique value in **Box 26** (Patient acccount number). The identifier should be more complex than a simple sequential number and should be hard to guess. The payer returns this value in related transactions, such as the 277CA and 835 ERA, so you can correlate responses and real-time claim status checks with the original claim. - Keep it 17 characters or less. Some payers cut off values longer than 17 characters in ERAs and claim acknowledgments, which makes it hard to match them with the original claim.
- Use alphanumeric characters only. Avoid special characters, as many payers don't handle them properly.
- Use random strings. Formats with patient initials or the date of service in them can create duplicates.
|
| Line item control numbers | The line item control number is an identifier for each service line in **Box 24** (Service lines) that you can use correlate the original claim with the 835 ERA. - By default, Stedi automatically assigns line item control numbers for each service line.
- To set your own identifiers, click the **Set manual line item control numbers** in the service lines table. Line item control numbers must be 30 characters or less and unique within the claim.
Note that Stedi will automatically reuse the same line item control numbers if you resubmit this claim through the CMS-1500 form. |
| Attachments | You can submit claim-level attachments in **Box 19b** (Claim attachments) and service-line attachments in **Box 24** (Service lines). Note that you can't add attachments to claims that were already submitted through the portal. To include attachments for those, resubmit the claim with the attachments. - Click **+ Add attachment** (claim-level) or **Add attachment, note or NDC codes** (service-line) to specify the details for an attachment.
- Choose the appropriate **Report type** for each attachment.
- Choose the appropriate **Transmission code**. If you plan to upload an attachment file, set this to **EL (EDI)**. If you plan to submit the attachment through another method, such as directly through the payer's portal, set this to the appropriate code.
- Either enter the **Attachment control number** or click **Upload file** to select the file you want to attach. Supported file types are JPG, PDF, PNG, or TIFF. Each attachment should be 10 MB or less to comply with most payer requirements. You can add up to 10 attachment files at the claim level and up to 10 attachment files for each service line. If you included attachment files, Stedi automatically generates the required attachment control numbers for you.
|
When you're finished, click **Submit claim**. Stedi validates the claim and submits it to the payer. It will appear on the [claims view](https://portal.stedi.com/app/healthcare/claims) within a few minutes.
### X12 EDI upload [#x12-edi-upload]
Your X12 EDI claim data must adhere to the [837 Claim: Professional (X222A1)](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-professional-x222a1/01HR60MDFAGCSEJNKY8J38867Y) specification.
To manually submit an X12 EDI claim:
1. Go to the [transactions view](https://portal.stedi.com/app/healthcare/transactions).
2. Click **Submit claim** and choose **Upload EDI file** from the menu.
3. Do one of the following:
* Click **Upload X12 EDI** and select an existing `.edi` file to add.
* Select the transaction type and then paste the X12 EDI content into the text area.
4. Configure the settings to send a test or a production claim. Production claims are sent to payers. Test claims aren't sent to payers - Stedi's test clearinghouse processes them and returns test 277CA acknowledgments so you can evaluate your claim processing pipeline.
1. Select either **Test** or **Production** in the menu at the top of the text area.
2. Set `ISA15` (Interchange Usage Indicator) to `T` (Test Data) or `P` (Production Data), accordingly.
5. Fix any validation errors that appear after adding the claim X12 EDI content. Stedi highlights errors in red and displays the specification for the claim type you selected on the right side of the screen to make it easier to identify and fix issues.
6. Click **Submit claim** to submit the claim to Stedi.
Stedi processes the claim and takes you to the claim's details page. Stedi also displays the claim on the [claims view](https://portal.stedi.com/app/healthcare/claims) and the [transactions view](https://portal.stedi.com/app/healthcare/transactions).
## SFTP submission [#sftp-submission]
You can use Stedi’s fully-managed SFTP server to submit claims to to payers and retrieve claim responses without calling Stedi’s APIs.
You must submit claims in X12 EDI format, and Stedi returns claim responses through the SFTP connection in X12 EDI format. This makes Stedi SFTP a good option if you have an existing system that generates X12 EDI files and you want to send them through the Stedi clearinghouse without completing an API integration. Visit [SFTP connection](/healthcare/submit-claims-sftp-connection) for more information.
## API submission [#api-submission]
Call one of the following endpoints to submit 837P professional claims:
* [Professional Claims](/healthcare/api-reference/post-healthcare-claims) to send requests in JSON
* [Professional Claims Raw X12](/healthcare/api-reference/post-healthcare-claims-raw-x12) to send requests in X12 EDI
Both endpoints return a synchronous response from Stedi in JSON format. Later, the payer will respond with a 277CA claim acknowledgment.
### Headers [#headers]
When constructing the request, you must include the following information in HTTP headers:
* **`Authorization`:** [Generate an API key](https://portal.stedi.com/app/settings/api-keys) to use for authentication.
* **`Content-Type`:** Set to `application/json`.
#### Idempotency key [#idempotency-key]
We **strongly recommend** including an [idempotency key](/healthcare/api-reference#idempotency-keys) in the `Idempotency-Key` header to prevent sending duplicate claims to payers in the case of network errors or other intermittent failures. You can safely retry requests with the same idempotency key as many times as necessary within 24 hours after making the first request.
### Body - JSON [#body---json]
The information you submit for a claim depends on your use case. Refer to the [Professional Claims](/healthcare/api-reference/post-healthcare-claims) endpoint for a complete list of properties. However, all claims require the following high-level information:
{/* prettier-ignore-start */}
| Information | Description |
| --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tradingPartnerServiceId` | This is the payer ID. You can send requests using the primary payer ID, the Stedi payer ID, or any alias listed in the payer record. If you don't already have payer IDs you use today, we recommend using the primary Payer ID. Visit the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list. |
| `tradingPartnerName` | This is the payer's business name, like Cigna or Aetna. |
| `submitter` object | Information about the entity submitting the claim. This can be either an individual or an organization, such as a doctor, hospital, or insurance company. |
| `receiver` object | Information about the payer, such as an insurance company or government agency. |
| `subscriber` and/or `dependent` objects | Information about the patient who received the medical services. Note that if a dependent has their own, unique member ID for their health plan, you should submit their information in the `subscriber` object and omit the `dependent` object from the request. You can check whether the dependent has a unique member ID by submitting an [Eligibility Check](/healthcare/api-reference/post-healthcare-eligibility) to the payer for the dependent. The payer will return the member ID in the `dependents.memberId` field, if present. |
| `claimInformation` object | Information about the claim, such as the [patient control number](#patient-control-number-pcn), claim charge amount, and place of service code. It also includes information about each individual service line included in the claim. |
| `billing` object | Information about the billing provider, such as the [NPI](/healthcare/national-provider-identifier), taxonomy code, and organization name. |
{/* prettier-ignore-end */}
#### Patient Control Number [#patient-control-number]
You must submit a Patient Control Number (PCN) with each claim in [`claimInformation.patientControlNumber`](/healthcare/api-reference/post-healthcare-claims#body.claimInformation.patientControlNumber). The payer returns this value in related transactions, such as the 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA), so you can correlate responses and real-time claim status checks with the original claim.
When assigning a PCN, follow these best practices:
* Use a unique PCN for each claim. The identifier should be more complex than a simple sequential number and should be hard to guess.
* Use random strings. Formats with patient initials or the date of service in them can create duplicates. We recommend using [nanoid](https://www.npmjs.com/package/nanoid) or a similar library configured with the characters available in the [basic character set](#character-set) to create a strong, unique 17-character PCN for each claim.
* Keep it 17 characters or less. Some payers cut off values longer than 17 characters in ERAs and claim acknowledgments, which makes it hard to match them with the original claim.
* Use only characters available in the [basic character set](#character-restrictions), and avoid special characters that are only available in the extended character set. Payers are permitted to return data using the basic character set. Using other characters may result in data loss or mismatches when correlating claims with responses.
* Treat PCN values as case-insensitive when matching transactions, even if the submitted value included both lower and uppercase characters.
#### Service line identification [#service-line-identification]
A claim can contain multiple service lines. Since the payer may accept, reject, or pay a subset of those lines, you can receive an 835 ERA that references a `patientControlNumber`, but only pertains to some of the service lines.
However, the `claimInformation.serviceLines[].providerControlNumber` serves as a unique identifier for each service line in your claim submission. This value appears in the 277CA claim acknowledgment and 835 ERA as the `lineItemControlNumber`, allowing you to correlate these responses to specific service lines from the original claim. If you don't set the `providerControlNumber` for a service line, Stedi uses a random UUID.
Stedi returns service line identifiers in the `claimReference.serviceLines` array of the synchronous API response.
#### Conditional requirements [#conditional-requirements]
Note that objects marked as **required** are required for all requests, while others are conditionally required depending on the circumstances. When you include a conditionally required object, you must include all of its required properties.
For example, you must always include the `subscriber` object in your request, but you only need to include the `supervising` object when the rendering provider is supervised by a physician.
### Body - X12 EDI [#body---x12-edi]
You must send a payload in [837 X12 EDI format](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-professional-x222a1/01HR60MDFAGCSEJNKY8J38867Y).
Note the following requirements and behavior when sending professional claims through the raw X12 endpoint.
#### Envelope and header [#envelope-and-header]
Stedi generates its own `ISA` and `GS` headers and `IEA` and `GE` trailers before sending your claim to the payer. You can submit your claim to Stedi with any values in these segments, as long as they conform to the X12 EDI specification.
However, you must set `ST03` (Implementation Guide Version Name) to `005010X222A1`.
#### Payer ID [#payer-id]
You must submit a payer identifier in `Loop 2010BB` (Payer Name) `NM109` so Stedi can route your claim to the correct payer. This identifier **must** be a payer ID or payer ID alias listed in the [Payer Network](https://www.stedi.com/healthcare/network). If you don't already have payer IDs you use today, we recommend using the primary Payer ID.
You must include leading `0` characters in payer IDs. For example, use `00540` for SISCO, not `540`.
#### `CLM01` (Patient Control Number) [#clm01-patient-control-number]
We **strongly recommend** submitting a unique value for `Loop 2300` (Claim Information) `CLM01` (Patient Control Number). The payer returns this value in related transactions, such as the 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA), so you can correlate responses and real-time claim status checks with the original claim.
When assigning a PCN, follow these best practices:
* Use a unique PCN for each claim. The identifier should be more complex than a simple sequential number and should be hard to guess.
* Use random strings. Formats with patient initials or the date of service in them can create duplicates. We recommend using [nanoid](https://www.npmjs.com/package/nanoid) or a similar library configured with the characters available in the [basic character set](#character-set) to create a strong, unique 17-character PCN for each claim.
* Keep it 17 characters or less. Some payers cut off values longer than 17 characters in ERAs and claim acknowledgments, which makes it hard to match them with the original claim.
* Use only characters available in the [basic character set](#character-restrictions), and avoid special characters that are only available in the extended character set. Payers are permitted to return data using the basic character set. Using other characters may result in data loss or mismatches when correlating claims with responses.
* Treat PCN values as case-insensitive when matching transactions, even if the submitted value included both lower and uppercase characters.
#### Service line identification [#service-line-identification-1]
A claim can contain multiple service lines. Since the payer may accept, reject, or pay a subset of those lines, you can receive an 835 response that references a patient control number, but only pertains to some of the service lines.
However, the line item control number serves as a unique identifier for each service line in your claim submission.
* You can set the line item control number in `Loop 2400 REF02`, when `REF01` = `6R`. The line item control number appears in the 277CA and 835 ERA responses as the `lineItemControlNumber`, allowing you to correlate these responses to specific service lines from the original claim.
* If you don’t set the line item control number for a service line, Stedi uses a ULID.
### Character restrictions [#character-restrictions]
Only use the X12 Basic and Extended character sets in request data. Using characters outside these sets may cause errors.
The X12 Basic character set includes uppercase letters, digits, space, and some special characters. Lowercase letters and special language characters like `ñ` are not included.
The following special characters are included:
The Extended character set includes the characters listed in Basic, plus lowercase letters and additional special characters, such as `@`.
The following additional special characters are included:
In addition, the following characters are reserved for delimiters in the final X12 EDI transaction to the payer: `~`, `*`, `:` and `^`. X12 doesn't support using escape sequences to represent delimiters or special characters. Stedi returns a `400` error if you use these restricted characters improperly.
* **JSON endpoint:** Don’t include delimiter characters anywhere in your request data.
* **Raw X12 endpoint:** You can use these characters as delimiters, but not in the body of the request data.
### Sample request and response [#sample-request-and-response]
The following examples send a professional claim. The response shape is the same for both the JSON and X12 EDI endpoints. It contains summary information from Stedi about the claim submission and whether it was successful.
The response also includes an initial [277CA claim acknowledgment](/healthcare/claim-responses-overview#277ca-claim-acknowledgment) from Stedi in the `x12` property, which indicates whether the claim passed Stedi's claim edits.
{/* schema:ClaimsSubmissionRequestContent */}
{/* replace::1234567890 */}
{/* replace::1234567890 */}
```bash
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--header 'Idempotency-Key: ' \
--data '{
"usageIndicator": "T",
"tradingPartnerServiceId": "6400",
"submitter": {
"organizationName": "Test Data Health Services, Inc.",
"submitterIdentification": "",
"contactInformation": {
"name": "Test Data Health Services, Inc.",
"phoneNumber": "5552223333"
}
},
"receiver": {
"organizationName": "Cigna"
},
"subscriber": {
"memberId": "U7777788888",
"paymentResponsibilityLevelCode": "P",
"subscriberGroupName": "Cigna",
"firstName": "John",
"lastName": "Anon",
"gender": "M",
"dateOfBirth": "20000101",
"groupNumber": "3335555",
"address": {
"address1": "2222 Random St",
"city": "A City",
"state": "NY",
"postalCode": "123450000"
}
},
"billing": {
"providerType": "BillingProvider",
"npi": "",
"employerId": "123456789",
"taxonomyCode": "2084P0800X",
"organizationName": "Therapy Associates",
"address": {
"address1": "123 Some St",
"address2": "Floor 1",
"city": "A City",
"state": "NY",
"postalCode": "123450000"
},
"contactInformation": {
"name": "Test Data Health Services, Inc.",
"phoneNumber": "5553334444"
}
},
"claimInformation": {
"claimFilingCode": "CI",
"patientControlNumber": "",
"claimChargeAmount": "109.20",
"placeOfServiceCode": "02",
"claimFrequencyCode": "1",
"signatureIndicator": "Y",
"planParticipationCode": "A",
"benefitsAssignmentCertificationIndicator": "Y",
"releaseInformationCode": "Y",
"healthCareCodeInformation": [
{
"diagnosisTypeCode": "ABK",
"diagnosisCode": "F1111"
}
],
"serviceFacilityLocation": {
"organizationName": "Smith Associates",
"address": {
"address1": "1234 Other St",
"city": "A City",
"state": "NY",
"postalCode": "123450000"
},
"npi": "1999999984"
},
"serviceLines": [
{
"serviceDate": "20240101",
"professionalService": {
"procedureIdentifier": "HC",
"procedureCode": "90837",
"procedureModifiers": [
"95"
],
"lineItemChargeAmount": "109.20",
"measurementUnit": "UN",
"serviceUnitCount": "1",
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": [
"1"
]
}
},
"providerControlNumber": "111222333",
"renderingProvider": {
"providerType": "RenderingProvider",
"npi": "",
"taxonomyCode": "111YP2000X",
"firstName": "Jane",
"lastName": "Smith"
}
}
]
},
"tradingPartnerName": "Cigna"
}'
```
```bash
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/raw-x12-submission \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--header 'Idempotency-Key: ' \
--data '{
"x12": "ISA*00* *00* *ZZ*574183004559 *ZZ*STEDITEST *260213*2039*^*00501*000000039*0*T*>~GS*HC*574183004559*STEDITEST*20260213*203918*39*X*005010X222A1~ST*837*0001*005010X222A1~BHT*0019*00*01KHCBK84E40QQYJVXA5VVXG54*20260213*2038*CH~NM1*41*2*Test Data Health Services, Inc.*****46*123435~PER*IC**TE*5552223333~NM1*40*2*Cigna*****46*6400~HL*1**20*1~PRV*BI*PXC*2084P0800X~NM1*85*2*Therapy Associates*****XX*1999999984~N3*123 Some St*Floor 1~N4*A City*NY*123450000~REF*EI*123456789~PER*IC*Test Data Health Services, Inc.*TE*5553334444~HL*2*1*22*0~SBR*P*18*3335555******CI~NM1*IL*1*Anon*John****MI*U7777788888~N3*2222 Random St~N4*A City*NY*123450000~DMG*D8*20000101*M~NM1*PR*2*Cigna*****PI*6400~CLM*123456789*109.2***02>B>1*Y*A*Y*Y~HI*ABK>F1111~NM1*77*2*Smith Associates~N3*1234 Other St~N4*A City*NY*123450000~LX*1~SV1*HC>90837>95*109.2*UN*1***1~DTP*472*D8*20240101~REF*6R*111222333~SE*29*0001~GE*1*39~IEA*1*000000039~"
}'
```
{/* schema:ClaimsSubmissionResponseContent */}
```json
{
"status": "SUCCESS",
"controlNumber": "1",
"tradingPartnerServiceId": "6400",
"claimReference": {
"correlationId": "01KHC8Y4HNP0GVQ5NSVTPZBC0F",
"patientControlNumber": "111222333",
"timeOfResponse": "2026-02-13T19:51:51.496Z",
"payerId": "6400",
"formatVersion": "5010",
"rhclaimNumber": "01KHC8Y4HNP0GVQ5NSVTPZBC0F",
"serviceLines": [
{
"lineItemControlNumber": "111222333"
}
]
},
"meta": {
"traceId": "d61ca4bc-e9e7-4d0f-93d0-6f7ff810b0e6"
},
"payer": {
"payerName": "Cigna",
"payerId": "6400"
},
"x12": "ISA*00* *00* *ZZ*STEDITEST *ZZ*574183004559 *260213*1951*^*00501*980180479*0*T*`~GS*HN*STEDITEST*574183004559*20260213*195151*1*X*005010X214~ST*277*0001*005010X214~BHT*0085*08*01KHC8YJE8EY6A5HFR00Z5H305*20260213*195151*TH~HL*1**20*1~NM1*AY*2*STEDI INC*****46*117151744~TRN*1*01KHC8YJE8EY6A5HFR00Z5H305~DTP*050*D8*20260213~DTP*009*D8*20260213~HL*2*1*21*1~NM1*41*2*Test Data Health Services, Inc.*****46*123456~TRN*2*01KHC8Y4HNP0GVQ5NSVTPZBC0F~STC*A0`17`AY*20260213*WQ*109.2~QTY*90*1~AMT*YU*109.2~HL*3*2*19*1~NM1*85*2*Therapy Associates*****XX*1234567890~TRN*1*0~REF*TJ*123456789~QTY*QA*1~AMT*YU*109.2~HL*4*3*PT*0~NM1*QC*1*Anon*John****MI*U7777788888~TRN*2*111222333~STC*A1`20*20260213*WQ*109.2~DTP*472*RD8*20240101-20240101~SE*25*0001~GE*1*1~IEA*1*980180479~",
"httpStatusCode": "200 OK"
}
```
### Test claims [#test-claims]
All claims you submit through the API are sent to the payer as production claims unless you explicitly designate them as test data.
To send test claims:
* **JSON endpoint:** Set the `usageIndicator` property in the test claim body to `T`.
* **X12 EDI endpoint:** Set `ISA15` (Interchange Usage Indicator) to `T` (Test Data) instead of `P` (Production Data).
When you send a test claim, Stedi doesn't send it to the payer. Instead, it processes the claim as if it were sent to the payer and returns a 277CA claim acknowledgment indicating whether the claim was successfully processed.
Designating a claim as test data also allows you to filter for test claims on the [Transactions](https://portal.stedi.com/app/core/transactions) page in the Stedi portal.
You'll receive a 277CA claim acknowledgment in response to test claims, but you won't receive a test 835 Electronic Remittance Advice (ERA) response unless you send the claim to the [Stedi Test Payer](https://www.stedi.com/healthcare/network?search=StediTest\&entry=FRCPB). Visit [Test claims workflow](/healthcare/test-claims-workflow) to learn how generate test ERAs.
### Concurrency limit [#concurrency-limit]
Professional claim submission endpoints share a concurrency pool with other claim endpoints. For more information, visit [Concurrency limits](/healthcare/api-reference#concurrency-limits).
### Recommended API clients [#recommended-api-clients]
You may want to use an API client to make testing and debugging easier.
We **don't recommend** using Postman for requests containing Protected Health Information (PHI) because Postman defaults to storing request history - including full request payloads - on its cloud servers. You can’t turn this feature off without impractical workarounds.
Visit [API clients](/healthcare/api-reference#api-clients) for a list of recommended clients you can use instead.
## View submitted claims [#view-submitted-claims]
You can view the files that Stedi sends and receives on the [Files](https://portal.stedi.com/app/core/file-executions) page of the Stedi portal.
On the [Transactions](https://portal.stedi.com/app/core/transactions) page, you can review and filter claims by **Usage** - production or test. Click any claim submission to review its details, including the full request and response payload, processing events, and a link to download the auto-generated 1500 Claim Form PDF.
## 275 claim attachments [#275-claim-attachments]
If the claim requires attachments, you must include additional details about the attachments in the appropriate objects:
* Attachments for entire claim: [`claimInformation.claimSupplementalInformation.reportInformation`](/healthcare/api-reference/post-healthcare-claims#body.claimInformation.claimSupplementalInformation.reportInformation) or [`claimInformation.claimSupplementalInformation.reportInformations`](/healthcare/api-reference/post-healthcare-claims#body.claimInformation.claimSupplementalInformation.reportInformations) (multiple attachments)
* Attachments for a specific service line: [`claimInformation.serviceLines[].serviceLineSupplementalInformation`](/healthcare/api-reference/post-healthcare-claims#body.claimInformation.serviceLines.serviceLineSupplementalInformation)
Visit [Claim attachments](/healthcare/submit-claim-attachments) for complete instructions.
## Worker's compensation, auto, and liability claims [#workers-compensation-auto-and-liability-claims]
You can submit workers' compensation, automobile medical, and liability claims through Stedi's UI, claim submission APIs, and SFTP. Visit [Worker's compensation, auto, and liability claims](/healthcare/submit-workers-comp-auto-liability-claims) for details.
## Submit to a secondary or tertiary payer [#submit-to-a-secondary-or-tertiary-payer]
In [coordination of benefits (COB)](/healthcare/coordination-of-benefits) scenarios, you'll need to submit a claim to multiple payers.
You must set the `subscriber.paymentResponsibilityLevelCode` to either `S` (when submitting to the secondary payer) or `T` (when submitting to the tertiary payer).
You must also include the following information about how prior payers have adjudicated the claim. For example, if a patient's private insurance plan (primary payer) adjusted the requested reimbursement amount and paid for its portion of the services, you must include that information in the claim you submit to Medicare (secondary payer). You can find these details in 835 ERA responses from prior payers.
### Claim information [#claim-information]
You must submit one object in the `claimInformation.otherSubscriberInformation` array for each prior payer. Supply all the required properties in the object plus the following additional information:
* `claimLevelAdjustments`: Provide if the prior payer made adjustments at the claim level. Codes and their associated amounts must come from ERAs sent by the prior payers. You can find these codes in the ERA's [`transactions[].detailInfo[].paymentInfo[].claimAdjustments`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.claimAdjustments) array.
* `medicareInpatientAdjudication` (institutional claims only): You must include this if Medicare was one of the prior payers and reported inpatient adjudication information on the ERA.
* `medicareOutpatientAdjudication`: You must include this if Medicare was one of the prior payers and reported outpatient adjudication information on the ERA.
* `otherPayerName.otherPayerAdjudicationOrPaymentDate`: The date the payer adjudicated or paid the claim. You must provide this if you aren't providing a value in the `claimInformation.serviceLines[].lineAdjudicationInformation[].adjudicationOrPaymentDate` property.
* `payerPaidAmount`: This is the total amount in dollars the payer paid on this claim.
### Service line information [#service-line-information]
You must submit `serviceLines[].lineAdjudicationInformation` objects when the prior payers provided line-level adjudication information. Submit one object for each prior payer. For each object, you should include the following properties.
* `adjudicationOrPaymentDate`: The date the payer adjudicated or paid the claim. Don't include this if you're providing a date in the `otherPayerName.otherPayerAdjudicationOrPaymentDate` property.
* `claimAdjustmentInformation`: You can find this information in the ERA's [`transactions[].detailInfo[].paymentInfo[].serviceLines[].serviceAdjustments`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.serviceLines.serviceAdjustments) array.
* `otherPayerPrimaryIdentifier`: The identifier for the other payer. This value should match the identifier you supplied for the payer in the `claimInformation.otherSubscriberInformation[].otherPayerName.otherPayerIdentifier` property.
* `procedureCode`: The adjudicated procedure code for the service line.
* `serviceIdQualifier`: A code identify the type of procedure code. Visit [Claims code lists](/healthcare/claims-code-lists#composite-medical-procedure---product-or-service-id-qualifier-codes) for a complete list.
* `serviceLinePaidAmount`: The total amount in dollars the prior payer paid on this service line.
* `paidServiceUnitCount`: The number of paid units for the service line. When paid units are not present on the remittance advice, use the original billed units.
* `remainingPatientLiability`: The amount of the service line the patient is responsible for paying.
## Claim Filing Indicator Code [#claim-filing-indicator-code]
The Claim Filing Indicator Code indicates how a claim was filed with a payer, such as `MC` (Medicaid) or `CI` (Commercial Insurance Co.).
Choosing the correct claim filing indicator code is important for successful claim submission. Visit the [Claims code lists](/healthcare/claims-code-lists#choosing-the-right-code) documentation for best practices for selecting the appropriate code.
## Set a claim's correlation ID [#set-a-claims-correlation-id]
A claim's correlation ID is a business identifier that you can use to track and manage claims.
* When you submit claims through the JSON endpoint, Stedi generates the correlation ID for you, and this value will be unique for each claim.
* When you submit claims in X12 EDI through the API or an [SFTP connection](/healthcare/submit-claims-sftp-connection), you can specify your own correlation ID in the `BHT03` element. This allows you to use the same value for multiple claims if desired.
## CMS-1500 claim form PDF [#cms-1500-claim-form-pdf]
Stedi automatically generates a PDF [CMS-1500 claim form](https://www.nucc.org/index.php/1500-claim-form-mainmenu-35) for each professional claim you submit. You can manually download the form on the transaction details page for the claim in the Stedi portal or retrieve them programmatically through the following endpoints:
* [CMS-1500 PDF: Business Identifier](/healthcare/api-reference/get-pdf-1500-business-identifier): Retrieve PDFs through a claim's business identifier. You can find the business identifier value in the `claimReference.correlationId` property Stedi returns in the synchronous claim submission response.
* [CMS-1500 PDF: Transaction ID
](/healthcare/api-reference/get-pdf-1500): Retrieve PDFs through the `transactionId` Stedi assigns to the processed claim. This ID is included in the transaction processed event for the claim, which you can receive automatically through [webhooks](/healthcare/configure-webhooks). You can also retrieve this ID from the transaction's details page in Stedi.
Payers have strict requirements for submitted CMS-1500 claim forms. If you plan to send generated PDFs to payers or retain them for your records, we strongly recommend visiting [CMS-1500 Claim Form PDF](/healthcare/cms-1500-claim-form-pdf) for information about how to structure claim submissions for optimal generation, the correct printer settings for generated PDFs, and general best practices.
# Workers' compensation and automobile claims
Source: https://www.stedi.com/docs/healthcare/submit-workers-comp-auto-liability-claims
Workers' compensation and automobile (auto) claims are a subset of property and casualty claims (P\&C). They're required when an injury or illness is related to work or a motor vehicle accident. These claim types are different than standard medical claims because:
* They're typically submitted to different payers than the patient's primary insurance, such as state workers' compensation boards or auto insurance companies.
* They often require additional information, such as accident details and attachments to support the claim.
* They may be subject to different rules and regulations, which can vary by state and payer.
You can submit workers' compensation and auto claims through Stedi's UI, claim submission APIs, and SFTP. **Currently, only 837P professional claim transactions are supported.**
There is an additional cost to submit these claim types. Contact Stedi customer support for details.
## Transaction enrollment [#transaction-enrollment]
There is no enrollment required for workers' compensation or auto claims. There is also no transaction enrollment required for their associated 835 Electronic Remittance Advice (ERAs).
You can only receive 835 ERAs for workers' compensation claims through the clearinghouse you used for the claim submission. That means you can't split claim submission and ERA receipt between Stedi and another clearinghouse.
## Submit claims [#submit-claims]
You'll submit workers' compensation and auto claims to Stedi the same way you submit standard medical claims.
* **Stedi portal:** From the [transactions view](https://portal.stedi.com/app/healthcare/transactions), click **Submit claim**. You can either:
* **Upload EDI file**: Submit raw X12 EDI files.
* **Submit manually:** Complete a virtual CMS-1500 claim form.
* **SFTP:** Upload X12 EDI files to Stedi's SFTP server. Visit [SFTP claim submission](/healthcare/submit-claims-sftp-connection) for details.
* **API:** Submit claims through either of the following endpoints:
* [Professional Claims JSON](/healthcare/api-reference/post-healthcare-claims)
* [Professional Claims Raw X12](/healthcare/api-reference/post-healthcare-claims-raw-x12)
You'll provide much of the same information as standard medical claims, such as details about the patient, provider, and amount billed. However, workers' compensation and auto claims have the following additional requirements.
### Payer [#payer]
You must submit the claim to the payer responsible for processing the patient's compensation or auto claim. This is typically a different payer than the one you would use for the patient's standard medical claims. Contact Stedi support for a list of our supported workers' compensation and auto payers.
You can identify the payer using any Payer ID or alias listed in the Payer Network. When submitting claims, you'll indicate the payer in:
* **JSON:** `tradingPartnerServiceId`
* **X12 EDI:** `Loop 2010BB NM109` (Payer Identifier)
### Claim Filing Indicator Code [#claim-filing-indicator-code]
Set the Claim Filing Indicator Code to `WC` (Workers' Compensation Health Claim) or `AM` (Automobile Medical). This is what differentiates the claim from a standard medical claim.
When submitting claims, you'll indicate the Claim Filing Indicator Code in:
* **JSON:** `claimInformation.claimFilingCode`
* **X12 EDI:** `Loop 2000B SBR09` (Claim Filing Indicator Code)
### Patient information [#patient-information]
The subscriber is the entity that holds the insurance policy, and the patient is the individual who received care. Note that for workers' compensation claims, the subscriber is typically the employer.
You'll submit the subscriber information in:
* **JSON:** `subscriber` object
* **X12 EDI:** `Loop 2000B` (Subscriber)
You'll submit the patient's information in:
* **JSON:** `dependent` object
* **X12 EDI:** `Loop 2000C` (Patient)
### Individual Relationship Code [#individual-relationship-code]
The Individual Relationship Code indicates the relationship between the patient and the insurance holder.
* For all workers' compensation claims and auto claims where the insurer is *not* the same entity as the patient, leave this empty.
* For auto claims where the patient is the insurance holder, set this to `18` (Self).
When required, you'll indicate the Individual Relationship Code in:
* **JSON:** Stedi automatically sets the Individual Relationship Code to `18` in the final X12 EDI transaction to the payer when you include the patient's information in the `subscriber` object instead of the `dependent` object. There is no property to set this in JSON.
* **X12 EDI:** `Loop 2000B SBR02` (Individual Relationship Code)
### Attachments [#attachments]
Many workers' compensation and auto claims require attachments to support the claim. For example, you may need to include an accident report, test results, or medical records. Attachments are sent to the payer as separate 275 transactions that you link to the claim through an attachment control number.
Attachments aren't yet supported for workers' compensation and auto claims submitted through Stedi. You'll need to submit attachments directly to the payer and reference the attachment in your claim submission. Visit [Attachments](/healthcare/submit-claim-attachments) for details.
### Additional information [#additional-information]
You may need to include additional information in workers' compensation and auto claims that you don't typically include on standard medical claims. For example, you may need to include accident details such as the date, time, and location of the accident.
Review the payer's requirements for these claim types to ensure you include all necessary information.
### State board auto-submission [#state-board-auto-submission]
The New York Workers' Compensation Board requires that workers' compensation claims are submitted both to the clearinghouse and directly to their system.
We automatically send a copy of submitted claims to the New York Workers' Compensation Board. You don't need to do anything else to meet this requirement.
## Examples [#examples]
The following examples show claims in both JSON and X12 EDI format.
### Workers' compensation [#workers-compensation]
The following examples show a workers' compensation claim:
* The [Claim Filing Indicator Code](#claim-filing-indicator-code) is set to `WC` to indicate that this is a workers' compensation claim.
* The [Individual Relationship Code](#individual-relationship-code) is left empty because the subscriber (the employer) is not the same entity as the patient.
* The subscriber for most workers' compensation claims is the employer. In JSON, the patient's details are in the `dependent` object. In X12 EDI, the patient's details are in `Loop 2000C PAT` (Patient Information).
* The claim includes references to an attachment that supports the claim. In JSON, this is the `claimSupplementalInformation` object because the attachment is relevant for the entire claim. In X12 EDI submissions, this is `Loop 2300 PWK` (Claim Supplemental Information). Visit [Reference attachments in a claim](/healthcare/submit-claim-attachments#reference-attachments-in-a-claim) for more details.
```json
{
"tradingPartnerServiceId": "WCPAYER",
"usageIndicator": "T",
"billing": {
"address": {
"address1": "123 Some St",
"city": "Pittsburgh",
"postalCode": "12345",
"state": "VA"
},
"contactInformation": {
"name": "Billing Contact",
"phoneNumber": "1234567890"
},
"employerId": "123456789",
"npi": "1999999984",
"organizationName": "Billing Dr Last Name",
"providerType": "BillingProvider",
"taxonomyCode": "207QG0300X"
},
"claimInformation": {
"benefitsAssignmentCertificationIndicator": "Y",
"claimChargeAmount": "2160.00",
"claimFilingCode": "WC",
"claimFrequencyCode": "1",
"healthCareCodeInformation": [
{
"diagnosisCode": "G8250",
"diagnosisTypeCode": "ABK"
},
{
"diagnosisCode": "S24101A",
"diagnosisTypeCode": "ABF"
},
{
"diagnosisCode": "S060X0A",
"diagnosisTypeCode": "ABF"
}
],
"patientControlNumber": "123456",
"placeOfServiceCode": "11",
"planParticipationCode": "A",
"releaseInformationCode": "Y",
"serviceFacilityLocation": {
"address": {
"address1": "Addr 1",
"city": "City",
"postalCode": "99999",
"state": "ST"
},
"npi": "1999999984",
"organizationName": "Facility"
},
"serviceLines": [
{
"professionalService": {
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": [
"1",
"2",
"3"
]
},
"lineItemChargeAmount": "2148.00",
"measurementUnit": "UN",
"procedureCode": "A4353",
"procedureIdentifier": "HC",
"serviceUnitCount": "400.00"
},
"providerControlNumber": "111222333444",
"renderingProvider": {
"firstName": "James",
"lastName": "Smith",
"npi": "1999999984",
"providerType": "RenderingProvider",
"taxonomyCode": "111N00000X"
},
"serviceDate": "20181219"
},
{
"professionalService": {
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": [
"1",
"2",
"3"
]
},
"lineItemChargeAmount": "12.00",
"measurementUnit": "UN",
"procedureCode": "A9901",
"procedureIdentifier": "HC",
"serviceUnitCount": "1.00"
},
"providerControlNumber": "5555566667777888",
"renderingProvider": {
"firstName": "Preferred",
"lastName": "Medical Network",
"npi": "1999999984",
"providerType": "Supplier",
"taxonomyCode": "207RG0300X"
},
"serviceDate": "20181219"
}
],
"signatureIndicator": "Y",
"claimSupplementalInformation": {
"reportInformation": {
"attachmentReportTypeCode": "07",
"attachmentTransmissionCode": "EL",
"attachmentControlNumber": "12345"
}
}
},
"receiver": {
"organizationName": "WC PAYER"
},
"submitter": {
"contactInformation": {
"name": "Contact Name",
"phoneNumber": "1234567890"
},
"organizationName": "Submitting Company",
"submitterIdentification": "44444444"
},
"subscriber": {
"address": {
"address1": "Addr 1",
"city": "City",
"postalCode": "99999",
"state": "ST"
},
"lastName": "EmployerName",
"memberId": "123456789",
"paymentResponsibilityLevelCode": "P"
},
"dependent": {
"firstName": "Jane",
"lastName": "Doe",
"address": {
"address1": "Addr 1",
"city": "City",
"postalCode": "99999",
"state": "WA"
},
"dateOfBirth": "19900101",
"gender": "F",
"relationshipToSubscriberCode": "20"
}
}
```
```bash
curl --request POST \
--url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission" \
--header "Authorization: " \
--header "Content-Type: application/json" \
--data '{
"tradingPartnerServiceId": "WCPAYERID",
"usageIndicator": "T",
"billing": {
"address": {
"address1": "123 Some St",
"city": "Pittsburgh",
"postalCode": "12345",
"state": "VA"
},
"contactInformation": {
"name": "Billing Contact",
"phoneNumber": "1234567890"
},
"employerId": "123456789",
"npi": "1999999984",
"organizationName": "Billing Dr Last Name",
"providerType": "BillingProvider",
"taxonomyCode": "207QG0300X"
},
"claimInformation": {
"benefitsAssignmentCertificationIndicator": "Y",
"claimChargeAmount": "2160.00",
"claimFilingCode": "WC",
"claimFrequencyCode": "1",
"healthCareCodeInformation": [
{
"diagnosisCode": "G8250",
"diagnosisTypeCode": "ABK"
},
{
"diagnosisCode": "S24101A",
"diagnosisTypeCode": "ABF"
},
{
"diagnosisCode": "S060X0A",
"diagnosisTypeCode": "ABF"
}
],
"patientControlNumber": "123456",
"placeOfServiceCode": "11",
"planParticipationCode": "A",
"releaseInformationCode": "Y",
"serviceFacilityLocation": {
"address": {
"address1": "Addr 1",
"city": "City",
"postalCode": "99999",
"state": "ST"
},
"npi": "1999999984",
"organizationName": "Facility"
},
"serviceLines": [
{
"professionalService": {
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": [
"1",
"2",
"3"
]
},
"lineItemChargeAmount": "2148.00",
"measurementUnit": "UN",
"procedureCode": "A4353",
"procedureIdentifier": "HC",
"serviceUnitCount": "400.00"
},
"providerControlNumber": "111222333444",
"renderingProvider": {
"firstName": "James",
"lastName": "Smith",
"npi": "1999999984",
"providerType": "RenderingProvider",
"taxonomyCode": "111N00000X"
},
"serviceDate": "20181219"
},
{
"professionalService": {
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": [
"1",
"2",
"3"
]
},
"lineItemChargeAmount": "12.00",
"measurementUnit": "UN",
"procedureCode": "A9901",
"procedureIdentifier": "HC",
"serviceUnitCount": "1.00"
},
"providerControlNumber": "5555566667777888",
"renderingProvider": {
"firstName": "Preferred",
"lastName": "Medical Network",
"npi": "1999999984",
"providerType": "Supplier",
"taxonomyCode": "207RG0300X"
},
"serviceDate": "20181219"
}
],
"signatureIndicator": "Y",
"claimSupplementalInformation": {
"reportInformation": {
"attachmentReportTypeCode": "07",
"attachmentTransmissionCode": "EL",
"attachmentControlNumber": "12345"
}
}
},
"receiver": {
"organizationName": "WC PAYER"
},
"submitter": {
"contactInformation": {
"name": "Contact Name",
"phoneNumber": "1234567890"
},
"organizationName": "Submitting Company",
"submitterIdentification": "44444444"
},
"subscriber": {
"address": {
"address1": "Addr 1",
"city": "City",
"postalCode": "99999",
"state": "ST"
},
"lastName": "EmployerName",
"memberId": "123456789",
"paymentResponsibilityLevelCode": "P"
},
"dependent": {
"firstName": "Jane",
"lastName": "Doe",
"address": {
"address1": "Addr 1",
"city": "City",
"postalCode": "99999",
"state": "WA"
},
"dateOfBirth": "19900101",
"gender": "F",
"relationshipToSubscriberCode": "20"
}
}'
```
```text
ISA*00* *00* *ZZ*311573142P *ZZ*205367462 *190101*1317*^*00501*000000050*1*T*:~
GS*HC*ISA SENDER ID*205367462*20140522*0926*8*X*005010X222A1~
ST*837*0008*005010X222A1~
BHT*0019*00*8*20190522*0926*CH~
NM1*41*2*SUBMITTING COMPANY*****46*ISA SENDER ID~
PER*IC*CONTACT NAME*TE*1234567890~
NM1*40*2*WORKCOMPEDI*****46*205367462~
HL*1**20*1~
NM1*85*1*BILLING DR LAST NAME* BILLING DR FIRST NAME ****XX*1999999984~
N3*ADDR 1~
N4*CITY*ST*99999~
REF*EI*123456789~
PER*IC*DOCTOR NAME*TE*1234567890~
HL*2*1*22*0~
SBR*P********WC~
NM1*IL*2*EMPLOYER NAME*****MI*123456789~
N3*ADDR 1~
N4*CITY*ST*99999~
NM1*PR*2*WC PAYER*****PI*WCPAYERID~
N3*123 SOME ST~
N4*PITTSBURGH*VA*12345~
HL*3*2*23*0~
PAT*20~
NM1*QC*1*DOE*JANE~
N3*ADDR 1~
N4*CITY*ST*9999~
DMG*D8*19900101*F~
REF*Y4*123456789~
REF*SY*999999999~
CLM*L174065*2160.00***12:B:1*Y*A*Y*Y*P*EM~
DTP*439*D8*20160608~
PWK*OZ*EL***AC*AttachmentName~
HI*ABK:G8250*ABF:S24101A*ABF:S060X0A~
HCP*02*1880.00~
NM1*82*1*SMITH*JAMES****XX*1999999984~
PRV*PE*PXC*111N00000X~
NM1*77*2*FACILITY*****XX*FACILITY NPI~
N3*ADDR 1~
N4*CITY*ST*99999~
LX*1~
SV1*HC:A4353:NU::::Intermittent Urinary Catheter*2148.00*UN*400.00***1:2:3~
SV5*HC:A4353*DA*400.00*0*2148.00*4~
DTP*472*D8*20181219~
HCP*02*6808.00~
NM1*DQ*1*Preferred Medical Network~
REF*0B*1750529582~
LX*2~
SV1*HC:A9901:::::DME Dispensing Service Fee*12.00*UN*1.00***1:2:3~
SV5*HC:A9901*DA*1.00*0*12.00*4~
DTP*472*D8*20181219~
HCP*02*60.00~
NM1*DQ*1*Preferred Medical Network~
REF*0B*1750529582~
SE*52*0008~
GE*1*8~
IEA*1*000000050~
```
```bash
curl --request POST \
--url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/raw-x12-submission" \
--header "Authorization: " \
--header "Content-Type: application/json" \
--data '{
"x12": "ISA*00* *00* *ZZ*311573142P *ZZ*205367462 *190101*1317*^*00501*000000050*1*T*:~GS*HC*ISA SENDER ID*205367462*20140522*0926*8*X*005010X222A1~ST*837*0008*005010X222A1~BHT*0019*00*8*20190522*0926*CH~NM1*41*2*SUBMITTING COMPANY*****46*ISA SENDER ID~PER*IC*CONTACT NAME*TE*1234567890~NM1*40*2*WORKCOMPEDI*****46*205367462~HL*1**20*1~NM1*85*1*BILLING DR LAST NAME* BILLING DR FIRST NAME ****XX*1999999984~N3*ADDR 1~N4*CITY*ST*99999~REF*EI*123456789~PER*IC*DOCTOR NAME*TE*1234567890~HL*2*1*22*0~SBR*P********WC~NM1*IL*2*EMPLOYER NAME*****MI*123456789~N3*ADDR 1~N4*CITY*ST*99999~NM1*PR*2*WC PAYER*****PI*WCPAYERID~N3*123 SOME ST~N4*PITTSBURGH*VA*12345~HL*3*2*23*0~PAT*20~NM1*QC*1*DOE*JANE~N3*ADDR 1~N4*CITY*ST*9999~DMG*D8*19900101*F~REF*Y4*123456789~REF*SY*999999999~CLM*L174065*2160.00***12:B:1*Y*A*Y*Y*P*EM~DTP*439*D8*20160608~PWK*OZ*EL***AC*AttachmentName~HI*ABK:G8250*ABF:S24101A*ABF:S060X0A~HCP*02*1880.00~NM1*82*1*SMITH*JAMES****XX*1999999984~PRV*PE*PXC*111N00000X~NM1*77*2*FACILITY*****XX*FACILITY NPI~N3*ADDR 1~N4*CITY*ST*99999~LX*1~SV1*HC:A4353:NU::::Intermittent Urinary Catheter*2148.00*UN*400.00***1:2:3~SV5*HC:A4353*DA*400.00*0*2148.00*4~DTP*472*D8*20181219~HCP*02*6808.00~NM1*DQ*1*Preferred Medical Network~REF*0B*1750529582~LX*2~SV1*HC:A9901:::::DME Dispensing Service Fee*12.00*UN*1.00***1:2:3~SV5*HC:A9901*DA*1.00*0*12.00*4~DTP*472*D8*20181219~HCP*02*60.00~NM1*DQ*1*Preferred Medical Network~REF*0B*1750529582~SE*52*0008~GE*1*8~IEA*1*000000050~"
}'
```
### Auto [#auto]
The following examples show an auto claim:
* The [Claim Filing Indicator Code](#claim-filing-indicator-code) is set to `AM` to indicate that this is an auto claim.
* The [Individual Relationship Code](#individual-relationship-code) is set to `18` (Self) because the patient is also the subscriber (insurance holder).
* The claim includes information about the accident, including:
* The Related Causes Code is set to `AA` to indicate that the claim is related to an auto accident. This is `relatedCausesCode` in JSON and `Loop 2300 CLM11-01` in X12 EDI.
* The jurisdiction state, which is typically where the accident occurred. This is `autoAccidentStateCode` in JSON and `Loop 2300 CLM11-04` in X12 EDI.
* The date of the accident. This is `accidentDate` in JSON and `Loop 2300 DTP03` in X12 EDI.
* The subscriber is the patient. Therefore, this claim doesn't include a `dependent` object in JSON or `Loop 2010CA` (Patient) in X12 EDI.
```json
{
"tradingPartnerServiceId": "AUTOPAYERID",
"usageIndicator": "T",
"billing": {
"address": {
"address1": "123 Some St",
"city": "Pittsburgh",
"postalCode": "12345",
"state": "VA"
},
"contactInformation": {
"name": "Billing Contact",
"phoneNumber": "1234567890"
},
"employerId": "123456789",
"npi": "1999999984",
"organizationName": "Billing Dr Last Name",
"providerType": "BillingProvider"
},
"rendering": {
"firstName": "John",
"lastName": "Smith",
"npi": "1999999984",
"providerType": "RenderingProvider",
"taxonomyCode": "207Q00000X"
},
"claimInformation": {
"claimChargeAmount": "1450.00",
"claimFilingCode": "AM",
"claimFrequencyCode": "1",
"patientControlNumber": "AUTO12345",
"placeOfServiceCode": "12",
"signatureIndicator": "Y",
"releaseInformationCode": "Y",
"planParticipationCode": "A",
"benefitsAssignmentCertificationIndicator": "Y",
"patientSignatureSourceCode": true,
"relatedCausesCode": [
"AA"
],
"autoAccidentStateCode": "IL",
"claimDateInformation": {
"accidentDate": "20251015"
},
"claimSupplementalInformation": {
"reportInformation": {
"attachmentReportTypeCode": "OZ",
"attachmentTransmissionCode": "EL",
"attachmentControlNumber": "12345"
}
},
"healthCareCodeInformation": [
{
"diagnosisCode": "S12300A",
"diagnosisTypeCode": "ABK"
},
{
"diagnosisCode": "M25511",
"diagnosisTypeCode": "ABF"
}
],
"claimPricingRepricingInformation": {
"pricingMethodologyCode": "00",
"repricedAllowedAmount": "1450.00"
},
"serviceFacilityLocation": {
"address": {
"address1": "123 Main St",
"city": "City",
"postalCode": "99999",
"state": "IL"
},
"npi": "1999999984",
"organizationName": "Auto Health Clinic"
},
"serviceLines": [
{
"professionalService": {
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": [
"1"
]
},
"measurementUnit": "UN",
"procedureCode": "97110",
"procedureIdentifier": "HC",
"procedureModifiers": [
"GP"
],
"lineItemChargeAmount": "200.00",
"serviceUnitCount": "1.00",
"description": "Therapeutic Exercise"
},
"providerControlNumber": "111222333444",
"serviceDate": "20251016"
},
{
"professionalService": {
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": [
"1"
]
},
"procedureModifiers": [
"25"
],
"lineItemChargeAmount": "1250.00",
"measurementUnit": "UN",
"procedureCode": "99213",
"procedureIdentifier": "HC",
"serviceUnitCount": "1.00",
"description": "Office Visit"
},
"providerControlNumber": "5555566667777888",
"serviceDate": "20251017"
}
]
},
"receiver": {
"organizationName": "AUTO PAYER"
},
"submitter": {
"contactInformation": {
"name": "Contact Person",
"phoneNumber": "1234567890"
},
"organizationName": "Auto Billing Services",
"submitterIdentification": "777777777"
},
"subscriber": {
"address": {
"address1": "Addr 1",
"city": "City",
"postalCode": "99999",
"state": "ST"
},
"firstName": "Jane",
"lastName": "Doe",
"memberId": "123456789",
"dateOfBirth": "19900101",
"gender": "F",
"paymentResponsibilityLevelCode": "P"
}
}
```
```bash
curl --request POST \
--url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission" \
--header "Authorization: " \
--header "Content-Type: application/json" \
--data '{
"tradingPartnerServiceId": "AUTOPAYERID",
"usageIndicator": "T",
"billing": {
"address": {
"address1": "123 Some St",
"city": "Pittsburgh",
"postalCode": "12345",
"state": "VA"
},
"contactInformation": {
"name": "Billing Contact",
"phoneNumber": "1234567890"
},
"employerId": "123456789",
"npi": "1999999984",
"organizationName": "Billing Dr Last Name",
"providerType": "BillingProvider"
},
"rendering": {
"firstName": "John",
"lastName": "Smith",
"npi": "1999999984",
"providerType": "RenderingProvider",
"taxonomyCode": "207Q00000X"
},
"claimInformation": {
"claimChargeAmount": "1450.00",
"claimFilingCode": "AM",
"claimFrequencyCode": "1",
"patientControlNumber": "AUTO12345",
"placeOfServiceCode": "12",
"signatureIndicator": "Y",
"releaseInformationCode": "Y",
"planParticipationCode": "A",
"benefitsAssignmentCertificationIndicator": "Y",
"patientSignatureSourceCode": true,
"relatedCausesCode": [
"AA"
],
"autoAccidentStateCode": "IL",
"claimDateInformation": {
"accidentDate": "20251015"
},
"claimSupplementalInformation": {
"reportInformation": {
"attachmentReportTypeCode": "OZ",
"attachmentTransmissionCode": "EL",
"attachmentControlNumber": "12345"
}
},
"healthCareCodeInformation": [
{
"diagnosisCode": "S12300A",
"diagnosisTypeCode": "ABK"
},
{
"diagnosisCode": "M25511",
"diagnosisTypeCode": "ABF"
}
],
"claimPricingRepricingInformation": {
"pricingMethodologyCode": "00",
"repricedAllowedAmount": "1450.00"
},
"serviceFacilityLocation": {
"address": {
"address1": "123 Main St",
"city": "City",
"postalCode": "99999",
"state": "IL"
},
"npi": "1999999984",
"organizationName": "Auto Health Clinic"
},
"serviceLines": [
{
"professionalService": {
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": [
"1"
]
},
"measurementUnit": "UN",
"procedureCode": "97110",
"procedureIdentifier": "HC",
"procedureModifiers": [
"GP"
],
"lineItemChargeAmount": "200.00",
"serviceUnitCount": "1.00",
"description": "Therapeutic Exercise"
},
"providerControlNumber": "111222333444",
"serviceDate": "20251016"
},
{
"professionalService": {
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": [
"1"
]
},
"procedureModifiers": [
"25"
],
"lineItemChargeAmount": "1250.00",
"measurementUnit": "UN",
"procedureCode": "99213",
"procedureIdentifier": "HC",
"serviceUnitCount": "1.00",
"description": "Office Visit"
},
"providerControlNumber": "5555566667777888",
"serviceDate": "20251017"
}
]
},
"receiver": {
"organizationName": "AUTO PAYER"
},
"submitter": {
"contactInformation": {
"name": "Contact Person",
"phoneNumber": "1234567890"
},
"organizationName": "Auto Billing Services",
"submitterIdentification": "777777777"
},
"subscriber": {
"address": {
"address1": "Addr 1",
"city": "City",
"postalCode": "99999",
"state": "ST"
},
"firstName": "Jane",
"lastName": "Doe",
"memberId": "123456789",
"dateOfBirth": "19900101",
"gender": "F",
"paymentResponsibilityLevelCode": "P"
}
}'
```
```
ISA*00* *00* *ZZ*777777777 *ZZ*205367462 *251107*1030*^*00501*000000089*1*T*:~
GS*HC*AUTOCLAIMX12*205367462*20251107*1030*10*X*005010X222A1~
ST*837*0010*005010X222A1~
BHT*0019*00*AUTO12345*20251107*1030*CH~
NM1*41*2*AUTO BILLING SERVICES*****46*777777777~
PER*IC*Contact Person*TE*1234567890~
NM1*40*2*AUTOPAYER*****46*AUTOPAYER~
HL*1**20*1~
NM1*85*1*BILLING DR LAST NAME*****XX*1999999984~
N3*123 SOME ST~
N4*PITTSBURGH*VA*12345~
REF*EI*123456789~
PER*IC*BILLING CONTACT*TE*1234567890~
HL*2*1*22*0~
SBR*P*18*******AM~
NM1*IL*1*DOE*JANE****MI*123456789~
N3*ADDR 1~
N4*CITY*ST*99999~
DMG*D8*19900101*F~
NM1*PR*2*ABC AUTO INSURANCE*****PI*AUTOPAYERID~
N3*123 SOME ST~
N4*PITTSBURGH*VA*12345~
CLM*AUTO12345*1450.00***12:B:1*Y*A*Y*Y*P*AA:::IL~
DTP*439*D8*20251015~
PWK*OZ*EL***AC*12345~
HI*ABK:S12300A*ABF:M25511~
HCP*00*1450.00~
NM1*82*1*SMITH*JOHN****XX*1999999984~
PRV*PE*PXC*207Q00000X~
NM1*77*2*AUTO HEALTH CLINIC*****XX*1999999984~
N3*123 Main St~
N4*City*IL*99999~
LX*1~
SV1*HC:97110:GP::::Therapeutic Exercise*200.00*UN*1***1~
DTP*472*D8*20251016~
REF*6R*111222333444~
LX*2~
SV1*HC:99213:25::::Office Visit*1250.00*UN*1***1~
DTP*472*D8*20251017~
REF*6R*5555566667777888~
SE*39*0010~
GE*1*10~
IEA*1*000000089~
```
```bash
curl --request POST \
--url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/raw-x12-submission" \
--header "Authorization: " \
--header "Content-Type: application/json" \
--data '{
"x12": " ISA*00* *00* *ZZ*777777777 *ZZ*205367462 *251107*1030*^*00501*000000089*1*T*:~GS*HC*AUTOCLAIMX12*205367462*20251107*1030*10*X*005010X222A1~ST*837*0010*005010X222A1~BHT*0019*00*AUTO12345*20251107*1030*CH~NM1*41*2*AUTO BILLING SERVICES*****46*777777777~PER*IC*Contact Person*TE*1234567890~NM1*40*2*AUTOPAYER*****46*AUTOPAYER~HL*1**20*1~NM1*85*1*BILLING DR LAST NAME*****XX*1999999984~N3*123 SOME ST~N4*PITTSBURGH*VA*12345~REF*EI*123456789~PER*IC*BILLING CONTACT*TE*1234567890~HL*2*1*22*0~SBR*P*18*******AM~NM1*IL*1*DOE*JANE****MI*123456789~N3*ADDR 1~N4*CITY*ST*99999~DMG*D8*19900101*F~NM1*PR*2*ABC AUTO INSURANCE*****PI*AUTOPAYERID~N3*123 SOME ST~N4*PITTSBURGH*VA*12345~CLM*AUTO12345*1450.00***12:B:1*Y*A*Y*Y*P*AA:::IL~DTP*439*D8*20251015~PWK*OZ*EL***AC*12345~HI*ABK:S12300A*ABF:M25511~HCP*00*1450.00~NM1*82*1*SMITH*JOHN****XX*1999999984~PRV*PE*PXC*207Q00000X~NM1*77*2*AUTO HEALTH CLINIC*****XX*1999999984~N3*123 Main St~N4*City*IL*99999~LX*1~SV1*HC:97110:GP::::Therapeutic Exercise*200.00*UN*1***1~DTP*472*D8*20251016~REF*6R*111222333444~LX*2~SV1*HC:99213:25::::Office Visit*1250.00*UN*1***1~DTP*472*D8*20251017~REF*6R*5555566667777888~SE*39*0010~GE*1*10~IEA*1*000000089~"
}'
```
## 835 Electronic Remittance Advice (ERAs) [#835-electronic-remittance-advice-eras]
Some payers don't support electronic 835 Electronic Remittance Advice (ERA) transactions. You can expect to receive a paper Explanation of Benefits (EOB) from payers if Stedi's [Payer Network](https://www.stedi.com/healthcare/network) doesn't list 835 ERA support.
For payers that do support electronic 835 ERAs, you'll always receive them through the clearinghouse you used for the claim submission. That means you can't split claim submission and ERA receipt between Stedi and another clearinghouse.
Visit [Acknowledgments and ERAs](/healthcare/claim-responses-overview) for details about the kinds of electronic responses you can expect to receive for claims, how to retrieve them, and how to correlate them back to the original claim.
# Support
Source: https://www.stedi.com/docs/healthcare/support
We encourage you to contact us with questions, feedback, or for help using our products.
## Contact us [#contact-us]
We make every effort to respond as soon as possible, particularly to urgent requests. For both general support requests and billing inquiries, you can contact us through the following methods:
* [Website](https://www.stedi.com/contact) for all request types
* Email [support@stedi.com](mailto:support@stedi.com) for support requests, billing questions, and/or set up a dedicated Slack or Teams channel
When you report an issue, please include the following:
* A description of the issue, including the current behavior and the expected behavior
* Your Stedi account ID, if you submit through our website
* Screenshots showing the problem, when possible
# Supported payers
Source: https://www.stedi.com/docs/healthcare/supported-payers
Stedi supports thousands of medical and dental payers. You can get details about all supported payers through our interactive Payer Network, our Payers API, or the Stedi Agent.
## Find payer details [#find-payer-details]
You can use the following methods to determine:
* The transaction types supported for each payer.
* The payer IDs you need to send transactions through Stedi.
* Which payers support medical, dental, and vision use cases.
* The states and territories where each payer operates.
* Which payers require [transaction enrollment](/healthcare/transaction-enrollment) before you can begin exchanging transactions.
### Payer Network [#payer-network]
Visit the [Payer Network](https://www.stedi.com/healthcare/network) to review a searchable list of supported payers.
### Payers API [#payers-api]
You can use the following endpoints to search for payers and retrieve their details.
* [Retrieve payer](/healthcare/api-reference/get-payer): Retrieve a specific payer record using the [Stedi payer ID](/healthcare/supported-payers#stedi-payer-id), a unique identifier Stedi assigns to each payer that will never change
* [List Payers JSON](/healthcare/api-reference/get-payers): List all supported payers in JSON format - pagination is supported
* [List Payers CSV](/healthcare/api-reference/get-payers-csv): List all supported payers in CSV format
* [Search Payers](/healthcare/api-reference/get-search-payers): Search for payers by name, payer ID, or payer ID alias - fuzzy matching is supported. Results are returned in JSON format.
These endpoints are especially useful when you want to embed payer details or search capabilities into your system or application. For example, you could use the Search Payers endpoint to allow patients to search for and select their insurance provider in a patient intake form.
### Stedi Agent [#stedi-agent]
You can chat with the Stedi Agent to get information about supported payers. To use it, you must be at least an [Operator](/healthcare/accounts-and-billing#members) role within your Stedi account.
To start chatting with the Stedi Agent:
1. Go to the [Chats page](https://portal.stedi.com/app/healthcare/chats) in the Stedi portal.
2. Click **New chat** and select **Payer Finder**.
3. Type your question in the chat window and press **Enter.** For example, you could ask "What is the payer ID for Aetna?" or "Does Cigna support dental use cases?" You can also ask more complex questions, like "Which payers support dental use cases and require transaction enrollment?" Talk to Stedi Agent like you would a human support agent.
4. Ask follow-up questions as needed. You can ask multiple questions about different payers in the same chat.
The Stedi Agent will respond to your questions and display its answers in the chat window.
## Medical, dental, and vision payers [#medical-dental-and-vision-payers]
You can determine which payers support medical use cases, dental use cases, vision use cases, or all three.
* The [Payer Network](https://www.stedi.com/healthcare/network) lists **Coverage types** for each payer that indicate supported use cases.
* The [Retrieve Payer](/healthcare/api-reference/get-payer), [List Payers](/healthcare/api-reference/get-payers), and [Search Payers](/healthcare/api-reference/get-search-payers) endpoints return a `coverageTypes` array for each payer indicating supported use cases.
For example, Aetna's **Coverage types** in the network are **Dental, Medical, Vision**. That means you can submit eligibility checks and claims for medical, dental, and vision services to Aetna.
## Operating states [#operating-states]
Operating states refer to the geographical areas where a payer sells insurance plans. This can differ from the location of the payer's legal headquarters and from the location of the patient's home or work address.
For example, if a company is headquartered in Washington (WA), an employee in their Georgia office could still have Premera WA coverage. In this case, WA is the operating state because that's where the plan is sold.
You can determine where payers operate.
* The [Payer Network](https://www.stedi.com/healthcare/network) lists **Operating states** for each payer that indicate where they operate.
* The [Retrieve Payer](/healthcare/api-reference/get-payer), [List Payers](/healthcare/api-reference/get-payers), and [Search Payers](/healthcare/api-reference/get-search-payers) endpoints return an `operatingStates` array for each payer indicating where they operate.
For example, Cigna's **Operating states** in the network are **NATIONAL**, indicating that Cigna operates throughout the entire United States.
## Other names [#other-names]
The Payer Network includes other names for many payers. These additional names help you search for and identify payers using the name most familiar to your organization. For example, “Eaton Benefits Ohio” is an alternative associated with “Cigna”—searching for either name returns the same payer within the database.
## Payer IDs [#payer-ids]
The Payer Network includes three types of payer IDs. You can use any of these IDs to send transactions through Stedi.
You must include leading `0` characters in payer IDs. For example, use `00540`
for SISCO, not `540`.
### Primary payer ID (recommended) [#primary-payer-id-recommended]
The primary payer ID is the most commonly used ID for a payer and most often corresponds to the name the payer uses internally and provides to patients on member ID cards.
When you don't already have a payer ID you use for a particular payer, we recommend using the primary Payer ID.
### Stedi payer ID [#stedi-payer-id]
The Stedi payer ID is a unique identifier Stedi assigns to each payer. This ID will not change, even if the primary payer ID is updated. We maintain a list of Stedi payer IDs to ensure that 1) you can always refer to a payer using a consistent identifier, 2) we can more easily route requests to the payer through the most reliable connection behind the scenes, and 3) we can update our products without introducing breaking changes.
You may want to use the Stedi payer ID for requests if you are building a system that requires a consistent and immutable set of payer IDs.
### Payer ID aliases [#payer-id-aliases]
These are alternative IDs associated with a payer. If a payer changes their primary payer ID, payer ID aliases ensure that customers who still refer to the old ID can find the payer and continue sending transactions to the payer uninterrupted. Some payers also have different payer IDs for different plans. Payer ID aliases ensure that requests using these IDs are routed to the same payer.
## Stedi payer errors [#stedi-payer-errors]
Stedi returns the following error messages when a payer is not supported or enrolled properly.
{/* prettier-ignore-start */}
| Error message | Possible causes and resolutions |
| --------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Payer is not configured for {transaction type}. Please contact Stedi support to resolve.` | Stedi does not yet support this transaction type for this payer, or there is a mis-mapping of payer IDs. Contact us with the name of the payer, and we'll investigate the issue. |
| `Payer connection does not support {transaction type}. Please contact Stedi support to discuss connectivity options.` | Stedi has a connection to this payer, but it doesn't currently support this functionality (real-time eligibility or claim submission). Contact us for a timeline on enabling it. |
| `Payer is not configured. Please check our published payer list or contact Stedi support to resolve.` | Stedi doesn't recognize the payer ID you provided. Double-check the payer ID in the [Stedi Payer Network](https://www.stedi.com/healthcare/network), or contact us with the name of the payer, and we will help you determine the correct payer ID. |
| `Payer is not supported. Please contact Stedi support to discuss connectivity options.` | Stedi doesn't yet have connectivity to this payer. We're likely already working on it - contact us for details about the connectivity timeline. |
{/* prettier-ignore-end */}
# Test claims workflow
Source: https://www.stedi.com/docs/healthcare/test-claims-workflow
You can submit test professional, dental, and institutional claims to make sure your claims process is working smoothly from end to end. When you submit test claims to the [Stedi Test Payer](https://www.stedi.com/healthcare/network?search=StediTest\&entry=FRCPB), Stedi generates and returns an 835 Electronic Remittance Advice (ERA) based on the original claim.
## Submit test claims [#submit-test-claims]
You can submit test claims with any payer ID and receive test 277CA claim acknowledgments from Stedi. This helps you test your claim submission workflow and practice interpreting and handling 277CA responses.
To send test claims:
* **JSON endpoints:** Set the `usageIndicator` property in the test claim body to `T`.
* **X12 EDI endpoints and SFTP:** Set `ISA15` (Interchange Usage Indicator) to `T` (Test Data) instead of `P` (Production Data).
* **Stedi portal**: Designate the claim as a test claim during the submission process.
* In the [1500 claim form](https://portal.stedi.com/app/healthcare/claims/create), select **Test** for the **EDI mode**.
* During [X12 EDI upload](https://portal.stedi.com/app/healthcare/claims/upload), set `ISA15` (Interchange Usage Indicator) to `T` (Test Data).
Stedi processes the claim and applies our entire catalog of [edits and repairs](/healthcare/claim-edits-and-repairs).
### Test 277CAs [#test-277cas]
When you submit a test claim to any payer, Stedi returns a test 277CA claim acknowledgment indicating whether the claim was successfully processed.
## View test claims [#view-test-claims]
When you designate a claim as test data, you can:
* View it in test mode from the [claims view](https://portal.stedi.com/app/healthcare/claims). Toggle test mode to **ON** to review test claims and their associated responses.
* Filter for test claims on the [transactions view](https://portal.stedi.com/app/core/transactions). The following example shows the **Transactions** page filtered to show only 837 claims. There are two test claims (indicated by the **Test** badge) and one production claim.
## Generate test ERAs [#generate-test-eras]
When you submit test claims to the [Stedi Test Payer](https://www.stedi.com/healthcare/network?search=StediTest\&entry=FRCPB), Stedi returns a test 277CA claim acknowledgment and a test 835 Electronic Remittance Advice (ERA) based on the original claim. Only test claims you send to the Stedi Test Payer will generate a test 835 ERA.
You can use this approach to test your claims processing workflow from end to end.
### Enroll with the Stedi Test Payer [#enroll-with-the-stedi-test-payer]
You must enroll your provider with the [Stedi Test Payer](https://www.stedi.com/healthcare/network?search=StediTest\&entry=FRCPB) for **835 Claim payment**. Visit [Create and manage transaction enrollments](/healthcare/create-manage-transaction-enrollments) for instructions on how to submit an enrollment request.
Once submitted, the enrollment request is automatically set to `LIVE` status within one minute. You can start submitting test claims to the Stedi Test Payer immediately after enrollment.
### Submit a test claim [#submit-a-test-claim]
Submit a test claim to the Stedi Test Payer. Ensure that you:
* Designate the claim as test data:
* JSON endpoints: Set the `usageIndicator` property to `T`.
* X12 EDI endpoints and SFTP: Set `ISA15` to `T`.
* Stedi portal: Specify that this is a test claim in the submission form.
* Set the payer to the [Stedi Test Payer](https://www.stedi.com/healthcare/network?search=StediTest\&entry=FRCPB).
* Use the billing provider NPI and tax ID you enrolled with the Stedi Test Payer.
The following example shows how to submit a test professional claim to the Stedi Test Payer using the [Professional Claims](/healthcare/api-reference/post-healthcare-claims) JSON endpoint.
{/* schema:ClaimsSubmissionRequestContent */}
{/* replace::1234567890 */}
{/* replace::1234567890 */}
```bash
curl --request POST \
--url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission" \
--header "Authorization: " \
--header "Content-Type: application/json" \
--data '{
"tradingPartnerName": "Stedi Test Payer",
"tradingPartnerServiceId": "STEDITEST",
"usageIndicator": "T",
"billing": {
"address": {
"address1": "123 Some St",
"address2": "Floor 1",
"city": "A City",
"postalCode": "123450000",
"state": "NY"
},
"contactInformation": {
"name": "Test Data Health Services, Inc.",
"phoneNumber": "5553334444"
},
"employerId": "",
"npi": "",
"organizationName": "Therapy Associates",
"providerType": "BillingProvider",
"taxonomyCode": "2084P0800X"
},
"claimInformation": {
"benefitsAssignmentCertificationIndicator": "Y",
"claimChargeAmount": "109.20",
"claimFilingCode": "CI",
"claimFrequencyCode": "1",
"healthCareCodeInformation": [
{
"diagnosisCode": "F1111",
"diagnosisTypeCode": "ABK"
}
],
"patientControlNumber": "",
"placeOfServiceCode": "02",
"planParticipationCode": "A",
"releaseInformationCode": "Y",
"serviceFacilityLocation": {
"address": {
"address1": "1234 Other St",
"city": "A City",
"postalCode": "123450000",
"state": "NY"
},
"npi": "1999999984",
"organizationName": "Smith Associates"
},
"serviceLines": [
{
"professionalService": {
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": [
"1"
]
},
"lineItemChargeAmount": "109.20",
"measurementUnit": "UN",
"procedureCode": "90837",
"procedureIdentifier": "HC",
"procedureModifiers": [
"95"
],
"serviceUnitCount": "1"
},
"providerControlNumber": "111222333",
"renderingProvider": {
"firstName": "Jane",
"lastName": "Smith",
"npi": "1999999984",
"providerType": "RenderingProvider",
"taxonomyCode": "111YP2000X"
},
"serviceDate": "20240101"
}
],
"signatureIndicator": "Y"
},
"receiver": {
"organizationName": "Stedi"
},
"submitter": {
"contactInformation": {
"name": "Test Data Health Services, Inc.",
"phoneNumber": "5552223333"
},
"organizationName": "Test Data Health Services, Inc.",
"submitterIdentification": ""
},
"subscriber": {
"address": {
"address1": "2222 Random St",
"city": "A City",
"postalCode": "123450000",
"state": "NY"
},
"dateOfBirth": "20000101",
"firstName": "John",
"gender": "M",
"groupNumber": "3335555",
"lastName": "Anon",
"memberId": "U7777788888",
"paymentResponsibilityLevelCode": "P",
"subscriberGroupName": "Test ERAs Group"
}
}'
```
### Test responses [#test-responses]
Stedi returns the following responses within minutes of submitting a test claim to the Stedi Test Payer:
* A test 277CA claim acknowledgment response indicating whether the claim was successfully processed. Note that if Stedi rejects the claim in the 277CA, you won't receive a test 835 ERA.
* A test 835 Electronic Remittance Advice (ERA) containing information from the original claim, including the same:
* Provider information
* Patient information
* Service line details
* Charges
Test 835 ERAs always indicate that all service lines are paid, with the same charge amounts you submitted in the test claim. Note that when you submit production claims, payers may send ERAs with different outcomes, including partially paid, denied, split, or bundled claims.
## Retrieve test responses [#retrieve-test-responses]
You can retrieve test 277CAs and 835 ERAs through the following methods:
### APIs [#apis]
You can retrieve responses through Stedi's reports endpoints. Visit [Get and correlate acknowledgments and ERAs](/healthcare/receive-claim-responses) for details.
### SFTP [#sftp]
Claim responses will appear in your server's `from-stedi` directory. Visit [SFTP submission](/healthcare/submit-claims-sftp-connection#retrieve-claim-responses) for details.
### Stedi portal [#stedi-portal]
You can review claim responses in the Stedi portal through the claims view or the transactions view (classic).
#### Claims view [#claims-view]
You can review test 277CAs from the [claims view](https://portal.stedi.com/app/healthcare/claims).
1. Toggle test mode to **ON**. You can only view test claims and responses when test mode is active.
2. Click a claim to view a timeline of its processing activity.
3. Click an **Acknowledgment** (277CA) to review its details.
Stedi displays key information about the 277CA, including the billing provider's information and status codes.
#### Transactions view [#transactions-view]
You can review both 277CAs and 835 ERAs from the [transactions view](https://portal.stedi.com/app/healthcare/transactions). Click any transaction to view its details.
You can also access responses through the **Related transactions** tab of the original claim submission.
1. Go to the [transactions view](https://portal.stedi.com/app/healthcare/transactions).
2. Click the claim to review its details.
3. Click **Related transactions** to go to a list of related transactions, including 277CA and 835 ERA responses.
## Correlate test responses [#correlate-test-responses]
Both the test 277CA and the test 835 ERA will include the Patient Control Number you specified in the claim submission, which is what you can use to match these responses to the original claim.
### 277CA claim acknowledgment [#277ca-claim-acknowledgment]
* **JSON:** [`transactions[].payers[].claimStatusTransactions[].claimStatusDetails[].patientClaimStatusDetails[].claims[].claimStatus.patientAccountNumber`](/healthcare/api-reference/get-healthcare-reports-277#response.transactions.payers.claimStatusTransactions.claimStatusDetails.patientClaimStatusDetails.claims.claimStatus.patientAccountNumber)
* **X12 EDI:** `Loop 2200D TRN02` (Patient Control Number)
* **Stedi portal:** Do one of the following:
* Go to the [claims view](https://portal.stedi.com/app/healthcare/claims) and click a claim to open its timeline. All associated 277CAs are listed in the timeline view. Click a 277CA to review its details, including the **Patient control number**.
* Go to the [transactions view](https://portal.stedi.com/app/healthcare/transactions), find the 277CA, and click it to review its **Overview** tab. The Patient Control Number is displayed as the **Patient account number**. You can also go to the **Related transactions** tab to find links to related transactions, including the original claim.
### 835 Electronic Remittance Advice (ERA) [#835-electronic-remittance-advice-era]
* **JSON:** [`transactions[].detailInfo[].paymentInfo[].claimPaymentInfo.patientControlNumber`](/healthcare/api-reference/get-healthcare-reports-835#response.transactions.detailInfo.paymentInfo.claimPaymentInfo.patientControlNumber)
* **X12 EDI:** `Loop 2100 CLP01` (Patient Control Number)
* **Stedi portal:** Go to the [transactions view](https://portal.stedi.com/app/healthcare/transactions), find the 835 ERA, and click it to review its **Overview** tab. The Patient Control Number is listed as the first number in the **Claim identifiers** field.
# Test mode
Source: https://www.stedi.com/docs/healthcare/test-mode
Test mode provides a separate test environment where you can realistically simulate transactions in your Stedi account without PHI/PII and without sending any data to payers.
You can access test mode in your account at any time by toggling **Test mode** to **ON**.
## Send mock eligibility checks [#send-mock-eligibility-checks]
Mock transactions you send in test mode are free for testing purposes and
won’t incur any charges from Stedi.
You can submit mock real-time eligibility checks through the manual [eligibility check form](https://portal.stedi.com/app/healthcare/checks/create). You can choose from a variety of predefined requests for well-known payers, including:
* Aetna
* Cigna
* UnitedHealthcare
* National Centers for Medicare & Medicaid Services (CMS)
For each mock request, Stedi returns a realistic mock benefits response for that payer so you can get a sense for the kinds of data you'll receive in production. The benefits responses include examples of copays, deductibles, and other patient payment responsibilities, as well as active coverage.
You can also submit a mock Medicare Beneficiary Identifier (MBI) lookup. MBI lookups allow you to use a patient's Social Security Number (SSN) to retrieve their MBI and complete benefits information from the Centers for Medicare and Medicaid Services (CMS).
### Test the Stedi Agent [#test-the-stedi-agent]
The [Stedi Agent](/healthcare/eligibility-searches-view#retry-with-the-stedi-agent) resolves recoverable eligibility check errors automatically with the same best practices our Support team uses for troubleshooting. You can run a specific mock eligibility check to evaluate the Stedi Agent:
1. Create a new eligibility check and select **Stedi Agent** as the payer. Keep all other properties set to their defaults.
2. Submit the check. It's designed to fail so you can watch the agent resolve issues in real time. Specifically, it returns `AAA` error `73` (Invalid/Missing Subscriber/Insured Name).
3. Click **Resolve with Stedi Agent**. The agent runs in **Debug view** to fix the error and eventually produce a successful mock eligibility response.
4. Click **View check** to go to its details page and review the full mock benefits response.
## Review eligibility check results [#review-eligibility-check-results]
After you submit a mock eligibility check, you can review all of the request and response details. This includes:
* A list of historical eligibility checks that you can filter by status, payer ID, date, and error code.
* The raw API request and response.
* A user-friendly benefits view designed to help you quickly understand the patient's active coverage and payment responsibilities, such as co-pay and deductible amounts.
* Eligibility check **Debug** view, which allows you to to systematically troubleshoot failed checks until you receive a successful response from the payer.
To review an eligibility check's results:
1. Go to the [Eligibility searches page](https://portal.stedi.com/app/healthcare/eligibility).
2. Click the eligibility search with the benefits information you want to view.
Stedi opens the eligibility search's **Overview** tab. Click **Benefits** to review a table of the mock benefits data.
## View test claims [#view-test-claims]
You can submit test claims through SFTP or Stedi's APIs and view them in the [claims view](https://portal.stedi.com/app/healthcare/claims) when **Test mode** is toggled to **ON**. Submitting test claims through the claims view is not yet supported.
To submit test claims:
* **JSON endpoints:** Set the `usageIndicator` property in the test claim body to `T`.
* **X12 EDI endpoints and SFTP:** Set `ISA15` (Interchange Usage Indicator) to `T` (Test Data).
Visit the [test claims workflow](/healthcare/test-claims-workflow) page for detailed instructions on submitting test claims and generating test 835 Electronic Remittance Advice (ERA) responses from the Stedi Test Payer.
Click any test claim to view a timeline of its processing activity, including all associated test responses such as test 277CA claim acknowledgments and test 835 Electronic Remittance Advice (ERAs).
## Explore the Stedi portal [#explore-the-stedi-portal]
The test environment allows you to get familiar with Stedi's UI tools and learn more about how you can use Stedi to automate claims and eligibility check workflows.
## Not supported [#not-supported]
The following features aren't currently supported in test mode:
* Raw X12 real-time eligibility checks
* Batch eligibility checks
* Transaction enrollment
* Insurance discovery checks
* Coordination of benefits (COB) checks
* Submitting claims through the Stedi portal UI
* 275 claim attachments
* 276/277 real-time claim status
* Custom mock data or payer selection
# Transaction enrollment FAQ
Source: https://www.stedi.com/docs/healthcare/transaction-enrollment-faq
This FAQ provides answers to the most common questions about transaction enrollment. Please contact Stedi support with additional questions.
## How do I know if I need to enroll? [#how-do-i-know-if-i-need-to-enroll]
All payers require transaction enrollment for 835 Electronic Remittance Advice (ERAs). For other transactions, like claims and eligibility checks, it depends on the payer.
Check the [Payer Network](https://www.stedi.com/healthcare/network) to determine whether your payers require enrollment for the transaction types you want to send and receive.
For transactions marked as **Supported, enrollment required**, you must complete the transaction enrollment process before you can begin exchanging that transaction type through Stedi.
## How long does transaction enrollment take? [#how-long-does-transaction-enrollment-take]
The transaction enrollment process typically takes 24-48 hours, though it can take up to 30 days for some payers.
## Do I need to enroll through Stedi if I'm already enrolled through another clearinghouse? [#do-i-need-to-enroll-through-stedi-if-im-already-enrolled-through-another-clearinghouse]
Yes. Enrollment is specific to each clearinghouse. So if a payer requires enrollment, you will need to go through the enrollment process with Stedi to begin exchanging transactions through the Stedi clearinghouse.
## What will happen to the ERAs I currently receive through a different clearinghouse? [#what-will-happen-to-the-eras-i-currently-receive-through-a-different-clearinghouse]
ERAs can only be sent to a single clearinghouse. Once you enroll for ERAs through Stedi, all ERAs from that payer to the provider you enrolled will come through Stedi. The provider will no longer receive ERAs from that payer through your previous clearinghouse.
## Does enrolling with Stedi cancel my enrollment with another clearinghouse? [#does-enrolling-with-stedi-cancel-my-enrollment-with-another-clearinghouse]
For ERAs, yes. Once you enroll for ERAs through Stedi, the payer will stop sending ERAs to your previous clearinghouse.
For claims and other types of transactions, it depends on the payer. Some payers accept claims through multiple clearinghouses or direct connections. Customer support can help answer this question for your specific payers.
## Can a provider be enrolled through multiple clearinghouses at the same time? [#can-a-provider-be-enrolled-through-multiple-clearinghouses-at-the-same-time]
Yes, for claims and eligibility checks. Some payers allow providers to submit claims and eligibility checks through multiple clearinghouses. Customer support can help answer this question for your specific payers.
No, for ERAs. As soon as an ERA enrollment in Stedi is processed with the payer, you won't receive ERAs through your previous clearinghouse.
## Can I send claims through Stedi without switching my ERA enrollments? [#can-i-send-claims-through-stedi-without-switching-my-era-enrollments]
Yes, you can start sending claims through Stedi without enrolling for ERAs. The ERAs will still go to your current clearinghouse. In Stedi, you'll see the claim and the 277CA claim acknowledgment from the payer, but you won't see ERAs until you switch those enrollments to Stedi.
## Can I enroll one NPI without affecting others associated with the same TIN (tax ID)? [#can-i-enroll-one-npi-without-affecting-others-associated-with-the-same-tin-tax-id]
It depends on how the payer manages enrollment scope.
Some payers manage enrollments at the NPI level - when you enroll one NPI, only that NPI switches to Stedi. Other payers manage enrollments at the Tax Identification Number (TIN) level - when you enroll one NPI, all NPIs under that TIN switch to Stedi.
Payers vary in how they manage enrollment scope, and this information isn't always disclosed to Stedi. If you have multiple NPIs that share the same TIN and you want to keep some with your existing clearinghouse, contact Stedi support before submitting enrollment requests to discuss your specific situation.
# Enrollment tasks and PDF documents
Source: https://www.stedi.com/docs/healthcare/transaction-enrollment-tasks-documents
After you submit an enrollment request, you may need to complete tasks to move the enrollment forward. Some tasks require you to upload documentation, such as completed forms or tax documents.
Stedi is automatically notified when you complete a task, and the enrollment process continues.
## Task types [#task-types]
Tasks fall into three categories, which are reflected in the API as [`tasks[].definition`](/healthcare/api-reference/get-enrollment#response.tasks.definition):
* **Follow instructions** (`followInstructions`): Complete a specific action, such as logging into a payer portal or contacting a department. The task includes instructions explaining what to do.
* **Provide information** (`provideInformation`): Supply specific information or confirmation to Stedi. The task describes what information is needed.
* **Provide documentation** (`provideFilledPdf`): Upload PDF documentation related to the enrollment.
When a task requires documentation, Stedi may ask you to:
* **Complete a template:** Stedi provides a PDF template for you to download, fill out, and upload back to Stedi.
* **Upload supporting documentation** Stedi asks you to provide a document you already have, such as a W-9 form or voided check.
## Manage tasks [#manage-tasks]
When there's a new task that requires the provider to take action, Stedi adds a task to the enrollment request with instructions and sets the enrollment status to **Provider Action Required**. The email address listed as the **Person for Stedi to contact** will also [receive a notification](/healthcare/create-manage-transaction-enrollments#notification-emails) that there's a new task to complete.
You can complete tasks through the Stedi portal or programmatically through the API.
### UI [#ui]
You can review and manage tasks at the top of the enrollment request's details page in the Stedi portal. You must have the [Operator role](/healthcare/accounts-and-billing#assign-member-roles) or above to complete enrollment tasks.
If the task requires documentation, the instructions will specify what you need to provide. Some tasks include a PDF template to download, fill out, and upload to Stedi. Other tasks may ask you to upload a document you already have, such as a W-9 form.
Once you've taken the required action, check the box next to the task to mark it as complete.
### API [#api]
You may want to streamline your providers' workflows by allowing them to complete required enrollment tasks within your application. You can do this by integrating with Stedi's Enrollments API.
You can manage tasks with the following endpoints:
* [List Enrollments](/healthcare/api-reference/get-enrollment-list-enrollments) or [Retrieve Enrollment](/healthcare/api-reference/get-enrollment) to retrieve tasks associated with an enrollment request. When a new task is added, the enrollment status changes to **Provider Action Required**. You can poll for enrollments with this status to detect new tasks.
* [Update Enrollment Task](/healthcare/api-reference/post-enrollment-update-task) to mark tasks as complete or update task details.
#### Standard task workflow [#standard-task-workflow]
For `provideInformation` and `followInstructions` tasks that don't require a document upload, call the Update Enrollment Task endpoint to mark them complete.
The following example shows a `followInstructions` task on an enrollment request:
```json
{
"responsibleParty": "PROVIDER",
"definition": {
"followInstructions": {
"instructions": "Log in to your Authority's portal and request clearinghouse access for Stedi."
}
},
"rank": 1,
"isComplete": false,
"id": "f8e7d6c5-b4a3-9281-7654-321098765432"
}
```
To complete this task, call the [Update Enrollment Task](/healthcare/api-reference/post-enrollment-update-task) endpoint with the task ID:
```bash
curl --request POST \
--url "https://enrollments.us.stedi.com/2024-09-01/tasks/f8e7d6c5-b4a3-9281-7654-321098765432" \
--header "Authorization: " \
--header "Content-Type: application/json" \
--data '{
"completed": true
}'
```
#### PDF upload workflow [#pdf-upload-workflow]
When an enrollment requires additional documentation from the provider, Stedi adds a `provideFilledPdf` task to the enrollment request with instructions. Managing these tasks programmatically requires additional steps.
Follow this process to complete `provideFilledPdf` tasks.
When a task requires downloading a form and reuploading the completed PDF, Stedi provides the PDF for download on the enrollment request.
1. Call either the [Retrieve Enrollment](/healthcare/api-reference/get-enrollment) or [List Enrollments](/healthcare/api-reference/get-enrollment-list-enrollments) endpoint to retrieve the enrollment request details.
2. Check the `tasks[].definition.provideFilledPdf.documentDownloadUrl` property.
```json
{
"responsibleParty": "PROVIDER",
"definition": {
"provideFilledPdf": {
"instructions": "Please download the PDF, fill it out, and upload the completed version to this enrollment request.",
"documentDownloadUrl": "https://enrollments.us.stedi.com/2024-09-01/documents/b5a22e88-740c-1234-123b-0f801234f1e3/download"
}
},
"rank": 1,
"isComplete": false,
"id": "019ce833-b123-75f1-3456-0f14ba643709"
}
```
3. Do one of the following:
* If `documentDownloadUrl` is present, retrieve it to use in the next step.
* Otherwise, check the `instructions` property for details about what supporting documentation (such as the provider's W-9 form) is required. Then, skip to step 4 to upload that documentation.
Skip this step if uploading supporting documentation.
To retrieve the enrollment PDF template from Stedi:
1. Make an authenticated `GET` request to the `documentDownloadUrl`. This is the API URL for the [Download Enrollment Document](/healthcare/api-reference/get-enrollment-document-download) endpoint, prefilled with the proper document ID. Stedi returns a pre-signed URL in the `downloadUrl` property.
```bash
curl --request GET \
--url "https://enrollments.us.stedi.com/2024-09-01/documents/b5a22e88-740c-1234-123b-0f801234f1e3/download" \
--header "Authorization: "
```
The URL expires after 24 hours. If the URL expires before you download the PDF, call the endpoint again to get a new one.
2. Make a `GET` request to the `downloadUrl` to retrieve the PDF.
```bash
curl --request GET \
--url "" \
--output /path/to/file.pdf
```
Skip this step if uploading supporting documentation.
The provider should complete the PDF template according to the instructions provided in the `provideFilledPdf` task and the form itself.
Upload the required PDF documentation to the enrollment request. This is either a completed enrollment PDF template or supporting documentation (such as a W-9) that Stedi requested.
1. Call the [Upload Enrollment Document](/healthcare/api-reference/post-enrollment-document-upload) endpoint with the enrollment ID.
```bash
curl --request POST \
--url "https://enrollments.us.stedi.com/2024-09-01/enrollments/{enrollmentId}/documents" \
--header "Authorization: " \
--header "Content-Type: application/json" \
--data '{
"name": "completed-documentation.pdf",
"taskId": "019ce833-b123-75f1-3456-0f14ba643709"
}'
```
Stedi returns a pre-signed URL in the `uploadUrl` property you can use to upload the completed PDF to the enrollment request. The URL expires after 24 hours. If it expires, call the endpoint again to get a new one.
You should also save the `documentId` returned in the response. You'll use it later to poll for the document's status and when completing the task.
```json
{
"enrollmentId": "db6675c5-7b07-4af9-8c68-a54a336d2911",
"uploadUrl": "https://s3.amazonaws.com/enrollment-documents/db6675c5-7b07-4af9-8c68-a54a336d2911/provider-license.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=...",
"documentId": "doc-123e4567-e89b-12d3-a456-426614174000"
}
```
2. Make a `PUT` request to the `uploadUrl` to upload the completed PDF to Stedi. The request must include the `Content-Type: application/pdf` header.
```bash
curl --request PUT \
--url "" \
--header "Content-Type: application/pdf" \
--upload-file /path/to/file.pdf
```
You must wait for the document's status to change from `PENDING` to `UPLOADED` before marking the associated task as complete. This typically takes less than 10 seconds.
You can poll the [Retrieve Enrollment](/healthcare/api-reference/get-enrollment) endpoint to check the status of the uploaded document. When the status is `UPLOADED`, the document has been successfully received and processed by Stedi.
Our [TypeScript example](/healthcare/api-reference/post-enrollment-document-upload#poll-for-document-status) shows how you might poll.
Once the document status is `UPLOADED`, call the [Update Enrollment Task](/healthcare/api-reference/post-enrollment-update-task) endpoint to mark the `provideFilledPdf` task as complete.
```bash
curl --request POST \
--url "https://enrollments.us.stedi.com/2024-09-01/tasks/{taskId}" \
--header "Authorization: " \
--header "Content-Type: application/json" \
--data '{
"completed": true,
"responseData": {
"pdfUpload": {
"documentId": "doc-123e4567-e89b-12d3-a456-426614174000",
"fileName": "completed-documentation.pdf"
}
}
}'
```
## Review and download documents [#review-and-download-documents]
You can upload documents through [tasks](#task-types) Stedi assigns on the enrollment request. Stedi may also upload documentation throughout the enrollment process. You can review, download, or delete these documents as needed. Documents associated with an enrollment may include:
* Completed enrollment forms
* W-9 tax forms
* Voided checks
* Other documentation that Stedi completes and submits to the payer
### UI [#ui-1]
To review, download, or delete documents associated with an enrollment request:
1. Go to the [Enrollments page](https://portal.stedi.com/app/healthcare/enrollments) and click the enrollment request.
2. Scroll to the **Documents** section at the bottom of the page.
In the **Documents** section, click any document to view it in your web browser. You can also click **...** (ellipses) to the right of the document to:
* Download the original PDF file.
* Copy a secure link to view the file, which you can share with any member of your Stedi account.
* Delete the file, if necessary.
### API [#api-1]
You can use the following API endpoints to manage documents on an enrollment request programmatically:
* [Upload Enrollment Document](/healthcare/api-reference/post-enrollment-document-upload): Get a pre-signed URL to upload a PDF document related to a task. This endpoint requires a `taskId` - you can only use it as part of the [PDF upload workflow](#pdf-upload-workflow) for `provideFilledPdf` tasks.
* [Download Enrollment Document](/healthcare/api-reference/get-enrollment-document-download): Get a pre-signed URL to download a specific PDF document related to an enrollment request.
* [Delete Enrollment Document](/healthcare/api-reference/delete-enrollment-document): Delete a specific PDF document related to an enrollment request.
# Transaction enrollment
Source: https://www.stedi.com/docs/healthcare/transaction-enrollment
Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. It involves submitting information about the provider, including their name, tax ID, [NPI](/healthcare/national-provider-identifier), billing address, and contact information.
## Do I need to enroll my provider? [#do-i-need-to-enroll-my-provider]
For 835 ERAs, always yes. For other transactions, it depends on the payer.
Check the [Payer Network](https://www.stedi.com/healthcare/network) or use the [Payers API](/healthcare/api-reference/get-payers) to determine whether your payers require enrollment for the transaction types you want to send and receive. Each transaction type is marked as either:
* Supported, enrollment not required
* Supported, enrollment required
* Not supported
For example, the following payer record shows that Blue Cross Blue Shield of North Carolina requires enrollments for 835 ERAs, as indicated in the `transactionSupport.claimPayment` property.
```json
{
"stediId": "UPICO",
"displayName": "Blue Cross Blue Shield of North Carolina",
"primaryPayerId": "BCSNC",
"transactionSupport": {
"eligibilityCheck": "SUPPORTED",
"claimStatus": "SUPPORTED",
"claimSubmission": "SUPPORTED",
"claimPayment": "ENROLLMENT_REQUIRED",
"dentalClaimSubmission": "SUPPORTED",
"professionalClaimSubmission": "SUPPORTED",
"institutionalClaimSubmission": "SUPPORTED",
"coordinationOfBenefits": "SUPPORTED",
"unsolicitedClaimAttachment": "NOT_SUPPORTED"
}
// truncated for brevity
}
```
If enrollment for a supported transaction type is:
* **Not required:** The provider can start exchanging transactions through Stedi right away. They'll include their information (like their [NPI](/healthcare/national-provider-identifier)) in transactions as needed.
* **Required:** The provider must complete transaction enrollment before they can start exchanging those transactions through Stedi. Note that ERA enrollment is exclusive to one clearinghouse. Switching a provider to Stedi stops ERA delivery through the previous clearinghouse.
## How long does enrollment take? [#how-long-does-enrollment-take]
Most enrollments are completed within 24 - 48 hours. However, some payers may take up to 30 days, depending on their internal processes and requirements.
Check out [FAQ](/healthcare/transaction-enrollment-faq) for answers to other common questions about transaction
enrollment.
## Enrollment process [#enrollment-process]
Stedi handles the entire enrollment process for you, including submitting the required information to the payer and monitoring the status of the enrollment.
Here's how it works:
The provider record includes the information required to enroll the provider with payers, including the provider's name, tax ID, [NPI](/healthcare/national-provider-identifier), and contact information.
You can [create enrollment requests](/healthcare/create-manage-transaction-enrollments) individually through the Stedi portal, in bulk through CSV import, or programmatically through the API. Stedi gets alerted about new enrollment requests once they're in `STEDI_ACTION_REQUIRED` status.
For each provider, you'll create one enrollment request per transaction type. For example, you would create three separate requests to enroll a provider for 837P professional claims, 270 real-time eligibility checks, and 835 ERAs.
When we begin the enrollment process with the payer, we'll set the enrollment status to `PROVISIONING`. We'll reach out to you in your dedicated Slack or Teams channel with resources and to answer any follow-up questions.
For some payers, such as those with [one-click enrollment](/healthcare/transaction-enrollment#one-click-enrollment), Stedi can complete the entire enrollment process for you. We sign enrollment PDF forms on your behalf, when possible, to speed up the process and eliminate extra work for your team.
If payers require additional steps from providers as part of their standard enrollment process, Stedi sets the enrollment status to `PROVIDER_ACTION_REQUIRED` and adds a task to the enrollment request with clear instructions. The enrollment process continues once the required tasks are completed.
You can check which payers require additional steps on our [Transaction Enrollments Hub](https://enrollments.stedi.com/?v=1a7685bc14df80ed8e07000c941f6bff).
Once the enrollment is approved, the enrollment status is set to `LIVE`, and the provider can start exchanging the enrolled transactions with the payer.
### Enrollment statuses [#enrollment-statuses]
An enrollment request can have one of the following statuses:
* `DRAFT`: You are still editing the record and it has not been submitted to Stedi.
* `STEDI_ACTION_REQUIRED`: You have submitted the enrollment and it is ready for Stedi to begin processing.
* `PROVIDER_ACTION_REQUIRED`: The enrollment requires action from the healthcare provider to proceed, such as providing additional documentation. Stedi will add a note to your enrollment request with clear instructions.
* `PROVISIONING`: Stedi has begun the process of completing the enrollment with the payer.
* `LIVE`: The enrollment process is complete, and the specified provider can begin exchanging the listed transaction types with the payer.
* `REJECTED`: The payer rejected the enrollment. Common reasons for rejection include incorrect details in the request and that the provider is not credentialed with the payer. Customer support will contact you with reasons for rejection and next steps.
* `CANCELED`: The enrollment has been terminated per customer or provider request. You can only [cancel enrollments](#cancel-enrollments) that are in `DRAFT`, `STEDI_ACTION_REQUIRED`, or `PROVIDER_ACTION_REQUIRED` status.
### One-click enrollment [#one-click-enrollment]
We offer one-click enrollment for eligible payers. Once you submit the enrollment request, Stedi handles the entire process without any additional action from you. These payers don't require any signatures or documentation other than what is included in the enrollment request.
You can determine whether a payer is eligible for one-click enrollment by:
* Checking the [Payer Network](https://www.stedi.com/healthcare/network). Click a payer's name to view its details. Stedi lists the **Type** as **One-click** for transaction types that support one-click enrollment.
* Calling the [Payers API](/healthcare/api-reference/get-payers). The `enrollment.transactionEnrollmentProcesses.{transactionType}.type` property is set to `ONE_CLICK` for transaction types that support one-click enrollment.
### Rejected enrollments [#rejected-enrollments]
In rare cases, the enrollment status might be set to `REJECTED` if the payer denies the enrollment request. Rejection can happen for many reasons, but the most common are:
* The provider isn't credentialed with the payer. If a payer rejects your transaction enrollment request with a message indicating the provider is "not on file" or "not recognized," it likely means the provider hasn't completed credentialing and payer enrollment with that payer. Visit [Credentialing and enrollment](/healthcare/credentialing-and-enrollment) to learn more.
* There was incorrect data in the enrollment submission.
If an enrollment is rejected, Stedi puts a note on the enrollment request explaining the reason and how to resolve it. You can review the note through the UI or API and contact Stedi support in Slack or Teams with any additional questions.
# Trust Center
Source: https://www.stedi.com/docs/healthcare/trust-center
Visit our [Trust Center](https://trust.stedi.com/) for complete trust and compliance information for all Stedi products and APIs, including our:
* Privacy policy
* Data management policy
* Access control policy
* HIPAA compliance policy
* Certifications, including SOC 2 Type II and HIPAA
* Security and privacy controls
# Provider Docs
Source: https://www.stedi.com/docs/providers
Check patient benefits in real time. Submit, track, and review claims and remittance.
## Get started [#get-started]
Create your account in under 5 minutes. Install apps to connect to
third-party systems.
Required for 835 Electronic Remittance Advice (ERAs) and some other
transaction types.
## Eligibility & benefits [#eligibility--benefits]
Submit real-time checks to verify coverage in seconds.
Determine whether a service is covered. Get patient responsibility details,
such as co-pays and deductible amounts.
## Claims processing [#claims-processing]
Submit professional claims from the Stedi portal.
Review, revise, and resubmit professional, dental, and institutional claims.
Run real-time claim status checks for updates about adjudication and payment
status.
Get ERAs with payment details and explanations for any adjustments or
denials.
# Set up your account
Source: https://www.stedi.com/docs/providers/providers-account-setup
You can create and configure your Stedi account in under 5 minutes.
## Create a Stedi account [#create-a-stedi-account]
To create a Stedi account with the **Basic** plan:
1. Do one of the following:
* Go to the [Stedi signup page](https://portal.stedi.com/auth/sign-up).
* Go to the custom signup link your vendor provided. This is for providers who are signing up to integrate with a vendor's app in Stedi.
2. Follow the signup process, which includes:
* Filling out the signup form.
* Choosing the **Basic** plan option.
* Setting up Multi-Factor Authentication (MFA).
* Naming your Stedi account.
* Agreeing to a Business Associate Agreement (BAA).
Stedi begins provisioning your account. You'll be able to submit [transaction enrollment requests](/providers/providers-transaction-enrollment-intro) in about 15 minutes. However, you can start [running eligibility checks](/providers/providers-eligibility-checks) immediately.
### Join existing account [#join-existing-account]
During sign up, Stedi checks whether your email domain is associated with an existing Stedi account. If it is, you can request to join that account instead of creating a new one.
For example, if you sign up with `john.doe@example.com` and your company already has a Stedi account for `example.com`, you'll see the option to request to join it. This helps prevent duplicate accounts for the same organization.
You'll receive an email when the account admin invites you to join the account and log in.
## Add members [#add-members]
Your Stedi account can have many members - a member represents an individual email address used to log into the account. You may want to add additional members so that other individuals in your organization can help manage transactions and troubleshoot issues. Your vendor may also request to be invited to your account, so they can investigate and troubleshoot issues directly during support sessions.
Members can have different roles, depending on the permissions you want them to have within your account. An **Admin** has the highest permissions, and they can access and update all resources in your account, including members and billing details.
To add members to your account:
1. Go to the [Members](https://portal.stedi.com/app/settings/members) page in **Account settings**.
2. Click **Invite member**.
3. Enter the email address of the member you want to add.
4. Select the member's role from the dropdown. We recommend assigning most members to the **Operator** role. This role allows them to manage transactions (like claims and eligibility checks) and submit transaction enrollments requests, but not change account settings or billing information.
5. Click **Send invitation**.
The invited member will receive an email with instructions about how to accept the invitation and log into the account.
Visit [Account members and settings](/providers/providers-accounts-and-billing) for complete details about managing your account, including enabling Multi-Factor Authentication (MFA) and updating your billing information.
## (Optional) Install Stedi apps [#optional-install-stedi-apps]
You can install Stedi apps to quickly connect your account to third-party Revenue Cycle Management (RCM) systems, Practice Management Systems (PMS), Electronic Healthcare Record (EHR) platforms, and other [Platform Partners](https://www.stedi.com/platform-partners).
To install a Stedi app:
1. Click **Apps** in the navigation bar to go to the [Apps page](https://portal.stedi.com/app/settings/apps) in your **Account settings**.
2. Browse the list of apps and click the one you want to install.
3. Click **Install** to begin the installation process.
4. Read the installation details and then click **Confirm and install**. This action sends an email invitation to the app vendor. This will allow your vendor to log into your account, complete the setup process, and provide support as needed.
Stedi displays new API and SFTP credentials. You can ignore these. Your vendor will log into your account and generate their own credentials to connect their system to Stedi.
5. Check the box next to **I've added these details to my \[Vendor] account** and click **Done**.
The app is now installed, and your vendor will complete the setup process.
## Next step: Transaction enrollment [#next-step-transaction-enrollment]
Are you planning to process claims through Stedi?
If so, you must complete transaction enrollment with each payer before you can receive 835 Electronic Remittance Advice (ERAs). Transaction enrollment is also required for some other types of transactions, like claims and eligibility checks, depending on the payer.
[Start transaction enrollment ->](/providers/providers-transaction-enrollment-intro)
# Account members and settings
Source: https://www.stedi.com/docs/providers/providers-accounts-and-billing
Learn how to manage Stedi accounts, members, billing, and payments.
## Accounts [#accounts]
A Stedi account is a container for all of your Stedi activity and resources. Every account has a name, which you can find in the [Account profile](https://portal.stedi.com/app/settings/account-details). Your account also has an ID, which is used in dashboard URLs, where it appears in the `account` URL parameter.
Accounts can have unlimited members, and members can be [assigned different roles](#assign-member-roles) with different permissions.
It's possible to have multiple accounts, though using one account is recommended for most customers. If you need additional accounts, [contact us](https://www.stedi.com/contact) and we'll enable them for you.
### Join an existing account [#join-an-existing-account]
During [sign up](https://portal.stedi.com/auth/sign-up), Stedi checks whether your email domain is associated with an existing Stedi account. If it is, you can request to join that account instead of creating a new one.
For example, if you sign up with `john.doe@example.com` and your company already has a Stedi account for `example.com`, you'll see the option to request to join it. This helps prevent duplicate accounts for the same organization.
You'll receive an email when the account admin invites you to join the account and log in.
### Change account theme [#change-account-theme]
To change your account theme:
1. Click the account name in the top right of the portal.
2. Next to **Theme** you can choose between light, dark, or system (which matches your device settings).
### Set default landing page [#set-default-landing-page]
You can customize which page opens when you log in to the Stedi portal.
1. Go to the **General** page in your [Account settings](https://portal.stedi.com/app/settings/account-details).
2. Choose a **Default landing page** option:
* **Dynamic (default):** Stedi opens the claims view if you've processed at least one claim. Otherwise, Stedi opens the eligibility searches page.
* **Claims:** Stedi opens the claims view.
* **Eligibility:** Stedi opens the eligibility searches page.
### Delete an account [#delete-an-account]
[Contact support](https://www.stedi.com/contact). You can't delete your account through the Stedi portal or API.
## Members [#members]
Your account can have many members - a member represents an individual email address used to log into the account. You may want to add additional members so that other individuals in your organization can help manage transactions and troubleshoot issues.
### Invite members [#invite-members]
To add members to your account:
1. Go to the [Members page](https://portal.stedi.com/app/settings/members) in your account settings.
2. Click **Invite member**.
3. Enter the email address of the member you want to add.
4. Select the member's [role](#assigning-member-roles) from the dropdown.
5. Click **Send invitation**.
The invited member will receive an email with instructions about how to accept the invitation and log into the account. Invitations do not expire, but can be revoked by any account admin at any time before acceptance.
Stedi apps may automatically add one or more support users with a [Developer role](/healthcare/accounts-and-billing#assign-member-roles) to your account during installation. These support users allow your vendor to help you troubleshoot issues directly within your account and assist with implementation.
### Assign member roles [#assign-member-roles]
Admins can use role-based access control (RBAC) to ensure only authorized users can access and modify resources in a Stedi account. An Admin has the highest permissions, and they can access and update all resources in your account, including members and billing details. We recommend assigning most members to the Operator role. This role allows members to manage transactions (like claims and eligibility checks) and submit transaction enrollments requests, but not change account settings or billing information.
Admins can assign Stedi account members to one of four roles:
* **Admin:** These users can access and modify all resources within a Stedi account. This includes adding and removing members, assigning member roles, adding billing information, configuring settings, running eligibility checks, submitting claims, managing API keys, and configuring resources.
* **Developer:** These users can access and configure all resources, including managing API keys. However, they can't manage members or billing information.
* **Operator:** These users can run eligibility checks, run insurance discovery checks, submit claims, submit transaction enrollments, and review transaction data. They can also manage guides and trading partners (EDI platform). Finally, they can interact with developer resources, but can't modify them. For example, they can call our APIs, but they can't create or delete API keys.
Operator is the minimum required role for a user to interact with our
clearinghouse and review transactions (such as completed eligibility checks)
in Stedi.
* **Read-only:** These users can view some account resources, but cannot modify them. For example, they can review processed transactions in Stedi but can't call APIs.
To change a member's role:
1. Go to [Members page](https://portal.stedi.com/app/settings/members) in your **Account settings**.
2. Click the pencil icon for a member, choose the appropriate **Role** from the list, and click **Update role**.
### Remove members [#remove-members]
An account admin can remove other members from an account. Removed users will still retain their Stedi user credentials and access to other accounts of which they're a member.
To remove a member from your account:
1. Go to [Members page](https://portal.stedi.com/app/settings/members) in your **Account settings**.
2. Click the **...** (ellipses) to the right of the member you want to remove and select **Remove from account**.
3. Click **Are you sure?** to confirm.
The removed member will no longer have access to your Stedi account.
## Change your password [#change-your-password]
To change or reset your password:
1. Go to the [Authentication page](https://portal.stedi.com/app/settings/user-authentication) in your **Account settings**.
2. Click **Change password** in the **Password** section.
3. Enter your current password, then enter and confirm your new password.
4. Click **Done**.
You'll need to use the new password the next time you log in to Stedi.
## Multi-Factor Authentication (MFA) [#multi-factor-authentication-mfa]
You can enable Multi-Factor Authentication (MFA) for your user account. To enable MFA, click your user account icon in the top right of the app and then click **Enable MFA**.
### Enforce MFA for all members [#enforce-mfa-for-all-members]
You can require **all** users to enable MFA before accessing a Stedi account. To enforce MFA for all users:
1. Go to the [Account security page](https://portal.stedi.com/app/settings/account-security) in your **Account settings**.
2. Click the button to **Enforce multi-factor authentication**.
The next time a user logs into the Stedi account, Stedi prompts them to set up their MFA token: [https://portal.stedi.com/auth/setup-mfa](https://portal.stedi.com/auth/setup-mfa)
Once you enable MFA for a Stedi account, it cannot be disabled.
### Reset a member's MFA [#reset-a-members-mfa]
If a member loses access to their authenticator app, an account admin can reset their MFA token.
To reset a member's MFA token:
1. Go to [Members page](https://portal.stedi.com/app/settings/members) in your **Account settings**.
2. Click the **...** to the right of the member you want to reset.
3. Select **Reset member MFA**.
The member will be prompted to set up a new MFA token the next time they log in. If they're currently logged in, they may not be logged out immediately - the reset process can take up to an hour.
### Update your MFA [#update-your-mfa]
To update your MFA token:
1. Go to the [Account security](https://portal.stedi.com/app/settings/user-authentication) in your **Account settings**.
2. Click **Update** in the **Multi-factor authentication** section.
3. Follow the prompts to set up your new MFA token.
4. Click **Save**.
## Single Sign-On (SSO) and SCIM [#single-sign-on-sso-and-scim]
Admins can configure Single Sign-On (SSO) and directory sync (SCIM) through Stedi's WorkOS integration.
* SSO allows account members to sign in to Stedi through your chosen identity provider, such as Okta or OneLogin.
* Directory sync (SCIM) automatically creates and removes Stedi accounts through your chosen identity provider.
### Request access [#request-access]
To request SSO and/or directory sync for your account:
1. Go to the [Account security page](https://portal.stedi.com/app/settings/account-security) in your **Account settings**.
2. Click **Contact us** to go to Stedi's contact form and request SSO for your account.
Stedi support will review the request and enable access.
### Configure SSO [#configure-sso]
Once Stedi support enables SSO access, you can configure it for your account:
1. Go to the [Account security page](https://portal.stedi.com/app/settings/account-security) in your **Account settings**.
2. Click **Set up Single sign-on**. Stedi redirects you to the WorkOS portal for setup.
3. Follow the steps in the WorkOS portal to configure SSO for your identity provider. WorkOS provides detailed instructions for connecting each identity provider as part of the setup flow. You can also visit the WorkOS [Single Sign-On documentation](https://workos.com/docs/sso) for more details.
Once configured, you can manage the account's SSO settings from the [Account security page](https://portal.stedi.com/app/settings/account-security). This includes:
* **Require SSO for all members:** Toggling this to **ON** disables the standard email and password login process - account members will only be able to access Stedi through SSO.
* **Default role for new members:** Choose which [member role](#assign-member-roles) is automatically assigned to users when they join the account.
### Configure directory sync (SCIM) [#configure-directory-sync-scim]
Once SSO is configured, you can optionally also set up directory sync (SCIM) through WorkOS. If you don't see directory sync in your account, contact Stedi support to request access.
To configure directory sync:
1. Go to the [Account security page](https://portal.stedi.com/app/settings/account-security) in your **Account settings**.
2. In the **Single sign-on (SSO)** section, click **Set up directory sync**. Stedi redirects you to the WorkOS portal for setup.
3. Follow the steps in the WorkOS portal to configure directory sync for your identity provider. WorkOS provides detailed instructions for connecting each identity provider as part of the setup flow. You can also visit the WorkOS [directory sync documentation](https://workos.com/docs/directory-sync) for more details.
Once configured, you can review automatically created user accounts from the [Members page](https://portal.stedi.com/app/settings/members) in your **Account settings**.
You can manage the account's directory sync settings from the [Account security page](https://portal.stedi.com/app/settings/account-security).
## Reauthentication [#reauthentication]
Stedi requires all users to sign in every 12 hours. This aligns our maximum session duration with National Institute of Standards and Technology (NIST) best practices, and it isn't configurable.
### Enable inactivity sign-out [#enable-inactivity-sign-out]
Admins can opt in to have account members automatically sign out after 30 minutes of inactivity. This reduces the risk of unattended workstations being used to access patient data.
To enable inactivity sign-out for your account:
1. Go to the [Account security page](https://portal.stedi.com/app/settings/account-security) in your **Account settings**.
2. Click **Enable inactivity sign-out** under **Inactivity sign-out**.
Once enabled, members will be automatically signed out of the Stedi portal after 30 minutes of inactivity. Activity includes mouse movements, keyboard input, and touch events.
## Billing [#billing]
Each account will be invoiced monthly.
### Add or edit payment method [#add-or-edit-payment-method]
To add or edit your payment details:
1. Go to your [Account settings](https://portal.stedi.com/app/settings/account-details).
2. Click **Billing**. You'll be taken to a secure third-party payment site to enter or update your credit card information.
3. Click **Add payment method** or **Update payment method**.
4. Enter your payment details. You can enter either credit card details or the routing information for a United States bank account.
Once you save your changes, any charges will be billed to the payment information on file.
## Apps [#apps]
You can install Stedi apps to quickly connect your account to third-party Revenue Cycle Management (RCM) systems, Practice Management Systems (PMS), Electronic Healthcare Record (EHR) platforms, and other [Platform Partners](https://www.stedi.com/platform-partners).
To install a Stedi app:
1. Click **Apps** in the navigation bar to go to the [Apps page](https://portal.stedi.com/app/settings/apps) in your **Account settings**.
2. Browse the list of apps and click the one you want to install.
3. Click **Install** to begin the installation process.
4. Read the installation details and then click **Confirm and install**. This action sends an email invitation to the app vendor. This will allow your vendor to log into your account, complete the setup process, and provide support as needed.
Stedi displays new API and SFTP credentials. You can ignore these. Your vendor will log into your account and generate their own credentials to connect their system to Stedi.
5. Check the box next to **I've added these details to my \[Vendor] account** and click **Done**.
The app is now installed, and your vendor will complete the setup process.
## Developer settings [#developer-settings]
Developers can create test API keys and test SFTP credentials from their [Account settings](https://portal.stedi.com/app/settings/account-details).
* Test API keys allow you to send mock eligibility checks to Stedi's real-time JSON, Raw X12, and SOAP endpoints. Visit [Eligibility mock requests](https://www.stedi.com/docs/healthcare/api-reference/mock-requests-eligibility-checks) in our developer docs for more details.
* Test SFTP credentials allow you to upload test claims and retrieve test claim responses through Stedi's fully-managed SFTP server. Visit [Submit claims through SFTP](https://www.stedi.com/docs/healthcare/submit-claims-sftp-connection#create-sftp-users) in our developer docs for more details.
# Check claim status
Source: https://www.stedi.com/docs/providers/providers-check-claim-status
You may need to check a claim's status when you don't receive a 277CA claim acknowledgment or 835 Electronic Remittance Advice (ERA) from the payer within your expected timeframe.
You can run real-time claim status checks to determine whether a payer is still processing a claim or if it's been rejected or denied.
## Run a claim status check [#run-a-claim-status-check]
To submit a 276/277 real-time claim status check:
1. Go to the [Create claim status check page](https://portal.stedi.com/app/healthcare/claims/status/create).
2. Enter the required information. We strongly recommend reviewing our [best practices](#best-practices) for submitting claim status requests. Supplying too much information or a too narrow/broad date of services range can negatively affect the results.
3. Click **Submit**.
Stedi displays the claim status response on the next page. If the payer finds a matching claim, the response includes the claim's status and (if applicable) one or more rejection messages indicating the reason(s) for rejection. When the claim status check returns more than one matching claim, you can toggle between them using the dropdown at the top left of the page.
The claim status response also includes information about the attached claim, including key identifiers (such as the Patient Control Number), service details, billed amount, and paid amount (if applicable). However, it doesn't include all details from the original claim and any associated 835 Electronic Remittance Advice (ERAs). For example, if you need a detailed breakdown of payments and adjustments, you must check the related ERA.
Claim status checks aren't listed on the **Transactions** page. You can only
review the response immediately after submitting the request. If you need to
know the status of the same claim later, you must run a new claim status
check.
## Best practices [#best-practices]
We recommend following these best practices when checking claim status.
### Wait at least a week [#wait-at-least-a-week]
Don't run a claim status check until at least 7 days after the claim's submission date. It usually takes a few weeks for payers to process and fully adjudicate a claim.
If you haven't received an 835 ERA, we recommend checking the claim's status at 21 days after submission and then again at 1 month.
### Supply a date of services range [#supply-a-date-of-services-range]
We recommend the following best practices when providing dates of service in a claim status request:
* The date range should be at least plus or minus 7 days from the date of the services listed in the claim. The payer may have stored a different date for the encounter than the one in your records, so providing a date range increases the likelihood that the payer will find a match.
* Keep the date range to 30 days or less. Some payers may reject requests with a date range that is too wide.
* Don't submit future dates - only submit date ranges up to and including today's date. Some payers reject requests containing future service dates.
### Don't provide too much information [#dont-provide-too-much-information]
Providing too much information in a claim status request can negatively affect the results. That's why we recommend first sending a base request with only the following information.
You will eventually learn payer-specific nuances and can adjust your approach accordingly. For example, some payers may have better success rates when you include the claim number.
### Recommended base request [#recommended-base-request]
We recommend starting with the following fields in your claim status request.
{/* prettier-ignore-start */}
| Form fields | Description |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Trading partner service ID | You must specify the payer. Choose the payer from the dropdown. Start typing to filter the list. |
| Providers | The provider information from the original claim. To start, provide only the **NPI**, **Organization name**, and **Provider type** fields. |
| Subscriber | The subscriber information from the original claim. To start, provide only the **First name**, **Last name**, **Date of birth**, **Gender**, and **Member ID** fields. You'll need to click **Select fields** to add the **Gender** field to the form. |
| Dependent | The dependent information from the original claim. To start, provide only the **First name**, **Last name**, **Date of birth**, and **Gender** fields. You'll need to click **Select fields** to add the **Dependent** fields to the form. If the patient is the subscriber, don't include this information. |
| Encounter | The encounter information from the original claim. To start, provide only the **Beginning date of service** and **End date of service** fields. Remember that you should provide a date range that is plus or minus 7 days from the date of service listed in the claim for best results. |
{/* prettier-ignore-end */}
If this base request fails to return results, try adding in other information like the provider's **Electronic Transmitter Identification Number (ETIN)** or the **Trading partner claim number**.
## Claims submitted by other providers [#claims-submitted-by-other-providers]
You likely won't be able to check the status of a claim submitted by a different provider organization or by the patient themselves, even if you have all of the details about the claim.
Payers generally only allow a provider organization to check the status of the claims they submitted. They impose these access controls to protect plan member privacy and confidential commercial data.
## Claims older than 18 months [#claims-older-than-18-months]
Payers often archive claims older than 18 months, but this varies by payer. If you try to check the status of a claim from several years ago, the payer may return an error even if the information you submit matches a real historical claim.
# 277CA claim acknowledgments
Source: https://www.stedi.com/docs/providers/providers-claim-acknowledgments
You may receive 277CA claim acknowledgments after you submit 837 claims through Stedi.
These 277CAs indicate whether the claim was accepted for processing or rejected. If the claim was rejected, the 277CA explains why so you can understand what to change before resubmitting.
## 277CA responses [#277ca-responses]
You may receive multiple separate 277CAs for each claim you submit. Each 277CA typically correlates to one claim. However, some payers may send a single 277CA that references multiple claims.
* You'll receive the first 277CA from Stedi within about 30 minutes of submitting the claim. This 277CA may contain rejection message(s) and warnings, if applicable.
* You may receive additional 277CAs from intermediary clearinghouses.
* You may receive one or more 277CAs from the payer. Typically, there is one 277CA that indicates receipt of the claim and a second 277CA that contains summary counts of transactions received, information about accepted transactions, and details for rejected transactions.
## Review 277CAs [#review-277cas]
You can find 277CAs from the [claims view](https://portal.stedi.com/app/healthcare/claims).
1. Click a claim to view a timeline of its processing activity.
2. Click an **Acknowledgment** (277CA) to review its details page.
Stedi displays key information about the 277CA, including the billing provider's information and status codes, so you can determine whether the associated claim was accepted or rejected.
### Determine claim status [#determine-claim-status]
277CAs from the payer indicate whether the claim was accepted for processing or rejected.
This claim status information is available on the 277CA's **Overview** tab. If the 277CA references multiple claims, you can toggle between them to review each claim's status information.
Specifically, you should review the following details:
{/* prettier-ignore-start */}
| Information | Description |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Sender | The 277CA is from the payer when the **From** field contains the payer's name or ID and the **Entity type** is `Payer`. |
| Patient Control Number | The **Patient control number** is the value you sent in the original claim's `Loop 2300 CLM01` (Patient Control Number). This is **Box 26** (Patient account number) in the CMS-1500 form UI. This identifier helps match the 277CA to the original claim. |
| Status codes | The overview lists claim status codes that indicate whether the claim has been accepted or rejected. If the claim was rejected, the overview lists one or more rejection messages marked with **Claim issue** indicating the reason(s) for rejection. |
{/* prettier-ignore-end */}
### View X12 EDI [#view-x12-edi]
You can review the raw X12 EDI for any 277CA claim acknowledgment from the **EDI** tab.
The EDI is displayed on the left and the specification is displayed on the right. As you hover over different parts of the EDI, Stedi highlights the corresponding part of the specification to help you understand what each part of the EDI means.
## 277CA vs. claim status check [#277ca-vs-claim-status-check]
The 277CA contains different information than a real-time claim status check. Specifically:
* **277CAs**: Tell you whether the payer has received a claim and accepted it for processing. If the claim was rejected, 277CAs tell you why so you can resubmit. 277CAs don't indicate whether the claim has been adjudicated or paid.
* **Real-time claim status checks**: Tell you the status of a claim that's already been accepted into the payer's system. They provide information about whether the claim has been adjudicated, paid, denied, or is pending further review.
If you're waiting for an ERA, you should first check the related 277CA to confirm that the claim was accepted for processing. If the claim was rejected, you won't receive an ERA because the payer didn't adjudicate the claim.
Then, you can run a [real-time claim status check](/providers/providers-check-claim-status) to get updates about the claim's adjudication and payment status.
# Claim edits and repairs
Source: https://www.stedi.com/docs/providers/providers-claim-edits-and-repairs
Stedi checks each claim you submit for errors that could lead to rejections or denials.
Depending on the type of error, Stedi will either fix the issue automatically (repair) or reject the claim (edit rejection) with instructions explaining what to change before resubmitting. This process helps ensure claims are complete, accurate, HIPAA-compliant, and aligned with payer-specific rules *before* they reach the payer.
Catching and resolving issues early through claim edits and repairs streamlines claims processing so providers can get paid faster.
## Repairs [#repairs]
Repairs are fixes that Stedi applies to claims before checking them against our library of [claim edits](#edits). They fix problems with a known, deterministic solution, such as formatting issues. For example, if a phone number contains dashes or spaces, a repair might remove them so the claim passes validation.
We don't use repairs to change substantive or clinical content. For example, a repair won't change a CPT code in a claim to reflect a different procedure. That's a substantive change that requires resubmission.
Claim repairs don't require any action from you - they happen automatically, so you don't need to make changes or resubmit.
## Edits [#edits]
Claim edits are validation rules that check a specific requirement. For example, an edit might check that each phone number in the claim contains exactly 10 digits. Many of our [repairs](#repairs) fix issues that would cause claims to fail one or more edits. For example, a repair may remove dashes in a phone number so it's in the right format for the edit validation. If the phone number still doesn't have 10 digits, the claim fails the edit.
Stedi runs our entire library of edits on each claim you submit. This applies to both new claims and claims you're resubmitting through Stedi.
When a claim fails one or more edits, Stedi doesn't send it to the payer. Instead, you'll see a validation error for each edit the claim failed. You'll need to fix the issues causing the edit failures before you can successfully submit the claim to Stedi.
### Stedi's edit database [#stedis-edit-database]
Stedi has a growing library of claim edits, including edits for specific payers. You can review a filterable, up-to-date list of all our claim edits in our [Edits database](https://edits.stedi.com/).
There's no standardized universal library of claim edits. However, a large number of industry-standard edits originate from HIPAA rules (such as using ICD-10 as the standard coding system) and from Centers for Medicare & Medicaid Services (CMS) rules, such as the National Correct Coding Initiative (NCCI). NCCI edits were originally developed by CMS for Medicare, but many non-Medicare payers have adopted them or use them as a baseline.
Our goal is to eventually cover all non-provider-specific edits that can be deterministically applied to claims. You can submit requests for new edits or updates to existing ones through our [Request a claim edit](https://www.stedi.com/request-claim-edit) form.
### SNIP framework [#snip-framework]
Edits are often categorized using the Strategic National Implementation Process (SNIP) framework. The framework was created by the Workgroup for Electronic Data Interchange (WEDI), which sets guidelines (but not standards) for how EDI should be implemented in healthcare.
Each SNIP type, or level, checks a different aspect of a claim's correctness. You can find the SNIP level of all of our edits in the [Edits database](https://edits.stedi.com/).
**SNIP Type 1: EDI Standard Integrity Testing**
Edits that check whether the claim uses valid EDI syntax. Examples:
* Are the EDI segments in the right order?
* Do fields meant for numbers contain numbers?
**SNIP Type 2: HIPAA Implementation Guide Requirement Testing**
Edits that check whether the claim uses HIPAA-compliant X12 syntax. Examples:
* Invalid phone numbers
* Invalid date of birth
* Invalid billing provider address
* Missing primary payer
**SNIP Type 3: HIPAA Balance Testing**
Edits that check whether the billing amounts in the claim add up correctly. Examples:
* Non-zero adjustment amounts
* COB claims must be balanced
* Total claim charges must equal line-level charges
**SNIP Type 4: HIPAA Inter-Segment Situation Testing**
Edits that check whether fields are present or missing based on the presence of other fields. Examples:
* Missing accident date
* Missing admission source code
**SNIP Type 5: HIPAA External Code Set Testing**
Checks that fields that use official HIPAA-adopted code sets only contain valid values. For example, an edit could check for invalid ICD-10-CM diagnosis codes.
**SNIP Type 6: Product Type/Type of Service Testing**
Edits that check whether the claim is valid and in the right format for the type of healthcare service listed. These edits catch mismatches between the procedure code being billed and the type of claim or service category. Examples:
* Using a CDT dental code in an 837P professional claim.
* Billing a surgery CPT code under a diagnostic service type.
* Including a revenue code, which is used only in 837I institutional claims, in an 837P professional claim.
**SNIP Type 7: Trading Partner-Specific Testing**
Edits that check whether the claim complies with rules in HIPAA guides that apply only to government payers like Medicare and Medicaid. Examples:
* Invalid primary diagnosis on Medicare chiropractic claims
* Missing initial treatment date for Medicare chiropractic claims
# Claims view
Source: https://www.stedi.com/docs/providers/providers-claims-view
The [claims view](https://portal.stedi.com/app/healthcare/claims) in the Stedi portal provides insight into your claims processing pipeline. In the claims view, you can:
* Review every claim you submit through Stedi and the details of related claim transactions, such as 277CA claim acknowledgments.
* Review a clear timeline of activity for each claim, including resubmissions and responses you receive from Stedi and the payer.
* Understand a claim's current [status](#claim-processing-status) within the processing pipeline, such as whether the claim has been accepted or rejected.
* Filter submitted claims by key details, such as processed date, status, patient name, and service date(s).
## Filter claims [#filter-claims]
On the [claims view](https://portal.stedi.com/app/healthcare/claims), you can filter all of the claims you've submitted through Stedi. Available filters include:
* **Processed date:** When Stedi received each claim.
* **Status:** Where a claim is in the processing pipeline. Refer to [claim processing status](#claim-processing-status) for details on how we determine a claim's status and how to know if action is required to move the claim forward.
* **Type:** Claim type - professional, dental, or institutional.
* **Patient control number:** The patient control number for the claim, sometimes referred to as the claim ID. You submitted this value in:
* CMS-1500 claim form: Box 26 (Patient's Account No.)
* JSON: `claimInformation.patientControlNumber`
* X12 EDI: `Loop 2300` (Claim Information) `CLM01` (Patient Control Number)
* **Patient name:** The patient's first or last name. Partial matching is supported.
* **Member ID:** The subscriber's member ID for their health plan.
* **Payer:** Payer name, ID, or alias. Refer to the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list for each payer.
* **Billing provider NPI:** The billing provider's NPI.
* **Billing Provider TIN:** The billing provider's TIN.
* **Total charges:** Claims with a minimum or maximum charge amount.
* **Service date:** Claims with specific service dates.
Toggle **Test mode** to **ON** to review test claims you've submitted.
## Claim timeline [#claim-timeline]
From the claims view, click any claim to review a timeline of its processing activity, including when the claim was submitted and when you received 277CA claim acknowledgments from Stedi and the payer.
The timeline view also includes resubmissions for the claim and any associated 277CAs resulting from those resubmissions.
835 Electronic Remittance Advice (ERAs) and real-time claim status requests aren't currently included in the timeline. You can review 835 ERAs for adjudicated claims from the [transactions view](https://portal.stedi.com/app/healthcare/transactions) in the Stedi portal.
## Transaction details [#transaction-details]
From a claim's timeline view, hover over a transaction and click **See more detail** to review a user-friendly summary of key information, such as patient information, service dates, and service line details. You'll also be able to review the raw X12 EDI for the transaction.
## Resubmit or cancel claims [#resubmit-or-cancel-claims]
You can resubmit or cancel claims from within the claims view. Visit [Preparing claim resubmissions or cancellations](/providers/providers-review-resubmit-claims#preparing-claim-resubmissions-or-cancellations) for detailed instructions about how to prepare claim resubmissions, including choosing the right Claim Frequency Code.
### CMS-1500 form (professional) [#cms-1500-form-professional]
Stedi's CMS-1500 claim form UI is mostly limited to the CMS-1500 form fields. It may not be able to successfully resubmit complex claims originally submitted through our APIs or SFTP.
To resubmit a professional claim through Stedi's interactive CMS-1500 form:
1. Go to the [claims view](https://portal.stedi.com/app/healthcare/claims) and click the claim you want to resubmit to open its timeline.
2. Click **See more detail** above the claim submission to review its details page.
3. Click **Edit and resubmit** and select **CMS-1500 resubmission**. Stedi opens the interactive CMS-1500 form prepopulated with the claim's information.
4. Make any necessary changes to the claim.
* Make sure to update the Claim Frequency Code, the Payer Claim Control Number, and the Patient Control Number according to best practices.
* Click **Claims timeline** to open a side panel with the claim's activity. You can review related 277CA claim acknowledgments containing the errors you need to address before resubmitting. Hover over a transaction and click **See more detail** to review its details.
5. Click **Submit claim** to resubmit the updated claim to the payer.
The updated claim will appear on the [claims view](https://portal.stedi.com/app/healthcare/claims) within a few minutes. The claim timeline will reflect that this claim is a resubmission along with the original claim and any associated responses.
You'll receive new 277CA claim acknowledgments indicating whether the resubmitted claim was accepted or rejected.
### X12 EDI editor [#x12-edi-editor]
To resubmit a professional, dental, or institutional claim through Stedi's X12 EDI editor:
1. Go to the [claims view](https://portal.stedi.com/app/healthcare/claims) and click the claim you want to resubmit to open its timeline.
2. Click **See more detail** above the claim submission to review its details page.
3. Click **Edit and resubmit** and select **X12 transaction resubmission**. Stedi opens the claim in an interactive editor with the X12 EDI on the left and the EDI specification on the right.
As you hover over different parts of the EDI, Stedi highlights the corresponding part of the specification on the right to help you understand what each part of the EDI means and how to edit it correctly.
4. Make changes to the claim EDI.
* You can type directly in the EDI editor or copy and paste updated EDI from another source.
* Make sure to update the Claim Frequency Code, the Payer Claim Control Number, and the Patient Control Number according to best practices.
* Click **Claims timeline** to open a side panel with the claim's activity. You can review related 277CA claim acknowledgments containing the errors you need to address before resubmitting. Hover over a transaction and click **See more detail** to review its details.
5. Click **Review and submit**. Stedi shows a comparison of the original claim and the new claim containing your changes.
6. Click **Resubmit claim** to send the updated claim to the payer.
The updated claim will appear on the [claims view](https://portal.stedi.com/app/healthcare/claims) within a few minutes. The claim timeline will reflect that this claim is a resubmission along with the original claim and any associated responses.
You'll receive new 277CA claim acknowledgments indicating whether the resubmitted claim was accepted or rejected.
## Claim processing status [#claim-processing-status]
The claims view displays each claim's current processing status. These statuses are designed to help you quickly understand whether action is required to move claims forward.
Stedi's claim processing statuses are different from the status codes you receive in 277CAs and in real-time claim status checks:
* **277CAs:** Each 277CA contains one or more status category codes that indicate receipt, acceptance or rejection at a *specific stage* of processing. Stedi evaluates all available 277CAs to determine the claim's current *overall* processing status.
* **Real-time claim status checks:** Claim status checks can only provide status information about claims that have been accepted into the payer's adjudication system. Stedi's statuses provide insight both before and after the claim reaches the payer.
Stedi currently doesn't use information from real-time claim status checks or 835 ERAs to determine claim status. That means Stedi's statuses won't indicate when claims have been adjudicated or paid. You'll need to monitor for 835 ERAs independently.
### Stedi claim status codes [#stedi-claim-status-codes]
A claim in the Stedi portal can have one of the following processing statuses:
| status | description | What to do |
| --------- | --------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Submitted | You submitted the claim to Stedi but haven't yet received a 277CA response from Stedi or the payer. | No action needed. Monitor for the next 277CA claim acknowledgment with acceptance or rejection status. |
| Received | The clearinghouse or payer has acknowledged receipt of the claim. This doesn't mean the claim has been accepted for adjudication. | No action needed. Monitor for the next 277CA claim acknowledgment with acceptance or rejection status. |
| Rejected | Either Stedi or the payer rejected the claim. This can happen even when the payer has acknowledged receipt. | Review the 277CA claim acknowledgment for error details, correct the claim, and resubmit. |
| Accepted | The payer has accepted the claim into their adjudication system and it's currently being processed or adjudicated. | No action needed. Monitor for the next 277CA claim acknowledgment or the 835 ERA with adjudication details. |
| Invalid | The 277CA contains unsupported or invalid status codes. | Review the 277CA claim acknowledgment for details. If the 277CA is from Stedi, contact Stedi support. If the 277CA is from the payer, contact the payer for clarification. |
#### Received vs. Accepted [#received-vs-accepted]
Many payers send two 277CAs:
* An initial 277CA with `STC01-01` (Health Care Claim Status Category Code) set to `A1` (Acknowledgment/Receipt). Stedi sets the claim status to **Received**.
* A second 277CA with `STC01-01` set to an explicit Accepted or Rejected code. Stedi then updates the claim status to **Accepted** or **Rejected** accordingly.
However, some payers don't send 277CAs with explicit Accepted codes. In these cases, the claims view keeps the claim in **Received** status.
If a claim has been in **Received** status longer than expected, you can run a [claim status check](/healthcare/check-claim-status) to determine its processing status with the payer. You can also contact Stedi support with questions about behavior for particular payers.
### How we determine status [#how-we-determine-status]
Once you submit a claim, you'll receive several [277CA claim acknowledgments](/healthcare/claim-responses-overview#277ca-claim-acknowledgment) from the clearinghouse and the payer that indicate receipt, acceptance, or rejection at various stages of processing.
Stedi uses the information in the 277CAs to determine the current status of a claim.
#### Step 1: Classify each 277CA [#step-1-classify-each-277ca]
We assign each 277CA transaction a submission status based on the `STC01-1` (Health Care Claim Status Category Code) status category codes present in the transaction. [Full code list](https://x12.org/codes/claim-status-category-codes)
When there are multiple codes present within a 277CA, we evaluate codes in the following priority order:
1. Rejected
2. Accepted
3. Received
4. Invalid (unrecognized STC codes)
For example, if a 277CA contains both rejected and received status category codes, we classify the 277CA as rejected.
#### Step 2: Decide which 277CA reflects the claim's status [#step-2-decide-which-277ca-reflects-the-claims-status]
Each claim can receive multiple 277CAs from Stedi and the payer as it moves through the processing pipeline. Once we evaluate the status of all existing 277CAs for a claim, we apply the following rules to determine which 277CA reflects the claim's overall status:
1. **Current submission:** We focus on the 277CAs tied to the most-recent 837 submission. If there are no 277CAs for the most recent submission, the claim's status is set to **Submitted**.
2. **Terminal outcomes:** We prioritize by Rejected --> Accepted --> Received. For example, if any 277CA from Stedi or the payer has a rejected status, we use the 277CA rejection to set the claim status, even if there are other 277CAs with accepted codes. This helps ensure you don't miss required actions to correct and resubmit a rejected claim.
3. **Payer > Clearinghouse:** We prioritize 277CAs from the payer over 277CAs from Stedi or intermediaries. For example, if a claim has a Stedi 277CA with received status codes and a payer 277CA with received status codes, we use the payer's 277CA to set the overall claim status to **Received**.
4. **Recency:** We use recency as a final tiebreaker to ensure deterministic results. If a claim has multiple 277CAs from the same source with the same status category codes, we first check the effective date listed in the EDI transaction and use the most recent one. If those are the same, we'll use the 277CA that most recently entered Stedi's system.
Note that at this time, we **only** use 277CAs to determine claim status. We don't incorporate information from real-time claim status responses or 835 Electronic Remittance Advice (ERAs). For example, if a claim has been paid, that won't be reflected in Stedi's claim processing statuses - you'll need to monitor for the 835 ERA independently.
#### Examples [#examples]
The following scenarios illustrate how we use the above rules to determine a claim's status when there are multiple 277CAs.
**Scenario 1**
You submit a claim to Stedi and receive the following 277CAs:
| Source | Status classification | Effective date |
| ------ | --------------------- | -------------- |
| Stedi | Received | 2026-01-01 |
| Payer | Accepted | 2026-01-02 |
The claim's status would be set to **Accepted** based on the accepted status category codes in the payer's 277CA.
**Scenario 2**
You submit a claim to Stedi and receive the following 277CAs:
| Source | Status classification | Effective date |
| ------ | --------------------- | -------------- |
| Payer | Rejected | 2026-01-01 |
| Payer | Received | 2026-01-02 |
This scenario can happen when a payer sends responses out-of-order due to network delays, outage recovery, retries, or batch processes. In this case, the claim's status would be set to **Rejected** because we prioritize terminal statuses over the timing of the responses.
# CMS-1500 Claim Form PDF
Source: https://www.stedi.com/docs/providers/providers-cms-1500-claim-form-pdf
Stedi automatically generates a [CMS-1500 Claim Form](https://www.nucc.org/index.php/1500-claim-form-mainmenu-35) PDF for each professional claim you submit.
We strongly recommend reviewing the following behavior and recommendations if you plan to send these PDFs to payers or retain them for your records.
## Retrieve PDFs [#retrieve-pdfs]
To download the PDF:
1. Go to the [transactions view](https://portal.stedi.com/app/healthcare/transactions) and click the claim you want to download.
2. Click **Download CMS 1500 claim PDF**. You can choose to download it either with or without the CMS-1500 form overlay.
### Standard form size [#standard-form-size]
The generated PDFs use the standard 8.5" x 11" format.
## Edit PDFs [#edit-pdfs]
Single-page PDFs are editable so you can make any necessary adjustments before printing and sending them to payers. You can use any PDF editor to make changes to the generated CMS-1500 PDF.
## Print PDFs [#print-pdfs]
Note the following behavior and recommendations when printing CMS-1500 PDFs.
* We recommend generating PDFs with a white background (no red form overlay) if you plan to print them on pre-printed claim forms.
* The form boxes and labels **must** be printed in red ink and the item values **must** be printed in black ink for the claim form to be read by a scanner. Your vendor may choose not to process claim forms that don't conform to these specifications.
* Set the **Page Size & Handling** option to **Actual size** or the equivalent in your PDF reader application. The **Fit** option may cause the contents to be scaled down to fit within the printable area, causing the form fields to be misaligned when printed.
* Don't print forms from the Apple Preview app built in to macOS. There appear to be problems with field alignment and fonts. Instead, we recommend using either Adobe Acrobat or Google Chrome.
### Printer models [#printer-models]
We generally recommend using business laser printers to print CMS-1500 PDFs. However, due to mechanical variations between printer models, we can't guarantee that the generated PDFs will align perfectly with pre-printed forms. You should always test the alignment with your printer before using the generated PDFs for official submissions.
You may not get acceptable results when using inkjet printer models because the file contents can extend beyond the normal printable area. If you do plan to use an inkjet printer, don't enable a **borderless** option because this may cause the printer (or printer driver) to slightly magnify the page image regardless of other print settings. This behavior can crop form edges and cause form fields to appear in the wrong positions. Some inkjet printers have a manual setting to change the extension amount, but this isn't always available and may not give consistent results.
# 835 Electronic Remittance Advice (ERAs)
Source: https://www.stedi.com/docs/providers/providers-electronic-remittance-advice
An Electronic Remittance Advice (ERA) contains details about payments for specific services and explanations for any adjustments or denials. The payer only sends ERAs for accepted claims. If a claim is rejected in a 277CA, there's no adjudication or payment information to report.
## Transaction enrollment [#transaction-enrollment]
Processing ERAs always requires [transaction enrollment](/providers/providers-transaction-enrollment-intro) with the payer. Once you're enrolled, you'll receive all of your ERAs through Stedi, even if you submit some or all of your claims through another clearinghouse.
## Review 835 ERAs [#review-835-eras]
If you submitted a unique and compliant Patient Control Number for the claim, you can find related 835 ERAs on the **Related transactions** tab of the claim's details page.
1. Go to the [transactions view](https://portal.stedi.com/app/healthcare/transactions).
2. Click the associated claim to open its details.
3. Click **Related transactions** to review a list of associated transactions, including 277CA claim acknowledgments and the 835 ERA.
You can also find 835 ERAs through **Filters** on the [transactions view](https://portal.stedi.com/app/healthcare/transactions). We recommend the following filters:
{/* prettier-ignore-start */}
| Filter | Description |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Search term | - We recommend entering the claim's Patient Control Number (`Loop 2300 CLM01`) if it's unique for each claim. This is listed in the 277CA as the Patient Control Number, and it can help you find 835 ERAs for a specific claim.
- If you don't have the Patient Control Number, you can also search for another identifier, such as a the Provider Control Number (professional and dental) or Line Item Control Number (institutional) for a particular service line in the claim. You can also enter the patient's member ID or even their last name to filter the list, though this may return more than one result if there are multiple claims for the same patient.
- The search term must match what will be in the ERA exactly, including all spaces, capitalization, and punctuation.
|
| Date processed | This is the date Stedi received the 835 ERA, not the date of service. Make sure you select the correct **Time zone** at the bottom of the filter. |
| Transaction type | Select **835 Health Care Claim Payment/Advice** to show only 277CA transactions. |
{/* prettier-ignore-end */}
### Payment details [#payment-details]
You can find key payment information on the ERA's **Overview** tab, including the total amount, payment date, patient, and the charge breakdowns for each service.
### Download ERA PDF [#download-era-pdf]
Stedi autogenerates a PDF version of each processed 835 ERA. To download the PDF from the Stedi portal:
1. Go to the 835 ERA's **Overview** tab.
2. Click **Download 835 ERA PDF**.
The PDF contains a human-readable version of the ERA, including payment details, adjustments, and explanations for each service line. It adheres to the Standard Paper Remittance (SPR) format required by the Centers for Medicare and Medicaid Services (CMS).
This is a PDF representation of the 835 ERA - it's not the same as an Explanation of Benefits (EOB) or an Explanation of Payment (EOP) that you may receive from the payer.
* **EOB:** A statement from a payer explaining how a medical claim was processed, including what was covered, denied, and the remaining patient responsibility. The patient receives an EOB after a claim has been adjudicated.
* **EOP:** A version of the EOB for the provider. It contains more information related to how the payer has adjudicated the claim. The provider receives the EOP after claim adjudication and payment are sent.
* **ERA:** An electronic file that details payment and claim adjustment information. The provider receives the ERA after the payer has adjudicated the claim and issued payment, typically at the same time the funds are deposited electronically.
### Download X12 EDI [#download-x12-edi]
You can review and download the raw X12 EDI for any 835 Electronic Remittance Advice (ERA) from the **X12** tab.
The EDI is displayed on the right and the specification is displayed on the left. As you hover over different parts of the EDI, Stedi highlights the corresponding part of the specification to help you understand what each part of the EDI means.
Click the download button (down arrow icon) at the top left of the EDI viewer to download the transaction as an `.edi` file.
## Duplicate ERAs [#duplicate-eras]
Payers typically only send one ERA per claim. However, they may occasionally retransmit another identical 835 ERA, so you should be aware of the potential for duplicates.
You can assume an ERA is a duplicate if the Check or EFT Trace Number is the same. In X12 EDI, this is available in segment `TRN` (Reassociation Trace Number), element `TRN02` (Check or EFT Trace Number).
# Run eligibility checks
Source: https://www.stedi.com/docs/providers/providers-eligibility-checks
You can run real-time 270/271 eligibility checks in your account to verify a patient's insurance coverage and benefits.
You can also run a special kind of real-time eligibility check called a Medicare Beneficiary Identifier (MBI) lookup. MBI lookups allow you to retrieve benefits information from the Centers for Medicare and Medicaid Services (CMS) when you don't know the patient's MBI.
## Real-time eligibility checks [#real-time-eligibility-checks]
Real-time eligibility checks provide a response in seconds. They're ideal for in-person patient visits, telehealth appointments, and other scenarios where you need immediate information about a patient's coverage.
To run a new eligibility check:
1. Go to the [Eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility).
2. Click **+ New eligibility check**. Stedi opens the simplified eligibility check form, which we recommend for most use cases.
If you need to submit a check with additional information, click **Swap to advanced form**. On the advanced form, click **Select fields** on the top right of the window. The **Select fields** modal opens, where you can add additional form fields, such as the provider's Social Security Number (SSN) or procedure codes.
Check the boxes next to the fields you want to add to each section and click **Save selection**.
3. Complete the form. Review [eligibility request fields](#eligibility-request-fields) for detailed instructions and tips for required fields. We especially recommend reviewing how to choose the right service type code (STC) or procedure code. This is **very** important for getting the best results from the payer.
4. Click **Submit**.
Stedi opens the **Overview** page for the eligibility check. If the check was successful, you can click **Benefits** to review the patient's benefits information.
If the check failed, you can review the error code and retry the check with updated information. Visit [Fix failed eligibility checks](/providers/providers-eligibility-troubleshooting) for instructions.
## MBI lookup [#mbi-lookup]
A Medicare Beneficiary Identifier (MBI) is a unique, randomly-generated identifier assigned to individuals enrolled in Medicare. You must include the patient's MBI in every eligibility check you submit to the Centers for Medicare and Medicaid Services (CMS).
When patients don't know their MBI, you can perform an MBI lookup instead of a standard eligibility check.
### Types of MBI lookups [#types-of-mbi-lookups]
There are two types of MBI lookups you can perform with Stedi. For each, you'll use a special payer that tells Stedi to perform an MBI lookup for the patient in addition to a standard eligibility check.
| Type | What's required | Payer |
| -------- | ------------------------------------------------------------------ | ------------------------------ |
| With SSN | first name, last name, date of birth, Social Security Number (SSN) | **CMS MBI Lookup** |
| No SSN | first name, last name, date of birth, U.S. state | **CMS MBI Lookup Without SSN** |
We recommend running MBI lookups **with** the patient's SSN whenever possible. When the SSN is present, the MBI lookup has a higher likelihood of successfully returning their MBI. MBI lookups with no SSN are a fallback option when the patient's SSN isn't available.
You don't need to include more patient demographic information than what's required, such as additional address data. It doesn't improve MBI lookup success rates.
### Run an MBI lookup [#run-an-mbi-lookup]
To run an MBI lookup:
1. Go to the [Eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility) and click **+ New eligibility check**.
2. Click **Swap to advanced form**. The advanced form will allow you to add the additional fields required for an MBI lookup.
3. Construct an eligibility check request with the required patient demographic data. You don't need to include more than the required fields, such as extra address data. Extra demographic data won't improve lookup success rates.
* **With SSN:** Include the patient's first name, last name, date of birth, and SSN.
You'll need to click **Select fields** and check the box next to **Social Security Number (SSN)** under the **Subscriber** section. This adds the SSN field to the form.
* **No SSN:** Include the patient's first name, last name, date of birth, and U.S. state.
You'll need to click **Select fields** and check the box next to **State** under the **Subscriber > Address** section. This adds the **State** field to the form. You can leave the rest of the address fields blank.
4. Set the **Service type code** to `30` (Health Benefit Plan Coverage).
5. Set the **Trading partner service ID** to either:
* **CMS MBI Lookup** for MBI lookups with SSN.
* **CMS MBI Lookup Without SSN** for MBI lookups without SSN.
6. Enter the rest of the required information. Review [basic eligibility request fields](#basic-eligibility-request-fields) for detailed instructions about how to complete remaining form fields.
7. Click **Submit**.
Stedi uses the patient's demographic data and SSN to perform an MBI lookup. If there is a match, Stedi submits an eligibility check to CMS. Stedi returns a complete eligibility response from CMS for the patient and returns the patient's MBI as the subscriber's member ID.
Stedi automatically opens the **Eligibility search** overview page for the MBI lookup when it's complete.
Medicare Advantage plans have their own unique member ID, which **isn't** returned in the MBI lookup response. You also shouldn't submit eligibility checks for Medicare Advantage plans to CMS (HETS) - you should submit them to the actual Medicare Advantage plan payer instead.
#### Outdated MBI error [#outdated-mbi-error]
Stedi's MBI lookup may rarely retrieve an outdated MBI for a patient. CMS may rotate an MBI for a member for various reasons at any time, such as to help protect against identity theft.
In these cases, the response will contain an `AAA` error with code `72` (Invalid/Missing Subscriber/Insured ID) *and* return a subscriber member ID, which is the outdated MBI.
## Eligibility request fields [#eligibility-request-fields]
For the best chance of success, start by sending the smallest possible set of fields in your eligibility checks. Adding extra data can lead to unnecessary rejections.
We recommend starting with the following information. Only include more if the payer requires it.
{/* prettier-ignore-start */}
| Form section | Instructions | | | |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | - | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Payer**, or trading partner service ID | Select your payer from the provided list. Hover over **view details** to review a summary of the payer's various identifiers and open the full payer record in Stedi's [Payer Network](https://www.stedi.com/healthcare/network). | | | |
| **Provider** | Most eligibility requests require the provider's name - either their first and last name (individual) or business name (organization) - and their National Provider Identifier (NPI). If you need to provide additional information, such as the provider's Social Security Number (SSN), click **Swap to advanced form** and then click **Select fields** to add additional fields to the request form. | | | |
| **Subscriber** | - At a minimum, you must supply at least the subscriber's **Member ID**, **Date of birth**, or **Last name**. However, each payer has different requirements, so you should supply the fields necessary for each payer to identify the subscriber in their system.
- When you supply the subscriber's member ID, first name, last name, and date of birth, payers are required to return a response if the member is in their database. That's why these are the default form fields.
- If you need to run an MBI lookup with the subscriber's Social Security Number (SSN), click **Select fields** and check the box next to **Social Security Number (SSN)** under the **Subscriber** section. This adds the SSN field to the form.
| | | |
| **Dependent** | A patient qualifies as a dependent for eligibility checks when they are listed as a dependent on the subscriber's insurance plan and the payer cannot uniquely identify the patient through information outside the subscriber's policy. If the patient has their own member ID (even if it only differs by a suffix like `0`), you must identify them in the **Subscriber** section instead. - To add a dependent to the real-time eligibility check form, click **Select fields** and select **Dependents**.
- You can only submit one dependent per eligibility check.
- Most Medicaid plans don't support dependents - you'll almost always need to submit the child as a subscriber in the **Subscriber** section. Sending dependent information here for payers that don't support dependents will either cause an error, or the payer may return results for the subscriber instead.
- We strongly recommend including the dependent's date of birth in the request when available because many payers return errors without it.
- Enter the dependent's name exactly as written on their insurance card, if available, including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces.
| | **Trading partner service ID** | You must specify the payer.- For real-time eligibility checks, select the payer from the dropdown list.
- For MBI lookups, you must select **CMS MBI Lookup** from the dropdown list.
|
| **Encounter**, service or procedure codes | You must include either a service type code (STC) or a procedure code and qualifier. This tells the payer what kinds of benefits information you're requesting. Most medical payers don't support procedure codes. Some dental payers do, but we recommend trying an STC first.- We recommend STC `30` (Health Benefit Plan Coverage) to retrieve a patient's general medical benefits and `35` to retrieve a patient's general dental benefits.
- We recommend submitting one STC per request, unless you've tested and are certain that the payer supports multiple.
- When requesting benefits for specific services, you should test the STCs that seem most appropriate to determine which ones yield the most benefits information. Our STCs and procedure codes docs explain how.
- By default, the real-time eligibility check form allows you to choose a **Service type code**. If you want to include a procedure code instead, click **Swap to advanced form** and then click **Select fields**. Select the boxes for the **Procedure code** and **Product or service ID qualifier** to add them to the form. Note that you can submit either an STC or a procedure code and qualifier - not both.
| | | |
| **Encounter**, service dates | Stedi populates today's date as the date of service by default.- To add a date range, click **Swap to advanced form** and click **Select fields**. Under **Encounter**, select both the **Beginning date of service** and **End date of service** (date range).
- We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers such as the Centers for Medicare and Medicaid Services (CMS) do support requests for dates further in the future - especially the next calendar month. Check the payer's documentation to determine their specific behavior.
| | | |
{/* prettier-ignore-end */}
## Patient information [#patient-information]
Follow this guidance to help payers find the patient in their system.
### Payer search requirements [#payer-search-requirements]
All payers are required to be able to search for patients using the following "bare minimum" subsets of information. They will return benefits information as long as they can find a unique match for the patient within their system.
For a subscriber:
* Member ID, first name, last name, date of birth
* Member ID, last name, date of birth
* Member ID, first name, last name
For a dependent:
* Subscriber member ID, first name, last name, date of birth
* Subscriber member ID, last name, date of birth
* Subscriber member ID, first name, last name
Of course, not all of this patient information is always available. For example, a patient may forget their ID card. In these instances, some payers may still be able to search with even less information, such as the patient's first name, last name, and date of birth. Contact us if you have questions about alternative search options for a particular payer.
### Dependents [#dependents]
The patient qualifies as a dependent for eligibility checks when:
1. The patient is listed as a dependent on the subscriber's insurance plan.
2. The payer cannot uniquely identify the patient through information outside the subscriber's policy.
When the patient meets these criteria, you should submit their information in the **Dependent** section of the form. Otherwise, you must submit their information in the **Subscriber** section instead.
For example, if the dependent has their own member ID number in the payer's database, you must identify them as a subscriber. This includes member IDs that differ only by a suffix, such as `01`, because the patient can still be uniquely identified.
#### Medicaid dependents [#medicaid-dependents]
Most Medicaid plans don't support dependents. However, some state Medicaid plans support eligibility inquiries for newborn children under 12 months old.
Children typically must be enrolled in Medicaid as a separate subscriber with their own unique member ID, even if they are legally the dependent of a parent who is a Medicaid plan member. Therefore, you'll almost always need to submit the child as a subscriber in the **Subscriber** section.
Sending dependent information to payers that don't support dependents will either cause an error, or the payer may ignore the information and return results for the subscriber instead.
### Patient names [#patient-names]
Note the following information and best practices when entering patient names:
* Enter the name exactly as written on the patient's insurance ID card (if available), including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces. If the patient's insurance ID card isn't available, enter the name exactly as written on a government-issued ID card. If a government ID card isn't available, enter the name exactly as given by the patient.
* Don't include a name prefix, title, rank, honorific, or academic degree in any field. These include Mrs., Dr., Hon., and PhD.
* Don't include a suffix or generation such as Jr. or III in the **First name** or **Last name** field. Put it in the separate **Suffix** field instead. Payers are supposed to automatically parse suffixes out of the last name, but Stedi can't guarantee that all payers will do this correctly.
* You can populate a middle name (or names) or initial in the **Middle name** field, but most payers ignore it when searching for the patient.
* Case doesn't matter. For example, JANE is equivalent to Jane.
The following are supported for patient names:
* Compound last and first names separated by spaces or hyphens such as Jean‐Claude or Smith Jones
* Apostrophized or elided names such as O'Connor or D'Amore
* Numbers like 3, however this typically indicates a data entry error
Some payers may have more specific requirements or restrictions that we don't cover in our docs. If you're receiving errors for a specific payer, we recommend consulting that payer's documentation for eligibility checks for additional guidance.
## CMS HETS Rules of Behavior [#cms-hets-rules-of-behavior]
All parties involved in eligibility transactions sent to the Centers for Medicare & Medicaid Services (CMS) eligibility system, called HETS, must comply with the [HETS Rules of Behavior](https://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/hetshelp/downloads/eligibilitytransactionsysteminquiriesrulesofbehavior.pdf). Compliance is also required under our terms.
Review the Rules of Behavior before sending eligibility checks to CMS.
# Eligibility PDF
Source: https://www.stedi.com/docs/providers/providers-eligibility-pdf
Stedi generates a PDF with a summary of an eligibility check's request details and a user-friendly version of the benefits response.
If the response contains errors, the PDF displays them with possible resolutions. When an eligibility check returns benefits information, you can use the PDF to determine:
* whether the patient has active coverage with the health plan.
* whether a patient's health plan covers the requested services.
* patient responsibility amounts, such as co-pays and deductibles.
* whether prior authorization is required for specific services.
## Download the PDF [#download-the-pdf]
To download the PDF:
1. Go to the [eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility) in the Stedi portal.
2. Click the eligibility search with the patient information you want to view.
3. Click **Download PDF** at the top of the eligibility check's details page.
## PDF structure [#pdf-structure]
The PDF has the following primary sections.
### Summary [#summary]
For successful eligibility checks, the summary section at the top clearly indicates whether Stedi found *any* service type codes (STCs) or procedure codes with active coverage in the response. You can then check the [benefits tables](#benefits) to determine which specific services are covered.
The summary section also shows details about the subscriber, payer, and provider. This includes plan details such as when coverage starts, the plan dates, and the group name and number.
If the eligibility check response contains errors, the summary section indicates that the check was **Failed** and lists the errors with possible resolutions.
### Benefits [#benefits]
The **Benefits** section contains tables listing all the benefits information returned in the response. Each row in the table corresponds to a specific benefit for a specific service type code (STC) or procedure code.
The benefits are grouped in two ways:
* The first grouping mechanism is the patient's health plan. Many eligibility responses only contain benefits for a single health plan, but some responses include benefits for multiple plans. For example, if the patient has both a primary health plan and a dental plan, the PDF will contain separate sections for each plan.
* Within each health plan section, benefits are further grouped by STC and procedure code.
The following example shows the patient's benefits for STC `30` (Health Benefit Plan Coverage). Note that their plan name **E20** is at the top of the section. The PDF notes that this is **Plan 1 of 1**, meaning that the payer returned information about a single health plan for this patient.
For each STC or procedure code, the columns in the table include:
| Column | Description |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Type** | The type of benefit, such as co-payment, deductible, or prior authorization requirement. |
| **Coverage level** | The level of coverage for the benefit, such as Individual or Family. |
| **Network indicator** | Whether the benefit applies to in-network or out-of-network providers. Note that this column only indicates whether the benefit applies to in-network or out-of-network providers in general. It doesn't indicate whether the requesting provider is in-network or out-of-network for the patient. |
| **Coverage** | The amount or details of the benefit. For rows with the **Statuses** type, this column lists whether the patient has active coverage for that STC or procedure code. For patient responsibility rows, this column lists the amount the patient is responsible for. For example, a co-payment row may list a $20 co-payment amount. |
| **Benefit** | Additional details about the benefit. This column includes the plan type, places of service, whether prior authorization is required, and any messages from the payer about the benefit. For example, a co-payment row may include a message that says "waived if admitted to hospital." |
There may be multiple benefits for the same STC and benefit type. For example, a patient may have different co-insurance amounts for in-network and out-of-network providers or for specific services within a broader STC. The **Messages** field contains notes from the payer, which typically list limitations or conditions that apply to the benefit.
In the following example, the patient has a $200 co-payment for STC `86` (Emergency Services), but the messages indicate that this co-payment is waived if the patient is admitted to the hospital.
### Request [#request]
The final **Request** section provides a human-readable version of the original 270 eligibility check request. This helps you remember what STCs and procedure codes you requested and compare that to the benefits the payer returned in the response.
## Interpret the PDF [#interpret-the-pdf]
You can use the information in the PDF to answer important questions about the patient's coverage and financial responsibility for services.
### Does the patient have coverage? [#does-the-patient-have-coverage]
The PDF indicates at the top in the **Summary** section whether there was a service type code (STC) or procedure code with active coverage returned.
Then, you can check to see if there's a **Statuses** row for the STCs or procedure codes you care about. Typically, only broad STCs (`30` and `35` for general medical and dental coverage) will have a status.
Quick reference:
* The patient has coverage when the status is **Active coverage** for the relevant STC or procedure code. You can also assume the patient has coverage when there is no status, but benefits are listed (such as co-pay or deductible amounts).
* The patient doesn't have coverage when the status is **Inactive** for an STC or procedure code. You can also assume the patient doesn't have coverage if there are no benefits listed or the payer returned a message indicating that the service isn't covered.
### What is the patient's financial responsibility? [#what-is-the-patients-financial-responsibility]
Once you've confirmed that the patient has coverage, you may want to understand their financial responsibility for services. For example, you may want to know their co-pay amount for an in-office visit or whether they've met their deductible.
Within each STC or procedure code section, the PDF includes rows for each type of patient responsibility.
The following example shows that for STC `83` (Infertility), the patient has a yearly out-of-pocket maximum of $7,500 for individual coverage and a $15,000 out-of-pocket maximum for family coverage. They also have a co-payment of $50 for in-office visits for both in and out-of-network providers.
### Is the provider in- or -out-of-network? [#is-the-provider-in--or--out-of-network]
Unfortunately, you can't reliably answer this question from a standard eligibility response. That means you also can't reliably answer this question from the generated PDF.
Payers typically don't explicitly indicate whether the requesting provider is in- or out-of-network for the patient (though there are some exceptions). The Network indicator field in the table only indicates whether the benefit applies to in-network or out-of-network providers in general. It doesn't tell you whether the requesting provider is in- or out-of-network for the patient.
Some payers do provide additional information about whether the requesting provider is in- or out-of-network. They may do this through either freeform messages or selective inclusion of benefits in the response.
For example, some payers only return out-of-network benefits if the requesting provider is out-of-network. Likewise, if the provider is in-network, they only provide in-network benefits. Stedi doesn't have a complete list of payers that selectively include or exclude benefits based on the provider's network status.
**The most reliable way to determine network status is to check directly with the payer or the provider.** Note that payers may have different networks for different health plans, such as employer-sponsored plans versus Medicare Advantage, and these networks may have different contact paths.
### Is prior authorization required? [#is-prior-authorization-required]
Prior authorization (also called pre-authorization or pre-certification) is a requirement that the patient or their provider must get approval before a payer will cover specific services, procedures, medications, or devices. Without it, the payer may deny claims.
If the payer provides prior authorization information in the eligibility response, it will be listed in the **Benefit** column for that service or procedure. The payer may also send messages about prior authorization rules.
If the payer doesn't provide prior authorization information for a service or procedure, you can assume that prior authorization isn't required.
In the following example, the patient requires prior authorization for both STC `A7` (Psychiatric - Inpatient) and STC `A8` (Psychiatric - Outpatient) services. This rule applies to both in-network and out-of-network providers.
# Eligibility search
Source: https://www.stedi.com/docs/providers/providers-eligibility-search
Every eligibility check you run is stored in an **eligibility search**. An eligibility search is a container for all retries of a particular eligibility check. It's similar to how Microsoft Word and Google Docs keep a version history.
For example, if you submit an initial eligibility check with the wrong spelling for a patient's name, you can quickly edit the request details and resubmit it. Stedi stores both the original request and the retry within the same eligibility search. This creates a timeline of your troubleshooting efforts for failed checks and allows you to go back to previous versions if needed.
When you click an eligibility search to view its details, we show you the latest version of the eligibility check by default. The following example shows the details page for an eligibility search. It's showing **Check 1**, which is the latest version of the eligibility check.
You can view a list of all your eligibility searches on the [Eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility).
## Filter eligibility searches [#filter-eligibility-searches]
You can filter the list of eligibility searches to find previous eligibility checks you've run in your account.
To filter eligibility searches:
1. Go to the [Eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility).
2. Click **Filters**.
3. Specify the filter criteria. You can specify the following filters:
* **Error code:** By the AAA code returned by the payer. For example, `42` errors indicate a connectivity issue.
* **Payer:** By the Payer ID (62308) or business name (such as Cigna). Include any leading zeros when entering a payer ID - for example, use 00540, not 540.
* **Status:** By `Active`, `Inactive`, `Failed`, `Started`, `Queued`
* **Date started:** A date range for when the initial eligibility check within an eligibility search was submitted. For example, a filter beginning on October 1st would only include eligibility searches with an initial submission on or after October 1st. It would *not* include an eligibility search with an initial submission on September 30th and a retry on October 1st.
* **Provider NPI:** By the National Provider Identifier (NPI) of the requesting provider.
4. Click **Apply filters**.
Results are sorted by the date of the original eligibility check within the eligibility search, with the most recent listed first.
## Eligibility search statuses [#eligibility-search-statuses]
The status of an eligibility search is determined by the most recent eligibility check in the record. For example, if the most recent iteration of a check failed, the status of the entire eligibility search is `Failed`, even if a previous version of the request succeeded.
An eligibility search can have one of the following statuses:
{/* prettier-ignore-start */}
| Status | Description |
| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Queued** | Stedi placed the eligibility check in its internal queue and will send it to the payer when resources are available. You can typically expect the status to change to `Started` within a few seconds. |
| **Started** | Stedi sent your eligibility check to the payer and is waiting for a response. |
| **Failed** | The payer returned an error code in the response. |
| **Inactive** | The payer's response doesn't contain an active eligibility and benefit type. |
| **Active** | The payer's response contains an active eligibility and benefit type. These are the following benefit type codes:- 1 - Active Coverage
- 2 - Active - Full Risk Capitation
- 3 - Active - Services Capitated
- 4 - Active - Services Capitated to Primary Care Physician
- 5 - Active - Pending Investigation
|
{/* prettier-ignore-end */}
# Troubleshoot failed eligibility checks
Source: https://www.stedi.com/docs/providers/providers-eligibility-troubleshooting
You can edit the request details for failed eligibility checks and resubmit them as many times as you need to get a successful response. For some types of errors, you can use the Stedi Agent to troubleshoot automatically.
## Review eligibility check errors [#review-eligibility-check-errors]
The [Eligibility check errors page](https://portal.stedi.com/app/healthcare/checks/reports/errors) shows a list of recent eligibility check `AAA` error codes. These are errors the payer returns when they reject your eligibility request. They specify the reasons for rejection and any recommended follow-up actions.
To go to this page, open the **Eligibility** menu in the navigation bar and select **Errors**.
The errors are grouped by error code, and you can filter the list by Payer ID. You can look up any payer's ID in the [Payer Network](https://www.stedi.com/healthcare/network). Click on an error code to review a list of all the instances of that error.
This page helps you identify patterns in eligibility check failures. For example, if you see a large number of errors with code `75` (Subscriber/Insured Not Found) for a specific payer, you might want to investigate whether there are common issues with the patient data being submitted to that payer.
## Retry failed eligibility checks [#retry-failed-eligibility-checks]
There are three ways to retry a failed eligibility check: using the [Stedi Agent](#stedi-agent), [manually resubmitting](#edit-and-retry) the request, or using [Debug view](#debug-view).
### Retry with the Stedi Agent [#retry-with-the-stedi-agent]
The Stedi Agent can troubleshoot and resolve common recoverable eligibility check errors automatically. To use it, you must be at least an [Operator](/providers/providers-accounts-and-billing#assign-member-roles) role within your Stedi account.
To resolve a failure with the Stedi Agent:
1. Go to the [Eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility).
2. Click **Resolve with Stedi Agent** next to an eligibility search. The button appears when you hover over the green agent indicator. Only eligibility search with common recoverable errors will have the agent indicator next to them. If an eligibility search doesn't have this symbol, you'll need to retry it manually.
3. The Stedi Agent opens a side panel in [Debug view](#debug-view).
4. The Stedi Agent analyzes the eligibility request and works through best practice recovery strategies based on the error type. For example, if the payer returned an error code `75` (Subscriber/Insured Not Found), the agent may try different combinations of patient data or adjust the name format to find a match in the payer's system.
Each time the agent retries the eligibility check, it stores the new request in the same eligibility search record and it shows up in Debug view in real time. This allows you to see the history of attempts and the progression of the agent's troubleshooting efforts.
The agent only accesses data from the eligibility search it's working on. It can't access data from other searches, customers, or systems.
Please note:
* The Stedi Agent is available on all paid Stedi plans at no additional cost beyond those for related API calls.
* The agent is assistive. Outputs can be incorrect or incomplete. Verify all responses before taking any action based on them.
* You are responsible for any actions you instruct or authorize the AI service to take, including generating billable requests on your behalf.
### Manually edit and retry [#manually-edit-and-retry]
To manually resubmit an eligibility check:
1. Go to the [Eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility).
2. Click the eligibility search you want to troubleshoot to view its details.
3. Click **Actions** and then select **Edit and retry**.
4. Update the request details as needed, and click **Submit**.
You'll know the retry was successful when the [status of the eligibility search](/providers/providers-eligibility-search#eligibility-search-statuses) is either `Active` or `Inactive`. If the status of the eligibility search is still `Failed`, you may want to try resolving in [Debug view](#debug-view) or using the [Stedi Agent](#stedi-agent), if available.
### Iterate in Debug view [#iterate-in-debug-view]
Debug view is a workspace where you can systematically troubleshoot failed eligibility checks until you receive a successful response from the payer. For example, first you might try swapping the patient's nickname (Dave) for their full name (David) to see if that returns benefits information. In the next iteration, you might try submitting the request with a different service type code or dropping the date of birth.
Debug view shows all past iterations of the eligibility check and highlights the differences between each new version of the request. You can also draft and submit new requests directly from this page. This format helps you understand what you've already tried and quickly iterate on failed requests.
To troubleshoot eligibility checks in Debug view:
1. Go to the [Eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility).
2. Click the eligibility search you want to troubleshoot to view its details.
3. Click **Actions > Debug** to enter Debug view.
4. Click **+ Add draft** to create a new draft request. Stedi pre-populates the draft with the details from the most recent eligibility check in the search.
5. Update the draft request as needed. Use the **Edit columns** list to show or hide specific fields in the request.
6. Click the green arrow when you're ready to submit the updated eligibility check draft.
Stedi runs the check and moves it to the list of **Past checks**. Stedi highlights the differences between it and other past checks so you can see a clear record of your troubleshooting efforts. You can repeat this process as many times as needed to get a successful response.
## CMS attestation required [#cms-attestation-required]
CMS requires providers to complete attestation (also called HETS EDI Enrollment) before running Medicare eligibility checks. This requirement applies to traditional Medicare only, not Medicare Advantage (Part C) or Part D plans.
If you submit a Medicare eligibility check without completing attestation, CMS rejects the request with an error code `41` (Authorization/Access Restrictions).
To resolve this error, complete the [CMS eligibility enrollment requirement](/providers/providers-submit-enrollment-requests#cms-eligibility-enrollment) for the billing NPI. Attestation takes approximately 5-15 minutes per NPI.
## Payer unable to find patient [#payer-unable-to-find-patient]
Sometimes, a payer can't return benefits information for a patient even when the patient exists in their system. This problem can occur for a couple reasons.
### Multiple matching records [#multiple-matching-records]
Payers can have multiple records of patients with the same name and date of birth. The payer cannot return benefits information unless they are able to identify a unique match within their system.
To avoid this issue, we recommend:
* Include all of the demographic information available for a patient.
* Include the patient's member ID, if available.
### Information discrepancies [#information-discrepancies]
There can be discrepancies between the information the provider has collected from the patient and the record the payer has in their system. These discrepancies can lead to issues returning a patient, even though a match exists. Some examples include differences in spelling the patient's name, using a nickname instead of the full name ("Nick" vs. "Nicolas"), and accidentally transposing numbers in the date of birth.
If a request fails to return the expected member in the response, we recommend progressively sending additional eligibility check requests with fewer patient identity and demographic data elements, or different combinations of those. This allows you to identify and handle cases where there are data errors or discrepancies between payer and provider data.
### Name mismatches [#name-mismatches]
If the payer fails to find a matching plan member due to a name mismatch, the `errors` array in the response typically has the `code` set to one of the following values:
* `65`: Invalid/Missing Patient Name
* `67`: Patient Not Found
* `73`: Invalid/Missing Subscriber/Insured Name
* `75`: Subscriber/Insured Not Found
These error codes are set by the payer, not by Stedi, so it's possible that other error codes could be returned.
Resolving the error may require trying different name variations until the check is successful.
* Replace any nickname or shortened name with the full legal name, for example "Robert" instead of "Bob".
* Replace any non-English or accented characters (letters with diacritical marks) such as "Ñ" or "é" with the closest equivalent within the character restrictions. Stedi automatically replaces most such characters with the usual closest equivalent but this might not match the payer's record. For example, the character "Đ" could be transliterated to "D" or "J" depending on the romanization system used.
* For compound names try using only one or the other part. You can also try try removing the separator, or changing the separator from hyphen to space, or vice versa. Some payers may ignore special or separator characters when performing name searches.
* If the patient has recently changed their name, for example due to marriage, then the name stated by the patient or printed on their ID card might not match the payer's record. Try both the current and previous name.
# Manage enrollment requests
Source: https://www.stedi.com/docs/providers/providers-manage-transaction-enrollments
You'll get notification emails each time a transaction enrollment request status changes or there is new information for you to review. You can also track and manage enrollment requests from within your Stedi account.
## Monitor enrollment status [#monitor-enrollment-status]
You can track the status of your transaction enrollment requests from the [Enrollments page](https://portal.stedi.com/app/healthcare/enrollments) in your account.
Click an enrollment request to view its details, including:
* The provider and payer associated with the enrollment.
* The transaction types included in the enrollment.
* The current status of the enrollment.
* Any notes or instructions from Stedi or the payer.
* The history of status changes and actions taken on the enrollment.
* Enrollment documents, such as signed PDF forms.
### Enrollment statuses [#enrollment-statuses]
An enrollment request can have one of the following statuses:
{/* prettier-ignore-start */}
| Status | Description |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| DRAFT | You are still editing the record and it has not been submitted to Stedi. |
| STEDI\_ACTION\_REQUIRED | You have submitted the enrollment and it is ready for Stedi to begin processing. |
| PROVIDER\_ACTION\_REQUIRED | The enrollment requires action from the healthcare provider to proceed, such as providing additional documentation. Stedi will add a note to your enrollment request with clear instructions. |
| PROVISIONING | Stedi has begun the process of completing the enrollment with the payer. |
| LIVE | The enrollment process is complete, and the specified provider can begin exchanging the listed transaction types with the payer. |
| REJECTED | The payer rejected the enrollment. Common reasons for rejection include incorrect details in the request and that the provider is not credentialed with the payer. Customer support will contact you with reasons for rejection and next steps. |
| CANCELED | The enrollment has been terminated per customer or provider request. You can only [cancel enrollments](#cancel-enrollments) that are in `DRAFT`, `STEDI_ACTION_REQUIRED`, or `PROVIDER_ACTION_REQUIRED` status. |
{/* prettier-ignore-end */}
### Notification emails [#notification-emails]
Once an hour, Stedi checks for enrollment request status changes. If there are updates, Stedi sends a notification email with a summary. The email includes a link to the enrollment request where you can review required tasks, notes, and other details.
Email notifications are sent to the address designated as the **Person for Stedi to contact** about the enrollment. This is typically the email associated with the Stedi account that created the enrollment request, and it may differ from the provider's designated contact.
If you aren't receiving notification emails for enrollment request updates, contact Stedi support through our [Contact us form](https://www.stedi.com/contact) or your designated Slack or Teams channel.
### Rejected enrollments [#rejected-enrollments]
In rare cases, the enrollment status might be set to `REJECTED` if the payer denies the enrollment request. Rejection can happen for many reasons, but the most common are:
* You aren't credentialed with the payer. If a payer rejects your transaction enrollment request with a message indicating the provider is "not on file" or "not recognized," it likely means you haven't completed credentialing and payer enrollment with that payer. You'll need to contact the payer and complete their credentialing process before you can successfully enroll for transactions through Stedi.
* There was incorrect data in the enrollment submission.
If an enrollment is rejected, Stedi puts a note on the enrollment request explaining the reason and how to resolve it. Contact Stedi support with any additional questions.
## Manage enrollment tasks [#manage-enrollment-tasks]
Tasks are actions that either the provider or Stedi need to complete to move the enrollment process forward.
When there's a new task that requires you to take action, Stedi adds a task to the enrollment request with instructions and sets the enrollment status to **Provider Action Required**. You'll [receive a notification email](#notification-emails) that there's a new task to complete.
Stedi is automatically notified when you complete a task, and the enrollment process continues.
### Task types [#task-types]
Tasks fall into three categories:
* **Follow instructions:** Complete a specific action, such as logging into a payer portal or contacting a department. The task includes instructions explaining what to do.
* **Provide information:** Supply specific information or confirmation to Stedi. The task describes what information is needed.
* **Provide documentation:** Upload PDF documentation related to the enrollment.
When a task requires documentation, Stedi may ask you to:
* **Complete a template:** Stedi provides a PDF template for you to download, fill out, and upload back to Stedi.
* **Upload supporting documentation:** Stedi asks you to provide a document you already have, such as a W-9 form or voided check.
### Complete tasks [#complete-tasks]
You can review and manage tasks at the top of the enrollment request's details page in the Stedi portal. You must have the [Operator role](/providers/providers-accounts-and-billing#assign-member-roles) or above to complete enrollment tasks.
Once you've taken the required action, check the box next to the task to mark it as complete. Stedi is automatically notified when you complete a task, and the enrollment process continues.
## Manage enrollment documents [#manage-enrollment-documents]
You can upload documents through [tasks](#task-types) Stedi assigns on the enrollment request. Stedi may also upload documentation throughout the enrollment process. You can review, download, or delete these documents as needed. Documents associated with an enrollment may include:
* Completed enrollment forms
* W-9 tax forms
* Voided checks
* Other documentation that Stedi completes and submits to the payer
To review, download, or delete documents associated with an enrollment request:
1. Go to the [Enrollments page](https://portal.stedi.com/app/healthcare/enrollments) and click the enrollment request.
2. Scroll to the **Documents** section at the bottom of the page.
In the **Documents** section, click any document to view it in your web browser. You can also click **...** (ellipses) to the right of the document to:
* Download the original PDF file.
* Copy a secure link to view the file, which you can share with any member of your Stedi account.
* Delete the file, if necessary.
## Cancel enrollments [#cancel-enrollments]
You can only cancel enrollment requests that are in `DRAFT`, `STEDI_ACTION_REQUIRED`, or `PROVIDER_ACTION_REQUIRED` status. To cancel, reach out to Stedi support through our [Contact us form](https://www.stedi.com/contact) or your designated Slack or Teams channel. Once an enrollment is canceled, Stedi sets its status to `CANCELED` and stops the enrollment process with the payer.
We can't cancel enrollments that are in `PROVISIONING` or `LIVE` status. Once an enrollment is in one of these statuses, the only way to stop 835 ERAs from coming to Stedi is to submit an enrollment through another clearinghouse.
## Transaction Enrollments Hub [#transaction-enrollments-hub]
Our network and enrollment operations team knows the nuances of each payer’s enrollment requirements and maintains a public repository of payers that require additional transaction enrollment steps through our [Transaction Enrollments Hub](https://enrollments.stedi.com).
However, you don't need to keep track of these requirements. We'll contact you directly if there are additional steps you need to take to complete enrollment with a specific payer.
# Stedi portal UI
Source: https://www.stedi.com/docs/providers/providers-review-patient-benefits
In the [Stedi portal](https://portal.stedi.com/app/healthcare/eligibility), you can review the results of successful eligibility checks to determine whether a patient's health plan covers the requested services. You can also view details about specific benefits, such as co-pay amounts, deductible information, and whether prior authorization is required.
## Eligibility check results [#eligibility-check-results]
To review an eligibility check's results:
1. Go to the [eligibility searches view](https://portal.stedi.com/app/healthcare/eligibility).
2. Click the eligibility search with the patient information you want to view.
Stedi opens the eligibility search's **Overview** tab.
### Overview tab [#overview-tab]
The **Overview** tab shows details about the latest eligibility check in the eligibility search.
If the eligibility check was successful, the **Overview** tab contains:
* The check's [status](#eligibility-check-statuses)
* Patient information, such as their name, date of birth, and member ID.
* The service type code(s) you requested.
* The requesting provider's information, including their name and NPI.
* The payer's information, including their name and Payer ID.
* The patient's health plan information, including the plan names, group number, and plan begin and end dates.
* Any benefits related entities, which are commonly used to designate the patient's primary care provider (PCP), another organization that handles a specific carveout benefit type (such as telehealth mental health services), or another health plan for the patient (coordination of benefits scenarios).
### Benefits tab [#benefits-tab]
The **Benefits** tab displays the patient's benefits in filterable tables. Information in the table is grouped into sections:
* The first grouping mechanism is the patient's health plan. Many eligibility responses only contain benefits for a single health plan, but some responses include benefits for multiple plans. For example, if the patient has both a primary health plan and a dental plan, the benefits view will contain separate sections listing all of the benefits for each plan.
* Within each health plan section, benefits are further grouped by service type code (STC) and procedure code so that you can easily find and review all of the benefits for a specific set of services.
There may be multiple benefits for the same STC and benefit type. For example, a patient may have different co-insurance amounts for in-network and out-of-network providers or for specific services within a broader STC. The **Message** or **Messages** field contains notes from the payer, which typically list limitations or conditions that apply to the benefit.
In the following example, the patient has a $50 co-pay for Emergency Services (STC `86`), but the messages indicate that this co-pay is waived if the patient is admitted to the hospital.
#### Benefits filters [#benefits-filters]
Payers typically send more benefits information than you requested. You can filter the benefits table by the following criteria to review only the benefits you care about. The options for each filter type depend on the benefits data in the payer's response. For example, if the payer didn't return any family-level benefits, the **Coverage level** filter won't have a `Family` option.
{/* prettier-ignore-start */}
| Filter | Description |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Type | This is the benefit type code, such as `Co-insurance` or `Deductible`. |
| Coverage level | The coverage level. This is typically either `Individual` or `Family`, but the values can vary depending on the patient's plan. |
| Network | Whether the benefit applies to in-network providers, out-of-network providers, or both.- The payer may not send this indicator for every benefit. In these cases, the **Network indicator** field in the benefits table will be `Not set`.
- This field doesn't tell you whether the provider is in or out-of-network for the patient. To determine that, you must check directly with the payer.
|
| Service or procedure | The service type code (STC) or procedure code associated with the benefit. For example, `UC` for Urgent Care or `MH` for Mental Health. |
| Place of service | The names of place of service codes associated with the benefit. For example, `Emergency Room - Hospital` for service type code `23`. |
| Message | Messages from the payer associated with the benefit. For example, `Co-pay waived if admitted`. |
| Plan name | The name of the patient's health plan. |
{/* prettier-ignore-end */}
For example, to determine the patient's co-pay for urgent care visits with in-network providers, you might set the **Type** filter to `Co-payment`, the **Network** filter to `In-Network`, and the **Service or procedure** filter to `UC` or another relevant code.
### Eligibility check statuses [#eligibility-check-statuses]
An eligibility check can have the following statuses:
| Status | Description |
| ----------- | ----------------------------------------- |
| Active | A service with active coverage was found. |
| Failed | Coverage was not determined. |
| Inactive | Active coverage was not found. |
| Investigate | Contact the payer for more information. |
Note that an **Active** status only indicates that there was at least one service type with active coverage in the benefits response. You must check the response details to determine whether the patient has active coverage for the services you care about.
## Does the patient have coverage? [#does-the-patient-have-coverage]
The patient has coverage when the date of service is within the plan's eligibility period, and the patient has active coverage for the relevant services. Here's how to check whether these conditions are met:
1. Go to the **Overview** tab of an eligibility search.
2. Review any available **Plan begin** and/or **Plan end** dates.
If the date of service is within that range, the patient may have coverage.
1. Go to the **Benefits** tab.
2. Filter by **Service / procedure** and choose the STC(s) or procedure code(s) you care about.
The **Status** field in the **Benefit** column may show whether the patient has active coverage for the relevant STC(s) or procedure code(s). Typically, only broad STCs (`30` and `35` for general medical and dental coverage) will have a status.
* The patient has coverage when the status is **Active coverage** for the relevant STC or procedure code. You can also assume the patient has coverage when there is no status, but benefits are listed (such as co-pay or deductible amounts).
* The patient doesn't have coverage when the status is **Inactive** for an STC or procedure code. You can also assume the patient doesn't have coverage if there are no benefits listed or the payer returned a message indicating that the service isn't covered.
Eligibility searches have an **Active** status when the latest eligibility
search in the record returned at least one active benefit type. However, you
must review the benefits table to confirm that the patient has active coverage
for the STCs you care about.
## What is the patient's financial responsibility? [#what-is-the-patients-financial-responsibility]
Once you've confirmed that the patient has coverage, you may want to understand their financial responsibility for services. For example, you may want to know their co-pay amount for an in-office visit or whether they've met their deductible.
You can use the **Type** filter on the **Benefits** tab to narrow the results to specific benefits types (such as co-pay amounts) for each STC or procedure code.
The following example shows that the patient has a 20% co-insurance for Hospital - Inpatient (STC `48`) services performed by in-network providers and a 50% co-insurance for services performed by out-of-network providers. The co-insurance amounts also apply to specific services, which are listed in the **Messages** field.
## Is the provider in- or out-of-network? [#is-the-provider-in--or-out-of-network]
Unfortunately, you can't reliably answer this question from a standard eligibility response.
Payers typically don't explicitly indicate whether the requesting provider is in- or out-of-network for the patient (though there are some exceptions). The **Network indicator** field in the table only indicates whether the benefit applies to in-network or out-of-network providers in general. It doesn't tell you whether the requesting provider is in- or out-of-network for the patient.
Some payers do provide additional information about whether the requesting provider is in- or out-of-network. They may do this through either freeform messages or selective inclusion of benefits in the response.
For example, some payers only return out-of-network benefits if the requesting provider is out-of-network. Likewise, if the provider is in-network, they only provide in-network benefits. Stedi doesn't have a complete list of payers that selectively include or exclude benefits based on the provider's network status.
**The most reliable way to determine network status is to check directly with the payer or the provider.** Note that payers may have different networks for different health plans, such as employer-sponsored plans versus Medicare Advantage, and these networks may have different contact paths.
## Is prior authorization required? [#is-prior-authorization-required]
Prior authorization (also called pre-authorization or pre-certification) is a requirement that the patient or their provider must get approval before a payer will cover specific services, procedures, medications, or devices. Without it, the payer may deny claims.
If the payer provides prior authorization information in the eligibility response, it will be listed in the **Benefit** column for that service or procedure. The payer may also send messages about prior authorization rules.
If the payer doesn't provide prior authorization information for a service or procedure, you can assume that prior authorization isn't required.
# Review and resubmit claims
Source: https://www.stedi.com/docs/providers/providers-review-resubmit-claims
You can review, revise, and resubmit claims in the Stedi portal. This includes professional claims you submitted through the portal as well as professional, dental, and institutional claims third-party vendors submitted through Stedi on your behalf.
You may need to resubmit claims for several reasons, including changes to the patient's coverage, errors in the original claim's information, or appealing a denied claim. You may also need to cancel duplicate claims or claims that were submitted in error.
## Pre-adjudication vs. adjudication [#pre-adjudication-vs-adjudication]
When resubmitting claims, you need to know whether your claim is pre-adjudication or in adjudication.
| Stage | Definition | How you'll know |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Pre-adjudication | The claim hasn't entered the payer's adjudication system. This includes claims the payer has received and then rejected based on front-end edits. | - You received a 277CA claim acknowledgment from Stedi or the payer. Payer rejections may include a message, such as "returned as unprocessable" or "not entered into processing system."
- The payer's 277CA doesn't contain a [Payer Claim Control Number (PCCN)](#payer-claim-control-number-pccn).
|
| Adjudication | The claim has entered the payer's adjudication system. This includes claims that were rejected during adjudication, claims still in progress (for example, in **Pending** status), and claims that completed adjudication (resulting in an 835 ERA). | - The payer's 277CA contains a [Payer Claim Control Number (PCCN)](#payer-claim-control-number-pccn), indicating it has entered the payer's system. OR
- You ran a real-time claim status check that included a PCCN in the response. OR
- You received an 835 Electronic Remittance Advice (ERA) from the payer with adjudication details. All 835 ERAs include a PCCN.
|
The following diagram illustrates the claim submission lifecycle and the responses you can expect to receive at each stage.
## Preparing claim resubmissions or cancellations [#preparing-claim-resubmissions-or-cancellations]
Stedi's guidance for resubmissions varies depending on three factors:
* **Whether the claim has entered the payer's adjudication system** - Visit [Pre-adjudication vs. adjudication](#pre-adjudication-vs-adjudication) to determine where your claim is in the lifecycle.
* **Whether you're resubmitting to Medicare** - Medicare Part A and Part B (processed through MACs) have different requirements than other payers. Visit [Medicare resubmission](#medicare-resubmission) for details.
* **Claim type** - Institutional claims have different requirements than professional or dental claims. Visit [Institutional claims](#institutional-claims) for details.
These factors determine which codes and identifiers to include in the resubmission:
* The proper [Claim Frequency Code (CFC)](#claim-frequency-code-cfc) - indicates the type of submission
* The [Payer Claim Control Number (PCCN)](#payer-claim-control-number-pccn), if appropriate - the payer's unique identifier for your claim
* The appropriate [Patient Control Number (PCN)](#patient-control-number-pcn) - your unique identifier for the claim
You'll also need to include any necessary corrections to the claim data.
### Claim Frequency Code (CFC) [#claim-frequency-code-cfc]
The Claim Frequency Code (CFC) indicates the type of claim submission. It's what tells the payer the claim is an original, a replacement, or a cancellation.
| Scenario | CFC Guidance |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Pre-adjudication (all payers) | - **Professional/Dental:** `1` (Admit thru Discharge Claim)
- **Institutional:** CFC from original submission
|
| Adjudication, non-Medicare | - **All claim types:** `7` (Replacement of Prior Claim) or `8` (Void/Cancel of Prior Claim)
- Resubmission requirements can vary by payer. Always confirm this guidance with the payer's companion guide.
|
| Adjudication, Medicare | - **Professional/Dental:** `1` (Admit thru Discharge Claim)
- **Institutional:** CFC from original submission
|
#### Set the CFC [#set-the-cfc]
You can set the Claim Frequency Code (CFC) in the following locations:
* **X12 EDI:** `Loop 2300 CLM05-03` (Claim Frequency Code) component
* **CMS-1500 claim form UI:** Set the **Qualifier** in **Box 22** (Resubmission code)
#### Institutional claims [#institutional-claims]
Institutional claims support a broader set of Claim Frequency Code (CFC) values than professional or dental claims.
For example, in long term care settings, facilities commonly submit interim claims every 30 days to receive partial payments while the patient is still admitted, rather than waiting until the end of the patient's stay. The CFC codes for these interim claims are `2` (Interim - First Claim), `3` (Interim - Continuing Claims), or `4` (Interim - Last Claim).
Therefore, the guidance for institutional claim CFCs is different from professional and dental claims. Specifically, for claims in pre-adjudication or Medicare claims in adjudication, you should resubmit with the same CFC you used in the original submission.
### Payer Claim Control Number (PCCN) [#payer-claim-control-number-pccn]
The Payer Claim Control Number (PCCN) is the unique identifier the payer assigns when your claim enters their adjudication system. It's different from the [Patient Control Number](#patient-control-number-pcn) you sent in the original claim.
| Scenario | PCCN Guidance |
| ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Pre-adjudication (all payers) | Don't include a PCCN. The claim hasn't entered the payer's adjudication system yet, so no PCCN exists. |
| Adjudication, non-Medicare | Include the PCCN the payer returned in [one or more responses](#find-existing-pccn) to the original claim. Without the PCCN, the payer won't know which claim to replace or cancel. |
| Adjudication, Medicare | Don't include the PCCN. Medicare explicitly instructs providers to omit it when resubmitting claims. Visit [Medicare resubmission](#medicare-resubmission) for details. |
#### Set the PCCN [#set-the-pccn]
You can supply the Payer Claim Control Number (PCCN) in the following locations:
* **X12 EDI:** `Loop 2300 REF02`, where `REF01` = `F8` (Original Reference Number)
* **CMS-1500 claim form UI:** Set the **Original reference number** in **Box 22** (Resubmission code)
#### Find existing PCCN [#find-existing-pccn]
You can retrieve the Payer Claim Control Number (PCCN) for the original claim from any of the following transactions from the payer.
| Transaction | How to get it |
| ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [277CA claim acknowledgment](/providers/providers-claim-acknowledgments) | Go to the [claims view](https://portal.stedi.com/app/healthcare/claims), click the claim to open its timeline, and click **See more detail** on the 277CA to review a user-friendly summary with the PCCN. |
| [277 real-time claim status](/providers/providers-check-claim-status) | Run a claim status check for the claim you want to resubmit. The PCCN is available on the results page as **Payer claim control number**. |
| [835 Electronic Remittance Advice (ERA)](/providers/providers-electronic-remittance-advice) | Go to the **Overview** tab. The PCCN is labeled as the **Payer claim number** in the **claim identifiers** column. |
### Patient Control Number (PCN) [#patient-control-number-pcn]
The Patient Control Number (PCN) is a unique identifier you assign to the claim. The payer returns this value in related transactions, such as the 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA), so you can correlate responses with the original claim.
| Scenario | PCN Guidance |
| ----------------------------- | ------------------------------- |
| Pre-adjudication (all payers) | Same PCN as original submission |
| Adjudication, Medicare | Same PCN as original submission |
| Adjudication, non-Medicare | New, unique PCN |
Reuse the same PCN from the original submission for pre-adjudication resubmissions and adjudication Medicare resubmissions. Stedi uses the PCN to match claims and resubmissions in the claims view, so reusing the PCN allows Stedi to show the original claim and resubmissions within a unified claim timeline. Reusing the PCN also helps you track the claim throughout the resubmission process.
Use a new, unique PCN for adjudication non-Medicare resubmissions. In this scenario, a new PCN helps you avoid potential duplicate claim errors from the payer. A new PCN also helps you differentiate between the 835 Electronic Remittance Advice (ERAs) for the original submission and the resubmission.
#### Set the PCN [#set-the-pcn]
You can set the PCN in the following locations:
* **X12 EDI:** `Loop 2300 CLM01` (Patient Control Number)
* **CMS-1500 claim form UI:** Set **Box 26** (Patient account number)
#### PCN format [#pcn-format]
When assigning a PCN, follow these best practices:
* Use a unique PCN for each claim. The identifier should be more complex than a simple sequential number and should be hard to guess.
* Use random strings. Formats with patient initials or the date of service in them can create duplicates. We recommend using [nanoid](https://www.npmjs.com/package/nanoid) or a similar library configured with the characters available in the [basic character set](#character-set) to create a strong, unique 17-character PCN for each claim.
* Keep it 17 characters or less. Some payers cut off values longer than 17 characters in ERAs and claim acknowledgments, which makes it hard to match them with the original claim.
* Use only characters available in the [basic character set](#character-restrictions), and avoid special characters that are only available in the extended character set. Payers are permitted to return data using the basic character set. Using other characters may result in data loss or mismatches when correlating claims with responses.
* Treat PCN values as case-insensitive when matching transactions, even if the submitted value included both lower and uppercase characters.
## Find specific claims [#find-specific-claims]
You can find a list of all your submitted claims on the [claims view](https://portal.stedi.com/app/healthcare/claims).
We recommend filtering for the claim's **Patient control number** (`Loop 2300 CLM01`) if it's unique for each claim. This will help you find the specific claim you're looking for. If you don't have the Patient Control Number, you can search for another identifier, such as the **Patient name**, to help narrow down the results. Your search terms must match what's in the claim exactly, including all spaces, capitalization, and punctuation.
## Revise and resubmit claims [#revise-and-resubmit-claims]
The resubmission process is the same for both corrections and cancellations - the [Claim Frequency Code](#claim-frequency-code-cfc) indicates which action you want to take.
* For professional claims, you can edit and resubmit through either the interactive CMS-1500 form or the X12 EDI editor.
* For dental and institutional claims, you can only edit and resubmit through the X12 EDI editor.
### CMS-1500 form (professional) [#cms-1500-form-professional]
Stedi's CMS-1500 claim form UI is mostly limited to the CMS-1500 form fields. It may not be able to successfully resubmit complex claims originally submitted through our APIs or SFTP.
To resubmit a professional claim through Stedi's interactive CMS-1500 form:
1. Go to the [claims view](https://portal.stedi.com/app/healthcare/claims) and click the claim you want to resubmit to open its timeline.
2. Click **See more detail** above the claim submission to review its details page.
3. Click **Edit and resubmit** and select **CMS-1500 resubmission**. Stedi opens the interactive CMS-1500 form prepopulated with the claim's information.
4. Make any necessary changes to the claim.
* Make sure to update the Claim Frequency Code, the Payer Claim Control Number, and the Patient Control Number according to best practices.
* Click **Claims timeline** to open a side panel with the claim's activity. You can review related 277CA claim acknowledgments containing the errors you need to address before resubmitting. Hover over a transaction and click **See more detail** to review its details.
5. Click **Submit claim** to resubmit the updated claim to the payer.
The updated claim will appear on the [claims view](https://portal.stedi.com/app/healthcare/claims) within a few minutes. The claim timeline will reflect that this claim is a resubmission along with the original claim and any associated responses.
You'll receive new 277CA claim acknowledgments indicating whether the resubmitted claim was accepted or rejected.
### X12 EDI editor [#x12-edi-editor]
To resubmit a professional, dental, or institutional claim through Stedi's X12 EDI editor:
1. Go to the [claims view](https://portal.stedi.com/app/healthcare/claims) and click the claim you want to resubmit to open its timeline.
2. Click **See more detail** above the claim submission to review its details page.
3. Click **Edit and resubmit** and select **X12 transaction resubmission**. Stedi opens the claim in an interactive editor with the X12 EDI on the left and the EDI specification on the right.
As you hover over different parts of the EDI, Stedi highlights the corresponding part of the specification on the right to help you understand what each part of the EDI means and how to edit it correctly.
4. Make changes to the claim EDI.
* You can type directly in the EDI editor or copy and paste updated EDI from another source.
* Make sure to update the Claim Frequency Code, the Payer Claim Control Number, and the Patient Control Number according to best practices.
* Click **Claims timeline** to open a side panel with the claim's activity. You can review related 277CA claim acknowledgments containing the errors you need to address before resubmitting. Hover over a transaction and click **See more detail** to review its details.
5. Click **Review and submit**. Stedi shows a comparison of the original claim and the new claim containing your changes.
6. Click **Resubmit claim** to send the updated claim to the payer.
The updated claim will appear on the [claims view](https://portal.stedi.com/app/healthcare/claims) within a few minutes. The claim timeline will reflect that this claim is a resubmission along with the original claim and any associated responses.
You'll receive new 277CA claim acknowledgments indicating whether the resubmitted claim was accepted or rejected.
## Medicare resubmission [#medicare-resubmission]
Medicare Part A and Part B (processed through MACs) have different requirements for resubmissions and cancellations than non-Medicare payers. Non-Medicare includes all other payers, such as commercial insurance and Medicaid.
* Medicare does not accept Claim Frequency Codes `7` or `8` for resubmissions. For professional and dental claims, resubmit with Claim Frequency Code `1`. For institutional claims, resubmit with the same Claim Frequency Code as the original submission.
* Don't include the original claim's Payer Claim Control Number (PCCN) when resubmitting, even if one is available.
## Determine 277CA sender [#determine-277ca-sender]
To determine whether Stedi or the payer sent a 277CA claim acknowledgment:
1. Go to the [claims view](https://portal.stedi.com/app/healthcare/claims).
2. Find the associated claim and click it to view the claim timeline.
3. Find the 277CA in the timeline view. The **From** field indicates whether the acknowledgment is from Stedi or the payer.
## Character restrictions [#character-restrictions]
Only use the X12 Basic and Extended character sets in request data. Using characters outside these sets may cause errors.
The X12 Basic character set includes uppercase letters, digits, space, and some special characters. Lowercase letters and special language characters like `ñ` are not included.
The following special characters are included:
The Extended character set includes the characters listed in Basic, plus lowercase letters and additional special characters, such as `@`.
The following additional special characters are included:
In addition, the following characters are reserved for delimiters in the final X12 EDI transaction to the payer: `~`, `*`, `:` and `^`. X12 doesn't support using escape sequences to represent delimiters or special characters. Stedi returns a `400` error if you use these restricted characters improperly.
* **CMS-1500 form:** Don't include delimiter characters anywhere in your request data.
* **Raw X12:** You can use these characters as delimiters, but not in the body of the request data.
# STCs and procedure codes
Source: https://www.stedi.com/docs/providers/providers-stc-procedure-codes
You're likely running an eligibility check to determine the patient's coverage and financial responsibility for particular medical or dental services, such as chiropractic or hospice care.
You can retrieve specific types of benefits information from the payer by including either a service type code (STC) or a procedure code and qualifier in your request.
However, it's not always clear which STC or procedure code to use for best results. This page explains how to choose the right STC or procedure code for your eligibility check, how to test whether a payer supports a specific STC, and how to map procedure codes to STCs when necessary.
## Should I use STCs or procedure codes? [#should-i-use-stcs-or-procedure-codes]
It depends on the type of benefits information you want to retrieve.
### Medical benefits [#medical-benefits]
You'll almost always need to submit an STC because most medical payers don't support procedure codes (CPT/HCPCS/CDT). Refer to our guidance for [choosing STCs](#choose-the-right-stc).
### Dental benefits [#dental-benefits]
Many (but not all) dental payers support procedure codes. However, we recommend:
1. First try STC `35` - especially if you need information about general dental benefits. Many payers only return comprehensive dental-specific benefits for STC `35`.
2. Try the relevant CDT code if you still need more benefits information for a specific service.
3. If the CDT code still doesn't return what you need, try the STC mapped to that CDT code. Refer to our list of [common mappings](#dental) for dental benefits.
## Choose the right STC [#choose-the-right-stc]
A Service Type Code (STC) is a two-character code that groups similar healthcare services into standard categories, such as `47` (Hospital) and `UC` (Urgent Care). STC support varies by payer:
* Not all payers support all STCs.
* Some payers only respond to the first STC you send and ignore the rest.
* Some payers completely ignore the STCs in the request and always return a default response for STC `30` (Health Benefit Plan Coverage).
* Some payers don't support multiple STCs in a single request.
* Some payers do support multiple STCs, but only a limited number per request.
When choosing an STC, we recommend:
* Send the most specific STC you can for the services you're targeting. You should [test the STCs](#test-payer-stc-support) that seem most appropriate to determine which ones yield the most benefits information. Refer to our list of [STCs for common services](#stcs-for-common-services).
* If no specific STC seems appropriate or if the payer doesn't support it, fall back to a [general benefit check](#general-benefit-checks).
* Include only one STC per request, unless you've tested the payer and confirmed they support multiple STCs in a single request *and* that the response contains better benefits information when you include more than one.
If after testing, no STC produces the benefits information you need, you may need to call the payer or visit the payer portal.
### General benefit checks [#general-benefit-checks]
Use STC `30` for general medical benefits or `35` for general dental benefits. These STCs are supported by all payers and are a good fall back when a payer doesn't support a more specific STC.
When you send STC `30` in an eligibility check, all payers must return benefits information for the following STCs when the patient's plan covers them:
* `1` (Medical Care)
* `33` (Chiropractic)
* `47` (Hospital)
* `86` (Emergency Services)
* `88` (Pharmacy)
* `98` (Professional Physician Visit - Office)
* `AL` (Vision - Optometry)
* `MH` (Mental Health)
* `UC` (Urgent Care)
[CAQH CORE-certified payers](#required-stcs-for-core-certified-payers) are required to support a broader set of STCs.
### STCs for common services [#stcs-for-common-services]
Try the following STCs in the order shown - from the most specific to more general alternatives. We recommend sending only one STC at a time, unless you've [tested the payer](#test-payer-stc-support) and confirmed they support multiple in a single request.
We've also included the mapping to specific procedure codes where possible, to make it easier to determine the right STC for your use case.
You can also try our interactive [Service Type Code Lookup](https://www.stedi.com/cpt-hcpcs-to-stc) tool.
#### Medical [#medical]
Ranges of applicable codes are represented as `rangeStart - rangeEnd`.
{/* prettier-ignore-start */}
| Procedure codes | Type of care | STCs to try |
| ---------------------------------------------------------------------------------------- | -------------------------------------------- | ---------------------------------------------------- |
| `97151 - 97157` | ABA Therapy | `BD`, `MH` |
| `97810`, `97811 - 97814` | Acupuncture | `64`, `1` |
| `96401 - 96549` | Chemotherapy | `ON`, `78`, `87`, `91`, `92` |
| `96493` | Chemotherapy, IV push | `78`, `87`, `91`, `92` |
| `96494` | Chemotherapy, additional infusion | `78`, `87`, `91`, `92` |
| `99490`, `99439`, `99491`, `99437`, `99487` | Chronic Care Management (CCM) services | `A4`, `MH`, `98`, `1` |
| too many to list | Dermatology | `3`, `98` |
| `T1032`, `T1033` | Doula | `BT`, `BU`, `BV`, `1` |
| `E1399` | Durable Medical Equipment | `DM`, `11`, `12`, `18` |
| `96375` | IV push | `92` |
| `96360`, `96365`, `96366` | IV Therapy/Infusion | `92`, `98` |
| too many to list | Maternity (professional) | `BT`, `BU`, `BV`, `69` |
| `97802` | Medical nutrition therapy | `98`, `MH`, `BZ`, `1` |
| `97803` | Medical nutrition follow-up | `98`, `MH`, `BZ`, `1` |
| too many to list | Mental health | `MH`, `96`, `98`, `A4`, `BD`, `CF` |
| `95700 - 96020` | Neurology | `98` |
| `99460`, `99463` | Newborn/facility | `65`, `BI` |
| `97165 - 97168` and `97110`, `97530`, `97112`, `97140`, `97535`, `97116`, `97129` | Occupational therapy | `AD`, `98` |
| `97110`, `97112`, `97116`, `97350`, and several others | Physical therapy | `PT`, `AE` |
| too many to list | Podiatry | `93`, `98` |
| too many to list | Primary care | `96`, `98`, `A4`, `A3`, `99`, `A0`, `A1`, `A2`, `98` |
| `99214` | Physician office visit | `1`, `98`, `BY` |
| `96130 - 96133`, `96136 - 96137` | Psychological testing evaluation | `MH`, `CF`, `A6`, `A8`, `A4`, `98`, `96` |
| `90832 - 90834`, `90836 - 90840`, `90845 - 90847`, `90849`, `90853` | Psychotherapy | `MH`, `CF`, `A6`, `A8`, `A4`, `BD`, `98`, `96` |
| too many to list | Rehabilitation | `A9`, `AA`, `AB`, `AC` |
| `98975`, `98976`, `98977`, `98980`, `98981` | Remote Therapeutic Monitoring (RTM) services | `A4`, `98`, `MH`, `92`, `DM`, `1` |
| `99304-99318` | Skilled Nursing | `AG`, `AH` |
| `92507`, `92508`, `92521`, `92522`, `92523`, `92526`, `92607`, `92609`, `92605`, `92618` | Speech Therapy | `AF`, `98` |
| `90791`, `90832`, `90834`, `90837`, `90853`, `99408`, `99409`, and `H0017-H0019` | Substance Abuse/Addiction | `AI`, `AJ`, `AK`, `MH` |
| `99202-99215`, `99421-99423`, `99441-99443`, `G2010` and `G2012` | Telehealth | `9`, `98` |
| `90867` | Transcranial magnetic stimulation | `A4`, `MH` |
{/* prettier-ignore-end */}
#### Dental [#dental]
Procedure codes are listed in ranges. For example, `D0xxx` represents CDT codes from `D0000` to `D0999`.
{/* prettier-ignore-start */}
| Procedure | Type of care | STCs to try |
| ----------------------------- | ---------------------------------------------------------------------------------------------- | ----------- |
| `D0xxx` | Diagnostic (such as evaluations and radiographs) | `23` |
| `D1xxx` | Preventive (such as prophylaxis, fluoride, and sealants) | `41` |
| `D2xxx` | Restorative (fillings and crowns not tied to implants) | `25` |
| `D3xxx` | Endodontics (such as root canals) | `26` |
| `D4xxx` | Periodontics (such as SRP and perio maintenance) | `24` |
| `D59xx` | Maxillofacial prosthetics (specifically for `D5900–D5999`, all other `D5xxx` use `39` instead) | `27` |
| `D5xxx/D6xxx`, except `D59xx` | Prosthodontics (removable and fixed, such as dentures and bridges) | `39` |
| `D7xxx` | Oral & maxillofacial surgery (such as extractions and osseous surgery) | `40` |
| `D9xxx` | Adjunctive general services (such as palliative, occlusal guards, and anesthesia) | `28` |
{/* prettier-ignore-end */}
### Full STC list [#full-stc-list]
You can include the following STCs in an eligibility check. Not all payers support all STCs, so you should always [test each payer](#test-payer-stc-support) to ensure they support the STCs you plan to use.
* The word physician in service type codes refers to any healthcare provider, including physician assistants, nurse practitioners, and other types of healthcare professionals.
* **Don't send STCs that aren't in this list.** This list is specific to X12 version 005010, the mandated version for eligibility checks. It's different from the [X12 Service Type Codes](https://x12.org/codes/service-type-codes) list, which applies to X12 versions later than 005010. Payers shouldn't accept or send STCs not explicitly listed in version 005010.
- `1` Medical Care
- `2` Surgical
- `3` Consultation
- `4` Diagnostic X-Ray
- `5` Diagnostic Lab
- `6` Radiation Therapy
- `7` Anesthesia
- `8` Surgical Assistance
- `9` Other Medical
- `10` Blood Charges
- `11` Used Durable Medical Equipment
- `12` Durable Medical Equipment Purchase
- `13` Ambulatory Service Center Facility
- `14` Renal Supplies in the Home
- `15` Alternate Method Dialysis
- `16` Chronic Renal Disease (CRD) Equipment
- `17` Pre-Admission Testing
- `18` Durable Medical Equipment Rental
- `19` Pneumonia Vaccine
- `20` Second Surgical Opinion
- `21` Third Surgical Opinion
- `22` Social Work
- `23` Diagnostic Dental
- `24` Periodontics
- `25` Restorative
- `26` Endodontics
- `27` Maxillofacial Prosthetics
- `28` Adjunctive Dental Services
- `30` Health Benefit Plan Coverage - **supported by all payers**
- `32` Plan Waiting Period
- `33` Chiropractic
- `34` Chiropractic Office Visits
- `35` Dental Care
- `36` Dental Crowns
- `37` Dental Accident
- `38` Orthodontics
- `39` Prosthodontics
- `40` Oral Surgery
- `41` Routine (Preventive) Dental
- `42` Home Health Care
- `43` Home Health Prescriptions
- `44` Home Health Visits
- `45` Hospice
- `46` Respite Care
- `47` Hospital
- `48` Hospital - Inpatient
- `49` Hospital - Room and Board
- `50` Hospital - Outpatient
- `51` Hospital - Emergency Accident
- `52` Hospital - Emergency Medical
- `53` Hospital - Ambulatory Surgical
- `54` Long Term Care
- `55` Major Medical
- `56` Medically Related Transportation
- `57` Air Transportation
- `58` Cabulance
- `59` Licensed Ambulance
- `60` General Benefits
- `61` In-vitro Fertilization
- `62` MRI/CAT Scan
- `63` Donor Procedures
- `64` Acupuncture
- `65` Newborn Care
- `66` Pathology
- `67` Smoking Cessation
- `68` Well Baby Care
- `69` Maternity
- `70` Transplants
- `71` Audiology Exam
- `72` Inhalation Therapy
- `73` Diagnostic Medical
- `74` Private Duty Nursing
- `75` Prosthetic Device
- `76` Dialysis
- `77` Otological Exam
- `78` Chemotherapy
- `79` Allergy Testing
- `80` Immunizations
- `81` Routine Physical
- `82` Family Planning
- `83` Infertility
- `84` Abortion
- `85` AIDS
- `86` Emergency Services
- `87` Cancer
- `88` Pharmacy
- `89` Free Standing Prescription Drug
- `90` Mail Order Prescription Drug
- `91` Brand Name Prescription Drug
- `92` Generic Prescription Drug
- `93` Podiatry
- `94` Podiatry - Office Visits
- `95` Podiatry - Nursing Home Visits
- `96` Professional (Physician)
- `97` Anesthesiologist
- `98` Professional (Physician) Visit - Office
- `99` Professional (Physician) Visit - Inpatient
- `A0` Professional (Physician) Visit - Outpatient
- `A1` Professional (Physician) Visit - Nursing Home
- `A2` Professional (Physician) Visit - Skilled Nursing Facility
- `A3` Professional (Physician) Visit - Home
- `A4` Psychiatric
- `A5` Psychiatric - Room and Board
- `A6` Psychotherapy
- `A7` Psychiatric - Inpatient
- `A8` Psychiatric - Outpatient
- `A9` Rehabilitation
- `AA` Rehabilitation - Room and Board
- `AB` Rehabilitation - Inpatient
- `AC` Rehabilitation - Outpatient
- `AD` Occupational Therapy
- `AE` Physical Medicine
- `AF` Speech Therapy
- `AG` Skilled Nursing Care
- `AH` Skilled Nursing Care - Room and Board
- `AI` Substance Abuse
- `AJ` Alcoholism
- `AK` Drug Addiction
- `AL` Vision (Optometry)
- `AM` Frames
- `AN` Routine Exam - Use for Routine Vision Exam only
- `AO` Lenses
- `AQ` Nonmedically Necessary Physical
- `AR` Experimental Drug Therapy
- `B1` Burn Care
- `B2` Brand Name Prescription Drug - Formulary
- `B3` Brand Name Prescription Drug - Non-Formulary
- `BA` Independent Medical Evaluation
- `BB` Partial Hospitalization (Psychiatric)
- `BC` Day Care (Psychiatric)
- `BD` Cognitive Therapy
- `BE` Massage Therapy
- `BF` Pulmonary Rehabilitation
- `BG` Cardiac Rehabilitation
- `BH` Pediatric
- `BI` Nursery
- `BJ` Skin
- `BK` Orthopedic
- `BL` Cardiac
- `BM` Lymphatic
- `BN` Gastrointestinal
- `BP` Endocrine
- `BQ` Neurology
- `BR` Eye
- `BS` Invasive Procedures
- `BT` Gynecological
- `BU` Obstetrical
- `BV` Obstetrical/Gynecological
- `BW` Mail Order Prescription Drug - Brand Name
- `BX` Mail Order Prescription Drug - Generic
- `BY` Physician Visit - Office: Sick
- `BZ` Physician Visit - Office: Well
- `C1` Coronary Care
- `CA` Private Duty Nursing - Inpatient
- `CB` Private Duty Nursing - Home
- `CC` Surgical Benefits - Professional (Physician)
- `CD` Surgical Benefits - Facility
- `CE` Mental Health Provider - Inpatient
- `CF` Mental Health Provider - Outpatient
- `CG` Mental Health Facility - Inpatient
- `CH` Mental Health Facility - Outpatient
- `CI` Substance Abuse Facility - Inpatient
- `CJ` Substance Abuse Facility - Outpatient
- `CK` Screening X-ray
- `CL` Screening Laboratory
- `CM` Mammogram, High Risk Patient
- `CN` Mammogram, Low Risk Patient
- `CO` Flu Vaccination
- `CP` Eyewear and Eyewear Accessories
- `CQ` Case Management
- `DG` Dermatology
- `DM` Durable Medical Equipment
- `DS` Diabetic Supplies
- `GF` Generic Prescription Drug - Formulary
- `GN` Generic Prescription Drug - Non-Formulary
- `GY` Allergy
- `IC` Intensive Care
- `MH` Mental Health
- `NI` Neonatal Intensive Care
- `ON` Oncology
- `PT` Physical Therapy
- `PU` Pulmonary
- `RN` Renal
- `RT` Residential Psychiatric Treatment
- `TC` Transitional Care
- `TN` Transitional Nursery Care
- `UC` Urgent Care
### Test payer STC support [#test-payer-stc-support]
We recommend testing each payer to determine which STC(s) they support and which STC(s) return the most benefits information for the services you care about.
To test whether a payer supports a specific STC:
1. Send a baseline request with just STC `30` for general medical benefits or `35` for general dental benefits.
2. Send a request with the specific STC that best matches the benefit type you want to check. For example, to check mental health benefits, you might send a request with STC `MH` (Mental Health). Use our list of [STCs for common services](#stcs-for-common-services) as a starting point.
3. Compare the baseline response with the response to the specific STC. If they're different, the payer likely supports the specific STC.
You may also want to test whether the payer supports multiple STCs in a single request:
1. Send a baseline request with just STC `30` for general medical benefits or `35` for general dental benefits.
2. Send a request with multiple STCs matching the benefit types you want to check.
3. Compare the responses. If they change based on the number of STCs, the payer likely supports multiple STCs in a single request. If not, the payer may be ignoring or only partially supporting STCs - for example, they may only be returning information for the first STC.
**Developers:** We recommend scripting your requests to speed up the testing process. Specifically, you should loop through candidate STCs and compare the responses against the baseline STC `30` or `35` response for the same patient. You can also save the `benefitsInformation` array for each STC and diff them.
## Map procedure codes to STCs [#map-procedure-codes-to-stcs]
It can be hard to map procedure codes to the right STC. For example, if a provider offers medical nutrition therapy and bills using CPT code 97802, should they use service type code `1` - Medical Care, `3` - Consultation, `MH` - Mental Health, or another option?
Unfortunately, there's no standardized mapping between procedure codes and STCs. In fact, payers themselves often don't have an explicit mapping for their own health plans. Their eligibility check systems aren't necessarily directly integrated with their claims processing systems, so when you ask them which STC to use, they may not always be able to provide a good answer.
Review our list of [STCs for common services](#stcs-for-common-services), which contains mappings to the associated procedure codes. You can also try our interactive [Service Type Code Lookup](https://www.stedi.com/cpt-hcpcs-to-stc) tool.
If you don't find the procedure code you're looking for, use the following approaches to determine the best STC for your use case:
* Review the payers' documentation for eligibility checks. Some payers provide a list of STCs they support and their mappings to procedure codes.
* If you can't find the information in the payer's documentation, contact the payer directly or reach out to [Stedi support](https://www.stedi.com/contact), and we'll contact the payer for you.
* For dental payers that don't support specific CDT codes, you can use either of these sources to map CDT codes to service type codes. You can either purchase a copy of these documents or contact Stedi support for recommendations about specific mappings:
* NDEDIC's [Companion to ASC X12 270/271](https://ndedic.org/Sys/Store/Products/1016)
* Table 6 in the American Dental Association's [Technical Report No. 1102](https://engage.ada.org/p/eg/ada-technical-report-no-1102-electronic-dental-benefits-eligibility-verification-e-book-1390?itm_source=pp-1316\&itm_component=p-related).
* If none of the above methods work, you can ask a medical coder with [AAPC certification](https://www.aapc.com/certifications) for guidance. Their familiarity with billable codes will help them make good recommendations about service type code mappings.
Once you determine the right STC code(s), we recommend maintaining an internal document that contains the mappings for the health plans you most frequently bill.
## Required STCs for CORE-Certified payers [#required-stcs-for-core-certified-payers]
CAQH CORE creates operating rules and frameworks that improve interoperability in healthcare data exchange. CORE requires certified payers to support a broader set of STC codes than those mandated for [general benefits inquiries](#general-benefit-checks).
If the plan covers the service, certified payers must return benefit information for the following STCs. Visit CAQH CORE's website for a complete list of [CORE-Certified Health Plans](https://www.caqh.org/core/core-certified-organizations-pending-and-current).
* `4` Diagnostic X-Ray
* `5` Diagnostic Lab
* `6` Radiation Therapy
* `7` Anesthesia
* `8` Surgical Assistance
* `12` DME Purchase
* `13` Ambulatory Surgery Facility
* `18` DME Rental
* `20` Second Surgical Opinion
* `30` Health Benefit Plan Coverage
* `33` Chiropractic
* `62` MRI/CAT Scan
* `65` Newborn Care
* `68` Well Baby Care
* `78` Chemotherapy
* `80` Immunizations
* `81` Routine Physical
* `82` Family Planning
* `86` Emergency Services
* `93` Podiatry
* `98` Physician Visit - Office
* `99` Physician Visit - Inpatient
* `A0` Physician Visit - Outpatient
* `A3` Physician Visit - Home
* `AD` Occupational Therapy
* `AE` Physical Medicine
* `AF` Speech Therapy
* `AG` Skilled Nursing Care
* `BG` Cardiac Rehabilitation
* `BH` Pediatric
## STCs in the eligibility response [#stcs-in-the-eligibility-response]
To determine whether the payer is returning the benefits information you need, you must check the [**Benefits tab** of a completed eligibility check](/providers/providers-review-patient-benefits#benefits-tab). Each benefit listed in the table may be associated with one or more STCs or procedure codes.
The payer may send benefits information for additional STCs you didn't request - this is expected. It can also mean that the payer is ignoring the STC you sent, which is why we recommend [testing payers](#test-payer-stc-support) to determine their support for specific STCs.
To learn more about interpreting the eligibility response, visit [Review patient benefits](/providers/providers-review-patient-benefits).
# Submit claims
Source: https://www.stedi.com/docs/providers/providers-submit-claims
You can submit professional, dental, and institutional claims through the Stedi portal.
You can submit professional claims through our interactive claim form or by uploading X12 EDI claim data. There's no interactive claim form for dental and institutional claims, but you can submit them by uploading X12 EDI claim data.
## Claim form (professional only) [#claim-form-professional-only]
You can only submit claims to the patient's primary health plan through our interactive CMS-1500 form. You must submit secondary or tertiary claims through X12 EDI upload, API, or SFTP instead.
To submit a professional claim: Open the **Claims** menu and select **+ Submit professional claim**.
The submission form is based on the CMS-1500 Claim Form.
Enter the required information for your professional claim. Notably:
| Field | Instructions and Notes |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Stedi payer | Select a **Payer** from the dropdown list. Start typing to filter the list. |
| EDI mode | Select whether you want to submit a **Production** or **Test** claim.- Production claims are sent to the payer.
- Test claims aren't sent to the payer. Stedi validates them and displays them in the portal so you can get familiar with Stedi's claim processing workflow. Stedi responds to test claims with a 277CA claim acknowledgment, but you won't receive an 835 Electronic Remittance Advice (ERA).
|
| Patient account number | We strongly recommend submitting a unique value in **Box 26** (Patient acccount number). The identifier should be more complex than a simple sequential number and should be hard to guess. The payer returns this value in related transactions, such as the 277CA and 835 ERA, so you can correlate responses and real-time claim status checks with the original claim. - Keep it 17 characters or less. Some payers cut off values longer than 17 characters in ERAs and claim acknowledgments, which makes it hard to match them with the original claim.
- Use alphanumeric characters only. Avoid special characters, as many payers don't handle them properly.
- Use random strings. Formats with patient initials or the date of service in them can create duplicates.
|
| Line item control numbers | The line item control number is an identifier for each service line in **Box 24** (Service lines) that you can use correlate the original claim with the 835 ERA. - By default, Stedi automatically assigns line item control numbers for each service line.
- To set your own identifiers, click the **Set manual line item control numbers** in the service lines table. Line item control numbers must be 30 characters or less and unique within the claim.
Note that Stedi will automatically reuse the same line item control numbers if you resubmit this claim through the CMS-1500 form. |
| Attachments | You can submit claim-level attachments in **Box 19b** (Claim attachments) and service-line attachments in **Box 24** (Service lines). Note that you can't add attachments to claims that were already submitted through the portal. To include attachments for those, resubmit the claim with the attachments. - Click **+ Add attachment** (claim-level) or **Add attachment, note or NDC codes** (service-line) to specify the details for an attachment.
- Choose the appropriate **Report type** for each attachment.
- Choose the appropriate **Transmission code**. If you plan to upload an attachment file, set this to **EL (EDI)**. If you plan to submit the attachment through another method, such as directly through the payer's portal, set this to the appropriate code.
- Either enter the **Attachment control number** or click **Upload file** to select the file you want to attach. Supported file types are JPG, PDF, PNG, or TIFF. Each attachment should be 10 MB or less to comply with most payer requirements. You can add up to 10 attachment files at the claim level and up to 10 attachment files for each service line. If you included attachment files, Stedi automatically generates the required attachment control numbers for you.
|
When you're finished, click **Submit claim**. Stedi validates the claim and submits it to the payer. It will appear on the [claims view](https://portal.stedi.com/app/healthcare/claims) within a few minutes.
Later, you'll also see related claim responses, such as [277CA claim acknowledgments](/providers/providers-claim-acknowledgments) and [835 Electronic Remittance Advice (ERAs)](/providers/providers-electronic-remittance-advice).
## X12 EDI upload [#x12-edi-upload]
You can submit professional, dental, and institutional claims through the Stedi portal in X12 EDI format. Claim data must adhere to the following X12 HIPAA claim specifications:
* [837 Claim: Professional (X222A1)](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-professional-x222a1/01HR60MDFAGCSEJNKY8J38867Y)
* [837 Claim: Institutional (X223A2)](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-institutional-x223a2/01JBHW2YXMN2F9KXK2PS0BFP9F)
* [837 Claim: Dental (X224A2)](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-dental-x224a2/01JCJZ46AEK835RYV1BXQNBPK8)
To manually submit an X12 EDI claim:
1. Go to the [transactions view](https://portal.stedi.com/app/healthcare/transactions).
2. Click **Submit claim** and choose **Upload EDI file** from the menu.
3. Do one of the following:
* Click **Upload X12 EDI** and select an existing `.edi` file to add.
* Select the transaction type and then paste the X12 EDI content into the text area.
4. Configure the settings to send a test or a production claim. Production claims are sent to payers. Test claims aren't sent to payers - Stedi's test clearinghouse processes them and returns test 277CA acknowledgments so you can evaluate your claim processing pipeline.
1. Select either **Test** or **Production** in the menu at the top of the text area.
2. Set `ISA15` (Interchange Usage Indicator) to `T` (Test Data) or `P` (Production Data), accordingly.
5. Fix any validation errors that appear after adding the claim X12 EDI content. Stedi highlights errors in red and displays the specification for the claim type you selected on the right side of the screen to make it easier to identify and fix issues.
6. Click **Submit claim** to submit the claim to Stedi.
Stedi processes the claim and takes you to the claim's details page. Stedi also displays the claim on the [claims view](https://portal.stedi.com/app/healthcare/claims) and the [transactions view](https://portal.stedi.com/app/healthcare/transactions).
## Download CMS-1500 PDF [#download-cms-1500-pdf]
Stedi automatically generates a [PDF CMS-1500 claim form](https://www.nucc.org/index.php/1500-claim-form-mainmenu-35) for submitted professional claims.
To download the PDF:
1. Go to the [transactions view](https://portal.stedi.com/app/healthcare/transactions) and click the claim you want to download.
2. Click **Download CMS 1500 claim PDF**. You can choose to download it either with or without the CMS-1500 form overlay.
Payers have strict requirements for submitted CMS-1500 claim forms. If you plan to send generated PDFs to payers or retain them for your records, we strongly recommend visiting [CMS-1500 Claim Form PDF](/providers/providers-cms-1500-claim-form-pdf) for information about the correct printer settings for generated PDFs and general best practices.
# Submit transaction enrollment requests
Source: https://www.stedi.com/docs/providers/providers-submit-enrollment-requests
You can submit transaction enrollment requests either individually or in bulk through CSV import.
You must create one enrollment request for each combination of payer and transaction type. For example, you'd need two separate requests to enroll for 835 Electronic Remittance Advice (ERAs) and 270/271 eligibility checks with the same payer.
**835 ERAs:** Once enrollments are live, you'll no longer receive ERAs for that provider through your previous clearinghouse. If the payer supports it, you can specify a [requested effective date](#requested-effective-date) to help coordinate your migration to Stedi.
## Consider enrollment scope [#consider-enrollment-scope]
When you enroll a provider for 835 Electronic Remittance Advice (ERAs), payers can scope the enrollment in one of two ways:
* **NPI:** The payer registers only the specific National Provider Identifier (NPI) you submitted in the enrollment request. Other NPIs under the same Tax Identification Number (TIN) continue receiving ERAs through their existing clearinghouses.
* **TIN:** The payer registers all NPIs under the TIN. When you enroll one NPI, the payer switches the entire TIN to Stedi, affecting all NPIs that share that TIN.
Payers vary in how they manage enrollment scope, and this information isn't always disclosed to Stedi. For payers with TIN scope, enrolling one NPI may unintentionally enroll the other NPIs under that TIN. This means the ERAs for all of the associated NPIs will start flowing through Stedi - not just ERAs for the NPI you meant to enroll.
### Prevent disruptions [#prevent-disruptions]
To reduce the likelihood of unintentionally disrupting your workflows, we recommend:
* Enroll all NPIs that share the same TIN at the same time. This is common for hospital systems, clinic networks, or large medical groups that have multiple service locations operating under the same billing entity.
* If you need to keep some NPIs with your existing clearinghouse, contact Stedi support before submitting enrollment requests. We can help ensure the process goes smoothly.
## Submit enrollment requests [#submit-enrollment-requests]
Submit enrollment requests individually through the [Stedi portal](#individual-submission) or in bulk using [CSV import](#bulk-submission---csv-import).
### Individual submission [#individual-submission]
Individual submission is the simplest way to complete transaction enrollment. It involves two steps: creating a provider record and submitting enrollment requests.
#### Step 1: Create a provider record [#step-1-create-a-provider-record]
You must create a provider record with the name, tax ID, NPI, and contact information of the billing provider you plan to use in claims. Stedi submits this information to the payer as part of the enrollment process.
If you're a solo provider, this is likely your information. If you're [enrolling a group practice](#practices-and-facilities-with-multiple-providers-or-locations), you only need to create provider records for the NPIs and the tax IDs you use for billing. You don't need to create provider records for individual rendering providers.
To create a provider record:
1. Go to the [Providers page](https://portal.stedi.com/app/healthcare/providers).
2. Click **New provider**.
3. Enter the required information:
* **Display name**: A name to help you identify the provider record in your account. For example, "XYZ Medical Group". We don't share this name with payers.
* **NPI**: The National Provider Identifier (NPI) on file with the payer that you use for billing. If you're enrolling a group practice, this is typically the group's NPI.
* **Tax ID**: The tax ID, which can be an EIN or SSN. This should be the tax ID on file with the payer that you use for billing.
* **Contacts**: This is where the payer will send communications about the enrollment, if needed. For many providers, Stedi can fetch contact information from the NPI registry. The name and address should exactly match what the payer has on file. However, the email and phone number can be set to wherever you want to receive payer communications.
4. Click **Create provider**.
The provider record is created and appears in the list on the [**Providers** page](https://portal.stedi.com/app/healthcare/providers).
#### Step 2: Create enrollment requests [#step-2-create-enrollment-requests]
Once you've created a provider record, you can attach it to one or more enrollment requests.
To create an enrollment request:
1. Go to the [Enrollments page](https://portal.stedi.com/app/healthcare/enrollments).
2. Click **New enrollment**.
3. Complete the required information:
* **Payer**: Select the payer you want to enroll with. Start typing the payer's name to filter the list.
* **Provider**: Select an existing provider record. The form automatically populates the provider's information. You can choose to use an existing contact or enter new contact information for the payer to use for communications about the enrollment. Review our guidance on [provider contact information](#provider-contact) to ensure updates go to the correct location.
* **Transaction**: Select the transaction type you want to enroll for. The form populates the list of transaction types that the payer supports, and you'll only be able to select transaction types that require enrollment.
* **Aggregate ERAs by (optional)**: For Electronic Remittance Advice (ERA) enrollments with supported payers, you can specify an [aggregation preference](#era-aggregation-preference).
* **Requested effective date (optional)**: For supported payers, you can specify the date you'd like the enrollment to take effect. This is helpful for coordinating the migration from your previous clearinghouse, especially for ERA enrollments. Visit [Requested effective date](#requested-effective-date) to learn more.
* **Stedi contact person**: This is the email address where Stedi will send updates about the enrollment request. We'll use it to notify you when there are next steps and send updates on the enrollment's status. This email address can be different from the contact information you provided in the provider record. Set it to wherever you want to receive Stedi's communications about the enrollment.
4. Click **Create enrollment**. Stedi asks you to confirm the information.
5. Review the enrollment information carefully and then click **Submit enrollment**.
The enrollment request is created and appears in the list of enrollments on the [Enrollments page](https://portal.stedi.com/app/healthcare/enrollments).
### Bulk submission - CSV import [#bulk-submission---csv-import]
You can import enrollment requests from a CSV file. This is a great option if you need to submit many requests at once.
To submit enrollment requests through bulk CSV import:
1. Go to the [Bulk imports page](https://portal.stedi.com/app/healthcare/enrollments/bulk).
2. Click **New bulk import**. The upload page contains detailed instructions for formatting the CSV file.
3. Download the CSV template and prepare your file according to the provided instructions. We also recommend reviewing the instructions about [enrollment contact information](#enrollment-contact-information) and [practices and facilities with multiple providers or locations](#practices-and-facilities-with-multiple-providers-or-locations) to ensure your file is set up correctly.
4. Click **+ Upload file** and select your file or drag and drop your file into the **Upload CSV** section.
5. Enter a **Name** for the batch. Stedi displays this batch name in the portal, so choose something descriptive.
6. Click **Verify file**. Stedi checks for errors and flags any rows that require adjustments. If there are errors, you can either fix them and re-upload the CSV file or click **Execute import without invalid rows** to proceed with importing valid rows.
7. Click **Execute import**. Stedi processes the import and creates the enrollment requests.
You can review the status of each bulk import on the [Bulk imports page](https://portal.stedi.com/app/healthcare/enrollments/bulk). The overview shows the number of rows that were successfully imported, the number of rows that were skipped due to errors or duplicates, and the date and time of the import. Click an import to view more details and download the [import status report](#import-status-report).
Imported enrollment requests appear in the list of enrollments on the [Enrollments page](https://portal.stedi.com/app/healthcare/enrollments).
#### Importing behavior [#importing-behavior]
Stedi automatically does the following when importing enrollment requests from a CSV file:
* Creates a new provider record for each unique combination of NPI and tax ID in the CSV file. For example, these two providers would be created as separate records even though they have the same name and NPI:
* `John Doe, NPI: 1999999984, Tax ID: 987654321`
* `John Doe, NPI: 1999999984, Tax ID: 123456789`
When a row in your CSV file contains an NPI and tax ID that match an
existing provider record in your account, Stedi overwrites the existing
provider record with the information in the CSV file. Any changes (such as
updated address or contact information) aren't automatically applied to
existing enrollment requests for that provider, only to requests created
after Stedi updated the record.
* Creates and submits enrollment requests.
* Removes duplicate rows to prevent duplicate requests.
* Skips rows that contain errors. For example, if a row contains an invalid NPI, Stedi skips that row and imports the rest of the file. Review the import status report to understand which rows were skipped and why.
#### Import status report [#import-status-report]
After importing, you can download a report that shows the status of each row in the CSV file. For example, duplicate rows are marked as `Duplicate: Enrollment already exists` in the `result` column.
To download the report:
1. Go to the [Bulk imports page](https://portal.stedi.com/app/healthcare/enrollments/bulk).
2. Click an import to view its details.
3. Click **Download full report**.
Rows with errors display a clear inline error message to help you make the necessary adjustments. You can fix rows with errors and re-upload the CSV file as many times as needed until all imports are successful.
## Enrollment contact information [#enrollment-contact-information]
When you submit an enrollment request, you'll need to provide two types of contact information. It's important to understand the difference between them.
### Provider contact [#provider-contact]
This is where the **payer** will send communications about the enrollment, if needed.
* The name and address should match exactly what the payer has on file for the provider. Some payers reject enrollment requests with addresses that don't match their records.
* However, you may want to set the phone number or email to a different contact - for example, a credentialing or general inbox - to ensure payer communications go to the right place.
* If you're enrolling a group practice, select a single administrative entity as the contact - don't use individual provider emails.
#### Where to set [#where-to-set]
You can specify contacts on both the provider record and on the enrollment request.
* **(Optional) Provider record:** These contacts are for convenience - they allow the Stedi portal to prepopulate contact information options when you create enrollment requests. They aren't required when you create provider records, and they aren't automatically added to enrollment requests.
* **(Required) Enrollment request:** You must specify a provider contact on the enrollment request. This is the information that Stedi shares with the payer when submitting the enrollment on your behalf. This contact information doesn't need to match the existing contact information on the provider record, which allows you to use different contacts for different payers as needed.
### Stedi contact email [#stedi-contact-email]
This is the email address where **Stedi** will send updates about the enrollment. It's required when you submit an enrollment request - we use it to notify you when there are next steps and send updates on the enrollment's status.
This is called the **Stedi contact person** on the enrollment request form, and it's the **user\_email** column in the CSV file for bulk imports.
This email address can be different from the contact information you provided in the provider record. Set it to wherever you want to receive Stedi's communications about the enrollment.
## Requested effective date [#requested-effective-date]
You can specify a requested effective date for transaction enrollments. This is the date you'd like the enrollment to take effect with the payer. For example, setting this for an 835 Electronic Remittance Advice (ERAs) enrollment to a future date helps you coordinate the migration from your previous clearinghouse to Stedi.
Stedi processes enrollments accordingly, but can't guarantee that the enrollment will be effective on this exact date.
### Check payer support [#check-payer-support]
You can determine which payers support requested effective dates in the [Payer Network](https://www.stedi.com/healthcare/network) by checking the **Requested effective date** field for the transaction type.
### Set requested effective date [#set-requested-effective-date]
To specify a requested effective date on enrollments:
* **Stedi portal:** Enter a date in the **Requested effective date** field when submitting enrollments. This field is visible for supported payers once you select a transaction type. You can submit today's date or a future date up to 6 months from today.
* **CSV import:** Populate the `requested_effective_date` column in YYYYMMDD format for each enrollment. Only set this for payers that support requested effective dates.
If you include a requested effective date for an unsupported payer, Stedi rejects the enrollment request. If you don't set a requested effective date, Stedi defaults to the enrollment's submission date.
## ERA aggregation preference [#era-aggregation-preference]
835 Electronic Remittance Advice (ERAs) can contain payment and adjudication details for multiple claims.
For supported payers, you can specify an aggregation preference for grouping claim information within each ERA. This helps ensure ERAs arrive in the way your billing system expects, reducing time spent matching payments to providers or practices.
### Aggregation types [#aggregation-types]
Payers use one of the following billing provider identifiers to group claim information in ERAs:
* **NPI:** The National Provider Identifier (NPI) always uniquely identifies a single provider entity, either an individual provider or an organization. For example, a doctor employed by multiple clinics may use the same NPI to submit claims across multiple TINs.
* **TIN:** The Tax Identification Number (TIN) can be the provider's Social Security Number (SSN) or Employee Identification Number (EIN). TINs are sometimes shared across multiple billing providers within the same organization. For example, a clinic may submit claims for several doctors using a single TIN.
Most payers default to TIN-based aggregation, and not all payers support both aggregation types.
### Check payer support [#check-payer-support-1]
You can determine which aggregation types your payers support through the [Payer Network](https://www.stedi.com/healthcare/network) - check the **ERA aggregation preferences** field.
### Set aggregation preference [#set-aggregation-preference]
To specify your aggregation preference on ERA enrollments:
* **Stedi portal:** Choose an identifier in the **Aggregate ERAs by** section when submitting ERA enrollments.
* **CSV import:** Populate either the `aggregationPreferenceNpi` (10 digit string) or `aggregationPreferenceTaxId` (9 digit string) column for each enrollment.
Stedi attempts to enroll with with your specified preference, but it's not guaranteed - ultimately, the payer controls how ERAs are grouped and routed. If you don't set a preference, Stedi automatically selects a default based on the payer's supported aggregation types and the available identifiers for the provider.
When available, Stedi displays the aggregation preference on the enrollment request's details page in the Stedi portal.
### Independent from scope [#independent-from-scope]
ERA aggregation preferences and [enrollment scope](#consider-enrollment-scope) are independent payer behaviors:
* **Enrollment scope:** Controls which NPIs the payer registers when you submit an enrollment request.
* **ERA aggregation:** Controls how the payer packages 835 ERAs after enrollment is complete - grouping claim information by NPI or TIN.
The payer's supported aggregation types don't indicate how they manage enrollment scope. A payer can support NPI-level aggregation preferences for 835 ERAs *and* manage enrollments at the TIN level. In these cases, specifying **NPI** as your preferred aggregation type in the enrollment request won't prevent the payer from enrolling all the NPIs associated with a specific TIN once the request is processed.
## Complete enrollment tasks [#complete-enrollment-tasks]
Tasks are actions that either the provider or Stedi need to complete to move the enrollment process forward.
When there's a new task that requires you to take action, Stedi adds a task to the enrollment request with instructions and sets the enrollment status to **Provider Action Required**. You'll [receive a notification email](/providers/providers-manage-transaction-enrollments#notification-emails) that there's a new task to complete.
Stedi is automatically notified when you complete a task, and the enrollment process continues.
### Task types [#task-types]
Tasks fall into three categories:
* **Follow instructions:** Complete a specific action, such as logging into a payer portal or contacting a department. The task includes instructions explaining what to do.
* **Provide information:** Supply specific information or confirmation to Stedi. The task describes what information is needed.
* **Provide documentation:** Upload PDF documentation related to the enrollment.
When a task requires documentation, Stedi may ask you to:
* **Complete a template:** Stedi provides a PDF template for you to download, fill out, and upload back to Stedi.
* **Upload supporting documentation:** Stedi asks you to provide a document you already have, such as a W-9 form or voided check.
### Complete tasks [#complete-tasks]
You can review and manage tasks at the top of the enrollment request's details page in the Stedi portal. You must have the [Operator role](/providers/providers-accounts-and-billing#assign-member-roles) or above to complete enrollment tasks.
If the task requires you to complete and upload documentation, it will include instructions with a PDF template to download, fill out, and upload to Stedi.
Once you've taken the required action, check the box next to the task to mark it as complete.
## Practices and facilities with multiple providers or locations [#practices-and-facilities-with-multiple-providers-or-locations]
Some healthcare organizations operate multiple facilities or practices under a shared structure. This is common in hospital systems, clinic networks, or large medical groups where multiple service locations operate under the same billing entity.
Transaction enrollment requires the billing provider's tax ID and NPI that you plan to use in claims and Electronic Remittance Advice (ERAs). When the same group NPI and tax ID are used as the billing provider throughout the healthcare organization, you should:
* Create a single provider record with that NPI and the tax ID. You don't need to create provider records for individual rendering providers.
* Create enrollment requests with the billing provider record attached. You don't need to submit additional enrollment requests for individual rendering providers. Select a single administrative entity as the contact - don't include individual provider emails. This should be a credentialing or general inbox.
* Use the taxonomy code that matches the billing provider's credentials when submitting claims.
## One-click enrollment [#one-click-enrollment]
We offer one-click enrollment for eligible payers. Once you submit the enrollment request, Stedi handles the entire process without any additional action from you. These payers don't require any signatures or documentation other than what is included in the enrollment request.
To determine whether a payer is eligible for one-click enrollment:
1. Go to the [Payer Network](https://www.stedi.com/healthcare/network).
2. Search for the payer you want to enroll with.
3. Click the payer's name to view its details. Stedi lists the **Type** as **One-click** for transaction types that support one-click enrollment.
The following example shows that one-click enrollment is available for 835 ERAs with Blue Cross Blue Shield of Illinois.
## Automatic enrollment requests [#automatic-enrollment-requests]
Some payers, such as the Centers for Medicare and Medicaid Services (CMS), require enrollment for eligibility checks.
Eligibility checks fail when a provider isn't properly enrolled. In these cases, Stedi automatically submits the required transaction enrollment request. Payers typically process these requests within 1-2 days.
We support automatic enrollment requests for the following payers in the [Payer Network](https://www.stedi.com/healthcare/network):
* The Centers for Medicare and Medicaid Services (CMS) (Payer ID: `CMS`)
* CMS MBI Lookup with SSN (Payer ID: `MBILU`)
* Highmark of Pennsylvania (Payer ID: `54771`)
* Highmark Senior Health Company (Payer ID: `15460`)
* Highmark Blue Cross Blue Shield of Delaware (Payer ID: `030`)
* Highmark Blue Cross Blue Shield of West Virginia (Payer ID: `54828`)
Please note:
* If the provider's NPI isn't active in the [National Plan & Provider Enumeration System (NPPES)](https://npiregistry.cms.hhs.gov/search), Stedi won't automatically create the enrollment for the NPI. The provider will need to apply directly with CMS to be added to the registry.
* For CMS enrollments, the provider must also complete [attestation](#cms-attestation). Stedi adds a task to the enrollment request when attestation is required.
* For CMS enrollments, the transaction enrollment request will be rejected and set to `REJECTED` status if the provider's NPI isn't active in [PECOS](https://pecos.cms.hhs.gov/pecos/login.do#headingLv1), the system CMS uses to manage active Medicare providers. In this case, we'll send you instructions explaining how to resolve the issue.
* Stedi sets the [Stedi contact email](#stedi-contact-email) to the oldest account member with the Admin role. This is where Stedi sends enrollment status notifications.
## CMS eligibility enrollment [#cms-eligibility-enrollment]
The Centers for Medicare and Medicaid Services (CMS) requires providers to complete attestation, also called HETS EDI Enrollment, before running Medicare eligibility checks. Attestation confirms that clearinghouses like Stedi have authorization to conduct eligibility checks on the provider's behalf. This requirement applies only to traditional Medicare, not Medicare Advantage (Part C) or Part D plans.
### How attestation works [#how-attestation-works]
Attestation is required for each billing National Provider Identifier (NPI) enrolled with CMS for eligibility checks. Stedi can't complete this step on the provider's behalf, and there is no bulk attestation across NPIs. The process takes approximately 5-15 minutes per NPI.
When you submit a CMS eligibility check enrollment request, Stedi moves the enrollment to the **Provider Action Required** status and adds an enrollment task to complete attestation. The task contains instructions for completing attestation. After the provider completes attestation, they can start submitting eligibility checks immediately, even if the enrollment status is not yet **Live**.
CMS rejects Medicare eligibility requests from providers who haven't completed attestation using `AAA` error code `41`.
You can view the attestation task and its status in the **Tasks** section of the enrollment request's details page in the Stedi portal.
# Support
Source: https://www.stedi.com/docs/providers/providers-support
We encourage you to contact us with questions, feedback, or for help using our products.
## Contact us [#contact-us]
We make every effort to respond as soon as possible, particularly to urgent requests. For both general support requests and billing inquiries, you can contact us through the following methods:
* [Website](https://www.stedi.com/contact) for all request types
* Email [support@stedi.com](mailto:support@stedi.com) for support requests, billing questions, and/or set up a dedicated Slack or Teams channel
When you report an issue, please include the following:
* A description of the issue, including the current behavior and the expected behavior
* Your Stedi account ID, if you submit through our website
* Screenshots showing the problem, when possible
# Test claims workflow
Source: https://www.stedi.com/docs/providers/providers-test-claims-workflow
You can submit test professional, dental, and institutional claims to make sure your claims process is working smoothly from end to end. When you submit test claims to the [Stedi Test Payer](https://www.stedi.com/healthcare/network?search=StediTest\&entry=FRCPB), Stedi generates and returns an 835 Electronic Remittance Advice (ERA) based on the original claim.
## Submit test claims [#submit-test-claims]
You can submit test claims with any payer ID and receive test [277CA claim acknowledgments](/providers/providers-claim-acknowledgments) from Stedi. This helps you test your claim submission workflow and practice interpreting and handling 277CA responses.
To send a test claim:
* In the [1500 claim form](https://portal.stedi.com/app/healthcare/claims/create), select **Test** for the **EDI mode**.
* During [X12 EDI upload](https://portal.stedi.com/app/healthcare/claims/upload), select **Test** from the dropdown at the top of the text area.
Stedi processes the claim and applies our entire catalog of [edits and repairs](/providers/providers-claim-edits-and-repairs).
### Test 277CAs [#test-277cas]
When you submit a test claim to any payer, Stedi returns a test 277CA claim acknowledgment indicating whether the claim was successfully processed.
## View test claims [#view-test-claims]
When you designate a claim as test data, you can:
* View it in test mode from the [claims view](https://portal.stedi.com/app/healthcare/claims). Toggle test mode to **ON** to review test claims and their associated responses.
* Filter for test claims on the [transactions view](https://portal.stedi.com/app/core/transactions). The following example shows the **Transactions** page filtered to show only 837 claims. There are two test claims (indicated by the **Test** badge) and one production claim.
## Generate test ERAs [#generate-test-eras]
When you submit test claims to the [Stedi Test Payer](https://www.stedi.com/healthcare/network?search=StediTest\&entry=FRCPB), Stedi returns a test 277CA claim acknowledgment and a test 835 Electronic Remittance Advice (ERA) based on the original claim. Only test claims you send to the Stedi Test Payer will generate a test 835 ERA.
You can use this approach to test your claims processing workflow from end to end.
### Enroll with the Stedi Test Payer [#enroll-with-the-stedi-test-payer]
You must enroll your provider with the [Stedi Test Payer](https://www.stedi.com/healthcare/network?search=StediTest\&entry=FRCPB) for **835 Claim payment**. Visit [Transaction enrollment](/providers/providers-submit-enrollment-requests) for instructions on how to submit an enrollment request.
Once submitted, the enrollment request is automatically set to `LIVE` status within one minute. You can start submitting test claims to the Stedi Test Payer immediately after enrollment.
### Submit a test claim [#submit-a-test-claim]
Submit a test claim to the Stedi Test Payer. Ensure that you:
* Designate the claim as test data:
* Select **Test** for the **EDI mode** in the [1500 claim form](https://portal.stedi.com/app/healthcare/claims/create).
* Set `ISA15` (Interchange Usage Indicator) to `T` (Test Data) during [X12 EDI upload](https://portal.stedi.com/app/healthcare/claims/upload).
* Set the payer to the [Stedi Test Payer](https://www.stedi.com/healthcare/network?search=StediTest\&entry=FRCPB).
* Use the billing provider NPI and tax ID you enrolled with the Stedi Test Payer.
The following example shows how to submit a test professional claim to the Stedi Test Payer using the CMS-1500 claim form in the Stedi portal.
### Test responses [#test-responses]
Stedi returns the following responses within minutes of submitting a test claim to the Stedi Test Payer:
* A test 277CA claim acknowledgment response indicating whether the claim was successfully processed. Note that if Stedi rejects the claim in the 277CA, you won't receive a test 835 ERA.
* A test 835 Electronic Remittance Advice (ERA) containing information from the original claim, including the same:
* Provider information
* Patient information
* Service line details
* Charges
Test 835 ERAs always indicate that all service lines are paid, with the same charge amounts you submitted in the test claim. Note that when you submit real claims, payers may send ERAs with different outcomes, including partially paid, denied, split, or bundled claims.
## Review test responses [#review-test-responses]
You can review claim responses in the Stedi portal through the claims view or the transactions view (classic).
#### Claims view [#claims-view]
You can review test 277CAs from the [claims view](https://portal.stedi.com/app/healthcare/claims).
1. Toggle test mode to **ON**. You can only view test claims and responses when test mode is active.
2. Click a claim to view a timeline of its processing activity.
3. Click an **Acknowledgment** (277CA) to review its details.
Stedi displays key information about the 277CA, including the billing provider's information and status codes.
#### Transactions view [#transactions-view]
You can review both 277CAs and 835 ERAs from the [transactions view](https://portal.stedi.com/app/healthcare/transactions). Click any transaction to view its details.
You can also access responses through the **Related transactions** tab of the original claim submission.
1. Go to the [transactions view](https://portal.stedi.com/app/healthcare/transactions).
2. Click the claim to review its details.
3. Click **Related transactions** to go to a list of related transactions, including 277CA and 835 ERA responses.
Both the test 277CA and the test 835 ERA will include the Patient Control Number you specified in the claim submission, which is what Stedi uses to match these responses to the original claim.
| Response type | How to find Patient Control Number |
| ------------- | --------------------------------------------------------------------------------------------------------------------- |
| 277CA | On the **Overview** tab, the Patient Control Number is displayed as the **Patient account number**. |
| 835 ERA | On the **Overview** tab, the Patient Control Number is listed as the first number in the **Claim identifiers** field. |
# Test mode
Source: https://www.stedi.com/docs/providers/providers-test-mode
Test mode provides a separate test environment where you can realistically simulate transactions in your Stedi account without PHI/PII and without sending any data to payers.
You can access test mode in your account at any time by toggling **Test mode** to **ON**.
## Send mock eligibility checks [#send-mock-eligibility-checks]
Mock transactions you send in test mode are free for testing purposes and
won’t incur any charges from Stedi.
You can submit mock real-time eligibility checks through the manual [eligibility check form](https://portal.stedi.com/app/healthcare/checks/create). You can choose from a variety of predefined requests for well-known payers, including:
* Aetna
* Cigna
* UnitedHealthcare
* National Centers for Medicare & Medicaid Services (CMS)
For each mock request, Stedi returns a realistic mock benefits response for that payer so you can get a sense for the kinds of data you'll receive in production. The benefits responses include examples of copays, deductibles, and other patient payment responsibilities, as well as active coverage.
You can also submit a mock Medicare Beneficiary Identifier (MBI) lookup. MBI lookups allow you to use a patient's Social Security Number (SSN) to retrieve their MBI and complete benefits information from the Centers for Medicare and Medicaid Services (CMS).
### Test the Stedi Agent [#test-the-stedi-agent]
The [Stedi Agent](/healthcare/eligibility-searches-view#retry-with-the-stedi-agent) resolves recoverable eligibility check errors automatically with the same best practices our Support team uses for troubleshooting. You can run a specific mock eligibility check to evaluate the Stedi Agent:
1. Create a new eligibility check and select **Stedi Agent** as the payer. Keep all other properties set to their defaults.
2. Submit the check. It's designed to fail so you can watch the agent resolve issues in real time. Specifically, it returns `AAA` error `73` (Invalid/Missing Subscriber/Insured Name).
3. Click **Resolve with Stedi Agent**. The agent runs in **Debug view** to fix the error and eventually produce a successful mock eligibility response.
4. Click **View check** to go to its details page and review the full mock benefits response.
## Review eligibility check results [#review-eligibility-check-results]
After you submit a mock eligibility check, you can review all of the request and response details. This includes:
* A list of historical eligibility checks that you can filter by status, payer ID, date, and error code.
* The raw API request and response.
* A user-friendly benefits view designed to help you quickly understand the patient's active coverage and payment responsibilities, such as co-pay and deductible amounts.
* Eligibility check **Debug** view, which allows you to to systematically troubleshoot failed checks until you receive a successful response from the payer.
To review an eligibility check's results:
1. Go to the [Eligibility searches page](https://portal.stedi.com/app/healthcare/eligibility).
2. Click the eligibility search with the benefits information you want to view.
Stedi opens the eligibility search's **Overview** tab. Click **Benefits** to review a table of the mock benefits data.
## View test claims [#view-test-claims]
You can submit test claims through SFTP or Stedi's APIs and view them in the [claims view](https://portal.stedi.com/app/healthcare/claims) when **Test mode** is toggled to **ON**. Submitting test claims through the claims view is not yet supported.
To submit test claims:
* **JSON endpoints:** Set the `usageIndicator` property in the test claim body to `T`.
* **X12 EDI endpoints and SFTP:** Set `ISA15` (Interchange Usage Indicator) to `T` (Test Data).
Visit the [test claims workflow](/healthcare/test-claims-workflow) page for detailed instructions on submitting test claims and generating test 835 Electronic Remittance Advice (ERA) responses from the Stedi Test Payer.
Click any test claim to view a timeline of its processing activity, including all associated test responses such as test 277CA claim acknowledgments and test 835 Electronic Remittance Advice (ERAs).
## Explore the Stedi portal [#explore-the-stedi-portal]
The test environment allows you to get familiar with Stedi's UI tools and learn more about how you can use Stedi to automate claims and eligibility check workflows.
## Not supported [#not-supported]
The following features aren't currently supported in test mode:
* Raw X12 real-time eligibility checks
* Batch eligibility checks
* Transaction enrollment
* Insurance discovery checks
* Coordination of benefits (COB) checks
* Submitting claims through the Stedi portal UI
* 275 claim attachments
* 276/277 real-time claim status
* Custom mock data or payer selection
# Transaction enrollment FAQ
Source: https://www.stedi.com/docs/providers/providers-transaction-enrollment-faq
This FAQ provides answers to the most common questions about transaction enrollment. Please contact Stedi support with additional questions.
## How do I know if I need to enroll? [#how-do-i-know-if-i-need-to-enroll]
All payers require transaction enrollment for 835 Electronic Remittance Advice (ERAs). For other transactions, like claims and eligibility checks, it depends on the payer.
Check the [Payer Network](https://www.stedi.com/healthcare/network) to determine whether your payers require enrollment for the transaction types you want to send and receive.
For transactions marked as **Supported, enrollment required**, you must complete the transaction enrollment process before you can begin exchanging that transaction type through Stedi.
## How long does transaction enrollment take? [#how-long-does-transaction-enrollment-take]
The transaction enrollment process typically takes 24-48 hours, though it can take up to 30 days for some payers.
## Do I need to enroll through Stedi if I'm already enrolled through another clearinghouse? [#do-i-need-to-enroll-through-stedi-if-im-already-enrolled-through-another-clearinghouse]
Yes. Enrollment is specific to each clearinghouse. So if a payer requires enrollment, you will need to go through the enrollment process with Stedi to begin exchanging transactions through the Stedi clearinghouse.
## What will happen to the ERAs I currently receive through a different clearinghouse? [#what-will-happen-to-the-eras-i-currently-receive-through-a-different-clearinghouse]
ERAs can only be sent to a single clearinghouse. Once you enroll for ERAs through Stedi, all ERAs from that payer to the provider you enrolled will come through Stedi. The provider will no longer receive ERAs from that payer through your previous clearinghouse.
## Does enrolling with Stedi cancel my enrollment with another clearinghouse? [#does-enrolling-with-stedi-cancel-my-enrollment-with-another-clearinghouse]
For ERAs, yes. Once you enroll for ERAs through Stedi, the payer will stop sending ERAs to your previous clearinghouse.
For claims and other types of transactions, it depends on the payer. Some payers accept claims through multiple clearinghouses or direct connections. Customer support can help answer this question for your specific payers.
## Can a provider be enrolled through multiple clearinghouses at the same time? [#can-a-provider-be-enrolled-through-multiple-clearinghouses-at-the-same-time]
Yes, for claims and eligibility checks. Some payers allow providers to submit claims and eligibility checks through multiple clearinghouses. Customer support can help answer this question for your specific payers.
No, for ERAs. As soon as an ERA enrollment in Stedi is processed with the payer, you won't receive ERAs through your previous clearinghouse.
## Can I send claims through Stedi without switching my ERA enrollments? [#can-i-send-claims-through-stedi-without-switching-my-era-enrollments]
Yes, you can start sending claims through Stedi without enrolling for ERAs. The ERAs will still go to your current clearinghouse. In Stedi, you'll see the claim and the 277CA claim acknowledgment from the payer, but you won't see ERAs until you switch those enrollments to Stedi.
## Can I enroll one NPI without affecting others associated with the same TIN (tax ID)? [#can-i-enroll-one-npi-without-affecting-others-associated-with-the-same-tin-tax-id]
It depends on how the payer manages enrollment scope.
Some payers manage enrollments at the NPI level - when you enroll one NPI, only that NPI switches to Stedi. Other payers manage enrollments at the Tax Identification Number (TIN) level - when you enroll one NPI, all NPIs under that TIN switch to Stedi.
Payers vary in how they manage enrollment scope, and this information isn't always disclosed to Stedi. If you have multiple NPIs that share the same TIN and you want to keep some with your existing clearinghouse, contact Stedi support before submitting enrollment requests to discuss your specific situation.
# Transaction enrollment overview
Source: https://www.stedi.com/docs/providers/providers-transaction-enrollment-intro
Transaction enrollment is the process of registering a provider to exchange:
* a specific healthcare transaction (like 835 Electronic Remittance Advice ERAs)
* with a specific payer (like Cigna or UnitedHealthcare)
* through a specific clearinghouse (Stedi).
When a payer requires transaction enrollment, you **must** complete the process before you can begin exchanging that transaction type through Stedi. It typically takes 24-48 hours.
## Do I need to enroll? [#do-i-need-to-enroll]
All payers require transaction enrollment for 835 Electronic Remittance Advice
(ERAs). For other transactions, like claims and eligibility checks, it depends
on the payer.
Check the [Payer Network](https://www.stedi.com/healthcare/network) to determine whether your payers require enrollment for the transaction types you want to send and receive. For transactions marked as **Supported, enrollment required**, you must complete the transaction enrollment process before you can begin exchanging that transaction type through Stedi.
Transaction enrollment is specific to each clearinghouse. If you're already enrolled with a payer through another clearinghouse, you still need to complete enrollment with Stedi.
Don't enroll for 835 ERAs until you're ready to switch to Stedi. Once you enroll, all ERAs from that payer will come through Stedi exclusively. You'll no longer receive ERAs from that payer through your previous clearinghouse.
## Transaction enrollment process [#transaction-enrollment-process]
Stedi handles most of the transaction enrollment process for you. Here's how it works:
You can submit transaction enrollment requests either individually or in bulk through CSV import. With both methods, you'll:
1. Create a provider record with the billing provider's tax ID, NPI, and contact information.
2. Submit enrollment requests containing the provider record, the payer, and the transaction type.
When we begin the enrollment process with the payer, we'll set the enrollment status to **PROVISIONING**. You'll get notification emails each time the status changes or there is new information for you to review.
For some payers, such as those with [one-click enrollment](/providers/providers-submit-enrollment-requests#one-click-enrollment), Stedi can complete the entire enrollment process for you. We sign enrollment PDF forms on your behalf, when possible, to speed up the process and eliminate extra work for your team.
Some enrollments may require you to complete additional steps. If there are additional steps, we'll set the enrollment status to **PROVIDER ACTION REQUIRED** and add a task to the enrollment request with clear instructions. The enrollment process continues once you complete the required tasks.
Once a transaction enrollment request is in **LIVE** status, you can start exchanging that transaction type through Stedi.
ERAs can only be sent to one clearinghouse, so you'll start receiving them through Stedi exclusively. Your enrollment with any other clearinghouses will be canceled.
For other transaction types, like claims and eligibility checks, you may be able to continue sending them through other clearinghouses - it depends on the payer.
Check out our [Enrollment FAQ](/providers/providers-transaction-enrollment-faq) for answers to common
questions.
# Trust Center
Source: https://www.stedi.com/docs/providers/providers-trust-center
Visit our [Trust Center](https://trust.stedi.com/) for complete trust and compliance information for all Stedi products and APIs, including our:
* Privacy policy
* Data management policy
* Access control policy
* HIPAA compliance policy
* Certifications, including SOC 2 Type II and HIPAA
* Security and privacy controls
# Delete Enrollment Document
Source: https://www.stedi.com/docs/healthcare/api-reference/delete-enrollment-document
This endpoint deletes the specified PDF document associated with a [transaction enrollment](/healthcare/transaction-enrollment).
1. Call this endpoint with the document ID for the PDF document you want to delete. The document ID is returned in the responses for the [Retrieve Enrollment](/healthcare/api-reference/get-enrollment) and [List Enrollments](/healthcare/api-reference/get-enrollment-list-enrollments) endpoints.
2. The endpoint returns an empty response to indicate that the document has been successfully deleted.
You can also delete enrollment documents manually from the enrollment's details page in the Stedi portal.
## API Specification
Deletes the specified PDF document associated with a transaction enrollment.
**Endpoint:** `DELETE /documents/{documentId}`
**Base URL:** `https://enrollments.us.stedi.com/2024-09-01`
### Parameters
- **`documentId`** (path) (required): The document ID for the PDF document you want to delete. The document ID is returned in the responses for the [Retrieve Enrollment](/healthcare/api-reference/get-enrollment) and [List Enrollments](/healthcare/api-reference/get-enrollment-list-enrollments) endpoints.
- Type: `string`
### Responses
#### 200
DeleteEnrollmentDocument 200 response
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
QuotaExceededException 429 response
**Schema:** `QuotaExceededExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Delete Provider
Source: https://www.stedi.com/docs/healthcare/api-reference/delete-enrollment-provider
This endpoint allows you to delete providers without associated [transaction enrollments](/healthcare/transaction-enrollment). If you need to delete a provider that has associated enrollments, contact support.
## API Specification
Deletes a provider record. Providers can only be deleted if they have no associated enrollments. This operation is idempotent.
**Endpoint:** `DELETE /providers/{providerId}`
**Base URL:** `https://enrollments.us.stedi.com/2024-09-01`
### Parameters
- **`providerId`** (path) (required): The Stedi-assigned identifier for the provider you want to delete.
- Type: `string`
### Responses
#### 200
DeleteProvider 200 response
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
QuotaExceededException 429 response
**Schema:** `QuotaExceededExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Delete Enrollment
Source: https://www.stedi.com/docs/healthcare/api-reference/delete-enrollment
This endpoint allows you to delete a [transaction enrollment](/healthcare/transaction-enrollment) that is still in `DRAFT` status.
## API Specification
Deletes an enrollment request. Only enrollments in DRAFT status can be deleted. This operation is idempotent.
**Endpoint:** `DELETE /enrollments/{enrollmentId}`
**Base URL:** `https://enrollments.us.stedi.com/2024-09-01`
### Parameters
- **`enrollmentId`** (path) (required): The Stedi-assigned identifier for the enrollment you want to delete.
- Type: `string`
### Responses
#### 200
DeleteEnrollment 200 response
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
QuotaExceededException 429 response
**Schema:** `QuotaExceededExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Retrieve Eligibility PDF (271)
Source: https://www.stedi.com/docs/healthcare/api-reference/get-eligibility-pdf
This endpoint retrieves the [eligibility PDF](/healthcare/eligibility-pdf) for a 270/271 eligibility check. Stedi generates a PDF for eligibility checks with valid 271 responses. The PDF contains a summary of the request details and a human-readable version of the 271 response.
1. Call this endpoint with the `eligibilityCheckId` path parameter set to the eligibility check's ID. You can retrieve this ID from the:
* `id` property of the real-time JSON, Raw X12, and SOAP eligibility check endpoint responses.
* `items.id` property of the Poll Batch Eligibility Checks endpoint response.
* Eligibility check's details page within the [Stedi portal](https://portal.stedi.com/app/healthcare/eligibility).
2. The endpoint returns the PDF as a base64-encoded string by default. To receive unencoded binary PDF data instead, include the `Accept: application/pdf` request header.
To view the PDF, save the unencoded response body to a file with a `.pdf` extension.
```bash
curl --request GET \
--url "https://manager.us.stedi.com/2024-04-01/eligibility-manager/eligibility-checks/{eligibilityCheckId}/pdf" \
--header "Accept: application/pdf" \
--header "Authorization: " \
--output ~/Desktop/eligibility.pdf
```
## API Specification
Retrieve a PDF version of the 271 benefits response for the specified eligibility check
**Endpoint:** `GET /eligibility-manager/eligibility-checks/{eligibilityCheckId}/pdf`
**Base URL:** `https://manager.us.stedi.com/2024-04-01`
### Parameters
- **`eligibilityCheckId`** (path) (required): The globally unique identifier for this eligibility check across all Stedi accounts. It's formatted as `ec_`. For example: `ec_550e8400-e29b-41d4-a716-446655440000`. You can find it:
- In the `id` property of the real-time JSON, Raw X12, and SOAP eligibility check endpoint responses.
- In the `items[].id` property of the Poll Batch Eligibility Checks endpoint response.
- On the eligibility check's details page within the Stedi portal.
- Type: `string`
### Responses
#### 200
GetEligibilityCheckPdf 200 response
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Download Enrollment Document
Source: https://www.stedi.com/docs/healthcare/api-reference/get-enrollment-document-download
This endpoint returns a pre-signed URL that you can use to download a PDF document related to the specified [transaction enrollment](/healthcare/transaction-enrollment).
1. Call this endpoint with the document ID for the PDF document you want to download. The document ID is returned in the responses for the [Retrieve Enrollment](/healthcare/api-reference/get-enrollment) and [List Enrollments](/healthcare/api-reference/get-enrollment-list-enrollments) endpoints.
2. The endpoint returns a pre-signed URL that you can use to download the specified PDF document.
3. Use a `GET` request to download the PDF document from the pre-signed URL.
```bash
curl --request GET \
--url "" \
--output /path/to/file.pdf
```
You can also download enrollment documents manually from the enrollment's details page in the Stedi portal.
## API Specification
Returns a pre-signed URL to download the specified enrollment document.
**Endpoint:** `GET /documents/{documentId}/download`
**Base URL:** `https://enrollments.us.stedi.com/2024-09-01`
### Parameters
- **`documentId`** (path) (required): The document ID for the PDF document you want to download. The document ID is returned in the responses for the [Retrieve Enrollment](/healthcare/api-reference/get-enrollment) and [List Enrollments](/healthcare/api-reference/get-enrollment-list-enrollments) endpoints.
- Type: `string`
### Responses
#### 200
CreateEnrollmentDocumentDownload 200 response
**Schema:** `CreateEnrollmentDocumentDownloadResponseContent`
**Properties:**
- **`documentId`** (`string`) (required): The document ID for the PDF document associated with the `downloadUrl`.
- **`downloadUrl`** (`string`) (required): The pre-signed URL to download the document.
**Example:**
```json
{
"documentId": "doc-123e4567-e89b-12d3-a456-426614174000",
"downloadUrl": "https://s3.amazonaws.com/enrollment-documents/doc-123e4567-e89b-12d3-a456-426614174000/provider-license.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=..."
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
QuotaExceededException 429 response
**Schema:** `QuotaExceededExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# List Enrollments
Source: https://www.stedi.com/docs/healthcare/api-reference/get-enrollment-list-enrollments
This endpoint retrieves a list of all [transaction enrollments](/healthcare/transaction-enrollment) in your Stedi account.
You can filter the results by various criteria, such as a query string (fuzzy matching is supported), enrollment status, creation date, provider names, provider NPIs, provider tax IDs, and Stedi payer IDs. When a query parameter is an array, you can include it more than once in the URL to filter by multiple values.
| Query parameters | Endpoint returns |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `?providerNames=John%20Doe&providerNames=Jane%20Doe` | Enrollments associated with either John Doe or Jane Doe. |
| `?status=LIVE` | Enrollments in `LIVE` status. |
| `?filter=OS&createdFrom=2025-01-01T00:00:00Z` | - Enrollments with provider names, provider NPIs, provider tax IDs, or Stedi payer IDs containing `os` or `OS`. The search is case-insensitive, and fuzzy matching is supported.
- Enrollments created after `2025-01-01T00:00:00Z`.
|
## API Specification
Lists transaction enrollment records with optional filtering and pagination.
**Endpoint:** `GET /enrollments`
**Base URL:** `https://enrollments.us.stedi.com/2024-09-01`
### Parameters
- **`pageSize`** (query): The maximum number of elements to return in a page. If not specified, the default is 100.
- Type: `number`
- **`pageToken`** (query): The `nextPageToken` value from a previous response. You can use this to get the next page of results. If not set, Stedi returns the first page of results.
- Type: `string`
- **`filter`** (query): Filter for enrollments with properties matching a query string.
You can provide all or part of a provider name, NPI, or tax ID. You can also provide all or part of a payer's [Stedi payer ID](https://www.stedi.com/docs/healthcare/supported-payers#stedi-payer-id) - primary payer IDs and aliases aren't supported. The search is case-insensitive and supports fuzzy matching.
For example, providing `?filter=OS` returns enrollments with `provider.name` containing `os` or `OS` (such as `Joseph`) and Stedi payer IDs containing `OS`, such as `OSBLI` for OptumHealth Salt Lake County.
- Type: `string`
- **`status`** (query): Filter for enrollments with specific statuses.
You can include this parameter multiple times to filter for multiple statuses. For example, `?status=LIVE&status=REJECTED` returns enrollments that are in either `LIVE` or `REJECTED` status.
- Type: `array`
- **`providerNpis`** (query): Filter for enrollments associated with specific provider NPIs.
You can include this parameter multiple times to filter for multiple NPIs. For example, `?providerNpis=1234567890&providerNpis=0987654321` returns enrollments associated with either of the specified NPIs.
- Type: `array`
- **`providerTaxIds`** (query): Filter for enrollments associated with specific provider tax IDs.
You can include this parameter multiple times to filter for multiple tax IDs. For example, `?providerTaxIds=123456789&providerTaxIds=987654321` returns enrollments associated with either of the specified tax IDs.
- Type: `array`
- **`providerNames`** (query): Filter for enrollments associated with specific provider names.
This search is case-sensitive and doesn't support fuzzy matching. The name you provide must match the provider's name exactly, including spaces and capitalization.
You can include this parameter multiple times to filter for multiple names. For example, `?providerNames=John%20Doe&providerNames=Jane%20Doe` returns enrollments associated with either John Doe or Jane Doe.
- Type: `array`
- **`providerIds`** (query): Filter for enrollments associated with specific provider IDs.
The provider ID is a UUID Stedi assigns to each provider record upon creation, allowing you to differentiate between provider records that share the same NPI. It's returned in the `id` property of the [Create Provider](/healthcare/api-reference/post-enrollment-create-provider#response.id) and [Retrieve Provider](/healthcare/api-reference/get-enrollment-provider#response.id) responses.
You can include this parameter multiple times to filter for multiple providers. For example, `?providerIds=10334e76-f073-4b5d-8984-81d8e5107857&providerIds=10234e76-f067-4b5d-8984-81d8e5107123` returns enrollments associated with either of the specified providers.
- Type: `array`
- **`payerIds`** (query): Filter for enrollments associated with specific [Stedi payer IDs](https://www.stedi.com/docs/healthcare/supported-payers#stedi-payer-id).
This parameter only supports Stedi payer IDs, not primary payer IDs or aliases. It also doesn't support fuzzy matching. The payer ID you provide must match the Stedi payer ID exactly, including capitalization. You must include leading `0` characters - for example, use `00540` for SISCO, not `540`.
You can include this parameter multiple times to filter for multiple payer IDs. For example, `?payerIds=HGJLR&payerIds=EWDCI` returns enrollments associated with either of the specified payer IDs.
- Type: `array`
- **`sources`** (query): Filter for enrollments submitted through specific sources, such as the API or UI.
You can include this parameter multiple times to filter for multiple sources. For example, `?sources=API&sources=UI` returns enrollments submitted through either of the specified sources.
- Type: `array`
- **`transactions`** (query): Filter for enrollments for specific transaction types.
You can include this parameter multiple times to filter for multiple types. For example, `?transactions=eligibilityCheck&transactions=claimStatus` returns enrollments for both 270/271 eligibility checks and 276/277 real-time claim status.
- Type: `array`
- **`createdFrom`** (query): Filter for enrollments created from a specific date.
For example, if you set this to `2025-01-01T00:00:00Z`, Stedi returns enrollments with a `createdAt` timestamp on or after this date.
- Type: `string`
- **`createdTo`** (query): Filter for enrollments created before a specific date. The time must be later than `createdFrom`, if present.
For example, if you set this to `2025-01-01T00:00:00Z`, Stedi only returns enrollments with a `createdAt` timestamp before this date.
- Type: `string`
- **`statusUpdatedFrom`** (query): Filter for enrollments whose status was last updated from a specific date.
For example, if you set this to `2025-01-01T00:00:00Z`, Stedi returns enrollments with a `statusLastUpdatedAt` timestamp on or after this date.
- Type: `string`
- **`statusUpdatedTo`** (query): Filter for enrollments whose status was last updated before a specific date. The time must be later than `statusUpdatedFrom`, if present.
For example, if you set this to `2025-01-01T00:00:00Z`, Stedi only returns enrollments with a `statusLastUpdatedAt` before this date.
- Type: `string`
- **`importId`** (query): The import ID associated with an enrollment through a CSV bulk import. This ID is only available for enrollments created through the CSV import process.
- Type: `string`
- **`requestedEffectiveDateFrom`** (query): Filter for enrollments with a requested effective date on or after this date, in YYYYMMDD format.
For example, `?requestedEffectiveDateFrom=20260101` returns enrollments with a `requestedEffectiveDate` of `20260101` or later.
- Type: `string`
- **`requestedEffectiveDateTo`** (query): Filter for enrollments with a requested effective date on or before this date, in YYYYMMDD format. The date must be the same as or later than `requestedEffectiveDateFrom`, if present.
For example, `?requestedEffectiveDateTo=20261231` returns enrollments with a `requestedEffectiveDate` of `20261231` or earlier.
- Type: `string`
- **`lastEraReceivedFrom`** (query): Filter for enrollments with a `lastEraReceivedAt` timestamp on or after this value. Only enrollments with an ERA are included.
You can use this filter with `lastEraReceivedTo` to define a date range. For example, setting this to `2025-01-01T00:00:00Z` returns enrollments with a `lastEraReceivedAt` on or after that date.
- Type: `string`
- **`lastEraReceivedTo`** (query): Filter for enrollments with a `lastEraReceivedAt` timestamp on or before this value. Only enrollments with an ERA are included. This value must be later than `lastEraReceivedFrom`, if present.
For example, setting this to `2025-01-01T00:00:00Z` returns enrollments with a `lastEraReceivedAt` on or before that date.
- Type: `string`
- **`userEmails`** (query): Filter for enrollments associated with specific submitter emails. This is the `userEmail` property in [Create Enrollment](https://www.stedi.com/docs/healthcare/api-reference/post-enrollment-create-enrollment) requests, or the **Stedi contact person** in the portal.
This search is case-sensitive and doesn't support fuzzy matching. The email you provide must match the submitter's email exactly, including capitalization.
You can include this parameter multiple times to filter for multiple submitter emails. For example, `?userEmails=alice%40example.com&userEmails=bob%40example.com` returns enrollments submitted by either `alice@example.com` or `bob@example.com`.
- Type: `array`
- **`sortBy`** (query): Sort the results by one or more properties. By default, Stedi sorts results by the `createdAt` property in descending order.
Supply a query string with each property appended using `&`. Each property must be provided in a `property:direction` format, where `property` is the name of the property to sort by and `direction` is the sort direction, either `asc` (ascending) or `desc` (descending).
- When you don't include `id`, Stedi automatically adds it as the final sort criterion to ensure deterministic results.
- When you provide multiple properties, Stedi sorts by their order in the query string. For example, if you provide `?sortBy=updatedAt:desc&sortBy=id:asc`, Stedi sorts first by `updatedAt` in descending order. If multiple records share the same `updatedAt` date, Stedi then sorts those records by `id` in ascending order.
**Supported properties:** `updatedAt`, `statusLastUpdatedAt`, `id`, `requestedEffectiveDate`, `lastEraReceivedAt`
Examples:
- Sort by `updatedAt` in descending order: `?sortBy=updatedAt:desc`
- Sort by `statusLastUpdatedAt` in ascending order: `?sortBy=statusLastUpdatedAt:asc`
- Sort by `updatedAt` and then by `id`: `?sortBy=updatedAt:desc&sortBy=id:asc`
- Type: `array`
### Responses
#### 200
ListEnrollments 200 response
**Schema:** `ListEnrollmentsResponseContent`
**Properties:**
- **`items`** (`array`): Details about the enrollments matching the search criteria.
- Items schema: `EnrollmentSummary`
- **`nextPageToken`** (`string`): Token that you can supply in subsequent requests to retrieve the next page of results. If not returned, there are no more results.
- **`totalCount`** (`number`): The total count of enrollments matching the filter criteria, regardless of pagination.
**Example:**
```json
{
"items": [
{
"aggregationPreference": {
"taxId": "123456789"
},
"createdAt": "2025-04-01T12:00:00Z",
"documents": [
{
"createdAt": "2025-04-01T12:00:00Z",
"enrollmentId": "db6675c5-7bg7-4af9-8c68-a54a336d2911",
"id": "dc6665a5-7b97-4agh-8c74-a00a336c2989",
"name": "pdf-agreement.pdf",
"status": "UPLOADED",
"updatedAt": "2025-04-02T12:00:00Z"
}
],
"history": [
{
"changedAt": "2025-04-15T09:00:00Z",
"changedBy": "user@example.com",
"newStatus": "DRAFT",
"type": "STATUS_CHANGE"
},
{
"changedAt": "2025-04-15T09:05:00Z",
"changedBy": "user@example.com",
"newStatus": "STEDI_ACTION_REQUIRED",
"previousStatus": "DRAFT",
"type": "STATUS_CHANGE"
},
{
"changedAt": "2025-04-20T14:30:00Z",
"changedBy": "system",
"newStatus": "PROVIDER_ACTION_REQUIRED",
"previousStatus": "STEDI_ACTION_REQUIRED",
"type": "STATUS_CHANGE"
},
{
"changedAt": "2025-05-02T12:00:00Z",
"changedBy": "system",
"newStatus": "PROVISIONING",
"previousStatus": "PROVIDER_ACTION_REQUIRED",
"type": "STATUS_CHANGE"
},
{
"changedAt": "2025-05-10T15:30:00Z",
"changedBy": "system",
"newStatus": "LIVE",
"previousStatus": "PROVISIONING",
"type": "STATUS_CHANGE"
}
],
"id": "db6675c5-7bg7-4af9-8c68-a54a336d2911",
"lastEraReceivedAt": "2025-05-02T12:00:00Z",
"payer": {
"name": "UnitedHealthcare",
"stediPayerId": "KMQTZ",
"submittedPayerIdOrAlias": "87726"
},
"provider": {
"id": "db6665c5-7b97-4af9-8c68-a00a336c2998",
"name": "Test Medical Provider",
"npi": "1234567890",
"taxId": "123456789",
"taxIdType": "EIN"
},
"requestedEffectiveDate": "20250415",
"source": "API",
"status": "LIVE",
"statusLastUpdatedAt": "2025-05-01T12:00:00Z",
"tasks": [
{
"definition": {
"followInstructions": {
"instructions": "Please follow these instructions: ."
}
},
"id": "ac6665a5-7b97-4agh-8c74-a00a336c2989",
"isComplete": true,
"rank": 0,
"responsibleParty": "PROVIDER"
}
],
"transactions": {
"claimPayment": {
"enroll": true
}
},
"updatedAt": "2025-05-01T12:00:00Z"
},
{
"createdAt": "2025-04-20T08:15:00Z",
"documents": [
{
"createdAt": "2026-11-08T12:00:00Z",
"enrollmentId": "db6675c5-7bg7-4af9-8c68-a54a336d2911",
"id": "dc6665a5-7b97-4agh-8c74-a00a336c2989",
"name": "pdf-agreement.pdf",
"status": "UPLOADED",
"updatedAt": "2026-11-08T12:05:00Z"
}
],
"history": [
{
"changedAt": "2026-11-07T05:31:56Z",
"changedBy": "user@example.com",
"newStatus": "DRAFT",
"type": "STATUS_CHANGE"
},
{
"changedAt": "2026-11-07T05:31:56Z",
"changedBy": "user@example.com",
"newStatus": "STEDI_ACTION_REQUIRED",
"previousStatus": "DRAFT",
"type": "STATUS_CHANGE"
},
{
"changedAt": "2026-11-07T06:15:22Z",
"changedBy": "system",
"newStatus": "PROVIDER_ACTION_REQUIRED",
"previousStatus": "STEDI_ACTION_REQUIRED",
"type": "STATUS_CHANGE"
},
{
"changedAt": "2026-11-08T06:15:22Z",
"changedBy": "system",
"newStatus": "STEDI_ACTION_REQUIRED",
"previousStatus": "PROVIDER_ACTION_REQUIRED",
"type": "STATUS_CHANGE"
},
{
"changedAt": "2026-11-10T06:15:22Z",
"changedBy": "system",
"newStatus": "PROVIDER_ACTION_REQUIRED",
"previousStatus": "STEDI_ACTION_REQUIRED",
"type": "STATUS_CHANGE"
}
],
"id": "e9a8b7c6-d5f4-3e2d-1c0b-a9876543210f",
"payer": {
"name": "Aetna",
"stediPayerId": "AETNA",
"submittedPayerIdOrAlias": "60054"
},
"provider": {
"id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"name": "Test Medical Provider",
"npi": "9876543210",
"taxId": "987654321",
"taxIdType": "EIN"
},
"reason": "Waiting for provider action",
"requestedEffectiveDate": "20250801",
"source": "API",
"status": "PROVIDER_ACTION_REQUIRED",
"statusLastUpdatedAt": "2025-04-22T14:45:00Z",
"submittedAt": "2025-04-20T08:20:00Z",
"tasks": [
{
"definition": {
"followInstructions": {
"instructions": "Log in to your Authority's portal and request clearinghouse access for Stedi."
}
},
"id": "f8e7d6c5-b4a3-9281-7654-321098765432",
"isComplete": false,
"rank": 1,
"responsibleParty": "PROVIDER"
},
{
"completedAt": "2026-11-08T06:14:22Z",
"definition": {
"provideFilledPdf": {
"instructions": "Please download the PDF, fill it out, and upload the completed version to this enrollment request."
}
},
"id": "019ce833-b234-75f1-9599-0f14ba643709",
"isComplete": true,
"rank": 0,
"responseData": {
"pdfUpload": {
"documentId": "dc6665a5-7b97-4agh-8c74-a00a336c2989",
"fileName": "pdf-agreement.pdf"
}
},
"responsibleParty": "PROVIDER"
}
],
"transactions": {
"eligibilityCheck": {
"enroll": true
}
},
"updatedAt": "2025-04-25T10:30:00Z"
}
],
"nextPageToken": "945ff6de213d3ef481d028065d4c12fb996a166a3a90ef98564318decfae50ce4b36d74b7e9d9bafa6e1d169",
"totalCount": 42
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
QuotaExceededException 429 response
**Schema:** `QuotaExceededExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# List Providers
Source: https://www.stedi.com/docs/healthcare/api-reference/get-enrollment-list-providers
This endpoint retrieves all of the provider records in your Stedi account. You can filter the results by the provider's name, NPI, or tax ID.
This endpoint returns only the provider record; it doesn't include information about associated [transaction enrollments](/healthcare/transaction-enrollment). To retrieve enrollment information, use the [List Enrollments](/healthcare/api-reference/get-enrollment-list-enrollments) endpoint.
## API Specification
Lists providers with optional filtering and pagination.
**Endpoint:** `GET /providers`
**Base URL:** `https://enrollments.us.stedi.com/2024-09-01`
### Parameters
- **`pageSize`** (query): The maximum number of elements to return in a page. If not specified, the default is 100.
- Type: `number`
- **`pageToken`** (query): The `nextPageToken` value from a previous response. You can use this to get the next page of results. If not set, Stedi returns the first page of results.
- Type: `string`
- **`filter`** (query): Filter for providers with properties matching a query string. You can provide all or part of a provider name, NPI, or tax ID. The search is case-insensitive and supports fuzzy matching.
For example, providing `?filter=OS` returns providers with names containing `os` (such as `Joseph`).
- Type: `string`
- **`providerNpis`** (query): Filter for providers with NPIs matching any value in this list.
- Type: `array`
- **`providerTaxIds`** (query): Filter for providers with tax IDs matching any value in this list.
- Type: `array`
### Responses
#### 200
ListProviders 200 response
**Schema:** `ListProvidersResponseContent`
**Properties:**
- **`items`** (`array`): Details about every provider your organization has created within Stedi.
- Items schema: `ProviderSummary`
- **`nextPageToken`** (`string`): Token that you can supply in subsequent requests to retrieve the next page of results. If not returned, there are no more results.
**Example:**
```json
{
"items": [
{
"id": "10334e76-f073-4b5d-8984-81d8e5107857",
"name": "BDQ Dental Inc",
"npi": "1999999992",
"taxId": "555123456",
"taxIdType": "EIN"
},
{
"id": "10234e76-f067-4b5d-8984-81d8e5107123",
"name": "Example Medical Associates",
"npi": "1999999984",
"taxId": "100100111",
"taxIdType": "EIN"
}
]
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
QuotaExceededException 429 response
**Schema:** `QuotaExceededExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Retrieve Provider
Source: https://www.stedi.com/docs/healthcare/api-reference/get-enrollment-provider
This endpoint allows you to retrieve details for the specified provider.
## API Specification
Retrieves a provider record by its ID. This operation returns the complete provider details including contact information.
**Endpoint:** `GET /providers/{providerId}`
**Base URL:** `https://enrollments.us.stedi.com/2024-09-01`
### Parameters
- **`providerId`** (path) (required): The unique ID Stedi assigned to the provider when it was created in the system.
- Type: `string`
### Responses
#### 200
GetProvider 200 response
**Schema:** `GetProviderResponseContent`
**Properties:**
- **`contacts`** (`array`): The contact information for the provider. These contacts appear as prepopulated options for contact information when creating enrollment requests for this provider in the Stedi portal. They aren't automatically added to enrollment requests.
These contacts should specify where payers should send communications about the enrollment, if needed.
- Items schema: `ProviderContact`
- **`createdAt`** (`string`): The date and time Stedi created the provider record.
- **`id`** (`string`) (required): A unique identifier Stedi assigns to this provider.
- **`name`** (`string`) (required): The provider's business name. This is typically the provider's practice name, such as `Dental Associates, LLC`, but it can also be the provider's first and last name.
- **`npi`** (`string`) (required): The provider's [National Provider Identifier (NPI)](https://npiregistry.cms.hhs.gov/search). This is a 10-digit number that is unique to the provider.
- **`taxId`** (`string`): The provider's tax ID, as specified by `taxIdType`. This identifier is formatted without any separators, such as dashes or spaces. For example 111-22-3333 is represented as `111223333`.
- **`taxIdType`** (`object`): The type of tax ID. Can be either an `EIN` - Employer Identification Number, or an `SSN` - Social Security Number.
- **`updatedAt`** (`string`): The date and time Stedi last updated the provider record.
**Example:**
```json
{
"contacts": [
{
"city": "Chevy Chase",
"email": "bob@fortdental.center",
"firstName": "Bob",
"lastName": "Dentist",
"organizationName": "",
"phone": "5551234567",
"state": "MD",
"streetAddress1": "123 Some Str",
"zipCode": "20814"
},
{
"city": "Chevy Chase",
"email": "tom@fortdental.center",
"firstName": "Tom",
"lastName": "Dentist",
"organizationName": "",
"phone": "5551234568",
"state": "MD",
"streetAddress1": "123 Some Str",
"zipCode": "20814"
}
],
"createdAt": "2024-11-18T17:39:52.406Z",
"id": "10334e76-f073-4b5d-8984-81d8e5107857",
"name": "BDQ Dental Inc",
"npi": "1999999992",
"taxId": "555123456",
"taxIdType": "EIN",
"updatedAt": "2024-11-18T17:39:52.406Z"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
QuotaExceededException 429 response
**Schema:** `QuotaExceededExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Retrieve Enrollment
Source: https://www.stedi.com/docs/healthcare/api-reference/get-enrollment
This endpoint retrieves details for the specified [transaction enrollment](/healthcare/transaction-enrollment).
## API Specification
Retrieves an enrollment request by its ID. This operation returns the complete enrollment details including provider and payer information.
**Endpoint:** `GET /enrollments/{enrollmentId}`
**Base URL:** `https://enrollments.us.stedi.com/2024-09-01`
### Parameters
- **`enrollmentId`** (path) (required): The Stedi-assigned identifier for the enrollment you want to retrieve.
- Type: `string`
### Responses
#### 200
GetEnrollment 200 response
**Schema:** `GetEnrollmentResponseContent`
**Properties:**
- **`aggregationPreference`** (`object`): Preference for how the payer should group 835 Electronic Remittance Advice (ERA) transactions. This property is only returned for 835 ERA enrollments.
- If not set, Stedi automatically selects a default based on the payer's supported aggregation types and the available identifiers for the provider.
- Stedi attempts to enroll with this preference, but it's not guaranteed. Each payer has its own restrictions and behaviors.
- This property isn't returned for enrollment records created before Stedi added support for aggregation preferences.
- **`createdAt`** (`string`) (required): The date and time when the enrollment was created within Stedi.
- **`documents`** (`array`): Documents associated with this enrollment, such as signed enrollment forms. This list doesn't include deleted documents.
Each document object contains metadata such as the document's name, status, and timestamps for creation and last update.
- Items schema: `EnrollmentDocument`
- **`history`** (`array`): The history of updates to this enrollment, such as status changes. This property is experimental and may change in the future.
- Items schema: `EnrollmentHistoryEntry`
- **`id`** (`string`) (required): The Stedi-assigned identifier for the enrollment request.
- **`lastEraReceivedAt`** (`string`): The timestamp of the most recent 835 ERA (Electronic Remittance Advice) Stedi received for this enrollment, based on the enrollment's payer ID, provider NPI, and provider tax ID. Stedi automatically updates this property for each new ERA.
- This property is only returned for ERA enrollments in `LIVE` status with at least one matching ERA from the payer.
- If this timestamp doesn't match your expected timeline for ERA processing, there may be an upstream issue. Contact Stedi support for assistance.
- **`payer`** (`object`) (required): Information about the payer the provider is enrolling with.
- **`primaryContact`** (`object`) (required): The contact information for the provider. This is where the payer will send communications about the enrollment, if needed.
- **`provider`** (`object`) (required): Information about the provider enrolling with the payer.
- **`providerTransactionAccessNumber`** (`string`): This property is required for payers that require a Provider Transaction Access Number (PTAN).
The PTAN is a Medicare-issued number given to providers upon enrollment with Medicare. This number is usually six digits and is assigned based on the type of service and the location of the provider. Upon enrollment, Medicare Administrating Contracting (MAC) providers should receive their assigned PTAN number in their approval letter.
- **`reason`** (`string`): Reasons why the enrollment request is still in `PROVISIONING` status, may take additional time to process, or was rejected by the payer. Only Stedi can set or update this property.
- **`requestedEffectiveDate`** (`string`): The requested effective date for the enrollment in YYYYMMDD format. This is the date the submitter would like the enrollment to take effect with the payer. If not provided during submission, Stedi defaults to the enrollment's submission date.
Not all payers support requested effective dates. Stedi can't guarantee that the enrollment will be effective with the payer on this exact date.
- **`source`** (`object`): The source of this enrollment.
- **`status`** (`object`): The status of the enrollment. You can submit enrollments with either `DRAFT` or `STEDI_ACTION_REQUIRED` status. The default status is `DRAFT` if not specified. When you're ready for Stedi to begin processing the enrollment, set the status to `STEDI_ACTION_REQUIRED`. Once an enrollment is `STEDI_ACTION_REQUIRED`, only Stedi can set or update its status.
- `DRAFT` - You're still editing the enrollment and haven't submitted it to Stedi.
- `STEDI_ACTION_REQUIRED` - You have submitted the enrollment and it is ready for Stedi to begin processing.
- `PROVIDER_ACTION_REQUIRED` - The enrollment requires action from the healthcare provider to proceed, such as providing additional documentation. Stedi will add a note to your enrollment request with clear instructions.
- `SUBMITTED` - (Deprecated) Legacy status being phased out in favor of the more specific action-required statuses. If you set an enrollment request to `SUBMITTED`, Stedi treats it as `STEDI_ACTION_REQUIRED`.
- `PROVISIONING` - Stedi has begun the process of completing the enrollment with the payer.
- `LIVE` - The enrollment process is complete, and the specified provider can begin exchanging the listed transaction types with the payer.
- `REJECTED` - The payer rejected the enrollment. Common reasons for rejection include incorrect details in the request and that the provider is not credentialed with the payer. Customer support will contact you with reasons for rejection and next steps.
- `CANCELED` - The enrollment has been terminated per customer or provider request.
- **`statusLastUpdatedAt`** (`string`) (required): The date and time when the enrollment status was last updated. This timestamp is used to track enrollment processing durations and enables filtering to identify recently changed enrollments. It automatically updates whenever an enrollment's status changes but remains unchanged during other updates.
- **`submittedAt`** (`string`): The date and time when the enrollment was submitted. If the enrollment is in `DRAFT` status, `submittedAt` is not present. When the enrollment transitions from draft to `STEDI_ACTION_REQUIRED`, `submittedAt` is updated to the submission time. If the enrollment was created and submitted immediately, the `submittedAt` time will be equal or close to the `createdAt` time.
- **`tasks`** (`array`): Tasks associated with this enrollment representing work that needs to be completed. Each task has a responsible party and specific definition.
- Items schema: `Task`
- **`transactions`** (`object`) (required): The type of transactions included in the enrollment.
- **`updatedAt`** (`string`) (required): The date and time when the enrollment was updated.
- **`userEmail`** (`string`) (required): The email address where Stedi should send updates about the enrollment. We'll use it to notify you when there are next steps and send updates on the enrollment's status.
- This email address can be different from the `primaryContact.email` where the payer sends communications about the enrollment.
- For [automatic enrollment requests](https://www.stedi.com/docs/healthcare/create-manage-transaction-enrollments#automatic-enrollment-requests), Stedi sets this to the oldest account member with the Admin role.
**Example:**
```json
{
"createdAt": "2023-11-07T05:31:56Z",
"documents": [
{
"createdAt": "2026-11-08T12:00:00Z",
"enrollmentId": "db6675c5-7bg7-4af9-8c68-a54a336d2911",
"id": "dc6665a5-7b97-4agh-8c74-a00a336c2989",
"name": "pdf-agreement.pdf",
"status": "UPLOADED",
"updatedAt": "2026-11-08T12:05:00Z"
}
],
"history": [
{
"changedAt": "2026-11-07T05:31:56Z",
"changedBy": "user@example.com",
"newStatus": "DRAFT",
"type": "STATUS_CHANGE"
},
{
"changedAt": "2026-11-07T05:31:56Z",
"changedBy": "user@example.com",
"newStatus": "STEDI_ACTION_REQUIRED",
"previousStatus": "DRAFT",
"type": "STATUS_CHANGE"
},
{
"changedAt": "2026-11-07T06:15:22Z",
"changedBy": "system",
"newStatus": "PROVIDER_ACTION_REQUIRED",
"previousStatus": "STEDI_ACTION_REQUIRED",
"type": "STATUS_CHANGE"
},
{
"changedAt": "2026-11-08T06:15:22Z",
"changedBy": "system",
"newStatus": "STEDI_ACTION_REQUIRED",
"previousStatus": "PROVIDER_ACTION_REQUIRED",
"type": "STATUS_CHANGE"
},
{
"changedAt": "2026-11-10T06:15:22Z",
"changedBy": "system",
"newStatus": "PROVIDER_ACTION_REQUIRED",
"previousStatus": "STEDI_ACTION_REQUIRED",
"type": "STATUS_CHANGE"
}
],
"id": "db6675c5-7bg7-4af9-8c68-a54a336d2911",
"payer": {
"name": "UnitedHealthcare",
"stediPayerId": "KMQTZ",
"submittedPayerIdOrAlias": "87726"
},
"primaryContact": {
"city": "A City",
"email": "test@example.com",
"firstName": "John",
"lastName": "Doe",
"phone": "5551234567",
"state": "MD",
"streetAddress1": "123 Some Str.",
"zipCode": "20814"
},
"provider": {
"id": "db6665c5-7b97-4af9-8c68-a00a336c2998",
"name": "Test Medical Provider",
"npi": "1234567890",
"taxId": "123456789",
"taxIdType": "EIN"
},
"requestedEffectiveDate": "20231107",
"source": "API",
"status": "PROVIDER_ACTION_REQUIRED",
"statusLastUpdatedAt": "2023-11-07T06:15:22Z",
"submittedAt": "2023-11-07T05:31:56Z",
"tasks": [
{
"definition": {
"followInstructions": {
"instructions": "Log in to your Authority's portal and request clearinghouse access for Stedi."
}
},
"id": "ac6665a5-7b97-4agh-8c74-a00a336c2989",
"isComplete": false,
"rank": 1,
"responsibleParty": "PROVIDER"
},
{
"completedAt": "2026-06-01T12:00:00Z",
"definition": {
"provideFilledPdf": {
"instructions": "Please download the PDF, fill it out, and upload the completed version to this enrollment request."
}
},
"id": "019ce833-b234-75f1-9599-0f14ba643709",
"isComplete": true,
"rank": 0,
"responseData": {
"pdfUpload": {
"documentId": "dc6665a5-7b97-4agh-8c74-a00a336c2989",
"fileName": "pdf-agreement.pdf"
}
},
"responsibleParty": "PROVIDER"
}
],
"transactions": {
"professionalClaimSubmission": {
"enroll": true
}
},
"updatedAt": "2023-11-07T05:31:56Z",
"userEmail": "test@example.com"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
QuotaExceededException 429 response
**Schema:** `QuotaExceededExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# 835 ERA PDF
Source: https://www.stedi.com/docs/healthcare/api-reference/get-era-pdf
This endpoint uses an 835 Electronic Remittance Advice (ERA) `transactionId` to retrieve its associated PDF file.
Stedi autogenerates a PDF file for each processed 835 ERA. The PDF contains a human-readable version of the ERA, including payment details, adjustments, and explanations for each service line. It resembles the Standard Paper Remittance (SPR) format that the Centers for Medicare and Medicaid Services (CMS) uses for ERA PDFs, regardless of which payer sent the ERA.
1. Call this endpoint with the `transactionId` path parameter set to the 835 ERA's transaction ID. This ID is included in the transaction processed event for the 835 ERA, which you can receive automatically through Stedi [webhooks](/healthcare/configure-webhooks). You can also retrieve this ID through the [Poll Transactions](/healthcare/api-reference/get-poll-transactions) endpoint or from the transaction's details page within the Stedi portal.
2. By default, the endpoint returns the PDF as a base64-encoded string. To receive the unencoded PDF data, include the `Accept: application/pdf` request header.
To view the PDF, save the PDF data to a file with a `.pdf` extension.
This is a PDF representation of the 835 ERA - it's not the same as an Explanation of Benefits (EOB) that you may receive from the payer.
## API Specification
Retrieve the generated PDF of an 835 Electronic Remittance Advice (ERA).
**Endpoint:** `GET /electronic-remittance-advice/{transactionId}/pdf`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Parameters
- **`transactionId`** (path) (required): A unique identifier for the Electronic Remittance Advice (ERA) within Stedi. This ID is included in the transaction processed event for the ERA, which you can receive automatically through Stedi [webhooks](https://www.stedi.com/docs/healthcare/configure-webhooks). You can also retrieve this ID through the [Poll Transactions endpoint](https://www.stedi.com/docs/healthcare/api-reference/get-poll-transactions) or from the transaction's details page within Stedi.
- Type: `string`
- **`logo`** (query): If false, the generated PDF will not include the Stedi logo in the footer. The default is true.
- Type: `boolean`
### Responses
#### 200
GetElectronicRemittanceAdvicePdf 200 response
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`code`** (`string`): A code describing the type of validation failure.
- **`message`** (`string`) (required): A message describing the causes of the validation failure. There may be more than one.
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# Retrieve Event
Source: https://www.stedi.com/docs/healthcare/api-reference/get-event-destinations-event
This endpoint retrieves the full details of the specified event. You can use it as part of your workflow to [manually process undelivered events](/healthcare/event-destinations-message-handling#process-undelivered-events) as needed.
1. Call this endpoint with the event's ID. This ID returned as the `items[].id` property in the [List Events](/healthcare/api-reference/get-event-destinations-list-events) endpoint response.
2. Stedi returns the event details, including the event type, event status, creation date, and full event payload.
## API Specification
Retrieves the details of an existing event by its identifier.
**Endpoint:** `GET /events/{eventId}`
**Base URL:** `https://events.us.stedi.com/2026-02-01`
### Parameters
- **`eventId`** (path) (required): The unique identifier for the event, formatted as `evt_{UUID}`.
- Type: `string`
### Responses
#### 200
GetEvent 200 response
**Schema:** `GetEventResponseContent`
**Properties:**
- **`createdAt`** (`string`) (required): An ISO 8601 timestamp of when the event was created.
- **`eventPayload`** (`object`) (required): The event payload Stedi delivers to event destinations.
- **`eventType`** (`string`) (required): The type of event, such as `enrollment.activated`.
- **`id`** (`string`) (required): The unique identifier for the event, formatted as `evt_{UUID}`.
- **`status`** (`object`) (required): The current status of the event. Can be:
- `DELIVERED`: Stedi successfully delivered the event to all relevant event destinations.
- `PENDING`: Stedi is still trying to deliver the event to one or more event destinations. Events may stay in this state for multiple days as Stedi automatically retries.
- `FAILED`: Stedi couldn't deliver the event to at least one event destination and is no longer retrying. Deliveries to some event destinations may have been successful.
**Example:**
```json
{
"createdAt": "2026-02-01T12:00:00Z",
"eventPayload": {
"v1Event": {
"account": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"created": "2026-02-01T12:00:00.000Z",
"environment": "PRODUCTION",
"id": "evt_550e8400-e29b-41d4-a716-446655440000",
"object": "v1.event",
"resource": {
"id": "enr_661f9511-f3ac-52e5-b827-557766551111",
"type": "enrollment"
},
"type": "enrollment.activated"
}
},
"eventType": "enrollment.activated",
"id": "evt_550e8400-e29b-41d4-a716-446655440000",
"status": "DELIVERED"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`)
- **`message`** (`string`) (required)
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# List Events
Source: https://www.stedi.com/docs/healthcare/api-reference/get-event-destinations-list-events
This endpoint retrieves a list of events generated within your Stedi account. By default, it returns all events regardless of delivery status for the past 30 days. You can use it to [recover from delivery failures](/healthcare/event-destinations-message-handling#process-undelivered-events) and [check for processing errors](/healthcare/event-destinations-message-handling#check-for-processing-errors).
1. Call this endpoint with one or more query parameters to filter the results. You can filter by event type, delivery status, or created date.
2. Stedi returns the a list of events matching the criteria. You can use the `items[].id` value with the [Retrieve Event](/healthcare/api-reference/get-event-destinations-event) endpoint to retrieve the full payload for each event.
## API Specification
Lists all events for your account. Results are paginated.
**Endpoint:** `GET /events`
**Base URL:** `https://events.us.stedi.com/2026-02-01`
### Parameters
- **`pageSize`** (query): The maximum number of elements to return in a page. If not specified, the default is 100.
- Type: `number`
- **`pageToken`** (query): The `nextPageToken` value from a previous response. You can use this to get the next page of results. If not set, Stedi returns the first page of results.
- Type: `string`
- **`eventId`** (query): Filter results by event ID, such as `evt_019d554b-311b-7813-b491-0a8973762eae`.
- Type: `string`
- **`status`** (query): Filter results by one or more event statuses. Can be:
- `DELIVERED`: Stedi successfully delivered the event to all relevant event destinations.
- `PENDING`: Stedi is still trying to deliver the event to one or more event destinations.
- `FAILED`: Stedi couldn't deliver the event to at least one event destination and is no longer retrying.
- Type: `array`
- **`eventType`** (query): Filter results by event type, such as `enrollment.activated`.
- Type: `string`
- **`created`** (query): Filter results by their `createdAt` timestamp. Each value is in the format `operator:ISO-8601-timestamp`.
- The supported operators are `gt` (after), `gte` (at or after), `lt` (before), and `lte` (at or before). For example: Setting this to `lt:2024-02-01T00:00:00Z` filters for events created before the specified timestamp.
- Combine multiple values with `&` to specify a date range. For example: `created=gt:2026-01-01T00:00:00Z&created=lt:2026-02-01T00:00:00Z`.
- Type: `array`
### Responses
#### 200
ListEvents 200 response
**Schema:** `ListEventsResponseContent`
**Properties:**
- **`items`** (`array`) (required): The list of event summaries.
- Items schema: `EventSummary`
- **`nextPageToken`** (`string`): Token that you can supply in subsequent requests to retrieve the next page of results. If not returned, there are no more results.
**Example:**
```json
{
"items": [
{
"createdAt": "2026-02-01T12:00:00Z",
"eventType": "enrollment.activated",
"id": "evt_550e8400-e29b-41d4-a716-446655440000",
"status": "DELIVERED"
}
]
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Retrieve File Execution Input
Source: https://www.stedi.com/docs/healthcare/api-reference/get-execution-input
This endpoint retrieves a file execution's input document before it passes through any translation or mappings. You can use it to retrieve 277CA claim acknowledgments or 835 Electronic Remittance Advice (ERAs) in X12 EDI format.
1. Call this endpoint with the file execution ID for the transaction you want to retrieve. This is returned as the `items[].fileExecutionId` in the [List Transactions](/healthcare/api-reference/get-list-transactions) and [Poll Transactions](/healthcare/api-reference/get-poll-transactions) endpoint responses.
2. The endpoint returns a `302` temporary redirect to the document download URL. Many HTTP clients will automatically follow this redirect, or have a simple follow redirects configuration to set. For example, the `-L` or `--location` flags in cURL requests will automatically follow the redirect. In this case, the response contains the full input document.
If your implementation doesn't automatically follow the redirect, the response body contains a pre-signed URL in the `documentDownloadUrl` property. This URL is available for 60 minutes.
3. If required, make a `GET` request to download the input document from the `documentDownloadUrl`.
```bash
curl --request GET \
--url "" \
--output /path/to/file.txt
```
There are no size restrictions on documents when fetching from this endpoint.
## Input document format [#input-document-format]
The input document can be in either X12 EDI or JSON format, depending on the source. For example:
* If you send an 837 claim to one of Stedi's JSON endpoints, the input document will be in JSON format.
* If a payer sends you a 277CA claim acknowledgment or an 835 Electronic Remittance Advice (ERA), the input document will be in the original X12 EDI format, including the envelope.
```txt
ISA*00* *00* *ZZ*STEDITEST *ZZ*599264680681 *260403*2042*^*00501*000001520*0*T*`~GS*HN*STEDITEST*599264680681*20260403*204210*1520*X*005010X214~ST*277*0001*005010X214~BHT*0085*08*01KNAH9X25NM7JFSDAV1D5MXTW*20260403*204209*TH~HL*1**20*1~NM1*AY*2*STEDI INC*****46*117151744~TRN*1*01KNAH9X25NM7JFSDAV1D5MXTW~DTP*050*D8*20260403~DTP*009*D8*20260403~HL*2*1*21*1~NM1*41*2*Test Data Health Services, Inc.*****46*123435~TRN*2*01KHCBK84E40QQYJVXA5VVXG54~STC*A0`17`AY*20260403*WQ*109.2~QTY*90*1.0~AMT*YU*109.2~HL*3*2*19*1~NM1*85*2*Therapy Associates*****XX*1999999984~TRN*1*0~REF*TJ*123456789~QTY*QA*1.0~AMT*YU*109.2~HL*4*3*PT*0~NM1*QC*1*Anon*John****MI*U7777788888~TRN*2*123456789~STC*A1`20*20260403*WQ*109.2~REF*D9*DO68G47DYWKAUD72Y6U7~DTP*472*RD8*20240101-20240101~SE*26*0001~GE*1*1520~IEA*1*000001520~
```
```txt
ISA*00* *00* *ZZ*STEDITEST *ZZ*599264680681 *260403*1853*^*00501*000001519*0*T*>~GS*HP*STEDITEST*599264680681*20260403*185323*1519*X*005010X221A1~ST*835*0001~BPR*I*109.2*C*ACH************20260403~TRN*1*01KNAB2Q1HV0NV9PSFSEW8YBKS*1234567890~DTM*405*20260403~N1*PR*Stedi Test Payer*XV*STEDI~N3*228 PARK AVE S*STE 58460~N4*NEW YORK*NY*10003-1502~REF*EO*234567890~PER*BL~N1*PE*Therapy Associates*XX*1999999984~N3*123 Some St*Floor 1~N4*A City*NY*123450000~REF*TJ*333445678~LX*1~CLP*1111222223333*1*109.2*109.2*.0*ZZ*01KNAB2Q1HHKVCDS6T205GF09J*02*1~NM1*QC*1*Anon*John****MI*U7777788888~DTM*232*20240101~SVC*HC>90837>95*109.2*109.2**1.0*HC>90837>95*1.0~DTM*472*20240101~REF*6R*111222333~SE*21*0001~GE*1*1519~IEA*1*000001519~
```
## API Specification
Fetch a file execution's input document before any translation and mappings.
**Endpoint:** `GET /executions/{executionId}/input`
**Base URL:** `https://core.us.stedi.com/2023-08-01`
### Parameters
- **`executionId`** (path) (required): A unique identifier for the file execution within Stedi. This ID is included in the file processed event, or you can retrieve it manually from the file's details page within the Stedi portal.
- Type: `string`
### Responses
#### 302
GetExecutionInputDocument 302 response
**Schema:** `GetExecutionInputDocumentResponseContent`
**Properties:**
- **`documentDownloadUrl`** (`string`): A URL to download the document. This URL is available for 60 minutes.
**Example:**
```json
{
"documentDownloadUrl": "https://stedi-default-core-artifacts.s3.us-east-1.amazonaws.com/write/input/06bdccdc-4aaa-4aaa..."
}
```
#### 400
BadRequestException 400 response
**Schema:** `BadRequestExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 409
ResourceUnderChangeException 409 response
**Schema:** `ResourceUnderChangeExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
#### 422
UnprocessableEntityException 422 response
**Schema:** `UnprocessableEntityExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 500
ServiceException 500 response
**Schema:** `ServiceExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`exceptionCause`** (`object`)
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
# Retrieve Batch Check Statuses
Source: https://www.stedi.com/docs/healthcare/api-reference/get-healthcare-batch-eligibility-check-statuses
This endpoint retrieves the processing status and other summary information for all of the eligibility checks in the specified batch. It doesn't include the complete eligibility response. For the full results of each eligibility check, call the [Poll Batch Checks](/healthcare/api-reference/get-healthcare-polling-eligibility) endpoint instead.
You can use this endpoint to determine whether specific eligibility checks within a batch have completed. You can also use the response to determine whether patients have active or inactive coverage without having to poll.
1. Call this endpoint with the batch ID for the eligibility check batch. This is the `batchId` Stedi returned in the [Batch Eligibility Checks](/healthcare/api-reference/post-healthcare-batch-eligibility) endpoint response. It's also available on the batch's details page in the Stedi portal.
2. Stedi returns information about the processing status of each eligibility check within the batch, including whether the check completed successfully and information about the patient's coverage status (`eligibilitySearchStatus`). Each `item` in the response corresponds to one eligibility check within the batch.
## API Specification
Retrieve status information for all eligibility checks within a batch, regardless of processing status
**Endpoint:** `GET /eligibility-manager/batch/{batchId}/items`
**Base URL:** `https://manager.us.stedi.com/2024-04-01`
### Parameters
- **`batchId`** (path) (required): The unique identifier for the batch. This is the `batchId` returned in the Batch Eligibility Check endpoint response. It's also listed as the **Batch ID** in the Stedi portal.
- Type: `string`
- **`pageSize`** (query): The maximum number of elements to return in a page. If not specified, the default is 100.
- Type: `integer`
- **`pageToken`** (query): A token returned by a previous call to this operation in the `nextPageToken` property. If not specified, Stedi returns the first page of results.
- Type: `string`
- **`state`** (query): Filter for batch items in the specified states. Can be set to one or more of the following states:
- `PENDING`: Stedi hasn't begun processing the eligibility check.
- `VALIDATED`: Stedi finished validating the eligibility check and is ready to execute it.
- `VALIDATION_FAILED`: Stedi found errors in the eligibility check that you need to fix before processing can continue.
- `STARTED`: Stedi has begun processing the eligibility check.
- `RETRYING`: Stedi is retrying the eligibility check. Stedi retries eligibility checks that fail due to payer connectivity issues for up to 8 hours.
- `COMPLETED`: Stedi successfully processed the eligibility check and received a response from the payer. This doesn't indicate that the payer has active coverage, only that Stedi was able to get a response.
- `COMPLETED_WITH_ERRORS`: Stedi finished processing the eligibility check, but couldn't get a response from the payer.
- Type: `array`
- **`eligibilitySearchOutcome`** (query): Filter for batch items with the specified eligibility search outcomes.
Stedi groups retries (if present) for each eligibility check into an eligibility search. The eligibility search outcome reflects the `eligibilitySearchStatus` after the last retry attempt.
This filter is only relevant for batch items in `COMPLETED` state, which means Stedi has either received a response from the payer or has finished retrying. In-progress items, such as those in `PENDING` state, don't have an eligibility search outcome.
Can be set to one more of the following outcomes:
- `active`: The payer's response contains an active eligibility and benefit type. This means that the patient has active coverage for at least some services.
- `inactive`: The payer's response doesn't contain an active eligibility and benefit type. This means that the patient doesn't have active coverage for the requested services.
- `failed`: The payer returned an error code in the response.
- Type: `array`
### Responses
#### 200
GetBatchItems 200 response
**Schema:** `GetBatchItemsResponseContent`
**Properties:**
- **`items`** (`array`): A list of batch items. Each `item` represents a single eligibility check in the batch. Unlike the polling endpoint, which only returns results for completed eligibility checks, this endpoint returns results for all eligibility checks in the batch, regardless of their processing status.
All batch items may not be returned in a single response; use the `nextPageToken` to retrieve subsequent pages of results.
- Items schema: `BatchItem`
- **`nextPageToken`** (`string`): Token that you can supply in subsequent requests to retrieve the next page of results. If not returned, there are no more results.
**Example:**
```json
{
"items": [
{
"additionalInfo": {
"eligibility": {
"eligibilitySearchId": "01932c61-2d4f-7d22-85fa-c7db2e13e771",
"eligibilitySearchStatus": "active",
"payerId": "BCBS",
"submitterTransactionIdentifier": "ABC123456789",
"subscriberFirstName": "John",
"subscriberLastName": "Doe",
"subscriberMemberId": "123456789"
}
},
"batchId": "01932c61-2d4f-7d22-85fa-c7db2e13e771",
"createdAt": "2025-03-31T14:25:30Z",
"requestId": "req-01a2b3c4-d5e6-7f89-0123-456789abcdef",
"rowNumber": 1,
"state": "COMPLETED",
"updatedAt": "2025-03-31T14:26:45Z"
},
{
"additionalInfo": {
"eligibility": {
"eligibilitySearchId": "01932c61-2d4f-7d22-85fa-c7db2e13e772",
"eligibilitySearchStatus": "failed",
"payerId": "AETNA",
"submitterTransactionIdentifier": "GHJ987654321",
"subscriberFirstName": "Jane",
"subscriberLastName": "Smith",
"subscriberMemberId": "987654321"
}
},
"batchId": "01932c61-2d4f-7d22-85fa-c7db2e13e771",
"createdAt": "2025-03-31T14:25:30Z",
"requestId": "req-02a2b3c4-d5e6-7f89-0123-456789abcdef",
"rowNumber": 2,
"state": "COMPLETED_WITH_ERRORS",
"updatedAt": "2025-03-31T14:27:15Z"
}
],
"nextPageToken": "945ff6de213d3ef481d028065d4c12fb996a166a3a90ef98564318decfae50ce4b36d74b7e9d9bafa6e1d169"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Retrieve Batch Status
Source: https://www.stedi.com/docs/healthcare/api-reference/get-healthcare-batch-eligibility-status
This endpoint retrieves the processing status of an eligibility check batch you submitted through the asynchronous [Batch Eligibility Checks](/healthcare/api-reference/post-healthcare-batch-eligibility) endpoint or through [CSV upload](/healthcare/batch-refresh-eligibility-checks#manual-submission) in the Stedi portal.
You can use this endpoint to determine when to start polling for the results of the eligibility checks within the batch. For example, don't start polling until either the `successCount` or the `errorCount` are greater than zero because these indicate checks that Stedi has finished processing. You can also use this endpoint to monitor the progress of large batches and confirm that all checks have been completed.
1. Call this endpoint with the batch ID for the eligibility check batch. This is the `batchId` Stedi returned in the [Batch Eligibility Checks](/healthcare/api-reference/post-healthcare-batch-eligibility) endpoint response. It's also available on the batch's details page in the Stedi portal.
2. Stedi returns a summary of the batch's processing status, including the number of completed checks, the error count, and the overall batch status.
## API Specification
Retrieve the status of an eligibility check batch submitted through the API or CSV upload
**Endpoint:** `GET /eligibility-manager/batch/{batchId}`
**Base URL:** `https://manager.us.stedi.com/2024-04-01`
### Parameters
- **`batchId`** (path) (required): The unique identifier for the batch. This is the `batchId` returned in the Batch Eligibility Check endpoint response. It's also listed as the **Batch ID** in the Stedi portal.
- Type: `string`
### Responses
#### 200
GetBatch 200 response
**Schema:** `GetBatchResponseContent`
**Properties:**
- **`batchType`** (`object`) (required): The type of batch. Currently only supports eligibility.
- **`createdAt`** (`string`) (required): The date and time when the batch was created.
- **`errorCount`** (`integer`): The number of eligibility checks that failed during processing. A failure means that Stedi successfully processed the check but didn't receive a response from the payer, even after retrying. A common reason for failure is payer connectivity issues.
- **`id`** (`string`) (required): The unique identifier for the batch. This is the `batchId` returned in the Batch Eligibility Check endpoint response. It's also listed as the **Batch ID** in the Stedi portal.
- **`importUrl`** (`string`): The URL to download the original CSV file. Only relevant for batches submitted through CSV upload in the Stedi portal.
- **`inProgressCount`** (`integer`): The number of eligibility checks that are currently in progress (started or retrying).
- **`maxRetryHours`** (`integer`): The maximum number of hours that Stedi will retry eligibility checks in this batch that fail due to payer connectivity issues. This is the value that was set when the batch was created. Only applicable to batches submitted through the API.
- **`name`** (`string`) (required): The name assigned to the batch upon creation. For CSV uploads, this is the name you provided when uploading the file. For API submissions, this is the same as the `batchId`.
- **`source`** (`object`): How the batch was submitted. Can be:
- `API`: The batch was submitted through the Batch Eligibility Check endpoint.
- `CSV_IMPORT`: The batch was submitted through CSV upload in the Stedi portal.
- **`status`** (`object`) (required): The status of the batch. Can be:
- `PENDING`: Stedi created the batch and is waiting for the CSV file to finish uploading.
- `VALIDATED`: Stedi finished validating the batch and is ready to start executing it.
- `VALIDATION_FAILED`: Stedi found errors in the batch submission that you need to fix before processing can continue. This is usually due to malformed CSV data.
- `IN_PROGRESS`: Stedi is processing the batch. Some eligibility checks in the batch may be complete while others are still in progress.
- `COMPLETED`: Stedi finished processing all items in the batch successfully. This doesn't mean that all eligibility checks successfully returned benefits information, only that Stedi successfully sent them to the payers and received responses.
- `COMPLETED_WITH_ERRORS`: Stedi finished processing all eligibility checks in the batch, but some failed. A common reason for failure is payer connectivity issues.
- **`successCount`** (`integer`): The number of eligibility checks that were successfully completed. This means that Stedi successfully sent the check to the payer and received a response, but doesn't indicate whether the payer returned benefits information.
- **`totalCount`** (`integer`): The total number of eligibility checks in the batch. In the case of CSV uploads, one row in the CSV file corresponds to one eligibility check.
- **`updatedAt`** (`string`) (required): The date and time when the batch was last updated.
- **`validatedCount`** (`integer`): The number of eligibility checks that Stedi has validated.
- **`validationFailedCount`** (`integer`): The number of eligibility checks that failed validation. This is relevant to CSV uploads, where Stedi validates each row in the CSV file before processing it.
**Example:**
```json
{
"batchType": "ELIGIBILITY",
"createdAt": "2025-06-13T21:00:52.496Z",
"errorCount": 5,
"id": "01976b18-6d90-71d1-b27b-2556a9fbf837",
"importUrl": "https://s3.amazonaws.com/bucket/key",
"inProgressCount": 0,
"name": "test_CSV_upload",
"source": "CSV_IMPORT",
"status": "COMPLETED_WITH_ERRORS",
"successCount": 245,
"totalCount": 250,
"updatedAt": "2025-06-16T15:59:20.312Z"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Poll Batch Eligibility Checks (271)
Source: https://www.stedi.com/docs/healthcare/api-reference/get-healthcare-polling-eligibility
This endpoint retrieves the results of asynchronous eligibility checks you submitted through the asynchronous [Batch Eligibility Checks](/healthcare/api-reference/post-healthcare-batch-eligibility) endpoint or through [CSV upload](/healthcare/batch-refresh-eligibility-checks#manual-submission) in the Stedi portal. It doesn't return results for real-time eligibility checks.
1. Call this endpoint. You can optionally add one or more query parameters to filter the results you want to retrieve.
2. The endpoint returns completed checks matching the criteria. Stedi retries checks that fail due to [payer connectivity issues](/healthcare/eligibility-troubleshooting#payer-connectivity-issues) for 8 - 24 hours. It can take up to the configured retry period for all checks in a batch to return results.
Each `item` in the response contains the benefits information for a completed eligibility check. Note that our documentation lists all enums officially allowed in the eligibility response. Some payers return non-compliant values, which Stedi passes through as is.
## Pagination [#pagination]
By default, the response includes the results for up to 10 eligibility checks within a single page - each eligibility response is represented as one item in the `items` array. You can control the number of results returned per page using the `pageSize` query parameter, which accepts a value between 1 and 200.
When there are additional pages of results, the response includes the `nextPageToken` property. To retrieve the next page of results, call the endpoint with the same `batchId` and other query parameters, and set the `pageToken` query parameter to the `nextPageToken` value. Repeat this process until the response doesn't include a `nextPageToken` property.
If you set the page size to a value > 20, Stedi returns the requested batch check results in `gzip` format to reduce the size. Many common HTTP clients accept `gzip` by default, but if not, you must add the `Accept-Encoding: gzip` header to your request and resubmit.
## API Specification
Retrieve batch eligibility check results
**Endpoint:** `GET /eligibility-manager/polling/batch-eligibility`
**Base URL:** `https://manager.us.stedi.com/2024-04-01`
### Parameters
- **`pageSize`** (query): The maximum number of check results to return in a page - each check is represented as one item in the `items` array. If not specified, the default is 10.
- If you set the page size to a value > 20, Stedi returns the requested batch check results in `gzip` format to reduce the size. Many common HTTP clients accept `gzip` by default, but if not, you must add the `Accept-Encoding: gzip` header to your request and resubmit.
- When check results are especially large, Stedi may return fewer than the requested number per page. In these cases, you can use the `nextPageToken` property to retrieve the rest of the requested results.
- Type: `integer`
- **`pageToken`** (query): A token returned by a previous call to this operation in the `nextPageToken` property. If not specified, Stedi returns the first page of results.
- Type: `string`
- **`batchId`** (query): An identifier for a batch of eligibility checks submitted through the [Batch Eligibility Check](https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-batch-eligibility) endpoint. Use this to retrieve results for eligibility checks in the batch.
- Type: `string`
- **`startDateTime`** (query): An ISO 8601 formatted string. For example `2023-08-28T00:00:00Z`. Stedi returns asynchronous eligibility checks that have completed processing after this time. Completed means that the payer has successfully returned a benefits response, the check has failed due to errors in the request, or that the payer has been unavailable for 8 hours and Stedi will no longer attempt to retry.
- Type: `string`
### Responses
#### 200
BatchEligibilityPolling 200 response
**Schema:** `BatchEligibilityPollingResponseContent`
**Properties:**
- **`items`** (`array`) (required): Each eligibility check response is included as a separate item in this array. The response shape is identical to the shape of the response for the [Real-Time Eligibility Check](https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-eligibility) endpoint, with the addition of two new properties that help you correlate the results with individual eligibility checks.
- `batchId` contains the `batchId` Stedi returned from the [Batch Eligibility Check](https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-batch-eligibility) endpoint when making the request.
- `submitterTransactionIdentifier` contains the unique identifier for the eligibility check that you submitted in the request.
- Items schema: `BatchEligibilityResultItem`
- **`nextPageToken`** (`string`): A Stedi-generated token that you can submit in the `pageToken` query parameter to retrieve the next page of results. If there are no more results, this property is not included in the response.
**Example:**
```json
{
"items": [
{
"batchId": "01932c61-2d4f-7d22-85fa-c7db2e13e771",
"controlNumber": "000022222",
"eligibilitySearchId": "06956c88-a177-5252-b868-ju4974dd54gh",
"errors": [
{
"code": "79",
"description": "Invalid Participant Identification",
"followupAction": "Please Correct and Resubmit",
"location": "2100A",
"possibleResolutions": "Payer TEST is not configured. Please check our published payer list or contact Stedi support to resolve."
}
],
"id": "ec_750e8400-e29b-41d4-a716-446655440002",
"meta": {
"outboundTraceId": "01JCP62EYY1N6PZABF9Q45EN5Y"
},
"status": "ERROR",
"submitterTransactionIdentifier": "ABC123456789",
"tradingPartnerServiceId": "TEST"
},
{
"batchId": "01932c61-2d4f-7d22-85fa-c7db2e13e771",
"benefitsInformation": [
{
"additionalInformation": [
{
"description": "Complete Care Management"
}
],
"code": "1",
"name": "Active Coverage",
"planCoverage": "Open Access Plus",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "6000",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"benefitAmount": "500",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "3000",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"benefitAmount": "250",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "15000",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"additionalInformation": [
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "30000",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitPercent": "0.1",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
]
},
{
"benefitAmount": "7500",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"additionalInformation": [
{
"description": "Deductible does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "15000",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Co-Insurance",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Not Applicable",
"inPlanNetworkIndicatorCode": "W",
"name": "Active Coverage",
"serviceTypeCodes": [
"A7",
"BC",
"A8",
"A4",
"A5",
"A6",
"7",
"4",
"BB",
"22"
],
"serviceTypes": [
"Psychiatric - Inpatient",
"Day Care (Psychiatric)",
"Psychiatric - Outpatient",
"Psychiatric",
"Psychiatric - Room and Board",
"Psychotherapy",
"Anesthesia",
"Diagnostic X-Ray",
"Partial Hospitalization (Psychiatric)",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"BC",
"A4",
"A6",
"4",
"22"
],
"serviceTypes": [
"Day Care (Psychiatric)",
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"A8"
],
"serviceTypes": [
"Psychiatric - Outpatient"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"A4",
"A6",
"4",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
]
},
{
"authOrCertIndicator": "N",
"benefitAmount": "20",
"code": "B",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"A4",
"A6",
"4",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Included For Specific Services"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "20",
"code": "B",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Included For Specific Services"
}
],
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"A4",
"A6",
"4",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "20",
"code": "B",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "20",
"code": "B",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "Y",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"7"
],
"serviceTypes": [
"Anesthesia"
]
},
{
"authOrCertIndicator": "Y",
"code": "CB",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Coverage Basis",
"serviceTypeCodes": [
"7",
"BB"
],
"serviceTypes": [
"Anesthesia",
"Partial Hospitalization (Psychiatric)"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "Y",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"7"
],
"serviceTypes": [
"Anesthesia"
]
},
{
"authOrCertIndicator": "Y",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"7"
],
"serviceTypes": [
"Anesthesia"
]
},
{
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"4"
],
"serviceTypes": [
"Diagnostic X-Ray"
]
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"4"
],
"serviceTypes": [
"Diagnostic X-Ray"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "Y",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"BB"
],
"serviceTypes": [
"Partial Hospitalization (Psychiatric)"
]
},
{
"additionalInformation": [
{
"description": " Provider is out of network based on NPI ID provided in request."
}
],
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": [
"MH"
],
"serviceTypes": [
"Mental Health"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "5760",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"benefitAmount": "500",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "2760",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"benefitAmount": "250",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "15000",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"additionalInformation": [
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "30000",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "7500",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"additionalInformation": [
{
"description": "Deductible does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "15000",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
}
],
"controlNumber": "333344444",
"eligibilitySearchId": "01922a35-a177-7171-b868-cd4974dd54df",
"errors": [],
"id": "ec_850e8400-e29b-41d4-a716-446655440003",
"meta": {
"applicationMode": "production",
"outboundTraceId": "01J2VZA127GH93JT74HJU",
"senderId": "030240928",
"submitterId": "117151744",
"traceId": "01J2VZA127GH93JT74HJU"
},
"payer": {
"contactInformation": {
"contacts": [
{
"communicationMode": "Telephone",
"communicationNumber": "1234567890"
},
{
"communicationMode": "Uniform Resource Locator (URL)",
"communicationNumber": "website.company.com"
}
]
},
"entityIdentifier": "Payer",
"entityType": "Non-Person Entity",
"federalTaxpayersIdNumber": "123412345",
"name": "ABCDE"
},
"planDateInformation": {
"eligibilityBegin": "20220102",
"planBegin": "20240101",
"planEnd": "20241231"
},
"planInformation": {
"groupDescription": "ABCDE",
"groupNumber": "12341234",
"priorIdNumber": "1234567890"
},
"planStatus": [
{
"planDetails": "Open Access Plus",
"serviceTypeCodes": [
"30"
],
"status": "Active Coverage",
"statusCode": "1"
},
{
"serviceTypeCodes": [
"A7",
"BC",
"A8",
"A4",
"A5",
"A6",
"7",
"4",
"BB",
"22"
],
"status": "Active Coverage",
"statusCode": "1"
},
{
"serviceTypeCodes": [
"MH"
],
"status": "Active Coverage",
"statusCode": "1"
}
],
"provider": {
"entityIdentifier": "Provider",
"entityType": "Non-Person Entity",
"npi": "1234567890",
"providerName": "ACME HEALTH SERVICES"
},
"reassociationKey": "123456789",
"submitterTransactionIdentifier": "DEF123456799",
"subscriber": {
"address": {
"address1": "1234 FIRST ST",
"city": "NEW YORK",
"postalCode": "123451111",
"state": "WV"
},
"dateOfBirth": "19000101",
"entityIdentifier": "Insured or Subscriber",
"entityType": "Person",
"firstName": "JANE",
"gender": "F",
"groupNumber": "123456789",
"lastName": "DOE",
"memberId": "1234567892",
"middleName": "A"
},
"tradingPartnerServiceId": "123456789",
"x12": "ISA*00* *00* *ZZ*STEDI *01*117151744 *111111*1234*^*00501*123456782*0*P*>~GS*HB*STEDI*117151744*20240326*111000*1*X*005010X279A1~ST*271*1001*005010X279A1~BHT*0022*11*01J2VZA127GH93JT74HJU*20240326*1514~HL*1**20*1~NM1*PR*2*ABCDE*****FI*111000123~PER*IC**TE*123456789*UR*website.company.com~HL*2*1*21*1~NM1*1P*2*ACME HEALTH SERVICES*****XX*11234567890~HL*3*2*22*0~NM1*IL*1*DOE*JANE*A***MI*123456789~REF*6P*123456789*ABCDE~REF*Q4*123456789~N3*1234 FIRST ST~N4*NEW YORK*WV*123451111~DMG*D8*19000101*F~INS*Y*18*001*25~DTP*356*D8*20220102~DTP*346*D8*20240101~DTP*347*D8*20241231~EB*1**30**Open Access Plus~MSG*Complete Care Management~EB*G*FAM*30***23*6000.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*FAM*30***23*500.00*****Y~MSG*Includes services provided by Client Specific Network~EB*G*IND*30***23*3000.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***23*250.00*****Y~MSG*Includes services provided by Client Specific Network~EB*C*FAM*30***23*15000.00*****N~EB*G*FAM*30***23*30000.00*****N~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*A*IND*30*****.10****Y~EB*C*IND*30***23*7500.00*****N~EB*G*IND*30***23*15000.00*****N~MSG*Deductible does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~EB*A*IND*30*****.50****N~EB*1**A7^BC^A8^A4^A5^A6^7^4^BB^22*********W~EB*C*IND*BC^A4^A6^4^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*22~EB*C*IND*A8****0.00****N*Y~MSG*Includes services provided by Client Specific Network~EB*C*IND*A4^A6^4^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*11~EB*C*IND*A4^A6^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*02~EB*B*IND*A4^A6^22***27*20.00****N*Y~III*ZZ*11~EB*A*IND*A4^A6^4^22*****.00***N*Y~III*ZZ*11~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Included For Specific Services~III*ZZ*02~EB*A*IND*A4^A6^22*****.00***N*Y~MSG*Included For Specific Services~III*ZZ*02~EB*A*IND*A4^A6^22*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*02~EB*A*IND*A4^A6^4^22*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*02~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*A*IND*7*****.00***Y*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*CB**7^BB********Y*Y~EB*C*IND*7****0.00****Y*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*11~EB*A*IND*7*****.00***Y*Y~III*ZZ*11~EB*A*IND*4*****.00***N*Y~III*ZZ*22~EB*A*IND*4*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*22~EB*C*IND*BB****0.00****Y*Y~MSG*Includes services provided by Client Specific Network~EB*1**MH~MSG* Provider is out of network based on NPI ID provided in request.~EB*G*FAM*30***29*5760.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*FAM*30***29*500.00*****Y~MSG*Includes services provided by Client Specific Network~EB*G*IND*30***29*2760.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***29*250.00*****Y~MSG*Includes services provided by Client Specific Network~EB*C*FAM*30***29*15000.00*****N~EB*G*FAM*30***29*30000.00*****N~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***29*7500.00*****N~EB*G*IND*30***29*15000.00*****N~MSG*Deductible does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~SE*119*1001~GE*1*1~IEA*1*123456782~"
}
],
"nextPageToken": "01932c61-2d4f-7d22-85fa-c7db2e13e771"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# 277CA Report
Source: https://www.stedi.com/docs/healthcare/api-reference/get-healthcare-reports-277
The 277CA claim acknowledgment indicates whether a claim was accepted or rejected and (if relevant) the reasons for rejection. This endpoint retrieves processed 277CA transactions from Stedi.
1. Call this endpoint with the `transactionId` of the 277CA you want to retrieve. You can retrieve the transaction ID through webhooks or through Stedi's API. [Learn more](/healthcare/receive-claim-responses#discover-processed-responses)
2. The endpoint returns the 277CA in JSON format.
## API Specification
Retrieve a 277CA claim acknowledgment in JSON format
**Endpoint:** `GET /change/medicalnetwork/reports/v2/{transactionId}/277`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Parameters
- **`transactionId`** (path) (required): A unique identifier for the processed 277 transaction within Stedi. This ID is included in the transaction processed event, which you can receive automatically through Stedi [webhooks](https://www.stedi.com/docs/healthcare/configure-webhooks). You can also retrieve it through the [Poll Transactions endpoint](https://www.stedi.com/docs/healthcare/api-reference/get-poll-transactions) or from the transaction's details page within the Stedi portal.
- Type: `string`
### Responses
#### 200
ConvertReport277 200 response
**Schema:** `ConvertReport277ResponseContent`
**Properties:**
- **`meta`** (`object`) (required)
- **`transactions`** (`array`): The payer's 277 response.
- Items schema: `ReportsClaimAcknowledgmentResponse`
**Example:**
```json
{
"meta": {
"transactionId": "71716ec5-0e96-462f-bb77-869941bb27ab"
},
"transactions": [
{
"controlNumber": "1001",
"payers": [
{
"claimStatusTransactions": [
{
"claimStatusDetails": [
{
"patientClaimStatusDetails": [
{
"claims": [
{
"claimStatus": {
"claimServiceBeginDate": "20240101",
"claimServiceEndDate": "20240101",
"clearinghouseTraceNumber": "01J1SNT1FQC8ABWD44MAMBDYKA",
"informationClaimStatuses": [
{
"informationStatuses": [
{
"healthCareClaimStatusCategoryCode": "A1",
"healthCareClaimStatusCategoryCodeValue": "Acknowledgement/Receipt - The claim/encounter has been received. This does not mean that the claim has been accepted for adjudication.",
"statusCode": "20",
"statusCodeValue": "Accepted for processing."
}
],
"statusInformationEffectiveDate": "20240702",
"totalClaimChargeAmount": "109.20"
}
],
"patientAccountNumber": "11122233",
"referencedTransactionTraceNumber": "11122233"
}
}
],
"subscriber": {
"firstName": "JOHN",
"lastName": "ANON",
"memberId": "U7777788888"
}
}
],
"providerOFServiceInformationTraceIdentifier": "0",
"serviceProvider": {
"npi": "1235600834",
"organizationName": "THERAPY ASSOCIATES"
}
}
],
"claimTransactionBatchNumber": "01J1SNRJ0FP4ZE6EFWM4G4XB3N",
"provider": {
"etin": "1235600834",
"organizationName": "TEST DATA HEALTH SERVICES, INC."
},
"providerClaimStatuses": [
{
"providerStatuses": [
{
"healthCareClaimStatusCategoryCode": "A1",
"healthCareClaimStatusCategoryCodeValue": "Acknowledgement/Receipt - The claim/encounter has been received. This does not mean that the claim has been accepted for adjudication.",
"statusCode": "20",
"statusCodeValue": "Accepted for processing."
}
],
"statusInformationEffectiveDate": "20240702"
}
]
}
],
"organizationName": "STEDI INC"
}
],
"referenceIdentification": "1511096803",
"transactionSetCreationDate": "20240702",
"transactionSetCreationTime": "0815"
}
]
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`code`** (`string`): A code describing the type of validation failure.
- **`message`** (`string`) (required): A message describing the causes of the validation failure. There may be more than one.
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# 835 ERA Report
Source: https://www.stedi.com/docs/healthcare/api-reference/get-healthcare-reports-835
The 835 Electronic Remittance Advice (ERA) contains details about payments for specific services and explanations for any adjustments or denials. This endpoint retrieves processed 835 ERA transactions from Stedi.
1. Call this endpoint with the `transactionId` of the 835 ERA you want to retrieve. You can retrieve the transaction ID through webhooks or through Stedi's API. [Learn more](/healthcare/receive-claim-responses#discover-processed-responses)
2. The endpoint returns the 835 ERA in JSON format.
Note that the payer won't send 835 ERAs for rejected claims. If a claim is rejected in a 277CA claim acknowledgment, there's no adjudication or payment information to report.
## Claim status [#claim-status]
You can't reliably determine a claim's status based on the amount paid in an 835 ERA. There are many instances in which a claim is accepted and the total amount paid is 0 dollars. For example, in Value-Based Care (VBC) scenarios, line item rates are usually 0 dollars, and providers are paid a flat rate per month or for a complete bundle of services.
Use the [Real-Time Claim Status API](/healthcare/api-reference/post-healthcare-claim-status) to check the claim's status instead.
## API Specification
Retrieve an 835 Electronic Remittance Advice (ERA) in JSON format
**Endpoint:** `GET /change/medicalnetwork/reports/v2/{transactionId}/835`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Parameters
- **`transactionId`** (path) (required): A unique identifier for the processed 835 transaction within Stedi. This ID is included in the transaction processed event, which you can receive automatically through Stedi [webhooks](https://www.stedi.com/docs/healthcare/configure-webhooks). You can also retrieve it through the [Poll Transactions endpoint](https://www.stedi.com/docs/healthcare/api-reference/get-poll-transactions) or from the transaction's details page within the Stedi portal.
- Type: `string`
### Responses
#### 200
ConvertReport835 200 response
**Schema:** `ConvertReport835ResponseContent`
**Properties:**
- **`meta`** (`object`) (required): Metadata that helps Stedi track and debug the response.
- **`transactions`** (`array`): The payer's 835 response.
- Items schema: `ClaimPaymentAdviceResponse`
**Example:**
```json
{
"meta": {
"applicationMode": "production",
"senderId": "BSW",
"transactionId": "7647d644-9348-4596-a3b4-6830b8b48cc8"
},
"transactions": [
{
"controlNumber": "112233",
"detailInfo": [
{
"assignedNumber": "1",
"paymentInfo": [
{
"claimPaymentInfo": {
"claimFilingIndicatorCode": "12",
"claimFrequencyCode": "1",
"claimPaymentAmount": "500",
"claimStatusCode": "1",
"facilityTypeCode": "11",
"patientControlNumber": "1112223333",
"patientResponsibilityAmount": "300",
"payerClaimControlNumber": "94060555410000",
"totalClaimChargeAmount": "800"
},
"claimSupplementalInformation": {
"coverageAmount": "800"
},
"patientName": {
"firstName": "JOHN",
"lastName": "DOE",
"memberId": "1234567891"
},
"serviceLines": [
{
"lineItemControlNumber": "111222333",
"serviceAdjustments": [
{
"adjustmentAmount1": "300",
"adjustmentReason1": "Deductible Amount",
"adjustmentReasonCode1": "1",
"claimAdjustmentGroupCode": "PR",
"claimAdjustmentGroupCodeValue": "Patient Responsibility"
}
],
"serviceDate": "20190301",
"servicePaymentInformation": {
"adjudicatedProcedureCode": "99211",
"lineItemChargeAmount": "800",
"lineItemProviderPaymentAmount": "500",
"productOrServiceIDQualifier": "HC",
"productOrServiceIDQualifierValue": "Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes"
},
"serviceSupplementalAmounts": {
"allowedActual": "800"
}
}
]
},
{
"claimPaymentInfo": {
"claimFilingIndicatorCode": "12",
"claimFrequencyCode": "1",
"claimPaymentAmount": "600",
"claimStatusCode": "1",
"facilityTypeCode": "11",
"patientControlNumber": "22255566677",
"patientResponsibilityAmount": "600",
"payerClaimControlNumber": "9407779923000",
"totalClaimChargeAmount": "1200"
},
"claimSupplementalInformation": {
"coverageAmount": "1200"
},
"patientName": {
"firstName": "JANE",
"lastName": "DOE",
"memberId": "1234567891"
},
"serviceLines": [
{
"serviceAdjustments": [
{
"adjustmentAmount1": "600",
"adjustmentReason1": "Deductible Amount",
"adjustmentReasonCode1": "1",
"claimAdjustmentGroupCode": "PR",
"claimAdjustmentGroupCodeValue": "Patient Responsibility"
}
],
"serviceDate": "20190310",
"servicePaymentInformation": {
"adjudicatedProcedureCode": "93555",
"lineItemChargeAmount": "1200",
"lineItemProviderPaymentAmount": "600",
"productOrServiceIDQualifier": "HC",
"productOrServiceIDQualifierValue": "Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes"
},
"serviceSupplementalAmounts": {
"allowedActual": "1200"
}
}
]
}
]
}
],
"financialInformation": {
"checkIssueOrEFTEffectiveDate": "20190316",
"creditOrDebitFlagCode": "C",
"payerIdentifier": "000000000",
"paymentFormatCode": "CCP",
"paymentMethodCode": "ACH",
"receiverAccountDetails": {
"receiverAccountNumber": "144444",
"receiverAccountNumberQualifier": "DA",
"receiverDfiIdNumberQualifier": "01",
"receiverDfiIdentificationNumber": "111333555"
},
"senderAccountDetails": {
"senderAccountNumber": "11111111",
"senderAccountNumberQualifier": "DA",
"senderDFIIdentifier": "888999777",
"senderDfiIdNumberQualifier": "01"
},
"totalActualProviderPaymentAmount": "1100",
"transactionHandlingCode": "I"
},
"payee": {
"federalTaxPayersIdentificationNumber": "777667755",
"name": "ACME MEDICAL CENTER",
"npi": "1999999984"
},
"payer": {
"address": {
"address1": "10 SOUTH AVENUET",
"city": "NEW YORK",
"postalCode": "55111",
"state": "SD"
},
"name": "RUSHMORE LIFE",
"technicalContactInformation": [
{
"contactMethods": [
{
"phone": "8005550000"
}
],
"contactName": "JOHN DOE"
}
]
},
"paymentAndRemitReassociationDetails": {
"checkOrEFTTraceNumber": "71700666555",
"originatingCompanyIdentifier": "1935665544",
"traceTypeCode": "1"
},
"productionDate": "20190314"
}
]
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`code`** (`string`): A code describing the type of validation failure.
- **`message`** (`string`) (required): A message describing the causes of the validation failure. There may be more than one.
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# Insurance Discovery Check Results
Source: https://www.stedi.com/docs/healthcare/api-reference/get-insurance-discovery-results
You can use this endpoint to retrieve insurance discovery check results for a particular patient asynchronously.
You can begin polling immediately after receiving a `PENDING` status response from the synchronous Insurance Discovery Check endpoint. This endpoint can take up to 120 seconds to return a response.
It's unlikely for the insurance discovery process to take more than a few minutes, so it's rare to have to poll this endpoint more than once. However, if you receive a `PENDING` status, you can poll immediately again and continue polling until the status changes to `COMPLETE.`
Note that you should only expect to retrieve checks submitted within the last 24 hours. After 24 hours, the results may no longer be available.
## API Specification
Retrieve insurance discovery check results by `discoveryId`
**Endpoint:** `GET /insurance-discovery/check/v1/{discoveryId}`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Parameters
- **`discoveryId`** (path) (required): The unique ID for the insurance discovery check. Stedi returns this value in the response from the [Insurance Discovery Check](https://www.stedi.com/docs/healthcare/api-reference/post-insurance-discovery) endpoint.
- Type: `string`
### Responses
#### 200
GetInsuranceDiscoveryCheck 200 response
**Schema:** `GetInsuranceDiscoveryCheckResponseContent`
**Properties:**
- **`coveragesFound`** (`integer`): The number of potential coverage matches for the patient. This will be `0` if Stedi didn't find any matching coverage.
- **`discoveryId`** (`string`): A unique ID for this insurance discovery check. You can use it to retrieve the results asynchronously through the [Insurance Discovery Check Results](https://www.stedi.com/docs/healthcare/api-reference/get-insurance-discovery-results) endpoint.
- **`errors`** (`array`): When a payer rejects your eligibility check, the response contains one or more [`AAA` errors](https://www.stedi.com/docs/healthcare/eligibility-troubleshooting#payer-aaa-errors) that specify the reasons for the rejection and any recommended follow-up actions.
Any errors that occur at the `payer`, `provider`, `subscriber`, or `dependents` levels are also included in this array, allowing you to review all errors in a central location. If there are no `AAA` errors, this array will be empty.
- Items schema: `EligibilityCheckError`
- **`items`** (`array`): An array of potential coverage matches for the patient. This will only be populated if the insurance discovery check `status` is `COMPLETE`. Each item in the array contains information about a potential match, including the provider, subscriber, payer, and plan information.
- Items schema: `InsuranceDiscoveryResponseFields`
- **`meta`** (`object`)
- **`status`** (`object`): The status of the discovery check. This is either `PENDING` or `COMPLETE`.
- If the status is `COMPLETE`, the `items` array will contain any potential coverage matches Stedi found for the patient.
- If the status is `PENDING`, the check is still in progress. You can immediately begin polling the [Insurance Discovery Check Results](https://www.stedi.com/docs/healthcare/api-reference/get-insurance-discovery-results) endpoint to retrieve the results asynchronously.
**Example:**
```json
{
"discoveryId": "12345678-abcd-4321-efgh-987654321abc",
"items": [
{
"benefitsInformation": [
{
"additionalInformation": [
{
"description": "To determine if a prior authorization is required, please check the health plan's website."
}
],
"benefitsRelatedEntities": [
{
"entityFirstname": "Jane",
"entityIdentification": "XX",
"entityIdentificationValue": "1234567890",
"entityIdentifier": "Primary Care Provider",
"entityName": "Dough",
"entityType": "Person"
}
],
"code": "1",
"inPlanNetworkIndicator": "Not Applicable",
"inPlanNetworkIndicatorCode": "W",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Not Applicable",
"inPlanNetworkIndicatorCode": "W",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"1"
],
"serviceTypes": [
"Medical Care"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"4"
],
"serviceTypes": [
"Diagnostic X-Ray"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"4"
],
"serviceTypes": [
"Diagnostic X-Ray"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"4"
],
"serviceTypes": [
"Diagnostic X-Ray"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"5"
],
"serviceTypes": [
"Diagnostic Lab"
]
},
{
"additionalInformation": [
{
"description": "per visit"
}
],
"benefitAmount": "20",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"5"
],
"serviceTypes": [
"Diagnostic Lab"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"5"
],
"serviceTypes": [
"Diagnostic Lab"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"12"
],
"serviceTypes": [
"Durable Medical Equipment Purchase"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"12"
],
"serviceTypes": [
"Durable Medical Equipment Purchase"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"12"
],
"serviceTypes": [
"Durable Medical Equipment Purchase"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"13"
],
"serviceTypes": [
"Ambulatory Service Center Facility"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"13"
],
"serviceTypes": [
"Ambulatory Service Center Facility"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"13"
],
"serviceTypes": [
"Ambulatory Service Center Facility"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"18"
],
"serviceTypes": [
"Durable Medical Equipment Rental"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"18"
],
"serviceTypes": [
"Durable Medical Equipment Rental"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"18"
],
"serviceTypes": [
"Durable Medical Equipment Rental"
]
},
{
"additionalInformation": [
{
"description": "Limited to 26 visits per year (visits in excess of 26 require prior authorization)."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"33"
],
"serviceTypes": [
"Chiropractic"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"33"
],
"serviceTypes": [
"Chiropractic"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"33"
],
"serviceTypes": [
"Chiropractic"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"48"
],
"serviceTypes": [
"Hospital - Inpatient"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"48"
],
"serviceTypes": [
"Hospital - Inpatient"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"48"
],
"serviceTypes": [
"Hospital - Inpatient"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"50"
],
"serviceTypes": [
"Hospital - Outpatient"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"50"
],
"serviceTypes": [
"Hospital - Outpatient"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"50"
],
"serviceTypes": [
"Hospital - Outpatient"
]
},
{
"additionalInformation": [
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"51"
],
"serviceTypes": [
"Hospital - Emergency Accident"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"51"
],
"serviceTypes": [
"Hospital - Emergency Accident"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"51"
],
"serviceTypes": [
"Hospital - Emergency Accident"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"51"
],
"serviceTypes": [
"Hospital - Emergency Accident"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"52"
],
"serviceTypes": [
"Hospital - Emergency Medical"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"52"
],
"serviceTypes": [
"Hospital - Emergency Medical"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"52"
],
"serviceTypes": [
"Hospital - Emergency Medical"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"52"
],
"serviceTypes": [
"Hospital - Emergency Medical"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"53"
],
"serviceTypes": [
"Hospital - Ambulatory Surgical"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"53"
],
"serviceTypes": [
"Hospital - Ambulatory Surgical"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"53"
],
"serviceTypes": [
"Hospital - Ambulatory Surgical"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"62"
],
"serviceTypes": [
"MRI/CAT Scan"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"62"
],
"serviceTypes": [
"MRI/CAT Scan"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"62"
],
"serviceTypes": [
"MRI/CAT Scan"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"65"
],
"serviceTypes": [
"Newborn Care"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"65"
],
"serviceTypes": [
"Newborn Care"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"65"
],
"serviceTypes": [
"Newborn Care"
]
},
{
"additionalInformation": [
{
"description": "Covered in accordance with ACA guidelines."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"68"
],
"serviceTypes": [
"Well Baby Care"
]
},
{
"benefitAmount": "0",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"68"
],
"serviceTypes": [
"Well Baby Care"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"68"
],
"serviceTypes": [
"Well Baby Care"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"69"
],
"serviceTypes": [
"Maternity"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"69"
],
"serviceTypes": [
"Maternity"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"69"
],
"serviceTypes": [
"Maternity"
]
},
{
"additionalInformation": [
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"86"
],
"serviceTypes": [
"Emergency Services"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"86"
],
"serviceTypes": [
"Emergency Services"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"86"
],
"serviceTypes": [
"Emergency Services"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"86"
],
"serviceTypes": [
"Emergency Services"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"88"
],
"serviceTypes": [
"Pharmacy"
]
},
{
"additionalInformation": [
{
"description": "per prescription"
}
],
"benefitAmount": "10",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"88"
],
"serviceTypes": [
"Pharmacy"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"88"
],
"serviceTypes": [
"Pharmacy"
]
},
{
"additionalInformation": [
{
"description": "PCP"
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"98"
],
"serviceTypes": [
"Professional (Physician) Visit - Office"
]
},
{
"additionalInformation": [
{
"description": "per visit"
},
{
"description": "PCP"
}
],
"benefitAmount": "15",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"98"
],
"serviceTypes": [
"Professional (Physician) Visit - Office"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "PCP"
}
],
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"98"
],
"serviceTypes": [
"Professional (Physician) Visit - Office"
]
},
{
"additionalInformation": [
{
"description": "Specialist"
},
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"98"
],
"serviceTypes": [
"Professional (Physician) Visit - Office"
]
},
{
"additionalInformation": [
{
"description": "per visit"
},
{
"description": "Specialist"
}
],
"benefitAmount": "30",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"98"
],
"serviceTypes": [
"Professional (Physician) Visit - Office"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Specialist"
}
],
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"98"
],
"serviceTypes": [
"Professional (Physician) Visit - Office"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit. (Primary Care Provider (PCP) and other practitioner office visits do not require prior authorization.) Note| Services (excluding Emergency Room Care / Emergency Services) rendered by an out-of-network provider"
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A4"
],
"serviceTypes": [
"Psychiatric"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A4"
],
"serviceTypes": [
"Psychiatric"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A4"
],
"serviceTypes": [
"Psychiatric"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A6"
],
"serviceTypes": [
"Psychotherapy"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A6"
],
"serviceTypes": [
"Psychotherapy"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A6"
],
"serviceTypes": [
"Psychotherapy"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A7"
],
"serviceTypes": [
"Psychiatric - Inpatient"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A7"
],
"serviceTypes": [
"Psychiatric - Inpatient"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A7"
],
"serviceTypes": [
"Psychiatric - Inpatient"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A8"
],
"serviceTypes": [
"Psychiatric - Outpatient"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A8"
],
"serviceTypes": [
"Psychiatric - Outpatient"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A8"
],
"serviceTypes": [
"Psychiatric - Outpatient"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AD"
],
"serviceTypes": [
"Occupational Therapy"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AD"
],
"serviceTypes": [
"Occupational Therapy"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AD"
],
"serviceTypes": [
"Occupational Therapy"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AF"
],
"serviceTypes": [
"Speech Therapy"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AF"
],
"serviceTypes": [
"Speech Therapy"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AF"
],
"serviceTypes": [
"Speech Therapy"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Limited to 150 days per year."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AG"
],
"serviceTypes": [
"Skilled Nursing Care"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AG"
],
"serviceTypes": [
"Skilled Nursing Care"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AG"
],
"serviceTypes": [
"Skilled Nursing Care"
]
},
{
"additionalInformation": [
{
"description": "Covered in accordance with ACA guidelines."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"BZ"
],
"serviceTypes": [
"Physician Visit - Office: Well"
]
},
{
"benefitAmount": "0",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"BZ"
],
"serviceTypes": [
"Physician Visit - Office: Well"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"BZ"
],
"serviceTypes": [
"Physician Visit - Office: Well"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"MH"
],
"serviceTypes": [
"Mental Health"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"MH"
],
"serviceTypes": [
"Mental Health"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"MH"
],
"serviceTypes": [
"Mental Health"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"PT"
],
"serviceTypes": [
"Physical Therapy"
]
},
{
"additionalInformation": [
{
"description": "per visit"
}
],
"benefitAmount": "15",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"PT"
],
"serviceTypes": [
"Physical Therapy"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"PT"
],
"serviceTypes": [
"Physical Therapy"
]
},
{
"additionalInformation": [
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"UC"
],
"serviceTypes": [
"Urgent Care"
]
},
{
"additionalInformation": [
{
"description": "per visit"
}
],
"benefitAmount": "10",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"UC"
],
"serviceTypes": [
"Urgent Care"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"UC"
],
"serviceTypes": [
"Urgent Care"
]
},
{
"additionalInformation": [
{
"description": "per visit"
}
],
"benefitAmount": "10",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"UC"
],
"serviceTypes": [
"Urgent Care"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "3000",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "2000",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "6000",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "5000",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "0",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "0",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "0",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "0",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
}
],
"confidence": {
"level": "REVIEW_NEEDED",
"reason": "This record was identified as a low confidence match due to a DOB partial match"
},
"payer": {
"name": "EXAMPLE INSURANCE CO"
},
"planDateInformation": {
"eligibilityBegin": "20250101",
"planBegin": "20250101",
"service": "20250301"
},
"planInformation": {
"groupDescription": "Individual On-Exchange",
"groupNumber": "123456-78",
"planNumber": "123456-EXMPL9876"
},
"provider": {
"entityType": "Non-Person Entity",
"npi": "1999999984",
"providerName": "provider"
},
"subscriber": {
"address": {
"address1": "123 Main Street",
"city": "ANYTOWN",
"postalCode": "12345",
"state": "CA"
},
"dateOfBirth": "19900115",
"firstName": "John",
"gender": "M",
"groupDescription": "Individual On-Exchange",
"groupNumber": "123456-78",
"lastName": "Doe",
"memberId": "987654321000",
"middleName": "Smith",
"planNumber": "123456-EXMPL9876"
}
}
],
"meta": {
"applicationMode": "production",
"traceId": "1-abcdef12-123456789abcdef123456789"
},
"status": "COMPLETE"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`code`** (`string`): A code describing the type of validation failure.
- **`message`** (`string`) (required): A message describing the causes of the validation failure. There may be more than one.
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# List Transactions
Source: https://www.stedi.com/docs/healthcare/api-reference/get-list-transactions
This endpoint fetches a list of all the transactions Stedi has processed in your account. It's useful for displaying a list of transactions in a UI. If you want to programmatically fetch and check for new transactions, you should use the [Poll Transactions](/healthcare/api-reference/get-poll-transactions) endpoint instead.
## API Specification
Fetch a list of transactions, sorted by the date they were created from newest to oldest.
**Endpoint:** `GET /transactions`
**Base URL:** `https://core.us.stedi.com/2023-08-01`
### Parameters
- **`pageSize`** (query): The maximum number of elements to return in a page. You can set this to a maximum of 500 elements. If not specified, the default is 100.
- Type: `number`
- **`pageToken`** (query): A token returned by a previous call to this operation in the `nextPageToken`. If not specified, Stedi returns the first page of results.
- Type: `string`
- **`businessIdentifier`** (query): List only transactions containing a business identifier with the given value.
- Type: `string`
- **`transactionSetId`** (query): List only a given type of transaction. Accepts any valid 3-digit X12 Transaction Set Identifier Code, as defined in the X12 standard. See: .
- **`sender`** (query): List only transactions sent by the given profile. This is the profile ID of the sender.
- Type: `string`
- **`receiver`** (query): List only transactions sent to the given profile. This is the profile ID of the receiver.
- Type: `string`
- **`direction`** (query): The direction of the transaction. Inbound transactions are those you receive from a payer, provider, or other trading partner. Outbound transactions are those you send to a payer, provider, or other trading partner.
- **`mode`** (query): Indicates whether the transaction contains test or production data. Stedi determines this from the value in [`ISA15` Usage Indicator Code](https://www.stedi.com/edi/x12/segment/ISA#ISA-15).
- **`status`** (query): A status indicating whether Stedi was able to successfully process the transaction.
- **`from`** (query): The start of the time range to filter transactions. The results will include transactions created at or after this timestamp.
- Type: `string`
- **`to`** (query): The end of the time range to filter transactions. The results will include transactions up to and including this timestamp.
- Type: `string`
- **`elementId`** (query): List only transactions containing a business identifier with the given element ID. This is the X12 element ID, such as "127" for Reference Identification. May only be supplied if `businessIdentifier` is also supplied. See Stedi's EDI references pages to find element IDs.
- Type: `string`
- **`partnershipId`** (query): List only transactions that were sent or received on the given partnership. This is the partnership ID, such as "local_clearinghouse-test".
- Type: `string`
### Responses
#### 200
ListTransactions 200 response
**Schema:** `ListTransactionsResponseContent`
**Properties:**
- **`nextPageToken`** (`string`): Token that you can supply in subsequent requests to retrieve the next page of results. If not returned, there are no more results.
- **`items`** (`array`) (required)
- Items schema: `TransactionSummary`
**Example:**
```json
{
"items": [
{
"direction": "INBOUND",
"mode": "test",
"status": "succeeded",
"fileExecutionId": "95236a56-a020-4522-8fef-bcffcec0ec1d",
"transactionId": "c8dd3a67-b8ca-4b0e-aa73-e0de82414b8f",
"processedAt": "2025-04-02T21:30:15.801Z",
"artifacts": [
{
"artifactType": "application/edi-x12",
"sizeBytes": 8374,
"model": "transaction",
"usage": "input",
"url": "https://core.us.stedi.com/2023-08-01/transactions/112233344-b8ca-4h1e-aa73-123482414b8f/input"
},
{
"artifactType": "application/json",
"sizeBytes": 76898,
"model": "transaction",
"usage": "output",
"url": "https://core.us.stedi.com/2023-08-01/transactions/1115555-b8ca-1234-aa73-e0je82414hb8f/output"
}
],
"partnership": {
"partnershipId": "stedi_test-sender",
"partnershipType": "x12",
"sender": {
"profileId": "test-sender"
},
"receiver": {
"profileId": "stedi"
}
},
"businessIdentifiers": [
{
"elementId": "127",
"element": "BHT-03",
"name": "Reference Identification",
"value": "XXXXXX"
}
],
"x12": {
"metadata": {
"interchange": {
"acknowledgmentRequestedCode": "0",
"controlNumber": 1
},
"functionalGroup": {
"controlNumber": 1,
"release": "005010X222A1",
"date": "2025-04-02",
"time": "21:29:57",
"functionalIdentifierCode": "HC"
},
"transaction": {
"controlNumber": "0001",
"transactionSetIdentifier": "837"
},
"receiver": {
"applicationCode": "STEDI-TEST",
"isa": {
"qualifier": "ZZ",
"id": "STEDI-TEST"
}
},
"sender": {
"applicationCode": "TestSender",
"isa": {
"qualifier": "ZZ",
"id": "TestSender"
}
}
},
"transactionSetting": {
"guideId": "01JQW6E5RSBSTKS3ZQ1SPR4019",
"transactionSettingId": "01JQW6E72Q3HDXM40YYAQCBZDY"
}
}
}
],
"nextPageToken": "be08e5ba4bf36da9da27dcb651e64a6e5502685499994f354"
}
```
#### 400
BadRequestException 400 response
**Schema:** `BadRequestExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 409
ResourceUnderChangeException 409 response
**Schema:** `ResourceUnderChangeExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
#### 422
UnprocessableEntityException 422 response
**Schema:** `UnprocessableEntityExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 500
ServiceException 500 response
**Schema:** `ServiceExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`exceptionCause`** (`object`)
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
# Retrieve Payer
Source: https://www.stedi.com/docs/healthcare/api-reference/get-payer
You can use this endpoint to retrieve a specific payer record with the Stedi payer ID (`stediId`). You can find the Stedi payer ID for any supported payer in the [Payer Network](https://www.stedi.com/healthcare/network). Note that you must supply the Stedi payer ID - this endpoint doesn't support querying with the primary payer ID or payer ID aliases.
The payer record includes the payer's names, aliases, and supported use cases (medical, dental, or vision). It also contains supported transaction types and specifies whether [transaction enrollment](/healthcare/transaction-enrollment) is required.
## API Specification
Retrieve a single payer record by its Stedi payer ID.
**Endpoint:** `GET /payer/{stediId}`
**Base URL:** `https://payers.us.stedi.com/2024-04-01`
### Parameters
- **`stediId`** (path) (required): The Stedi payer ID, a unique identifier Stedi assigns to each payer that will never change. You can find the Stedi payer ID for any supported payer in the [Payer Network](https://www.stedi.com/healthcare/network).
This must be the Stedi payer ID - querying with the primary payer ID or payer ID aliases isn't supported.
- Type: `string`
### Responses
#### 200
GetPayerRecord 200 response
**Schema:** `GetPayerRecordResponseContent`
**Properties:**
- **`payer`** (`object`) (required): The payer record matching the provided Stedi payer ID. The record includes the payer's display name and aliases as well as supported transaction types and details about the payer's [transaction enrollment](https://www.stedi.com/docs/healthcare/transaction-enrollment) process.
**Example:**
```json
{
"payer": {
"aliases": [
"00420",
"13123",
"1584",
"4714",
"95655",
"MEDGL",
"MEDGLD",
"MEDIGOLD"
],
"avatarUrl": "https://prod-payer-avatars.payers.us.stedi.com/YKHRB/avatar.png?v=1766600157693",
"coverageTypes": [
"dental",
"medical"
],
"displayName": "Trinity Health Plan",
"enrollment": {
"ptanRequired": false,
"transactionEnrollmentProcesses": {
"claimPayment": {
"requestedEffectiveDate": "NOT_SUPPORTED",
"supportedAggregationPreferences": [
"NPI",
"TIN"
],
"timeframe": "DAYS",
"type": "ONE_CLICK"
}
}
},
"names": [
"MediGold",
"Medigold Health Plans",
"Mount Carmel Health Plan",
"Mount Carmel MediGold",
"Trinity Health Plan of Michigan"
],
"operatingStates": [
"ID",
"IA",
"MI",
"NY",
"OH"
],
"parentPayerGroupId": "GTRSH",
"primaryPayerId": "95655",
"stediId": "YKHRB",
"transactionSupport": {
"claimPayment": "ENROLLMENT_REQUIRED",
"claimStatus": "SUPPORTED",
"claimSubmission": "SUPPORTED",
"coordinationOfBenefits": "NOT_SUPPORTED",
"dentalClaimSubmission": "NOT_SUPPORTED",
"eligibilityCheck": "SUPPORTED",
"institutionalClaimSubmission": "SUPPORTED",
"professionalClaimSubmission": "SUPPORTED",
"unsolicitedClaimAttachment": "NOT_SUPPORTED"
},
"urls": {
"website": "https://www.thpmedicare.org"
}
}
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# List Payers CSV
Source: https://www.stedi.com/docs/healthcare/api-reference/get-payers-csv
You can use this endpoint to retrieve Payer IDs, determine which transactions each payer supports, and check whether [transaction enrollment](/healthcare/transaction-enrollment) is required for the transaction types you plan to send and receive.
You can also find a searchable list of payers in the [Payer Network](https://www.stedi.com/healthcare/network).
## API Specification
List Stedi's supported payers in CSV format
**Endpoint:** `GET /payers/csv`
**Base URL:** `https://payers.us.stedi.com/2024-04-01`
### Responses
#### 200
ListPayerRecordsCsv 200 response
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# List Payers JSON
Source: https://www.stedi.com/docs/healthcare/api-reference/get-payers
You can use this endpoint to retrieve Payer IDs, determine which transactions each payer supports, and check whether [transaction enrollment](/healthcare/transaction-enrollment) is required for the transaction types you plan to send and receive.
You can also find a searchable list of payers in the [Payer Network](https://www.stedi.com/healthcare/network).
## API Specification
List Stedi's supported payers in JSON format
**Endpoint:** `GET /payers`
**Base URL:** `https://payers.us.stedi.com/2024-04-01`
### Parameters
- **`pageSize`** (query): The maximum number of elements to return per page. If not set, Stedi returns all payers in a single response (no pagination).
- Type: `integer`
- **`pageToken`** (query): The `nextPageToken` value from a previous response. You can use this to get the next page of results. If not set, Stedi returns the first page of results.
- Type: `string`
### Responses
#### 200
ListPayerRecords 200 response
**Schema:** `ListPayerRecordsResponseContent`
**Properties:**
- **`items`** (`array`) (required): Payers that Stedi supports for each transaction type. Results are returned in alphabetical order of the Stedi ID.
- Items schema: `PayerRecord`
- **`nextPageToken`** (`string`): Token that you can supply in subsequent requests to retrieve the next page of results. If not returned, there are no more results.
**Example:**
```json
{
"items": [
{
"aliases": [
"00420",
"13123",
"1584",
"4714",
"95655",
"MEDGL",
"MEDGLD",
"MEDIGOLD"
],
"avatarUrl": "https://prod-payer-avatars.payers.us.stedi.com/YKHRB/avatar.png?v=1766600157693",
"coverageTypes": [
"dental",
"medical"
],
"displayName": "Trinity Health Plan",
"enrollment": {
"ptanRequired": false,
"transactionEnrollmentProcesses": {
"claimPayment": {
"requestedEffectiveDate": "NOT_SUPPORTED",
"supportedAggregationPreferences": [
"NPI",
"TIN"
],
"timeframe": "DAYS",
"type": "ONE_CLICK"
}
}
},
"names": [
"MediGold",
"Medigold Health Plans",
"Mount Carmel Health Plan",
"Mount Carmel MediGold",
"Trinity Health Plan of Michigan"
],
"operatingStates": [
"ID",
"IA",
"MI",
"NY",
"OH"
],
"parentPayerGroupId": "GTRSH",
"primaryPayerId": "95655",
"stediId": "YKHRB",
"transactionSupport": {
"claimPayment": "ENROLLMENT_REQUIRED",
"claimStatus": "SUPPORTED",
"claimSubmission": "SUPPORTED",
"coordinationOfBenefits": "NOT_SUPPORTED",
"dentalClaimSubmission": "NOT_SUPPORTED",
"eligibilityCheck": "SUPPORTED",
"institutionalClaimSubmission": "SUPPORTED",
"professionalClaimSubmission": "SUPPORTED",
"unsolicitedClaimAttachment": "NOT_SUPPORTED"
},
"urls": {
"website": "https://www.thpmedicare.org"
}
}
],
"nextPageToken": "yrZ3we9982etYlMgmw=="
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# CMS-1500 PDF: Business Identifier
Source: https://www.stedi.com/docs/healthcare/api-reference/get-pdf-1500-business-identifier
This endpoint uses a business identifier to retrieve autogenerated CMS-1500 Claim Form PDFs for submitted 837P professional claims.
1. Call this endpoint with the `businessId` query parameter set to the claim's correlation ID. The correlation ID is returned as the `claimReference.correlationId` in the synchronous response Stedi returns when you submit a professional claim.
2. The endpoint returns an array of PDFs for all claims with the specified `businessId` value. PDFs are returned as a base64 encoded string.
To view a PDF, decode the base64 string and save it to a file with a `.pdf` extension.
If you plan to send these PDFs to payers or retain them for your records, we
strongly recommend visiting [CMS-1500 Claim Form PDF](/healthcare/cms-1500-claim-form-pdf) for information about structuring claim submissions for optimal generation, the correct printer
settings, and best practices.
## API Specification
Retrieve a Stedi generatedCMS-1500 Claim Form PDF for a submitted 837P (professional) claim by business identifier
**Endpoint:** `GET /export/pdf`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Parameters
- **`businessId`** (query) (required): The business identifier for the claim PDF you want to retrieve. This value is returned as the `claimReference.correlationId` in the synchronous response Stedi returns when you submit a professional claim.
- Type: `string`
- **`background`** (query): If false, the generated PDF will only contain the form data on a white background, suitable for printing on pre-printed forms. The default is true.
- Type: `boolean`
### Responses
#### 200
ExportPDF 200 response
**Schema:** `ExportPDFResponseContent`
**Properties:**
- **`errors`** (`array`): Errors that prevented Stedi from returning one or more PDFs for the specified `businessId`. This array may be empty if there were no errors.
- Items schema: `PDFError`
- **`pdfs`** (`array`): Data for PDF files Stedi generated for the specified `businessId`. This array may be empty if there are no PDFs available for the specified `businessId`. It may also contain multiple PDFs if there is more than one claim with the same `businessId` value.
- Items schema: `PDFData`
**Example:**
```json
{
"errors": [
{
"error": "No artifacts found for transaction",
"transactionId": "a10b3344-7288-484a-8dbb-b240c123c767"
}
],
"pdfs": [
{
"data": "JVBERi0xLjcKJYGBgYEKCjcgMCBvYmoKPDwKL0ZpbHRlciAvRmxhdGVEZWNvZGUKL0xlbmd0aCAxMAo ...",
"transactionId": "a10b1111-7233-484c-8dee-b240c590c767"
}
]
}
```
#### 400
ExportPDF400Error 400 response
**Schema:** `ExportPDF400ErrorResponseContent`
#### 403
ExportPDF403Error 403 response
**Schema:** `ExportPDF403ErrorResponseContent`
#### 404
ExportPDF404Error 404 response
**Schema:** `ExportPDF404ErrorResponseContent`
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# CMS-1500 PDF: Transaction ID
Source: https://www.stedi.com/docs/healthcare/api-reference/get-pdf-1500
This endpoint uses a claim's `transactionId` to retrieve autogenerated CMS-1500 Claim Form PDFs for submitted 837P professional claims.
1. Call this endpoint with the `transactionId` path parameter set to the claim's transaction ID. This ID is included in the transaction processed event for the claim, which you can receive automatically through Stedi [webhooks](/healthcare/configure-webhooks). You can also retrieve this ID through the [Poll Transactions](/healthcare/api-reference/get-poll-transactions) endpoint or from the transaction's details page within Stedi.
2. The endpoint returns the PDF data as a base64 encoded string.
To view the PDF, decode the base64 string and save it to a file with a `.pdf` extension.
If you plan to send these PDFs to payers or retain them for your records, we
strongly recommend visiting [CMS-1500 Claim Form PDF](/healthcare/cms-1500-claim-form-pdf) for information about structuring claim submissions for optimal generation, the correct printer
settings, and best practices.
## API Specification
Retrieve the generated CMS-1500 Claim Form PDF for a submitted 837P professional claim
**Endpoint:** `GET /export/{transactionId}/1500/pdf`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Parameters
- **`transactionId`** (path) (required): A unique identifier for the processed claim within Stedi. This ID is included in the transaction processed event for the claim, which you can receive automatically through Stedi [webhooks](https://www.stedi.com/docs/healthcare/configure-webhooks). You can also retrieve this ID through the [Poll Transactions endpoint](https://www.stedi.com/docs/healthcare/api-reference/get-poll-transactions) or from the transaction's details page within Stedi.
- Type: `string`
- **`background`** (query): If false, the generated PDF will only contain the form data on a white background, suitable for printing on pre-printed forms. The default is true.
- Type: `boolean`
### Responses
#### 200
GetPDF1500 200 response
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`code`** (`string`): A code describing the type of validation failure.
- **`message`** (`string`) (required): A message describing the causes of the validation failure. There may be more than one.
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# Poll transactions
Source: https://www.stedi.com/docs/healthcare/api-reference/get-poll-transactions
This endpoint returns details about transactions that Stedi processed after the specified `startDateTime`.
You can use this endpoint to poll for new 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA) transactions in your account. Visit [Poll for transactions](/healthcare/receive-claim-responses#poll-for-transactions) for a step-by-step guide.
## Results [#results]
Transactions are ordered from oldest to newest according to the `processedAt` property. This is *exclusive* of the `startDateTime`. For example, if the provided `startDateTime` is `2023-08-10T18:00:00Z`, a transaction processed at exactly that time would not be included in the results.
There is also a fifteen-second window where newly created transactions are excluded, meaning Stedi returns results up to fifteen seconds before the time of your request. This functionality accounts for any network latency or clock drift within the systems to ensure you don't miss any transactions.
## Polling with page tokens [#polling-with-page-tokens]
We **don't** recommend polling using `startDateTime` only. Due to the exclusive nature of `startDateTime`, you could potentially miss a transaction if two transactions occur at the *exact* same time and are on the edge of a pagination. Instead, you should use `pageToken`.
After the initial request, you can poll again immediately using `pageToken` to continue iterating through the pages of transactions. The endpoint always returns a `nextPageToken`, regardless of whether additional transactions match the request criteria. If the `items` array is empty, continue using the provided `nextPageToken` to poll for new transactions. New transactions will be returned when available.
We recommend storing `pageToken` values as part of your polling process. They don't expire, allowing you to start from that point in the transaction stream again if you need to catch a system up to date or recover from a failure.
Note that `pageToken` values are unique per request, opaque, and shouldn't be parsed or modified in any way. They are not guaranteed to be in any particular format, and may change in the future.
## API Specification
Poll for new transactions that Stedi has processed.
**Endpoint:** `GET /polling/transactions`
**Base URL:** `https://core.us.stedi.com/2023-08-01`
### Parameters
- **`pageSize`** (query): The maximum number of elements to return in a page. You can set this to a maximum of 500 elements. If not specified, the default is 100.
- Type: `number`
- **`pageToken`** (query): A token returned by a previous call to this operation in the `nextPageToken`. If not specified, Stedi returns the first page of results.
You must supply either this property or `startDateTime` in every request.
- Type: `string`
- **`startDateTime`** (query): An ISO 8601 formatted string. For example `2023-08-28T00:00:00Z`. It must be at least one minute in the past. Stedi returns transactions processed after this time.
You must supply either this property or `pageToken` in every request.
- Type: `string`
### Responses
#### 200
ListPollingTransactions 200 response
**Schema:** `ListPollingTransactionsResponseContent`
**Properties:**
- **`nextPageToken`** (`string`): Token that you can supply in subsequent requests to retrieve the next page of results. If not returned, there are no more results.
- **`items`** (`array`) (required)
- Items schema: `TransactionSummary`
**Example:**
```json
{
"items": [
{
"direction": "INBOUND",
"mode": "test",
"status": "succeeded",
"fileExecutionId": "95236a56-a020-4522-8fef-bcffcec0ec1d",
"transactionId": "c8dd3a67-b8ca-4b0e-aa73-e0de82414b8f",
"processedAt": "2025-04-02T21:30:15.801Z",
"artifacts": [
{
"artifactType": "application/edi-x12",
"sizeBytes": 8374,
"model": "transaction",
"usage": "input",
"url": "https://core.us.stedi.com/2023-08-01/transactions/4443355-b8ca-4b0e-aa73-e0de12314b8f/input"
},
{
"artifactType": "application/json",
"sizeBytes": 76898,
"model": "transaction",
"usage": "output",
"url": "https://core.us.stedi.com/2023-08-01/transactions/111222333-b8ca-4b0e-aa73-e0de67454b8f/output"
}
],
"partnership": {
"partnershipId": "local-clearinghouse-test",
"partnershipType": "x12",
"sender": {
"profileId": "clearinghouse-test"
},
"receiver": {
"profileId": "local"
}
},
"businessIdentifiers": [
{
"elementId": "127",
"element": "BHT-03",
"name": "Reference Identification",
"value": "XXXXXX"
}
],
"x12": {
"metadata": {
"interchange": {
"acknowledgmentRequestedCode": "0",
"controlNumber": 1
},
"functionalGroup": {
"controlNumber": 1,
"release": "005010X222A1",
"date": "2025-04-02",
"time": "21:29:57",
"functionalIdentifierCode": "HC"
},
"transaction": {
"controlNumber": "0001",
"transactionSetIdentifier": "837"
},
"receiver": {
"applicationCode": "STEDI-TEST",
"isa": {
"qualifier": "ZZ",
"id": "STEDI-TEST"
}
},
"sender": {
"applicationCode": "TestSender",
"isa": {
"qualifier": "ZZ",
"id": "TestSender"
}
}
},
"transactionSetting": {
"guideId": "01JQW6E5RSBSTKS3ZQ1SPR4019",
"transactionSettingId": "01JQW6E72Q3HDXM40YYAQCBZDY"
}
}
}
]
}
```
#### 400
BadRequestException 400 response
**Schema:** `BadRequestExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 409
ResourceUnderChangeException 409 response
**Schema:** `ResourceUnderChangeExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
#### 422
UnprocessableEntityException 422 response
**Schema:** `UnprocessableEntityExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 500
ServiceException 500 response
**Schema:** `ServiceExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`exceptionCause`** (`object`)
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
# Search Payers
Source: https://www.stedi.com/docs/healthcare/api-reference/get-search-payers
This endpoint queries the [Payer Network](https://www.stedi.com/healthcare/network). It's especially useful when you want to embed dynamic payer search capabilities into your system or application.
1. Call this endpoint with your desired search criteria. You can search by the payer's name, [payer ID](/healthcare/supported-payers#payer-ids), or payer ID aliases. You can also filter the results by supported transaction types.
2. The endpoint returns information about matching payers, including their possible names, their primary payer ID, payer ID aliases, and supported transaction types.
The search supports fuzzy matching, which means that the results contain an array of exact (if available) and close matches.
## Results [#results]
When you specify multiple transaction filters, they are combined with AND logic, meaning payers must satisfy all specified transaction criteria to be included in results.
Stedi weights results based on text match relevance and additional factors, such as payer size, market share, and transaction volume in order to present the most likely matches first. Stedi also accounts for potential misspellings (a search for CEGNA still returns CIGNA) and transposed letters (a search for ICGNA still returns CIGNA) when searching the payer database.
## Examples [#examples]
This page contains two examples of search results:
* **Search for query string**: This example response shows the results of a basic search for the query string "Blue Cross". The URL for this request is `https://healthcare.us.stedi.com/2024-04-01/payers/search?query=Blue%20Cross`.
* **Search with multiple filters**: This example response shows the results of a more advanced search that includes a query string for "Blue Cross", plus additional query parameters that filter for payers supporting eligibility checks and real-time claim status. The URL for this request is `https://healthcare.us.stedi.com/2024-04-01/payers/search?query=Blue%20Cross&eligibilityCheck=SUPPORTED&claimStatus=SUPPORTED`. This advanced search only returns payers that support both eligibility checks and claim status, while the basic search returns all payers, regardless of the transaction types they support.
Both examples are truncated for brevity to show only one payer matching the results.
## API Specification
Search for payers by name, ID, or alias.
**Endpoint:** `GET /payers/search`
**Base URL:** `https://payers.us.stedi.com/2024-04-01`
### Parameters
- **`pageSize`** (query): The maximum number of elements to return in a page. If not specified, the default is 20.
- Type: `integer`
- **`pageToken`** (query): An opaque token returned by a previous call to this endpoint in the `nextPageToken` property. You can use it to request the next page of results. If not specified, Stedi returns the first page of results.
- Type: `string`
- **`query`** (query): The query Stedi will use to search the Payer Network database. You can supply a payer's name, ID, or alias. The query is case-insensitive, and fuzzy matching is supported. For example, `cig`, `62308`, and `SX071` all return Cigna in the results. If not provided, the other search options are used to conduct the search.
- Type: `string`
- **`eligibilityCheck`** (query): Filter for matching payers with the specified 270 eligibility checks support. When combined with other transaction filters, payers must satisfy **all** specified criteria to be included in results.
- **`claimStatus`** (query): Filter for matching payers with the specified 276/277 real-time claim status checks support. When combined with other transaction filters, payers must satisfy **all** specified criteria to be included in results.
- **`professionalClaimSubmission`** (query): Filter for matching payers with the specified 837 professional claims support. When combined with other transaction filters, payers must satisfy **all** specified criteria to be included in results.
- **`dentalClaimSubmission`** (query): Filter for matching payers with the specified 837 dental claims support. When combined with other transaction filters, payers must satisfy **all** specified criteria to be included in results.
- **`institutionalClaimSubmission`** (query): Filter for matching payers with the specified 837 institutional claims support. When combined with other transaction filters, payers must satisfy **all** specified criteria to be included in results.
- **`claimPayment`** (query): Filter for matching payers with the specified 835 Electronic Remittance Advice (ERA) support. When combined with other transaction filters, payers must satisfy **all** specified criteria to be included in results.
- **`coordinationOfBenefits`** (query): Filter for matching payers with the specified coordination of benefits (COB) checks support. When combined with other transaction filters, payers must satisfy **all** specified criteria to be included in results.
- **`unsolicitedClaimAttachment`** (query): Filter for matching payers with the specified unsolicited 275 claim attachments support. When combined with other transaction filters, payers must satisfy **all** specified criteria to be included in results.
- **`coverageTypes`** (query): Filter for matching payers that support transactions for **all** of the specified coverage types. For example, setting this array to `["medical", "dental"]` returns only payers who provide both medical and dental coverage.
The results also exclude payers without coverage type classifications in Stedi's database.
- Type: `array`
- **`operatingStates`** (query): Filter for matching payers that operate in **all** of the specified states. For example, setting this array to `["CA", "OR"]` returns only payers that operate in both California and Oregon, and setting it to `["NATIONAL"]` returns payers that operate throughout the entire United States.
The results also exclude payers without operating state classifications in Stedi's database.
- Type: `array`
### Responses
#### 200
SearchPayers 200 response
**Schema:** `SearchPayersResponseContent`
**Properties:**
- **`items`** (`array`) (required): Matching payers sorted by relevance, with the most relevant matches listed first.
- Items schema: `SearchResult`
- **`nextPageToken`** (`string`): Token that you can supply in subsequent requests to retrieve the next page of results. If not returned, there are no more results.
- **`stats`** (`object`) (required): Statistics about the search results, including the total number of payers matching the search query and the number of payers supported per transaction type.
**Example:**
```json
{
"items": [
{
"matches": {
"names": [
"Highmark Blue Cross Blue Shield",
"Highmark Blue Cross Blue Shield Pennsylvania",
"Highmark Blue Cross Blue Shield Pennsylvania Professional",
"Highmark Blue Shield",
"Keystone Health Plan West - Community Blue HMO"
]
},
"payer": {
"aliases": [
"10046",
"100900",
"10264",
"10524",
"2413",
"54771",
"95462",
"PABCBS",
"PABLS",
"SB865",
"SB865MA",
"SZXAY"
],
"avatarUrl": "https://prod-payer-avatars.payers.us.stedi.com/GUFCO/avatar.png?v=1763077235241",
"conciseName": "Highmark PA",
"coverageTypes": [
"dental",
"medical",
"vision"
],
"displayName": "Highmark of Pennsylvania",
"enrollment": {
"ptanRequired": false,
"transactionEnrollmentProcesses": {
"claimPayment": {
"requestedEffectiveDate": "NOT_SUPPORTED",
"supportedAggregationPreferences": [
"NPI",
"TIN"
],
"timeframe": "DAYS",
"type": "ONE_CLICK"
},
"claimStatusInquiry": {
"timeframe": "DAYS",
"type": "ONE_CLICK"
}
}
},
"names": [
"Highmark Blue Cross Blue Shield",
"Highmark Blue Cross Blue Shield Pennsylvania",
"Highmark Blue Cross Blue Shield Pennsylvania Professional",
"Highmark Blue Shield",
"Keystone Health Plan West - Community Blue HMO",
"First Priority Life Insurance Company (FPLIC) Out-of-Area Claims",
"Highmark of Pennsylvania - Medicare Advantage"
],
"operatingStates": [
"PA"
],
"parentPayerGroupId": "QOSPQ",
"primaryPayerId": "54771",
"stediId": "GUFCO",
"transactionSupport": {
"claimPayment": "ENROLLMENT_REQUIRED",
"claimStatus": "ENROLLMENT_REQUIRED",
"coordinationOfBenefits": "SUPPORTED",
"dentalClaimSubmission": "NOT_SUPPORTED",
"eligibilityCheck": "ENROLLMENT_REQUIRED",
"institutionalClaimSubmission": "NOT_SUPPORTED",
"professionalClaimSubmission": "SUPPORTED",
"unsolicitedClaimAttachment": "NOT_SUPPORTED"
}
},
"score": 2314894167593451500
}
],
"stats": {
"total": 142,
"transactionSupport": {
"claimPayment": {
"enrollmentRequired": 113,
"notSupported": 29,
"supported": 0
},
"claimStatus": {
"enrollmentRequired": 3,
"notSupported": 55,
"supported": 84
},
"coordinationOfBenefits": {
"enrollmentRequired": 0,
"notSupported": 114,
"supported": 28
},
"dentalClaimSubmission": {
"enrollmentRequired": 2,
"notSupported": 95,
"supported": 45
},
"eligibilityCheck": {
"enrollmentRequired": 5,
"notSupported": 33,
"supported": 104
},
"institutionalClaimSubmission": {
"enrollmentRequired": 10,
"notSupported": 30,
"supported": 102
},
"professionalClaimSubmission": {
"enrollmentRequired": 9,
"notSupported": 16,
"supported": 117
},
"unsolicitedClaimAttachment": {
"enrollmentRequired": 0,
"notSupported": 109,
"supported": 33
}
},
"transactionSupportCounts": {
"claimPayment": {
"notSupported": {
"total": 29
},
"supported": {
"enrollmentNotRequired": 0,
"enrollmentRequired": 113,
"total": 113
}
},
"claimStatus": {
"notSupported": {
"total": 55
},
"supported": {
"enrollmentNotRequired": 84,
"enrollmentRequired": 3,
"total": 87
}
},
"coordinationOfBenefits": {
"notSupported": {
"total": 114
},
"supported": {
"enrollmentNotRequired": 28,
"enrollmentRequired": 0,
"total": 28
}
},
"dentalClaimSubmission": {
"notSupported": {
"total": 95
},
"supported": {
"enrollmentNotRequired": 45,
"enrollmentRequired": 2,
"total": 47
}
},
"eligibilityCheck": {
"notSupported": {
"total": 33
},
"supported": {
"enrollmentNotRequired": 104,
"enrollmentRequired": 5,
"total": 109
}
},
"institutionalClaimSubmission": {
"notSupported": {
"total": 30
},
"supported": {
"enrollmentNotRequired": 102,
"enrollmentRequired": 10,
"total": 112
}
},
"professionalClaimSubmission": {
"notSupported": {
"total": 16
},
"supported": {
"enrollmentNotRequired": 117,
"enrollmentRequired": 9,
"total": 126
}
},
"unsolicitedClaimAttachment": {
"notSupported": {
"total": 109
},
"supported": {
"enrollmentNotRequired": 33,
"enrollmentRequired": 0,
"total": 33
}
}
}
}
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Retrieve Transaction Input
Source: https://www.stedi.com/docs/healthcare/api-reference/get-transactions-input
This endpoint retrieves a transaction's input document before it passes through any translation or mappings.
The input document can be in either X12 EDI or JSON format, depending on the direction of the transaction. For example, if a payer sends you an 835 ERA, the input document will be in the original X12 EDI format.
Note that when the input is X12 EDI, the document only includes the transaction information (`ST` to `SE` segments) and doesn't include the envelope. To retrieve the full X12 EDI document with the envelope, use the [Retrieve File Execution Input](/healthcare/api-reference/get-execution-input) endpoint instead.
There are no size restrictions on documents when fetching from this endpoint.
## Response [#response]
This endpoint returns a `302` Temporary redirect to the document download URL. Many HTTP clients will automatically follow this redirect, or have a simple follow redirects configuration to set. For example, using the `-L` or `--location` flag in cURL will automatically follow the redirect. In this case, the response will contain the full transaction input document.
In the event you cannot, or chose not to automatically follow the redirect, the body of the response contains a JSON object with a single key `documentDownloadUrl` which contains a temporary URL to download the document. This URL is available for 60 minutes.
## API Specification
Retrieve a transaction's input document.
**Endpoint:** `GET /transactions/{transactionId}/input`
**Base URL:** `https://core.us.stedi.com/2023-08-01`
### Parameters
- **`transactionId`** (path) (required): A unique identifier for the processed transaction within Stedi. This ID is included in the transaction processed event, or you can retrieve it manually from the transaction's details page within the Stedi portal.
- Type: `string`
### Responses
#### 302
GetTransactionInputDocument 302 response
**Schema:** `GetTransactionInputDocumentResponseContent`
**Properties:**
- **`documentDownloadUrl`** (`string`): A URL to download the document. This URL is available for 60 minutes.
**Example:**
```json
{
"documentDownloadUrl": "https://stedi-default-core-artifacts.s3.us-east-1.amazonaws.com/55907f88-999e-4912-9e9..."
}
```
#### 400
BadRequestException 400 response
**Schema:** `BadRequestExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 409
ResourceUnderChangeException 409 response
**Schema:** `ResourceUnderChangeExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
#### 422
UnprocessableEntityException 422 response
**Schema:** `UnprocessableEntityExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 500
ServiceException 500 response
**Schema:** `ServiceExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`exceptionCause`** (`object`)
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
# Retrieve Transaction Output
Source: https://www.stedi.com/docs/healthcare/api-reference/get-transactions-output
This endpoint retrieves a transaction's output document, which is the result after Stedi has finished translating and mapping the input document.
The output document can be in either X12 EDI or JSON format, depending on the direction of the transaction. For example, if a payer sends you an 835 ERA, the output document will be a JSON representation of the 835 ERA.
Note that when the output is X12 EDI, the document only includes the transaction information (`ST` to `SE` segments) and doesn't include the envelope.
There are no size restrictions on documents when fetching from this endpoint.
## Response [#response]
This endpoint returns a `302` Temporary redirect to the document download URL. Many HTTP clients will automatically follow this redirect, or have a simple follow redirects configuration to set. For example, using the `-L` or `--location` flag in cURL will automatically follow the redirect. In this case, the response body will contain the full transaction output document.
In the event you cannot, or chose not to automatically follow the redirect, the body of the response contains a JSON object with a single key `documentDownloadUrl` which contains a temporary URL to download the document. This URL is available for 60 minutes.
## API Specification
Retrieve a transaction's output document.
**Endpoint:** `GET /transactions/{transactionId}/output`
**Base URL:** `https://core.us.stedi.com/2023-08-01`
### Parameters
- **`transactionId`** (path) (required): A unique identifier for the processed transaction within Stedi. This ID is included in the transaction processed event, or you can retrieve it manually from the transaction's details page within the Stedi portal.
- Type: `string`
### Responses
#### 302
GetTransactionOutputDocument 302 response
**Schema:** `GetTransactionOutputDocumentResponseContent`
**Properties:**
- **`documentDownloadUrl`** (`string`): A URL to download the document. This URL is available for 60 minutes.
**Example:**
```json
{
"documentDownloadUrl": "https://stedi-default-core-artifacts.s3.us-east-1.amazonaws.com/55907f88-999e-4912-9e9..."
}
```
#### 400
BadRequestException 400 response
**Schema:** `BadRequestExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 409
ResourceUnderChangeException 409 response
**Schema:** `ResourceUnderChangeExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
#### 422
UnprocessableEntityException 422 response
**Schema:** `UnprocessableEntityExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 500
ServiceException 500 response
**Schema:** `ServiceExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`exceptionCause`** (`object`)
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
# Retrieve Transaction
Source: https://www.stedi.com/docs/healthcare/api-reference/get-transactions
This endpoint retrieves information about the transaction with the specified `transactionId`.
## API Specification
Fetch details for a specific transaction.
**Endpoint:** `GET /transactions/{transactionId}`
**Base URL:** `https://core.us.stedi.com/2023-08-01`
### Parameters
- **`transactionId`** (path) (required): A unique identifier for the processed transaction within Stedi. This ID is included in the transaction processed event. You can also retrieve it manually from the transaction's details page within the Stedi portal.
- Type: `string`
### Responses
#### 200
GetTransaction 200 response
**Schema:** `GetTransactionResponseContent`
**Properties:**
- **`transactionId`** (`string`) (required): A unique identifier for the processed transaction within Stedi. This ID is included in the transaction processed event. You can also retrieve it manually from the transaction's details page within the Stedi portal.
- **`fileExecutionId`** (`string`) (required): A unique identifier for the processed file within Stedi. This ID is included in the transaction processed event. You can also retrieve it manually from the file's details page in the Stedi portal.
- **`status`** (`object`) (required)
- **`direction`** (`object`) (required)
- **`mode`** (`object`) (required)
- **`processedAt`** (`string`) (required): The date and time when Stedi processed the transaction, in ISO 8601 format. For example, `2023-08-28T00:00:00Z`.
- **`artifacts`** (`array`) (required): A list of artifacts related to the transaction.
- Items schema: `Artifact`
- **`partnership`** (`object`) (required)
- **`x12`** (`object`)
- **`fragments`** (`object`)
- **`translationErrors`** (`array`): Details about errors that prevented Stedi from processing the transaction.
- Items schema: `TranslationError`
- **`businessIdentifiers`** (`array`): Any business identifiers extracted from the transaction.
- Items schema: `BusinessIdentifier`
**Example:**
```json
{
"direction": "INBOUND",
"mode": "test",
"status": "succeeded",
"fileExecutionId": "95236a56-a020-4522-8fef-bcffcec0ec1d",
"transactionId": "c8dd3a67-b8ca-4b0e-aa73-e0de82414b8f",
"processedAt": "2025-04-02T21:30:15.801Z",
"artifacts": [
{
"artifactType": "application/edi-x12",
"sizeBytes": 8374,
"model": "transaction",
"usage": "input",
"url": "https://core.us.stedi.com/2023-08-01/transactions/c8dd1111-b8ca-4330e-aa73-e0de33314b8f/input"
},
{
"artifactType": "application/json",
"sizeBytes": 76898,
"model": "transaction",
"usage": "output",
"url": "https://core.us.stedi.com/2023-08-01/transactions/c8dd3a67-b8ca-4b0e-kk73-55667882414b8f/output"
}
],
"partnership": {
"partnershipId": "stedi_test-sender",
"partnershipType": "x12",
"sender": {
"profileId": "test-sender"
},
"receiver": {
"profileId": "stedi"
}
},
"businessIdentifiers": [
{
"elementId": "127",
"element": "BHT-03",
"name": "Reference Identification",
"value": "XXXXXX"
}
],
"x12": {
"metadata": {
"interchange": {
"acknowledgmentRequestedCode": "0",
"controlNumber": 1
},
"functionalGroup": {
"controlNumber": 1,
"release": "005010X222A1",
"date": "2025-04-02",
"time": "21:29:57",
"functionalIdentifierCode": "HC"
},
"transaction": {
"controlNumber": "0001",
"transactionSetIdentifier": "837"
},
"receiver": {
"applicationCode": "STEDI-TEST",
"isa": {
"qualifier": "ZZ",
"id": "STEDI-TEST"
}
},
"sender": {
"applicationCode": "TestSender",
"isa": {
"qualifier": "ZZ",
"id": "TestSender"
}
}
},
"transactionSetting": {
"guideId": "01JQW6E5RSBSTKS3ZQ1SPR4019",
"transactionSettingId": "01JQW6E72Q3HDXM40YYAQCBZDY"
}
}
}
```
#### 400
BadRequestException 400 response
**Schema:** `BadRequestExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 409
ResourceUnderChangeException 409 response
**Schema:** `ResourceUnderChangeExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
#### 422
UnprocessableEntityException 422 response
**Schema:** `UnprocessableEntityExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 500
ServiceException 500 response
**Schema:** `ServiceExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`exceptionCause`** (`object`)
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`)
# API Reference
Source: https://www.stedi.com/docs/healthcare/api-reference
You can download our [OpenAPI](https://www.openapis.org/) specs below. OpenAPI is a standard, machine-readable format for describing HTTP APIs. You can use our OpenAPI spec for reference or to generate client code.
## Clearinghouse APIs [#clearinghouse-apis]
Our APIs allow you to automate business flows like [eligibility checks](/healthcare/api-reference/post-healthcare-eligibility) and [claims processing](/healthcare/api-reference/post-healthcare-claims). We also offer APIs for retrieving [Stedi's up-to-date payer list](/healthcare/api-reference/get-payers) and [provider enrollments](/healthcare/api-reference/post-enrollment-create-provider) with payers.
## Authentication [#authentication]
You need an API key to use any Stedi API. You pass the API key in the `Authorization` header of every request and Stedi determines which resources you can access.
### API key types [#api-key-types]
You can create two types of Stedi API keys: Test and Production.
Test API keys allow you to send mock requests to Stedi healthcare APIs and receive realistic mock responses, so you can test your integration without sending PHI or PII.
* Test keys can only be used in test mode with approved test requests. APIs that support test keys include a list of approved test requests you can send.
* Test keys are currently supported for the [Real-Time Eligibility Check](/healthcare/api-reference/post-healthcare-eligibility) API.
Production API keys allow you to send transactions to trading partners and payers. All Stedi APIs support production API keys.
### Creating an API key [#creating-an-api-key]
To create an API key:
1. Log into your [Stedi account](https://portal.stedi.com/app).
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. We recommend using a unique name and adding a `test` or `production` prefix to indicate the key type.
6. Choose whether the key is for test or production use.
7. Click **Generate**. Stedi generates an API key and allows you to copy it.
Make sure you copy your API key and store it in a safe location. Once you close the modal, Stedi will not show the API key again.
### API key access [#api-key-access]
Within your Stedi account, members can be assigned to roles with different permissions. Production API keys inherit the permissions of the account member who created them and keep those permissions even if the creator's role is later updated.
### Passing the API key [#passing-the-api-key]
Every request you send needs to include an API key. You pass the API key in the `Authorization` header. For example, if your API key is `Jclcke.ZHqS3demo4dS16XZ1KeyBY7`, you would insert it into the header according to the following example:
```bash
curl --request POST \
--url https://core.us.stedi.com/2023-08-01/x12/partnerships/{partnershipId}/generate-edi \
--header 'Authorization: Jclcke.ZHqS3demo4dS16XZ1KeyBY7' \
--header 'Content-Type: application/json' \
--data '{ ... }'
```
Stedi supports the previous method of prefixing the API key with `Key` (e.g.
`Authorization: Key Jclcke.ZHqS3demo4dS16XZ1KeyBY7`) for
backwards-compatibility.
### Deleting an API key [#deleting-an-api-key]
API keys don't expire automatically. To revoke an API key, delete it from the [API keys page](https://portal.stedi.com/app/settings/api-keys) in your Stedi account.
## Pagination [#pagination]
When you request a list of resources, the response may contain a subset of available responses. In that case, the response will include a key called `next_page_token`. To retrieve the next page of results, repeat the request, but add the query parameter `page_token` and give it the value you received in the response.
For example, when you call the [List Transactions API](/healthcare/api-reference/get-list-transactions), the result contains a list of every transaction within your Stedi account and a token for the next page.
```javascript
{
"items": [ ... ],
"next_page_token": "2t7M75ZN1w4OnYFKKT0SUkT95w_ULzPR"
}
```
You can then request the next page of results like this:
```bash
curl --request GET \
--url https://core.us.stedi.com/2023-08-01/transactions?page_token=2t7M75ZN1w4OnYFKKT0SUkT95w_ULzPR \
--header "Authorization: ${STEDI_API_KEY}"
```
As long as the response contains `next_page_token`, there are more results available. If a response doesn't contain `next_page_token`, then you're on the last page.
## Error Responses [#error-responses]
If you make a request that the API can't fulfill, the response code will be in the `4xx` range and the response body will contain the following two fields.
* `error` – A code indicating what went wrong.
* `message` – A human-readable message describing what went wrong.
You can use `error` to write code that handles the error and you can use `message` when you're debugging the problem yourself. If a response needs to report multiple errors, it will include an array called `errors`, but even in that case, the `error` and `message` fields will be available at top level.
It's possible for a response to contain both a result and an error. This happens when something went wrong, but the API is able to give a partial or best-effort result.
### `403` Unauthorized [#403-unauthorized]
When you receive a `403` error from Stedi, it's likely due to one of the following reasons:
* Your API key is invalid or expired.
* You accidentally sent a `GET` request to an endpoint that only accepts `POST` requests.
* Your IP address was previously flagged as malicious. Stedi uses the Amazon Web Services (AWS) Web Application Filter (WAF) as a layer of security for our APIs. Our WAF configurations include AWS-managed rules that determine whether to allow or block each request. One set of rules blocks requests when the [source IP address is determined to be malicious](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-ip-rep.html#aws-managed-rule-groups-ip-rep-amazon), based on Amazon internal threat intelligence. We've seen this happen most often with requests sent from Google Cloud Platform (GCP), but it can occasionally happen with requests sent through other platforms as well. You can fix this issue by routing your requests through a dedicated virtual private cloud (VPC) with a static IP address.
## Concurrency limits [#concurrency-limits]
Stedi's clearinghouse endpoints are subject to the following concurrency limits per customer account. These limits are based on *concurrent* requests, not requests per second. To request an increase to your default account concurrency limits, contact Stedi support in Slack or Teams.
When endpoints share a concurrency pool, it means the total number of in-flight requests across all endpoints in the pool cannot exceed the shared limit.
{/* prettier-ignore-start */}
| Endpoints | Shared pool | Default concurrency limit |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------------------- |
| - Real-time eligibility check JSON
- Real-time eligibility check Raw X12
- Real-time claim status JSON
- Real-time claim status Raw X12
| Yes | 50 |
| - Professional claims JSON
- Professional claims Raw X12
- Institutional claims JSON
- Dental claims JSON
- Dental claims Raw X12
- Create claim attachment JSON
- Submit claim attachment JSON
- Submit claim attachment Raw X12
| Yes | 100 |
| - CMS-1500 PDF: Business Identifier
- CMS-1500 PDF: Transaction ID
- 277CA Report
- 835 ERA Report
| Yes | 100 |
| Coordination of Benefits Check | No | 50 |
| Insurance Discovery Check | No | 5 |
| Insurance Discovery Check Results | No | 5 |
{/* prettier-ignore-end */}
When you reach the maximum concurrency limit for an endpoint, Stedi rejects additional requests with a `429` HTTP status code until one of your previous requests is completed. Rejected requests have the following error message:
```json
{
"message": "The request can't be submitted because the sender's submission has been throttled: CUSTOMER_LIMIT",
"code": "TOO_MANY_REQUESTS"
}
```
## API clients [#api-clients]
We strongly recommend determining the HIPAA and/or other security requirements for your organization before you begin testing with an API client. At a minimum, if you're testing APIs that handle PHI (Protected Health Information) from your local machine, we recommend using a client that defaults to local-only storage.
### Not recommended [#not-recommended]
We **don't recommend** using Postman for requests containing Protected Health Information (PHI) because Postman defaults to storing request history - including full request payloads - on its cloud servers. You can’t turn this feature off without impractical workarounds. So if your company doesn't have a BAA in place with Postman, you could unintentionally fall short of HIPAA requirements when testing.
You can learn more about why Postman isn't safe for requests containing PHI in our blog: [Postman is probably not HIPAA compliant](https://www.stedi.com/blog/postman-is-probably-not-hipaa-compliant).
### Recommended [#recommended]
The following open-source API clients have an offline-first approach. Each client also supports OpenAPI imports, which you can use to import the Stedi OpenAPI specs.
* [Bruno](https://www.usebruno.com/): A local-only API client built to avoid cloud syncing. Bruno has several interfaces, including a desktop app, CLI, and VS Code extension. [GitHub repository](https://github.com/usebruno/bruno)
* [Pororoca](https://pororoca.io/): A desktop-only API client with no cloud sync, built for secure local testing. Poroca’s data policy states that no data is synced to remote servers. [GitHub repository](https://github.com/alexandrehtrb/Pororoca)
* [Yaak](https://yaak.app/): A simple, fast desktop API client. Yaak supports several import formats, including Postman collections, OpenAPI, and Insomnia. [GitHub repository](https://github.com/mountain-loop/yaak)
Ensure your security and compliance teams review the tool you choose carefully, especially because applications evolve over time.
## Idempotency keys [#idempotency-keys]
Idempotency allows you to make an API request multiple times without causing different outcomes. We **strongly recommend** adding idempotency keys to claim submission requests to prevent sending duplicate claims to payers when there are network errors or other intermittent failures.
We support idempotency keys for the following endpoints:
* [Professional Claims (837P) JSON](/healthcare/api-reference/post-healthcare-claims)
* [Professional Claims (837P) Raw X12](/healthcare/api-reference/post-healthcare-claims-raw-x12)
* [Dental Claims (837D) JSON](/healthcare/api-reference/post-healthcare-dental-claims)
* [Dental Claims (837D) Raw X12](/healthcare/api-reference/post-healthcare-dental-claims-raw-x12)
* [Institutional Claims (837I) JSON](/healthcare/api-reference/post-healthcare-institutional-claims)
* [Institutional Claims (837I) Raw X12](/healthcare/api-reference/post-healthcare-institutional-claims-raw-x12)
### How idempotency works [#how-idempotency-works]
You can safely retry requests with the same idempotency key as many times as necessary within 24 hours after making the first request. Within the 24 hour period, if you reuse the same key with different request contents (change the HTTP method, path, or request body), Stedi returns a `422 Unprocessable Entity` error. After 24 hours, Stedi allows the request to execute again even if you submit the same idempotency token.
If you reuse the same key on a new request while the original request is still being processed, Stedi returns a `409 Conflict`. You can retry the request after the original request is completed. The `409` response includes a `Retry-After` header indicating a suggested number of seconds to wait before retrying.
### Generating keys [#generating-keys]
For APIs that support idempotency, you can generate and include an idempotency key within the `Idempotency-Key` header of your request. Our implementation conforms to the draft IETF [Idempotency-Key HTTP Header Field](https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/) RFC.
The token can be any unique string, such as a UUID. Common approaches to generating tokens are:
* Use an algorithm that generates a token with enough randomness, like UUID v4.
* Derive the key from data related to the API call, like the provider control number.
### Adding keys to your request [#adding-keys-to-your-request]
Once you have generated your idempotency key, include it in the header of your API request. The following example shows the header in a request:
```bash
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission \
--header 'Authorization: ${STEDI_API_KEY}' \
--header 'Idempotency-Key: 5b6f6d3e-2c6d-4e6f-8e6f-6d3e2c6d4e6f' \
--header 'Content-Type: application/json' \
--data '{ ... }'
```
## API upgrades [#api-upgrades]
We strive to maintain backwards compatibility. The following changes are considered backwards compatible:
* New API resources
* Additional optional parameters to API requests
* Additional fields in API responses
* Changes in the order of properties in API responses
* Changes in human-readable error messages
* Downgrading mandatory parameters to optional parameters.
When we introduce a breaking change, we release a root-level, dated version.
# Eligibility mock requests
Source: https://www.stedi.com/docs/healthcare/api-reference/mock-requests-eligibility-checks
When you submit the following requests with a [test API key](/healthcare/api-reference#api-key-types), Stedi returns mock benefits data from the specified payer you can use for testing. Each example includes request formats for Stedi's JSON, Raw X12, and SOAP endpoints.
You can also submit most of these mock requests through the [New eligibility check](https://portal.stedi.com/app/healthcare/checks/create) form in the UI when **Test mode** is enabled.
Mock requests are free for testing purposes and won't incur any charges in
your Stedi account.
## Test API key [#test-api-key]
When submitting these mock requests to the API, you must use a test [Stedi API key](/healthcare/api-reference#creating-an-api-key) for authentication. When using a test API key, you can only send the following mock requests to the endpoint. Stedi returns an error if you try to send production data with a test API key.
## API clients [#api-clients]
You may want to use an API client to make testing and debugging easier.
We **don't recommend** using Postman for requests containing Protected Health Information (PHI) because Postman defaults to storing request history - including full request payloads - on its cloud servers. You can’t turn this feature off without impractical workarounds.
Visit [API clients](/healthcare/api-reference#api-clients) for a list of recommended clients you can use instead.
## Eligibility check examples [#eligibility-check-examples]
The following examples work with all eligibility check endpoints. Each accordion contains tabs with request formats for:
* **JSON** - [Real-Time Eligibility Check](/healthcare/api-reference/post-healthcare-eligibility) endpoint
* **Raw X12** - [Raw X12](/healthcare/api-reference/post-healthcare-eligibility-raw-x12) endpoint
* **SOAP** - [CAQH CORE SOAP](/healthcare/api-reference/post-healthcare-eligibility-soap) endpoint
### Medical - Active coverage [#medical---active-coverage]
Request notes:
* `encounter`: Only service type code `30` is supported.
* `provider`: You can use any organization name and any NPI, as long as it passes [check digit validation](https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/NationalProvIdentStand/Downloads/NPIcheckdigit.pdf). To generate a dummy NPI, you can use [this free tool](https://jsfiddle.net/alexdresko/cLNB6).
* `subscriber`: You must use the exact values in the test request. Other birth dates, first names, last names, member IDs, and Social Security Numbers return errors.
#### Dependent [#dependent]
Each of these examples represent an eligibility check for a dependent. An individual qualifies as a dependent for eligibility checks when they are listed as a dependent on the subscriber's insurance plan AND the payer cannot uniquely identify them through information outside the subscriber's policy.
These example requests follow best practices for structuring eligibility checks. Specifically, all requests include the dependent's information, including their date of birth, in the `dependents` array. Some payers may allow different structures, such as sending the dependent's information in the `subscriber` object with the subscriber's member ID. However, we recommend following the guidance outlined in the [Real-Time Eligibility Check](/healthcare/api-reference/post-healthcare-eligibility#body.dependents) endpoint documentation for the most reliable results across all payers.
The way dependent information is included in the response varies by payer. Some contain the dependent's information in the `subscriber` object. Some include the actual subscriber's information in the `subscriber` object and the dependent's information in the `dependents` array.
**Aetna**
In this example, the dependent Jordan is the subscriber John's child. Jordan's information is returned in the `dependents` array in the response.
{/* schema:EligibilityCheckRequestContent */}
```bash test request for Aetna
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "60054",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "John",
"lastName": "Doe",
"memberId": "AETNA9wcSu"
},
"dependents": [
{
"firstName": "Jordan",
"lastName": "Doe",
"dateOfBirth": "20010714"
}
],
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for Aetna
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Aetna*****PI*60054~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*1~NM1*IL*1*Doe*John****MI*AETNA9wcSu~HL*4*3*23*0~TRN*1*00000000000000000000000000*3117151744~NM1*03*1*Doe*Jordan~DMG*D8*20010714~EQ*30~SE*14*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for Aetna
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Aetna*****PI*60054~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*1~NM1*IL*1*Doe*John****MI*AETNA9wcSu~HL*4*3*23*0~TRN*1*00000000000000000000000000*3117151744~NM1*03*1*Doe*Jordan~DMG*D8*20010714~EQ*30~SE*14*0001~GE*1*1~IEA*1*000000001~]]>
'
```
**Anthem Blue Cross Blue Shield of CA**
In this example, the dependent John is the subscriber Jane's spouse. John's information is returned in the `dependents` array in the response.
{/* schema:EligibilityCheckRequestContent */}
```bash test request for Anthem BCBSCA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "040",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Jane",
"lastName": "Doe",
"memberId": "CGMBCBSCA123"
},
"dependents": [
{
"firstName": "John",
"lastName": "Doe",
"dateOfBirth": "19750101"
}
],
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for Anthem BCBSCA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Anthem Blue Cross Blue Shield of California*****PI*040~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*1~NM1*IL*1*Doe*Jane****MI*CGMBCBSCA123~HL*4*3*23*0~TRN*1*00000000000000000000000000*3117151744~NM1*03*1*Doe*John~DMG*D8*19750101~DTP*291*D8*20260420~EQ*30~SE*15*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for Anthem BCBSCA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Anthem Blue Cross Blue Shield of California*****PI*040~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*1~NM1*IL*1*Doe*Jane****MI*CGMBCBSCA123~HL*4*3*23*0~TRN*1*00000000000000000000000000*3117151744~NM1*03*1*Doe*John~DMG*D8*19750101~DTP*291*D8*20260420~EQ*30~SE*15*0001~GE*1*1~IEA*1*000000001~]]>
'
```
**Blue Cross and Blue Shield of Texas**
In this example, the dependent Jane is the subscriber John's child. Jane's information is returned in the `dependents` array in the response.
{/* schema:EligibilityCheckRequestContent */}
```bash test request for BCBSTX
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "G84980",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "John",
"lastName": "Doe",
"memberId": "A2CBCBSTX123"
},
"dependents": [
{
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "20150101"
}
],
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for BCBSTX
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Blue Cross and Blue Shield of Texas*****PI*G84980~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*1~NM1*IL*1*Doe*John****MI*A2CBCBSTX123~HL*4*3*23*0~TRN*1*00000000000000000000000000*3117151744~NM1*03*1*Doe*Jane~DMG*D8*20150101~EQ*30~SE*14*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for BCBSTX
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Blue Cross and Blue Shield of Texas*****PI*G84980~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*1~NM1*IL*1*Doe*John****MI*A2CBCBSTX123~HL*4*3*23*0~TRN*1*00000000000000000000000000*3117151744~NM1*03*1*Doe*Jane~DMG*D8*20150101~EQ*30~SE*14*0001~GE*1*1~IEA*1*000000001~]]>
'
```
**Cigna**
In this example, the dependent Jordan is the subscriber's child. In the response, Jordan is returned in the `subscriber` object with no `dependents` array, even though they are a dependent.
{/* schema:EligibilityCheckRequestContent */}
```bash test request for Cigna
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "62308",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "John",
"lastName": "Doe",
"memberId": "CIGNAJTUxNm"
},
"dependents": [
{
"firstName": "Jordan",
"lastName": "Doe",
"dateOfBirth": "20150920"
}
],
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for Cigna
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*1~NM1*IL*1*Doe*John****MI*CIGNAJTUxNm~HL*4*3*23*0~TRN*1*00000000000000000000000000*3117151744~NM1*03*1*Doe*Jordan~DMG*D8*20150920~EQ*30~SE*14*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for Cigna
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*1~NM1*IL*1*Doe*John****MI*CIGNAJTUxNm~HL*4*3*23*0~TRN*1*00000000000000000000000000*3117151744~NM1*03*1*Doe*Jordan~DMG*D8*20150920~EQ*30~SE*14*0001~GE*1*1~IEA*1*000000001~]]>
'
```
**Oscar Health**
In this example, the dependent Jane is the subscriber John's child. Jane's information is returned in the `dependents` array in the response.
{/* schema:EligibilityCheckRequestContent */}
```bash test request for Oscar Health
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "OSCAR",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "John",
"lastName": "Doe",
"memberId": "OSCAR123456"
},
"dependents": [
{
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "20010101"
}
],
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for Oscar Health
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Oscar Health*****PI*OSCAR~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*1~NM1*IL*1*Doe*John****MI*OSCAR123456~HL*4*3*23*0~TRN*1*00000000000000000000000000*3117151744~NM1*03*1*Doe*Jane~DMG*D8*20010101~EQ*30~SE*14*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for Oscar Health
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Oscar Health*****PI*OSCAR~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*1~NM1*IL*1*Doe*John****MI*OSCAR123456~HL*4*3*23*0~TRN*1*00000000000000000000000000*3117151744~NM1*03*1*Doe*Jane~DMG*D8*20010101~EQ*30~SE*14*0001~GE*1*1~IEA*1*000000001~]]>
'
```
**UnitedHealthcare**
In this example, the dependent Jane is the subscriber John's spouse. Jane's information is returned in the `dependents` array in the response.
{/* schema:EligibilityCheckRequestContent */}
```bash test request for UnitedHealthcare
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "87726",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "John",
"lastName": "Doe",
"memberId": "UHC202649"
},
"dependents": [
{
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "19521121"
}
],
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for UnitedHealthcare
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*1~NM1*IL*1*Doe*John****MI*UHC202649~HL*4*3*23*0~TRN*1*00000000000000000000000000*3117151744~NM1*03*1*Doe*Jane~DMG*D8*19521121~EQ*30~SE*14*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for UnitedHealthcare
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*1~NM1*IL*1*Doe*John****MI*UHC202649~HL*4*3*23*0~TRN*1*00000000000000000000000000*3117151744~NM1*03*1*Doe*Jane~DMG*D8*19521121~EQ*30~SE*14*0001~GE*1*1~IEA*1*000000001~]]>
'
```
#### Subscriber only [#subscriber-only]
The following examples request benefits information for the subscriber only. The subscriber's information is sent in the `subscriber` object in the request. The payer's response contains the subscriber's information in the `subscriber` object and doesn't include any dependent information.
**Aetna**
{/* schema:EligibilityCheckRequestContent */}
```bash test request for Aetna
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "60054",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "20040404",
"memberId": "AETNA12345"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for Aetna
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Aetna*****PI*60054~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*AETNA12345~DMG*D8*20040404~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for Aetna
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Aetna*****PI*60054~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*AETNA12345~DMG*D8*20040404~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
**Ambetter**
{/* schema:EligibilityCheckRequestContent */}
```bash test request for Ambetter
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "68069",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "John",
"lastName": "Doe",
"dateOfBirth": "19940404",
"memberId": "AMBETTER123"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for Ambetter
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Centene (Medical)*****PI*68069~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*John****MI*AMBETTER123~DMG*D8*19940404~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for Ambetter
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Centene (Medical)*****PI*68069~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*John****MI*AMBETTER123~DMG*D8*19940404~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
**Cigna**
{/* schema:EligibilityCheckRequestContent */}
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"controlNumber":"123456789",
"tradingPartnerServiceId": "62308",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "James",
"lastName": "Jones",
"dateOfBirth": "19910202",
"memberId": "23456789100"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Jones*James****MI*23456789100~DMG*D8*19910202~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Jones*James****MI*23456789100~DMG*D8*19910202~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
{/* schema:EligibilityCheckRequestContent */}
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "62308",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Rolando",
"lastName": "Arrojo",
"dateOfBirth": "19710102",
"memberId": "5643296"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Arrojo*Rolando****MI*5643296~DMG*D8*19710102~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Arrojo*Rolando****MI*5643296~DMG*D8*19710102~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
{/* schema:EligibilityCheckRequestContent */}
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "62308",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Rod",
"lastName": "Beck",
"dateOfBirth": "19720203",
"memberId": "R5TJR4HR4H"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Beck*Rod****MI*R5TJR4HR4H~DMG*D8*19720203~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Beck*Rod****MI*R5TJR4HR4H~DMG*D8*19720203~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
{/* schema:EligibilityCheckRequestContent */}
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "62308",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "David",
"lastName": "Cone",
"dateOfBirth": "19730304",
"memberId": "5642296"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Cone*David****MI*5642296~DMG*D8*19730304~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Cone*David****MI*5642296~DMG*D8*19730304~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
{/* schema:EligibilityCheckRequestContent */}
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "62308",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Frank",
"lastName": "Castillo",
"dateOfBirth": "19750405",
"memberId": "FTRJRG3254"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Castillo*Frank****MI*FTRJRG3254~DMG*D8*19750405~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Castillo*Frank****MI*FTRJRG3254~DMG*D8*19750405~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
{/* schema:EligibilityCheckRequestContent */}
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "62308",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Casey",
"lastName": "Fossum",
"dateOfBirth": "19760506",
"memberId": "5641296"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Fossum*Casey****MI*5641296~DMG*D8*19760506~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Fossum*Casey****MI*5641296~DMG*D8*19760506~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
{/* schema:EligibilityCheckRequestContent */}
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "62308",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Rich",
"lastName": "Garces",
"dateOfBirth": "19770607",
"memberId": "DHW5445"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Garces*Rich****MI*DHW5445~DMG*D8*19770607~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for CIGNA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Garces*Rich****MI*DHW5445~DMG*D8*19770607~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
**Humana**
{/* schema:EligibilityCheckRequestContent */}
```bash test request for Humana
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "61101",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "19750505",
"memberId": "HUMANA123"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for Humana
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Humana*****PI*61101~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*HUMANA123~DMG*D8*19750505~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for Humana
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Humana*****PI*61101~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*HUMANA123~DMG*D8*19750505~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
**Kaiser Permanente Northern California**
{/* schema:EligibilityCheckRequestContent */}
```bash test request for Kaiser Permanente
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "KSRCN",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "20020202",
"memberId": "KAISER123456"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for Kaiser Permanente
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Kaiser Foundation Health Plan Northern California*****PI*KSRCN~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*KAISER123456~DMG*D8*20020202~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for Kaiser Permanente
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Kaiser Foundation Health Plan Northern California*****PI*KSRCN~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*KAISER123456~DMG*D8*20020202~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
**National Centers for Medicare & Medicaid Services (CMS)**
{/* schema:EligibilityCheckRequestContent */}
```bash test request for CMS
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "CMS",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "19550505",
"memberId": "CMS12345678"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for CMS
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20260420*1841~HL*1**20*1~NM1*PR*2*CMS*****PI*CMS~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*CMS12345678~DMG*D8*19550505~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for CMS
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20260420*1841~HL*1**20*1~NM1*PR*2*CMS*****PI*CMS~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*CMS12345678~DMG*D8*19550505~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
**UnitedHealthcare**
{/* schema:EligibilityCheckRequestContent */}
```bash test request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "87726",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "19710101",
"memberId": "UHC123456"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash test request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*UHC123456~DMG*D8*19710101~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*UHC123456~DMG*D8*19710101~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
#### MBI lookup for CMS checks [#mbi-lookup-for-cms-checks]
You must include the patient's Medicare Beneficiary Identifier (MBI) in every eligibility check you submit to the Centers for Medicare and Medicaid Services ([Payer ID: CMS](https://www.stedi.com/healthcare/network/cms)). When patients don’t know their MBI, you can use Stedi’s eligibility APIs to perform an MBI lookup.
This mock request is for an MBI lookup with the patient's Social Security Number (SSN), but you can also perform an MBI lookup without an SSN. Visit [MBI lookup](/healthcare/mbi-lookup) for more information.
{/* schema:EligibilityCheckRequestContent */}
```bash test request for CMS MBI Lookup
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key ' \
--header 'Content-Type: application/json' \
--data '{
"controlNumber": "112233445",
"tradingPartnerServiceId": "MBILU",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"lastName": "Doe",
"dateOfBirth": "19550505",
"ssn": "123456789"
},
"encounter": {
"serviceTypeCodes": [
"30"
]
}
}'
```
```bash test request for CMS MBI Lookup
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key ' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*CMS MBI Lookup*****PI*MBILU~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*****MI*123456789~REF*SY*123456789~DMG*D8*19550505~EQ*30~SE*13*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for CMS MBI Lookup
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*CMS MBI Lookup*****PI*MBILU~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*****MI*123456789~REF*SY*123456789~DMG*D8*19550505~EQ*30~SE*13*0001~GE*1*1~IEA*1*000000001~]]>
'
```
### Medical - Inactive coverage [#medical---inactive-coverage]
The following example requests benefits information for the subscriber.
**UnitedHealthcare**
{/* schema:EligibilityCheckRequestContent */}
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "87726",
"provider": {
"organizationName": "Provider Name",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "19710101",
"memberId": "UHCINACTIVE"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*UHCINACTIVE~DMG*D8*19710101~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*UHCINACTIVE~DMG*D8*19710101~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
### Dental [#dental]
The following example requests benefits information for the subscriber.
Request notes:
* `encounter`: Only service type code `35` is supported.
* `provider`: You can use any organization name and any NPI, as long as it passes [check digit validation](https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/NationalProvIdentStand/Downloads/NPIcheckdigit.pdf). To generate a dummy NPI, you can use [this free tool](https://jsfiddle.net/alexdresko/cLNB6).
* `subscriber`: You must use the exact values in the test request. Other birthdates, first names, last names, and member IDs return errors.
**Ameritas**
{/* schema:EligibilityCheckRequestContent */}
```bash test request for Ameritas
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "AMTAS00425",
"provider": {
"firstName": "Plaque",
"lastName": "Penguin",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Falcon",
"lastName": "Dent",
"dateOfBirth": "19850607",
"memberId": "007007007"
},
"encounter": {
"serviceTypeCodes": ["35"]
}
}'
```
```bash test request for Ameritas
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Ameritas*****PI*AMTAS00425~HL*2*1*21*1~NM1*1P*1*Penguin*Plaque****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Dent*Falcon****MI*007007007~DMG*D8*19850607~EQ*35~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for Ameritas
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Ameritas*****PI*AMTAS00425~HL*2*1*21*1~NM1*1P*1*Penguin*Plaque****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Dent*Falcon****MI*007007007~DMG*D8*19850607~EQ*35~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
**Anthem Blue Cross Blue Shield of CA**
{/* schema:EligibilityCheckRequestContent */}
```bash test request for BCBSCA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "84103",
"provider": {
"organizationName": "One",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Aardvark",
"lastName": "Dent",
"dateOfBirth": "19701212",
"memberId": "AFK987654321"
},
"encounter": {
"serviceTypeCodes": ["35"]
}
}'
```
```bash test request for BCBSCA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Anthem Blue Cross Blue Shield of California*****PI*84103~HL*2*1*21*1~NM1*1P*2*One*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Dent*Aardvark****MI*AFK987654321~DMG*D8*19701212~DTP*291*D8*20260420~EQ*35~SE*13*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for BCBSCA
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Anthem Blue Cross Blue Shield of California*****PI*84103~HL*2*1*21*1~NM1*1P*2*One*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Dent*Aardvark****MI*AFK987654321~DMG*D8*19701212~DTP*291*D8*20260420~EQ*35~SE*13*0001~GE*1*1~IEA*1*000000001~]]>
'
```
**Cigna**
{/* schema:EligibilityCheckRequestContent */}
```bash test request for Cigna
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "62308",
"provider": {
"organizationName": "One",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Jaguar",
"lastName": "Dent",
"dateOfBirth": "19960505",
"memberId": "U3141592653"
},
"encounter": {
"serviceTypeCodes": ["35"]
}
}'
```
```bash test request for Cigna
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*One*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Dent*Jaguar****MI*U3141592653~DMG*D8*19960505~EQ*35~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for Cigna
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*One*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Dent*Jaguar****MI*U3141592653~DMG*D8*19960505~EQ*35~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
**Cigna (with procedure code)**
{/* schema:EligibilityCheckRequestContent */}
```bash test request for Cigna with procedure code
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "62308",
"provider": {
"organizationName": "Smith Associates",
"npi": "1999999984"
},
"subscriber": {
"firstName": "James",
"lastName": "Doe",
"dateOfBirth": "19010101",
"memberId": "U9876543210"
},
"encounter": {
"serviceTypeCodes": ["35", "24", "28", "41", "23", "36", "37", "25", "40", "27", "39", "38", "26"],
"productOrServiceIDQualifier": "AD",
"procedureCode": "D4341",
"dateOfService": "20260401"
}
}'
```
```bash test request for Cigna with procedure code
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Smith Associates*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*James****MI*U9876543210~DMG*D8*19010101~DTP*291*D8*20260401~EQ*35~EQ*24~EQ*28~EQ*41~EQ*23~EQ*36~EQ*37~EQ*25~EQ*40~EQ*27~EQ*39~EQ*38~EQ*26*AD>D4341~SE*25*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for Cigna with procedure code
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Cigna*****PI*62308~HL*2*1*21*1~NM1*1P*2*Smith Associates*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*James****MI*U9876543210~DMG*D8*19010101~DTP*291*D8*20260401~EQ*35~EQ*24~EQ*28~EQ*41~EQ*23~EQ*36~EQ*37~EQ*25~EQ*40~EQ*27~EQ*39~EQ*38~EQ*26*AD>D4341~SE*25*0001~GE*1*1~IEA*1*000000001~]]>
'
```
**Metlife**
{/* schema:EligibilityCheckRequestContent */}
```bash test request for Metlife
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "10134",
"provider": {
"organizationName": "One",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Elephant",
"lastName": "Dent",
"dateOfBirth": "19840229",
"memberId": "88877788"
},
"encounter": {
"serviceTypeCodes": ["35"]
}
}'
```
```bash test request for Metlife
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*MetLife Dental Family*****PI*10134~HL*2*1*21*1~NM1*1P*2*One*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Dent*Elephant****MI*88877788~DMG*D8*19840229~EQ*35~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for Metlife
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*MetLife Dental Family*****PI*10134~HL*2*1*21*1~NM1*1P*2*One*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Dent*Elephant****MI*88877788~DMG*D8*19840229~EQ*35~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
**UnitedHealthcare**
{/* schema:EligibilityCheckRequestContent */}
```bash test request for UnitedHealthcare
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "52133",
"provider": {
"organizationName": "One",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Beaver",
"lastName": "Dent",
"dateOfBirth": "19690628",
"memberId": "404404404"
},
"encounter": {
"serviceTypeCodes": ["35"]
}
}'
```
```bash test request for UnitedHealthcare
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare Dental*****PI*52133~HL*2*1*21*1~NM1*1P*2*One*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Dent*Beaver****MI*404404404~DMG*D8*19690628~EQ*35~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for UnitedHealthcare
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare Dental*****PI*52133~HL*2*1*21*1~NM1*1P*2*One*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Dent*Beaver****MI*404404404~DMG*D8*19690628~EQ*35~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
### Common AAA errors [#common-aaa-errors]
The following requests return mock data for the most common Payer `AAA` errors. Visit [Eligibility troubleshooting](/healthcare/eligibility-troubleshooting) for a complete list of AAA error codes, other common eligibility check issues, and recommended resolution steps.
#### 42 - Unable to respond at current time [#42---unable-to-respond-at-current-time]
The following example request returns a `42` AAA error code, indicating that the payer is unable to respond at the current time. 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.
{/* schema:EligibilityCheckRequestContent */}
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "87726",
"provider": {
"organizationName": "Medical Provider",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "20010101",
"memberId": "UHCAAA42"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Medical Provider*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*UHCAAA42~DMG*D8*20010101~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Medical Provider*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*UHCAAA42~DMG*D8*20010101~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
#### 43 - Invalid/Missing Provider Identification [#43---invalidmissing-provider-identification]
The following example request returns a `43` AAA error code. This error can occur if provider's NPI is not registered with the payer, the provider's NPI is not registered *correctly* with the payer, or the payer requires an agreement.
{/* schema:EligibilityCheckRequestContent */}
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "87726",
"provider": {
"organizationName": "Medical Provider",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "19700101",
"memberId": "UHCAAA43"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Medical Provider*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*UHCAAA43~DMG*D8*19700101~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Medical Provider*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*UHCAAA43~DMG*D8*19700101~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
#### 72 - Invalid/Missing Subscriber/Insured ID [#72---invalidmissing-subscriberinsured-id]
The following example request returns a `72` AAA error code. This error can occur if the subscriber member ID was incorrect in the request, the request does not meet the payer's requirements for the subscriber ID, or there is another unidentified error in the request data.
{/* schema:EligibilityCheckRequestContent */}
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "87726",
"provider": {
"organizationName": "Medical Provider",
"npi": "1999999984"
},
"subscriber": {
"firstName": "John",
"lastName": "Doe",
"dateOfBirth": "19900101",
"memberId": "UHCAAA72"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Medical Provider*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*John****MI*UHCAAA72~DMG*D8*19900101~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Medical Provider*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*John****MI*UHCAAA72~DMG*D8*19900101~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
#### 73 - Invalid/Missing Subscriber/Insured Name [#73---invalidmissing-subscriberinsured-name]
The following example request returns a `73` AAA error code. This error can occur if an incorrect subscriber name was submitted, the subscriber name was missing, the subscriber name was spelled incorrectly, or the request doesn't meet the payer's requirements for the subscriber's name.
{/* schema:EligibilityCheckRequestContent */}
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "87726",
"provider": {
"organizationName": "Medical Provider",
"npi": "1999999984"
},
"subscriber": {
"firstName": "John",
"lastName": "Doe",
"dateOfBirth": "19900101",
"memberId": "UHCAAA73"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Medical Provider*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*John****MI*UHCAAA73~DMG*D8*19900101~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Medical Provider*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*John****MI*UHCAAA73~DMG*D8*19900101~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
#### 75 - Subscriber/Insured Not Found [#75---subscriberinsured-not-found]
The following example request returns a `75` AAA error code. This error occurs when the payer can't find the subscriber in their database. You should verify the subscriber details and try sending different combinations of `firstName`, `lastName`, `dateOfBirth`, and `memberId`. Note that not all search combinations are supported by all payers.
{/* schema:EligibilityCheckRequestContent */}
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "87726",
"provider": {
"organizationName": "Medical Provider",
"npi": "1999999984"
},
"subscriber": {
"firstName": "Jane",
"lastName": "Doe",
"dateOfBirth": "19900101",
"memberId": "UHCAAA75"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Medical Provider*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*UHCAAA75~DMG*D8*19900101~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Medical Provider*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*Jane****MI*UHCAAA75~DMG*D8*19900101~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
#### 79 - Invalid Participant Identification [#79---invalid-participant-identification]
The following example request returns a `79` AAA error code. This error occurs when there is a problem connecting with the payer. You should contact Stedi support for assistance.
{/* schema:EligibilityCheckRequestContent */}
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "87726",
"provider": {
"organizationName": "Medical Provider",
"npi": "1999999984"
},
"subscriber": {
"firstName": "John",
"lastName": "Doe",
"dateOfBirth": "19700101",
"memberId": "UHCAAA79"
},
"encounter": {
"serviceTypeCodes": ["30"]
}
}'
```
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Medical Provider*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*John****MI*UHCAAA79~DMG*D8*19700101~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash request for UHC
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Medical Provider*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*John****MI*UHCAAA79~DMG*D8*19700101~EQ*30~SE*12*0001~GE*1*1~IEA*1*000000001~]]>
'
```
## Test the Stedi Agent [#test-the-stedi-agent]
The [Stedi Agent](/healthcare/eligibility-searches-view#retry-with-the-stedi-agent) resolves recoverable eligibility check errors automatically with the same best practices our Support team uses for troubleshooting. You can run the following mock eligibility check to evaluate the Stedi Agent.
{/* schema:EligibilityCheckRequestContent */}
```bash test request for Stedi Agent
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"tradingPartnerServiceId": "STEDI",
"subscriber": {
"lastName": "Prohas",
"memberId": "23051322",
"firstName": "Bernie"
},
"provider": {
"organizationName": "STEDI",
"npi": "1999999984"
}
}'
```
```bash test request for Stedi Agent
curl --request POST \
--url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
--header 'Authorization: Key {test_api_key}' \
--header 'Content-Type: application/json' \
--data '{
"x12": "ISA*00* *00* *ZZ*AV09311993 *01*030240928 *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Stedi Test Payer*****PI*STEDI~HL*2*1*21*1~NM1*1P*2*STEDI*****XX*1447848577~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Prohas*Bernie****MI*23051322~EQ*30~SE*11*0001~GE*1*1~IEA*1*000000001~"
}'
```
```bash test request for Stedi Agent
curl --request POST \
--url 'https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core' \
--header 'Content-Type: application/soap+xml' \
--data '
STEDI-ACCOUNT-ID
STEDI-API-KEY
X12_270_Request_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2007-08-30T10:20:34.000Z
STEDI
STEDI
2.2.0
~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*Stedi Test Payer*****PI*STEDI~HL*2*1*21*1~NM1*1P*2*STEDI*****XX*1447848577~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Prohas*Bernie****MI*23051322~EQ*30~SE*11*0001~GE*1*1~IEA*1*000000001~]]>
'
```
This check is designed to fail so you can watch the agent resolve issues in real time. Specifically, it returns `AAA` error `73` (Invalid/Missing Subscriber/Insured Name).
Once the check is complete, you can use it to test the Stedi Agent's troubleshooting capabilities:
1. Go to the [Eligibility searches](https://portal.stedi.com/app/healthcare/eligibility) page in your Stedi account.
2. Toggle **Test mode** to **ON**.
3. Click the failed mock eligibility check to review its details.
4. Click **Resolve with Stedi Agent**. The agent runs in **Debug view** to fix the error and eventually produce a successful mock eligibility response.
# Coordination of Benefits Check
Source: https://www.stedi.com/docs/healthcare/api-reference/post-coordination-of-benefits
Coordination of benefits (COB) checks help you determine whether patients are covered by multiple health plans, whether coverage overlap requires coordination of benefits, and each payer's responsibility for payment (primacy).
1. Call this endpoint with a JSON payload. Each check **must** be for a Stedi-supported payer with which the patient has coverage. Visit the [Payer Network](https://www.stedi.com/healthcare/network?filter=eyJ0cmFuc2FjdGlvbkZpbHRlcnMiOnsiMjcwIjp7fSwiMjc2Ijp7fSwiODM1Ijp7fSwiODM3UCI6e30sIjgzN0kiOnt9LCI4MzdEIjp7fSwiQ09CIjp7ImlzU3VwcG9ydGVkIjp0cnVlfSwiMjc1VSI6e319LCJjb3ZlcmFnZVR5cGVzIjpbXX0%3D) for a complete list of supported payers.
2. Stedi searches a national database containing 245+ million patient coverage records from 45+ health plans, ASOs, TPAs, and others, including participation from the vast majority of national commercial health plans. Data is updated weekly to ensure accuracy.
3. The endpoint returns information about the patient's active health plans, the responsibility sequence number for each payer if available (such as primary or secondary), and whether coordination of benefits is required.
## API Specification
Submit a coordination of benefits (COB) check in JSON format
**Endpoint:** `POST /coordination-of-benefits`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Request Body
**Schema:** `CoordinationOfBenefitsRequestContent`
**Properties:**
- **`dependent`** (`object`)
- **`encounter`** (`object`) (required)
- **`provider`** (`object`) (required): An object containing information about the entity requesting the COB check. This may be an individual practitioner, a medical group, a hospital, or another type of healthcare provider. You must provide the `organizationName` (if the entity is an organization) or `firstName` and `lastName` (if the provider is an individual). You must also provide the provider's [National Provider Identifier](https://www.stedi.com/docs/healthcare/national-provider-identifier) (`npi`).
- **`subscriber`** (`object`) (required)
- **`tradingPartnerServiceId`** (`string`) (required): The payer ID. Visit the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list of supported payers for COB checks.
- Each check **must** be for a participating health plan for which the patient has coverage. For example, if the patient has coverage from Cigna and UnitedHealthcare, a COB check to Aetna will return an error.
- Medicare and Medicare Advantage plans aren't supported. If you submit a COB check for a Medicare or Medicare Advantage plan, the request will fail with an `AAA` = `75` error (Subscriber/Insured Not Found).
- Ensure that you're sending the request to the correct payer entity. For example, Blue Cross Blue Shield (BCBS) has multiple entities that operate in different states. If you send a request to the wrong entity, the request will fail with an `AAA` = `75` error (Subscriber/Insured Not Found).
- You must include leading `0` characters - payer IDs are alphanumeric strings and must be treated as complete strings, not integers. For example, use `00540` for SISCO, not `540`.
**Example:**
```json
{
"dependent": {
"dateOfBirth": "2002-12-31",
"firstName": "Jordan",
"lastName": "Doe"
},
"encounter": {
"dateOfService": "2024-08-02",
"serviceTypeCode": "30"
},
"provider": {
"npi": "1999999984",
"organizationName": "ACME Health Services"
},
"subscriber": {
"dateOfBirth": "1985-05-27",
"firstName": "John",
"lastName": "Doe",
"memberId": "W000000000"
},
"tradingPartnerServiceId": "SOMEID"
}
```
### Responses
#### 200
CoordinationOfBenefits 200 response
**Schema:** `CoordinationOfBenefitsResponseContent`
**Properties:**
- **`benefitsInformation`** (`array`): Information about the patient's healthcare benefits, including:
- Active coverage with the health plan identified in the COB request
- Coverage overlap (if it exists) with one or more payers
- Payer primacy details (if Stedi was able to determine)
- Benefits details, such as coverage dates and service types
- Items schema: `COBBenefitsInformation`
- **`coordinationOfBenefits`** (`object`): An overview of the COB response. It indicates whether there is a coverage overlap, whether that overlap creates a coordination of benefits instance, and whether Stedi was able to identify payer primacy (when a COB instance exists).
- **`dependent`** (`object`): Information about the dependent listed in the original COB request.
- **`errors`** (`array`): If the COB request fails, the COB response contains one or more `AAA` errors that specify the reasons for the rejection and any recommended follow-up actions.
- Items schema: `EligibilityCheckError`
- **`meta`** (`object`): Metadata about the response. Stedi uses this data for tracking and troubleshooting.
- **`payer`** (`object`): Information about the payer listed in the COB request.
- **`planDateInformation`** (`object`)
- **`provider`** (`object`): Information about the entity that submitted the original coordination of benefits request. This may be an individual practitioner, a medical group, a hospital, or another type of healthcare provider. This object will always include the provider's [NPI](https://www.stedi.com/docs/healthcare/national-provider-identifier).
- **`subscriber`** (`object`): Information about the primary policyholder for the insurance plan listed in the COB request.
**Example:**
```json
{
"benefitsInformation": [
{
"benefitsDateInformation": {
"benefitBegin": "2023-03-01"
},
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": [
"1"
],
"serviceTypes": [
"Medical Care"
],
"subscriber": {
"dateOfBirth": "2002-02-27"
}
},
{
"benefitsDateInformation": {
"benefitBegin": "2023-03-01"
},
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": [
"88"
],
"serviceTypes": [
"Pharmacy"
],
"subscriber": {
"dateOfBirth": "2002-02-27"
}
},
{
"benefitsDateInformation": {
"benefitBegin": "2023-03-01"
},
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": [
"AL"
],
"serviceTypes": [
"Vision (Optometry)"
],
"subscriber": {
"dateOfBirth": "2002-02-27"
}
},
{
"benefitsDateInformation": {
"coordinationOfBenefits": "2024-07-01"
},
"benefitsRelatedEntities": [
{
"entityIdentification": "PI",
"entityIdentificationValue": "1006",
"entityIdentifier": "Primary Payer",
"entityName": "CIGNA"
},
{
"entityFirstname": "JOHN",
"entityIdentification": "MI",
"entityIdentificationValue": "00000000000",
"entityIdentifier": "Insured or Subscriber",
"entityLastname": "DOE",
"entityMiddlename": "X"
}
],
"code": "R",
"name": "Other or Additional Payor",
"serviceTypeCodes": [
"1"
],
"serviceTypes": [
"Medical Care"
],
"subscriber": {
"dateOfBirth": "2002-12-31"
}
}
],
"coordinationOfBenefits": {
"benefitOverlap": true,
"classification": "CobInstanceExistsPrimacyDetermined",
"coverageOverlap": true,
"instanceExists": true,
"primacyDetermined": true
},
"dependent": {
"address": {
"address1": "1 MAIN ST.",
"city": "NEW YORK",
"postalCode": "10000",
"state": "NY"
},
"dateOfBirth": "2002-12-31",
"firstName": "JORDAN",
"gender": "M",
"lastName": "DOE",
"relationToSubscriber": "Child",
"relationToSubscriberCode": "19"
},
"errors": [],
"meta": {
"applicationMode": "production",
"outboundTraceId": "01JDQFT4W3KTWZNTADEZ55BFFX",
"traceId": "01JDQFT4W3KTWZNTADEZ55BFFX"
},
"payer": {
"name": "Aetna",
"payerIdentification": "AETNA-USH"
},
"provider": {
"npi": "1999999984",
"providerName": "ACME Health Services"
},
"subscriber": {
"address": {
"address1": "1 MAIN ST.",
"city": "NEW YORK",
"postalCode": "10000",
"state": "NY"
},
"firstName": "JOHN",
"lastName": "DOE",
"memberId": "W000000000"
}
}
```
#### 400
CoordinationOfBenefits400Error 400 response
**Schema:** `CoordinationOfBenefits400ErrorResponseContent`
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# Create Enrollment
Source: https://www.stedi.com/docs/healthcare/api-reference/post-enrollment-create-enrollment
This endpoint allows you to submit a [transaction enrollment](/healthcare/transaction-enrollment) request for a specific provider. You must create one enrollment request for each transaction type. For example, you would create three separate requests to enroll a provider for 837P claims (professional), 270 real-time eligibility checks, and 835 ERAs (claim payments).
1. Add the provider's details through either the [Providers page](https://portal.stedi.com/app/healthcare/enrollments) or the [Create Provider](/healthcare/api-reference/post-enrollment-create-provider) endpoint.
2. Call this endpoint to create the enrollment request. Set the `status` property to `DRAFT` for test enrollments. Set the `status` property to `STEDI_ACTION_REQUIRED` when you're ready for Stedi to begin processing the request.
3. The endpoint returns summary information about the enrollment request.
Once the status is set to `STEDI_ACTION_REQUIRED`, Stedi begins processing the enrollment request. You can track its progress through the Stedi portal or the API.
## Contact information [#contact-information]
You must submit a contact in `primaryContact`. This is where the payer will send communications about the enrollment, if needed.
The contact information you provide doesn't need to match the existing contact information on the provider record. This allows you to specify different contacts for different payers as needed.
When adding a contact, follow these best practices:
* The provider's name and address should match exactly what the payer has on file. Some payers reject enrollment requests with addresses that don't match their records.
* However, you may want to set the phone number or email to your own contact details. Do this when you want the payer to contact you about the enrollment instead of the provider directly.
## API Specification
Creates a new transaction enrollment request. Transaction enrollment registers a provider to exchange specific transaction types with a payer.
**Endpoint:** `POST /enrollments`
**Base URL:** `https://enrollments.us.stedi.com/2024-09-01`
### Request Body
**Schema:** `CreateEnrollmentRequestContent`
**Properties:**
- **`aggregationPreference`** (`object`): Preference for how the payer should group 835 Electronic Remittance Advice (ERA) transactions. Only set this property for 835 ERA enrollments.
- If you include this property for a non-ERA enrollment, Stedi rejects the enrollment request with an HTTP `400` error.
- If the payer doesn't support the requested aggregation type, Stedi rejects the enrollment request with an HTTP `400` error.
- If not set, Stedi automatically selects a default based on the payer's supported aggregation types and the available identifiers for the provider.
- Stedi will attempt to enroll with this preference, but it's not guaranteed. Each payer has its own restrictions and behaviors.
- **`payer`** (`object`) (required): Information about the payer the provider is enrolling with.
- **`primaryContact`** (`object`) (required): The contact information for the provider. This is where the payer will send communications about the enrollment, if needed.
- Either `organizationName` _or_ `firstName` and `lastName` are required.
- The name and address should match exactly what the payer has on file for the provider. Some payers reject enrollment requests with addresses that don't match their records.
- If you're submitting enrollment requests on a provider's behalf, you may want to set the phone number or email to your own contact details. Do this when you want the payer to contact you about the enrollment status instead of the provider directly.
- This contact information doesn't need to match existing contacts defined on the provider record. It also doesn't modify or replace contacts on the provider record.
- **`provider`** (`object`) (required): Information about the provider enrolling with the payer. You **must** use the [Create Provider](https://www.stedi.com/docs/api-reference/healthcare/post-enrollment-create-provider) endpoint to add the provider to Stedi before you can enroll them with one or more payers.
- **`providerTransactionAccessNumber`** (`string`): This property is required for payers that require a Provider Transaction Access Number (PTAN).
The PTAN is a Medicare-issued number given to providers upon enrollment with Medicare. This number is usually six digits and is assigned based on the type of service and the location of the provider. Upon enrollment, Medicare Administrating Contracting (MAC) providers should receive their assigned PTAN number in their approval letter.
- **`reason`** (`string`): This shape is deprecated since 2025-10-07: Only Stedi can set or update this property, and it will be removed in a future release.
- **`requestedEffectiveDate`** (`string`): The requested effective date for the enrollment in YYYYMMDD format. This is the date you'd like the enrollment to take effect with the payer. For example, setting this to `20260601` for an 835 Electronic Remittance Advice (ERAs) enrollment means you want to start receiving ERAs through Stedi on that date.
Stedi processes enrollments accordingly, but can't guarantee that the enrollment will be effective on this exact date.
- You can submit today's date or a future date up to 6 months from today.
- If not set for draft enrollments, this property remains empty.
- If not set for submitted enrollments, Stedi defaults to the enrollment's submission date.
- If you include this property for a payer that doesn't support requested effective dates, Stedi rejects the request with an HTTP `400` error.
- **`source`** (`object`): This shape is deprecated since 2025-12-23: Stedi ignores this property for API requests, and it will be removed in a future release. The enrollment source is always set to `API`.
- **`status`** (`object`): The status of the enrollment. You can submit enrollments with either `DRAFT` or `STEDI_ACTION_REQUIRED` status. The default status is `DRAFT` if not specified. When you're ready for Stedi to begin processing the enrollment, set the status to `STEDI_ACTION_REQUIRED`. Once an enrollment is `STEDI_ACTION_REQUIRED`, only Stedi can set or update its status.
- `DRAFT` - You're still editing the enrollment and haven't submitted it to Stedi.
- `STEDI_ACTION_REQUIRED` - You have submitted the enrollment and it is ready for Stedi to begin processing.
- `SUBMITTED` - (Deprecated) Legacy status being phased out in favor of the more specific action-required statuses. If you set an enrollment request to `SUBMITTED`, Stedi treats it as `STEDI_ACTION_REQUIRED`.
- **`transactions`** (`object`) (required): The type of transactions included in the enrollment.
- **`userEmail`** (`string`) (required): The email address where Stedi should send updates about the enrollment. We'll use it to notify you when there are next steps and send updates on the enrollment's status.
- This email address can be different from the `primaryContact.email` where the payer sends communications about the enrollment.
- For [automatic enrollment requests](https://www.stedi.com/docs/healthcare/create-manage-transaction-enrollments#automatic-enrollment-requests), Stedi sets this to the oldest account member with the Admin role.
**Example:**
```json
{
"aggregationPreference": {
"taxId": "123456789"
},
"payer": {
"idOrAlias": "87726"
},
"primaryContact": {
"city": "A City",
"email": "test@example.com",
"firstName": "John",
"lastName": "Doe",
"phone": "5551234567",
"state": "MD",
"streetAddress1": "123 Some Str.",
"zipCode": "20814"
},
"provider": {
"id": "db6665c5-7b97-4af9-8c68-a00a336c2998"
},
"requestedEffectiveDate": "20240301",
"status": "STEDI_ACTION_REQUIRED",
"transactions": {
"claimPayment": {
"enroll": true
}
},
"userEmail": "test@example.com"
}
```
### Responses
#### 200
CreateEnrollment 200 response
**Schema:** `CreateEnrollmentResponseContent`
**Properties:**
- **`aggregationPreference`** (`object`): Preference for how the payer should group 835 Electronic Remittance Advice (ERA) transactions. This property is only returned for 835 ERA enrollments.
- If not set, Stedi automatically selects a default based on the payer's supported aggregation types and the available identifiers for the provider.
- Stedi attempts to enroll with this preference, but it's not guaranteed. Each payer has its own restrictions and behaviors.
- This property isn't returned for enrollment records created before Stedi added support for aggregation preferences.
- **`createdAt`** (`string`) (required): The date and time when the enrollment was created within Stedi.
- **`documents`** (`array`): Documents associated with this enrollment, excluding deleted documents.
- Items schema: `EnrollmentDocument`
- **`history`** (`array`): The history of updates to this enrollment, such as status changes. This property is experimental and may change in the future.
- Items schema: `EnrollmentHistoryEntry`
- **`id`** (`string`) (required): The Stedi-assigned identifier for the enrollment request.
- **`lastEraReceivedAt`** (`string`): The timestamp of the most recent 835 ERA (Electronic Remittance Advice) Stedi received for this enrollment, based on the enrollment's payer ID, provider NPI, and provider tax ID. Stedi automatically updates this property for each new ERA.
- This property is only returned for ERA enrollments in `LIVE` status with at least one matching ERA from the payer.
- If this timestamp doesn't match your expected timeline for ERA processing, there may be an upstream issue. Contact Stedi support for assistance.
- **`payer`** (`object`) (required): Information about the payer the provider is enrolling with.
- **`primaryContact`** (`object`) (required): The contact information for the provider. This is where the payer will send communications about the enrollment, if needed.
- **`provider`** (`object`) (required): Information about the provider enrolling with the payer.
- **`providerTransactionAccessNumber`** (`string`): This property is required for payers that require a Provider Transaction Access Number (PTAN).
The PTAN is a Medicare-issued number given to providers upon enrollment with Medicare. This number is usually six digits and is assigned based on the type of service and the location of the provider. Upon enrollment, Medicare Administrating Contracting (MAC) providers should receive their assigned PTAN number in their approval letter.
- **`reason`** (`string`): Reasons why the enrollment request is still in `PROVISIONING` status, may take additional time to process, or was rejected by the payer. Only Stedi can set or update this property.
- **`requestedEffectiveDate`** (`string`): The requested effective date for the enrollment in YYYYMMDD format. This is the date the submitter would like the enrollment to take effect with the payer. If not provided during submission, Stedi defaults to the enrollment's submission date.
Not all payers support requested effective dates. Stedi can't guarantee that the enrollment will be effective with the payer on this exact date.
- **`source`** (`object`): The source of this enrollment.
- **`status`** (`object`): The status of the enrollment. You can submit enrollments with either `DRAFT` or `STEDI_ACTION_REQUIRED` status. The default status is `DRAFT` if not specified. When you're ready for Stedi to begin processing the enrollment, set the status to `STEDI_ACTION_REQUIRED`. Once an enrollment is `STEDI_ACTION_REQUIRED`, only Stedi can set or update its status.
- `DRAFT` - You're still editing the enrollment and haven't submitted it to Stedi.
- `STEDI_ACTION_REQUIRED` - You have submitted the enrollment and it is ready for Stedi to begin processing.
- `PROVIDER_ACTION_REQUIRED` - The enrollment requires action from the healthcare provider to proceed, such as providing additional documentation. Stedi will add a note to your enrollment request with clear instructions.
- `SUBMITTED` - (Deprecated) Legacy status being phased out in favor of the more specific action-required statuses. If you set an enrollment request to `SUBMITTED`, Stedi treats it as `STEDI_ACTION_REQUIRED`.
- `PROVISIONING` - Stedi has begun the process of completing the enrollment with the payer.
- `LIVE` - The enrollment process is complete, and the specified provider can begin exchanging the listed transaction types with the payer.
- `REJECTED` - The payer rejected the enrollment. Common reasons for rejection include incorrect details in the request and that the provider is not credentialed with the payer. Customer support will contact you with reasons for rejection and next steps.
- `CANCELED` - The enrollment has been terminated per customer or provider request.
- **`statusLastUpdatedAt`** (`string`) (required): The date and time when the enrollment status was last updated. This timestamp is used to track enrollment processing durations and enables filtering to identify recently changed enrollments. It automatically updates whenever an enrollment's status changes but remains unchanged during other updates.
- **`submittedAt`** (`string`): The date and time when the enrollment was submitted. If the enrollment is in `DRAFT` status, `submittedAt` is not present. When the enrollment transitions from draft to `STEDI_ACTION_REQUIRED`, `submittedAt` is updated to the submission time. If the enrollment was created and submitted immediately, the `submittedAt` time will be equal or close to the `createdAt` time.
- **`tasks`** (`array`): Tasks associated with this enrollment representing work that needs to be completed. Each task has a responsible party and specific definition.
- Items schema: `Task`
- **`transactions`** (`object`) (required): The type of transactions included in the enrollment.
- **`updatedAt`** (`string`) (required): The date and time when the enrollment was updated.
- **`userEmail`** (`string`) (required): The email address where Stedi should send updates about the enrollment. We'll use it to notify you when there are next steps and send updates on the enrollment's status.
- This email address can be different from the `primaryContact.email` where the payer sends communications about the enrollment.
- For [automatic enrollment requests](https://www.stedi.com/docs/healthcare/create-manage-transaction-enrollments#automatic-enrollment-requests), Stedi sets this to the oldest account member with the Admin role.
**Example:**
```json
{
"aggregationPreference": {
"taxId": "123456789"
},
"createdAt": "2023-11-07T05:31:56Z",
"history": [
{
"changedAt": "2023-11-07T05:31:56Z",
"changedBy": "test@example.com",
"newStatus": "DRAFT",
"type": "STATUS_CHANGE"
},
{
"changedAt": "2023-11-07T05:31:56Z",
"changedBy": "test@example.com",
"newStatus": "STEDI_ACTION_REQUIRED",
"previousStatus": "DRAFT",
"type": "STATUS_CHANGE"
}
],
"id": "db6675c5-7bg7-4af9-8c68-a54a336d2911",
"payer": {
"name": "UnitedHealthcare",
"stediPayerId": "KMQTZ",
"submittedPayerIdOrAlias": "87726"
},
"primaryContact": {
"city": "A City",
"email": "test@example.com",
"firstName": "John",
"lastName": "Doe",
"phone": "5551234567",
"state": "MD",
"streetAddress1": "123 Some Str.",
"zipCode": "20814"
},
"provider": {
"id": "db6665c5-7b97-4af9-8c68-a00a336c2998",
"name": "Test Medical Provider",
"npi": "1234567890",
"taxId": "123456789",
"taxIdType": "EIN"
},
"requestedEffectiveDate": "20240301",
"source": "API",
"status": "STEDI_ACTION_REQUIRED",
"statusLastUpdatedAt": "2023-11-07T05:31:56Z",
"submittedAt": "2023-11-07T05:31:56Z",
"transactions": {
"claimPayment": {
"enroll": true
}
},
"updatedAt": "2023-11-07T05:31:56Z",
"userEmail": "test@example.com"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
QuotaExceededException 429 response
**Schema:** `QuotaExceededExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Create Provider
Source: https://www.stedi.com/docs/healthcare/api-reference/post-enrollment-create-provider
This endpoint allows you to create a provider record with the details required for [transaction enrollment](/healthcare/transaction-enrollment).
1. Call this endpoint with the provider's details.
2. The endpoint returns the created provider record, including the provider `id`, which you'll need when creating enrollment requests.
You can now add the provider to one or more transaction enrollment requests.
All providers you create through this endpoint are available on the [Providers page](https://portal.stedi.com/app/healthcare/providers) for you to review and manage.
## Contact information [#contact-information]
You can add one or more `contacts` to a provider record. Contacts on the provider record are for convenience - they allow the Stedi portal to prepopulate contact information options when you create enrollment requests manually. However, they **aren't** automatically added to enrollment requests you submit through the portal or API, and you can submit different contact information in enrollment requests for the provider as needed.
When adding a contact, follow these best practices:
* The provider's name and address should match exactly what payers have on file. Some payers reject enrollment requests with addresses that don't match their records. Remember that you can add different contacts to enrollment requests for specific payers if needed.
* However, you may want to set the phone number or email to your own contact details. Do this when you want the payer to contact you about the enrollment instead of the provider directly.
## API Specification
Creates a new provider record. Providers must be created before they can be enrolled with payers.
**Endpoint:** `POST /providers`
**Base URL:** `https://enrollments.us.stedi.com/2024-09-01`
### Request Body
**Schema:** `CreateProviderRequestContent`
**Properties:**
- **`contacts`** (`array`): The contact information for the provider. These contacts appear as prepopulated options for contact information when creating enrollment requests for this provider in the Stedi portal. They aren't automatically added to enrollment requests.
These contacts should specify where payers should send communications about the enrollment, if needed.
- Either `organizationName` _or_ `firstName` and `lastName` are required.
- The name and address should match exactly what the payer has on file for the provider. Some payers reject enrollment requests with addresses that don't match their records.
- If you're submitting enrollment requests on a provider's behalf, you may want to set the phone number and email to your own contact details. Do this when you want the payer to contact you about the enrollment status instead of the provider directly.
- These contacts are for convenience only. You can specify different contacts on enrollment requests as needed.
- Items schema: `ProviderContact`
- **`name`** (`string`) (required): The provider's business name. This is typically the provider's practice name, such as `Dental Associates, LLC`, but it can also be the provider's first and last name.
- **`npi`** (`string`) (required): The provider's [National Provider Identifier (NPI)](https://npiregistry.cms.hhs.gov/search). This is a 10-digit number that is unique to the provider.
Each provider record must have a unique `npi` and `taxId` combination. For example, you can create two provider records with the same `npi` as long as they have different values for `taxId`.
- **`taxId`** (`string`) (required): The provider's tax ID, as specified by `taxIdType`. This identifier has to be provided without any separators, such as dashes or spaces. For example 111-22-3333 is invalid but `111223333` is valid.
Each provider record must have a unique `npi` and `taxId` combination. For example, you can create two provider records with the same `taxId` as long as they have different values for `npi`.
- **`taxIdType`** (`object`) (required): The type of tax ID. Can be either an `EIN` - Employer Identification Number, or an `SSN` - Social Security Number.
**Example:**
```json
{
"contacts": [
{
"city": "Chevy Chase",
"email": "bob@fortdental.center",
"firstName": "Bob",
"lastName": "Dentist",
"phone": "5551232135",
"state": "MD",
"streetAddress1": "123 Some Str",
"zipCode": "20814"
},
{
"city": "Chevy Chase",
"email": "tom@fortdental.center",
"firstName": "Tom",
"lastName": "Dentist",
"phone": "5551232133",
"state": "MD",
"streetAddress1": "123 Some Str",
"zipCode": "20814"
}
],
"name": "BDQ Dental Inc",
"npi": "1999999992",
"taxId": "555123456",
"taxIdType": "EIN"
}
```
### Responses
#### 200
CreateProvider 200 response
**Schema:** `CreateProviderResponseContent`
**Properties:**
- **`contacts`** (`array`): The contact information for the provider. These contacts appear as prepopulated options for contact information when creating enrollment requests for this provider in the Stedi portal. They aren't automatically added to enrollment requests.
These contacts should specify where payers should send communications about the enrollment, if needed.
- Items schema: `ProviderContact`
- **`createdAt`** (`string`): The date and time Stedi created the provider record.
- **`id`** (`string`) (required): A unique identifier Stedi assigns to this provider.
- **`name`** (`string`) (required): The provider's business name. This is typically the provider's practice name, such as `Dental Associates, LLC`, but it can also be the provider's first and last name.
- **`npi`** (`string`) (required): The provider's [National Provider Identifier (NPI)](https://npiregistry.cms.hhs.gov/search). This is a 10-digit number that is unique to the provider.
Each provider record must have a unique `npi` and `taxId` combination. For example, you can create two provider records with the same `npi` as long as they have different values for `taxId`.
- **`taxId`** (`string`): The provider's tax ID, as specified by `taxIdType`. This identifier has to be provided without any separators, such as dashes or spaces. For example 111-22-3333 is invalid but `111223333` is valid.
Each provider record must have a unique `npi` and `taxId` combination. For example, you can create two provider records with the same `taxId` as long as they have different values for `npi`.
- **`taxIdType`** (`object`): The type of tax ID. Can be either an `EIN` - Employer Identification Number, or an `SSN` - Social Security Number.
- **`updatedAt`** (`string`): The date and time Stedi last updated the provider record.
**Example:**
```json
{
"contacts": [
{
"city": "Chevy Chase",
"email": "bob@fortdental.center",
"firstName": "Bob",
"lastName": "Dentist",
"organizationName": "",
"phone": "5551232135",
"state": "MD",
"streetAddress1": "123 Some Str",
"zipCode": "20814"
},
{
"city": "Chevy Chase",
"email": "tom@fortdental.center",
"firstName": "Tom",
"lastName": "Dentist",
"organizationName": "",
"phone": "5551232133",
"state": "MD",
"streetAddress1": "123 Some Str",
"zipCode": "20814"
}
],
"createdAt": "2024-11-18T17:39:52.406Z",
"id": "10334e76-f073-4b5d-8984-81d8e5107857",
"name": "BDQ Dental Inc",
"npi": "1999999992",
"taxId": "555123456",
"taxIdType": "EIN",
"updatedAt": "2024-11-18T17:39:52.406Z"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
QuotaExceededException 429 response
**Schema:** `QuotaExceededExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Upload Enrollment Document
Source: https://www.stedi.com/docs/healthcare/api-reference/post-enrollment-document-upload
This endpoint returns a pre-signed URL to upload a PDF document to the specified [transaction enrollment](/healthcare/transaction-enrollment). You can only upload PDF documents required to complete a specific task on the enrollment.
1. Call this endpoint with the task ID for the task that requires the document upload and the enrollment ID for the associated transaction enrollment request. These IDs are returned in the responses for the [Retrieve Enrollment](/healthcare/api-reference/get-enrollment) and [List Enrollments](/healthcare/api-reference/get-enrollment-list-enrollments) endpoints.
2. The endpoint returns a pre-signed URL that you can use to upload the PDF document to the enrollment record. The URL expires in 24 hours.
3. Use a `PUT` request to upload the attachment file to the pre-signed URL (`uploadURL`) in the response. The request must include a `Content-Type` header set to `application/pdf`.
```bash
curl --request PUT \
--url "" \
--header "Content-Type: application/pdf" \
--upload-file /path/to/file.pdf
```
Stedi displays uploaded documents on the enrollment's details page in the Stedi portal.
## Poll for document status [#poll-for-document-status]
When you successfully upload the PDF to the pre-signed URL, the document record's status changes from `PENDING` to `UPLOADED`. You must wait for the document's status to change to `UPLOADED` before marking the associated task as complete. This typically takes less than 10 seconds.
You can poll the [Retrieve Enrollment](/healthcare/api-reference/get-enrollment) endpoint to determine when the status has been updated. The following example shows how to poll for a document's status.
```typescript
const STEDI_ENROLLMENTS_API = "https://enrollments.us.stedi.com";
async function waitForDocumentUploadedStatus(
enrollmentId: string,
documentId: string,
attempts = 5,
intervalMs = 500,
): Promise {
const resource = new URL(
`/2024-09-01/enrollments/${enrollmentId}`,
STEDI_ENROLLMENTS_API,
);
for (let attempt = 0; attempt < attempts; attempt++) {
const response = await fetch(resource, {
headers: {
authorization: "",
},
});
if (!response.ok) {
throw new Error(`HTTP error, status: ${response.status}`);
}
const enrollment = await response.json();
const documentUploaded = enrollment.documents?.some(
(document) =>
document.id === documentId && document.status === "UPLOADED",
);
if (documentUploaded) {
return true;
}
if (attempt < attempts - 1) {
await new Promise((resolve) => setTimeout(resolve, intervalMs));
}
}
return false;
}
// Usage
await waitForDocumentUploadedStatus(enrollmentId, documentId);
```
## Pending documents [#pending-documents]
After 24 hours, Stedi automatically deletes any document records that are still in the `PENDING` status. You'll need to call this endpoint again to get a new pre-signed URL for uploading the document.
## API Specification
Returns a pre-signed URL to upload a PDF document for the specified transaction enrollment.
**Endpoint:** `POST /enrollments/{enrollmentId}/documents`
**Base URL:** `https://enrollments.us.stedi.com/2024-09-01`
### Parameters
- **`enrollmentId`** (path) (required): The enrollment ID for the transaction enrollment where you want to upload the PDF document. The enrollment ID is returned in the responses for the [Create Enrollment](/healthcare/api-reference/post-enrollment-create-enrollment) and [List Enrollments](/healthcare/api-reference/get-enrollment-list-enrollments) endpoints. It's also listed at the top of the [enrollment's details page](https://portal.stedi.com/app/healthcare/enrollments) in the Stedi portal.
- Type: `string`
### Request Body
**Schema:** `CreateEnrollmentDocumentUploadRequestContent`
**Properties:**
- **`name`** (`string`) (required): The file name of the PDF document you want to upload. The name should include the file extension, such as `provider-license.pdf`. This name will be displayed in the Stedi portal.
- **`taskId`** (`string`) (required): The ID for the task associated with this document upload.
**Example:**
```json
{
"name": "provider-license.pdf",
"taskId": "11111111-1111-4111-8111-111111111111"
}
```
### Responses
#### 200
CreateEnrollmentDocumentUpload 200 response
**Schema:** `CreateEnrollmentDocumentUploadResponseContent`
**Properties:**
- **`documentId`** (`string`) (required): A unique identifier for the document record within Stedi.
- **`enrollmentId`** (`string`) (required): The enrollment ID for the transaction enrollment request associated with the PDF document.
- **`uploadUrl`** (`string`) (required): The pre-signed URL you can use to upload the PDF document. This URL expires after 24 hours.
**Example:**
```json
{
"documentId": "doc-123e4567-e89b-12d3-a456-426614174000",
"enrollmentId": "db6675c5-7bg7-4af9-8c68-a54a336d2911",
"uploadUrl": "https://s3.amazonaws.com/enrollment-documents/db6675c5-7bg7-4af9-8c68-a54a336d2911/provider-license.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=..."
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
QuotaExceededException 429 response
**Schema:** `QuotaExceededExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Update Enrollment
Source: https://www.stedi.com/docs/healthcare/api-reference/post-enrollment-update-enrollment
This endpoint allows you to update [transaction enrollments](/healthcare/transaction-enrollment) that are still in `DRAFT` status. If you need to make changes to an enrollment that is already in `STEDI_ACTION_REQUIRED`, `PROVIDER_ACTION_REQUIRED`, `PROVISIONING`, `LIVE`, `REJECTED`, or `CANCELED` status, contact support.
Calling this endpoint completely overwrites the previous request record. You **must** provide all the information for the enrollment in the request, not just the properties you want to update.
## API Specification
Updates an existing enrollment request. Only enrollments in DRAFT status can be updated. Once an enrollment is submitted, it cannot be modified.
**Endpoint:** `POST /enrollments/{enrollmentId}`
**Base URL:** `https://enrollments.us.stedi.com/2024-09-01`
### Parameters
- **`enrollmentId`** (path) (required): The Stedi-assigned identifier for the enrollment.
- Type: `string`
### Request Body
**Schema:** `UpdateEnrollmentRequestContent`
**Properties:**
- **`aggregationPreference`** (`object`): Preference for how the payer should group 835 Electronic Remittance Advice (ERA) transactions. Only set this property for 835 ERA enrollments.
- If you include this property for a non-ERA enrollment, Stedi rejects the enrollment request with an HTTP `400` error.
- If the payer doesn't support the requested aggregation type, Stedi rejects the enrollment request with an HTTP `400` error.
- If not set, Stedi automatically selects a default based on the payer's supported aggregation types and the available identifiers for the provider.
- Stedi will attempt to enroll with this preference, but it's not guaranteed. Each payer has its own restrictions and behaviors.
- **`payer`** (`object`) (required): Information about the payer the provider is enrolling with.
- **`primaryContact`** (`object`) (required): The contact information for the provider. This is where the payer will send communications about the enrollment, if needed.
- Either `organizationName` _or_ `firstName` and `lastName` are required.
- The name and address should match exactly what the payer has on file for the provider. Some payers reject enrollment requests with addresses that don't match their records.
- If you're submitting enrollment requests on a provider's behalf, you may want to set the phone number or email to your own contact details. Do this when you want the payer to contact you about the enrollment status instead of the provider directly.
- This contact information doesn't need to match existing contacts defined on the provider record. It also doesn't modify or replace contacts on the provider record.
- **`provider`** (`object`) (required): Information about the provider enrolling with the payer.
- **`providerTransactionAccessNumber`** (`string`): This property is required for payers that require a Provider Transaction Access Number (PTAN).
The PTAN is a Medicare-issued number given to providers upon enrollment with Medicare. This number is usually six digits and is assigned based on the type of service and the location of the provider. Upon enrollment, Medicare Administrating Contracting (MAC) providers should receive their assigned PTAN number in their approval letter.
- **`reason`** (`string`): This shape is deprecated since 2025-10-07: Only Stedi can set or update this property, and it will be removed in a future release.
- **`requestedEffectiveDate`** (`string`): The requested effective date for the enrollment in YYYYMMDD format. This is the date you'd like the enrollment to take effect with the payer. For example, setting this to `20260601` for an 835 Electronic Remittance Advice (ERAs) enrollment means you want to start receiving ERAs through Stedi on that date.
Stedi processes enrollments accordingly, but can't guarantee that the enrollment will be effective on this exact date.
- You can submit today's date or a future date up to 6 months from today.
- If not set for draft enrollments, this property remains empty.
- If not set for submitted enrollments, Stedi defaults to the enrollment's submission date.
- If you include this property for a payer that doesn't support requested effective dates, Stedi rejects the request with an HTTP `400` error.
- **`source`** (`object`): This shape is deprecated since 2025-12-23: Stedi ignores this property for API requests, and it will be removed in a future release. The enrollment source is always set to `API`.
- **`status`** (`object`): The status of the enrollment. You can submit enrollments with either `DRAFT` or `STEDI_ACTION_REQUIRED` status. The default status is `DRAFT` if not specified. When you're ready for Stedi to begin processing the enrollment, set the status to `STEDI_ACTION_REQUIRED`. Once an enrollment is `STEDI_ACTION_REQUIRED`, only Stedi can set or update its status.
- `DRAFT` - You're still editing the enrollment and haven't submitted it to Stedi.
- `STEDI_ACTION_REQUIRED` - You have submitted the enrollment and it is ready for Stedi to begin processing.
- `SUBMITTED` - (Deprecated) Legacy status being phased out in favor of the more specific action-required statuses. If you set an enrollment request to `SUBMITTED`, Stedi treats it as `STEDI_ACTION_REQUIRED`.
- **`transactions`** (`object`) (required): The type of transactions included in the enrollment.
- **`userEmail`** (`string`) (required): The email address where Stedi should send updates about the enrollment. We'll use it to notify you when there are next steps and send updates on the enrollment's status.
- This email address can be different from the `primaryContact.email` where the payer sends communications about the enrollment.
- For [automatic enrollment requests](https://www.stedi.com/docs/healthcare/create-manage-transaction-enrollments#automatic-enrollment-requests), Stedi sets this to the oldest account member with the Admin role.
**Example:**
```json
{
"aggregationPreference": {
"taxId": "123456789"
},
"payer": {
"idOrAlias": "87726"
},
"primaryContact": {
"city": "A City",
"email": "test@example.com",
"firstName": "Updated First Name",
"lastName": "Updated Last Name",
"phone": "3331234567",
"state": "MD",
"streetAddress1": "123 Some Str.",
"zipCode": "20814"
},
"provider": {
"id": "db6665c5-7b97-4af9-8c68-a00a336c2998"
},
"requestedEffectiveDate": "20250301",
"status": "STEDI_ACTION_REQUIRED",
"transactions": {
"claimPayment": {
"enroll": true
}
},
"userEmail": "test@example.com"
}
```
### Responses
#### 200
UpdateEnrollment 200 response
**Schema:** `UpdateEnrollmentResponseContent`
**Properties:**
- **`aggregationPreference`** (`object`): Preference for how the payer should group 835 Electronic Remittance Advice (ERA) transactions. This property is only returned for 835 ERA enrollments.
- If not set, Stedi automatically selects a default based on the payer's supported aggregation types and the available identifiers for the provider.
- Stedi attempts to enroll with this preference, but it's not guaranteed. Each payer has its own restrictions and behaviors.
- This property isn't returned for enrollment records created before Stedi added support for aggregation preferences.
- **`createdAt`** (`string`) (required): The date and time when the enrollment was created within Stedi.
- **`documents`** (`array`): Documents associated with this enrollment, excluding deleted documents.
- Items schema: `EnrollmentDocument`
- **`history`** (`array`): The history of updates to this enrollment, such as status changes. This property is experimental and may change in the future.
- Items schema: `EnrollmentHistoryEntry`
- **`id`** (`string`) (required): The Stedi-assigned identifier for the enrollment request.
- **`lastEraReceivedAt`** (`string`): The timestamp of the most recent 835 ERA (Electronic Remittance Advice) Stedi received for this enrollment, based on the enrollment's payer ID, provider NPI, and provider tax ID. Stedi automatically updates this property for each new ERA.
- This property is only returned for ERA enrollments in `LIVE` status with at least one matching ERA from the payer.
- If this timestamp doesn't match your expected timeline for ERA processing, there may be an upstream issue. Contact Stedi support for assistance.
- **`payer`** (`object`) (required): Information about the payer the provider is enrolling with.
- **`primaryContact`** (`object`) (required): The contact information for the provider. This is where the payer will send communications about the enrollment, if needed.
- **`provider`** (`object`) (required): Information about the provider enrolling with the payer.
- **`providerTransactionAccessNumber`** (`string`): This property is required for payers that require a Provider Transaction Access Number (PTAN).
The PTAN is a Medicare-issued number given to providers upon enrollment with Medicare. This number is usually six digits and is assigned based on the type of service and the location of the provider. Upon enrollment, Medicare Administrating Contracting (MAC) providers should receive their assigned PTAN number in their approval letter.
- **`reason`** (`string`): Reasons why the enrollment request is still in `PROVISIONING` status, may take additional time to process, or was rejected by the payer. Only Stedi can set or update this property.
- **`requestedEffectiveDate`** (`string`): The requested effective date for the enrollment in YYYYMMDD format. This is the date the submitter would like the enrollment to take effect with the payer. If not provided during submission, Stedi defaults to the enrollment's submission date.
Not all payers support requested effective dates. Stedi can't guarantee that the enrollment will be effective with the payer on this exact date.
- **`source`** (`object`): The source of this enrollment.
- **`status`** (`object`): The status of the enrollment. You can submit enrollments with either `DRAFT` or `STEDI_ACTION_REQUIRED` status. The default status is `DRAFT` if not specified. When you're ready for Stedi to begin processing the enrollment, set the status to `STEDI_ACTION_REQUIRED`. Once an enrollment is `STEDI_ACTION_REQUIRED`, only Stedi can set or update its status.
- `DRAFT` - You're still editing the enrollment and haven't submitted it to Stedi.
- `STEDI_ACTION_REQUIRED` - You have submitted the enrollment and it is ready for Stedi to begin processing.
- `PROVIDER_ACTION_REQUIRED` - The enrollment requires action from the healthcare provider to proceed, such as providing additional documentation. Stedi will add a note to your enrollment request with clear instructions.
- `SUBMITTED` - (Deprecated) Legacy status being phased out in favor of the more specific action-required statuses. If you set an enrollment request to `SUBMITTED`, Stedi treats it as `STEDI_ACTION_REQUIRED`.
- `PROVISIONING` - Stedi has begun the process of completing the enrollment with the payer.
- `LIVE` - The enrollment process is complete, and the specified provider can begin exchanging the listed transaction types with the payer.
- `REJECTED` - The payer rejected the enrollment. Common reasons for rejection include incorrect details in the request and that the provider is not credentialed with the payer. Customer support will contact you with reasons for rejection and next steps.
- `CANCELED` - The enrollment has been terminated per customer or provider request.
- **`statusLastUpdatedAt`** (`string`) (required): The date and time when the enrollment status was last updated. This timestamp is used to track enrollment processing durations and enables filtering to identify recently changed enrollments. It automatically updates whenever an enrollment's status changes but remains unchanged during other updates.
- **`submittedAt`** (`string`): The date and time when the enrollment was submitted. If the enrollment is in `DRAFT` status, `submittedAt` is not present. When the enrollment transitions from draft to `STEDI_ACTION_REQUIRED`, `submittedAt` is updated to the submission time. If the enrollment was created and submitted immediately, the `submittedAt` time will be equal or close to the `createdAt` time.
- **`tasks`** (`array`): Tasks associated with this enrollment representing work that needs to be completed. Each task has a responsible party and specific definition.
- Items schema: `Task`
- **`transactions`** (`object`) (required): The type of transactions included in the enrollment.
- **`updatedAt`** (`string`) (required): The date and time when the enrollment was updated.
- **`userEmail`** (`string`) (required): The email address where Stedi should send updates about the enrollment. We'll use it to notify you when there are next steps and send updates on the enrollment's status.
- This email address can be different from the `primaryContact.email` where the payer sends communications about the enrollment.
- For [automatic enrollment requests](https://www.stedi.com/docs/healthcare/create-manage-transaction-enrollments#automatic-enrollment-requests), Stedi sets this to the oldest account member with the Admin role.
**Example:**
```json
{
"aggregationPreference": {
"taxId": "123456789"
},
"createdAt": "2024-11-07T05:31:56Z",
"history": [
{
"changedAt": "2025-11-07T05:31:56Z",
"changedBy": "test@example.com",
"newStatus": "STEDI_ACTION_REQUIRED",
"type": "STATUS_CHANGE"
},
{
"changedAt": "2024-11-07T05:31:56Z",
"changedBy": "test@example.com",
"newStatus": "DRAFT",
"type": "STATUS_CHANGE"
}
],
"id": "db6675c5-7bg7-4af9-8c68-a54a336d2911",
"payer": {
"name": "UnitedHealthcare",
"stediPayerId": "KMQTZ",
"submittedPayerIdOrAlias": "87726"
},
"primaryContact": {
"city": "A City",
"email": "test@example.com",
"firstName": "Updated First Name",
"lastName": "Updated Last Name",
"phone": "3331234567",
"state": "MD",
"streetAddress1": "123 Some Str.",
"zipCode": "20814"
},
"provider": {
"id": "db6665c5-7b97-4af9-8c68-a00a336c2998",
"name": "Test Medical Provider",
"npi": "1234567890",
"taxId": "123456789",
"taxIdType": "EIN"
},
"requestedEffectiveDate": "20250301",
"source": "API",
"status": "STEDI_ACTION_REQUIRED",
"statusLastUpdatedAt": "2024-11-07T05:31:56Z",
"transactions": {
"claimPayment": {
"enroll": true
}
},
"updatedAt": "2024-11-18T07:25:42Z",
"userEmail": "test@example.com"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
QuotaExceededException 429 response
**Schema:** `QuotaExceededExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Update Provider
Source: https://www.stedi.com/docs/healthcare/api-reference/post-enrollment-update-provider
This endpoint allows you to update information for an existing provider. For example, you may want to add an additional contact.
Please note:
* Calling this endpoint completely overwrites the previous request record. You **must** provide all the information for the provider in the request, not just the properties you want to update.
* Updating a provider record doesn't affect associated enrollments that are in `SUBMITTED`, `PROVISIONING` or `LIVE` status. If you need to update the provider details for an enrollment with these statuses, contact support.
## API Specification
Updates an existing provider's information. Note that NPI and tax ID cannot be changed after creation.
**Endpoint:** `POST /providers/{providerId}`
**Base URL:** `https://enrollments.us.stedi.com/2024-09-01`
### Parameters
- **`providerId`** (path) (required): The Stedi-assigned identifier for the provider you want to update.
- Type: `string`
### Request Body
**Schema:** `UpdateProviderRequestContent`
**Properties:**
- **`contacts`** (`array`): The contact information for the provider. These contacts appear as prepopulated options for contact information when creating enrollment requests for this provider in the Stedi portal. They aren't automatically added to enrollment requests.
These contacts should specify where payers should send communications about the enrollment, if needed.
- Either `organizationName` _or_ `firstName` and `lastName` are required.
- The name and address should match exactly what the payer has on file for the provider. Some payers reject enrollment requests with addresses that don't match their records.
- If you're submitting enrollment requests on a provider's behalf, you may want to set the phone number and email to your own contact details. Do this when you want the payer to contact you about the enrollment status instead of the provider directly.
- These contacts are for convenience only. You can specify different contacts on enrollment requests as needed.
- Items schema: `ProviderContact`
- **`name`** (`string`) (required): The provider's business name. This is typically the provider's practice name, such as `Dental Associates, LLC`, but it can also be the provider's first and last name.
**Example:**
```json
{
"contacts": [
{
"city": "A City",
"email": "bob@fortdental.center",
"firstName": "Test",
"lastName": "Tester",
"phone": "5551234567",
"state": "WA",
"streetAddress1": "123 Some Str",
"zipCode": "12345"
}
],
"name": "TEST Updated Dental Inc"
}
```
### Responses
#### 200
UpdateProvider 200 response
**Schema:** `UpdateProviderResponseContent`
**Properties:**
- **`contacts`** (`array`): The contact information for the provider. These contacts appear as prepopulated options for contact information when creating enrollment requests for this provider in the Stedi portal. They aren't automatically added to enrollment requests.
These contacts should specify where payers should send communications about the enrollment, if needed.
- Items schema: `ProviderContact`
- **`createdAt`** (`string`): The date and time Stedi created the provider record.
- **`id`** (`string`) (required): A unique identifier Stedi assigns to this provider.
- **`name`** (`string`) (required): The provider's business name. This is typically the provider's practice name, such as `Dental Associates, LLC`, but it can also be the provider's first and last name.
- **`npi`** (`string`) (required): The provider's [National Provider Identifier (NPI)](https://npiregistry.cms.hhs.gov/search). This is a 10-digit number that is unique to the provider.
Each provider record must have a unique `npi` and `taxId` combination. For example, you can create two provider records with the same `npi` as long as they have different values for `taxId`.
- **`taxId`** (`string`): The provider's tax ID, as specified by `taxIdType`. This identifier has to be provided without any separators, such as dashes or spaces. For example 111-22-3333 is invalid but `111223333` is valid.
Each provider record must have a unique `npi` and `taxId` combination. For example, you can create two provider records with the same `taxId` as long as they have different values for `npi`.
- **`taxIdType`** (`object`): The type of tax ID. Can be either an `EIN` - Employer Identification Number, or an `SSN` - Social Security Number.
- **`updatedAt`** (`string`): The date and time Stedi last updated the provider record.
**Example:**
```json
{
"contacts": [
{
"city": "A City",
"email": "bob@fortdental.center",
"firstName": "Test",
"lastName": "Tester",
"organizationName": "",
"phone": "5551234567",
"state": "WA",
"streetAddress1": "123 Some Str",
"zipCode": "12345"
}
],
"createdAt": "2024-11-18T17:39:52.406Z",
"id": "10334e76-f073-4b5d-8984-81d8e5107857",
"name": "TEST Updated Dental Inc",
"npi": "1999999999",
"taxId": "111222333",
"taxIdType": "EIN",
"updatedAt": "2024-11-19T19:24:33.246Z"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
QuotaExceededException 429 response
**Schema:** `QuotaExceededExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Update Enrollment Task
Source: https://www.stedi.com/docs/healthcare/api-reference/post-enrollment-update-task
This endpoint updates the completion status and data of a task associated with a [transaction enrollment](/healthcare/transaction-enrollment).
Stedi adds tasks to an enrollment when specific actions are required to complete the enrollment process. For example, we might add a task to request additional information from the provider.
When the task's `responsibleParty` is set to `PROVIDER`, you can use this endpoint to mark the task as completed once the provider has taken the required action. You can also use this endpoint to mark tasks as incomplete if they were marked complete in error.
1. Call this endpoint with the `completed` property set to `true` to mark the task as completed. Optionally, provide additional details in the `responseData` object.
2. The endpoint returns the updated task record.
Stedi displays the task as completed in the Stedi portal and proceeds with the enrollment process.
## Task rank order [#task-rank-order]
You must complete tasks in the order defined by their `rank` property. For example, you can't complete a task with rank `2` if there's an uncompleted task on the enrollment record with rank `1`. If you try to complete a task out of order, the endpoint returns an HTTP `400` error.
## API Specification
Updates a task associated with an enrollment.
**Endpoint:** `POST /tasks/{taskId}`
**Base URL:** `https://enrollments.us.stedi.com/2024-09-01`
### Parameters
- **`taskId`** (path) (required): The Stedi-assigned identifier for the task to complete. You can get the task ID from either the [Retrieve Enrollment](/healthcare/api-reference/get-enrollment) or [List Enrollments](/healthcare/api-reference/get-enrollment-list-enrollments) endpoint.
- Type: `string`
### Request Body
**Schema:** `UpdateTaskPostRequestContent`
**Properties:**
- **`completed`** (`boolean`): Indicates whether the task is completed. Set to `true` to mark the task as complete. If omitted, the default is `false`.
- **`responseData`** (`object`): Additional data you can submit to Stedi when completing a task.
- Required for `provideFilledPdf` tasks. Use the `pdfUpload` object type. [Learn more](https://www.stedi.com/docs/healthcare/create-manage-transaction-enrollments#pdf-workflow)
- Optional for `provideInformation` tasks.
- Stedi ignores this object for `followInstructions` tasks.
**Example:**
```json
{
"completed": true,
"responseData": {
"provideInformation": {
"response": "I have completed the required steps as instructed."
}
}
}
```
### Responses
#### 200
UpdateTaskPost 200 response
**Schema:** `UpdateTaskPostResponseContent`
**Properties:**
- **`task`** (`object`) (required): The updated task record.
**Example:**
```json
{
"task": {
"completedAt": "2024-06-01T12:00:00Z",
"definition": {
"provideInformation": {
"instructions": "Please provide a brief summary of your experience."
}
},
"id": "01937d50-1234-7890-abcd-567890abcdef",
"isComplete": true,
"rank": 1,
"responseData": {
"provideInformation": {
"response": "I have completed the required steps as instructed."
}
},
"responsibleParty": "PROVIDER"
}
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
QuotaExceededException 429 response
**Schema:** `QuotaExceededExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Batch Eligibility Check (270)
Source: https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-batch-eligibility
You may want to periodically conduct asynchronous [batch eligibility checks](/healthcare/batch-refresh-eligibility-checks) for your entire patient population or a subset of patients, such as those who have active care plans or who have future services scheduled. These data refreshes allow you to proactively reach out to patients when they lose or change coverage.
* Call this endpoint with a JSON payload containing one or more eligibility checks. You can submit up to 10,000 individual eligibility checks within a single batch, and you can submit as many batches as you need to process. Use the optional `maxRetryHours` property to configure the automatic retry period for checks that fail due to payer connectivity issues.
* The endpoint returns a synchronous response containing a `batchId` that you can use to retrieve the results of these checks later, using the [Poll Batch Eligibility Checks](/healthcare/api-reference/get-healthcare-polling-eligibility) endpoint.
* Stedi translates each eligibility check included in the request to the X12 270 EDI format and sends it to the appropriate payer.
## Start with real-time checks [#start-with-real-time-checks]
Batch checks have a longer feedback cycle than real-time checks because you don’t receive the payer’s response immediately. That’s why we strongly recommend starting with real-time checks when integrating with a new payer or working with eligibility checks for the first time. To perform synchronous eligibility checks, use the [Real-Time Eligibility Check](/healthcare/api-reference/post-healthcare-eligibility) endpoint.
## API Specification
Submit multiple eligibility checks for Stedi to process asynchronously
**Endpoint:** `POST /eligibility-manager/batch-eligibility`
**Base URL:** `https://manager.us.stedi.com/2024-04-01`
### Parameters
- **`X-Forwarded-For`** (header):
- Type: `string`
### Request Body
**Schema:** `BatchEligibilityChecksRequestContent`
**Properties:**
- **`items`** (`array`) (required): Each entry in this array represents a single eligibility check. You can submit up to 10,000 eligibility checks in a single request. **Warning:** If _any_ of the individual checks contain invalid JSON data, such as missing required properties or invalid values, Stedi rejects the entire batch with a `400` status code and returns errors to help you correct the issues.
- Items schema: `BatchEligibilityChecksItem`
- **`maxRetryHours`** (`integer`): The maximum number of hours that Stedi will retry eligibility checks in this batch that fail due to [payer connectivity issues](https://www.stedi.com/docs/healthcare/eligibility-troubleshooting#payer-connectivity-issues). Must be an integer between 8 and 24 hours. If not specified, the default is 8 hours.
- **`name`** (`string`): The name that Stedi will use when displaying this batch on the [Eligibility check batches page](https://portal.stedi.com/app/healthcare/checks/batch). It must be unique within your Stedi account. If you don't specify a name, Stedi sets this property to the autogenerated `batchId` returned in the response.
**Example:**
```json
{
"items": [
{
"encounter": {
"serviceTypeCodes": [
"MH"
]
},
"provider": {
"npi": "1234567891",
"organizationName": "ACME Health Services"
},
"submitterTransactionIdentifier": "ABC123456789",
"subscriber": {
"dateOfBirth": "19000101",
"firstName": "Jane",
"lastName": "Doe",
"memberId": "1234567890"
},
"tradingPartnerServiceId": "AHS"
},
{
"encounter": {
"serviceTypeCodes": [
"78"
]
},
"provider": {
"npi": "1234567891",
"organizationName": "ACME Health Services"
},
"submitterTransactionIdentifier": "DEF123456799",
"subscriber": {
"dateOfBirth": "19001021",
"firstName": "John",
"lastName": "Doe",
"memberId": "1234567892"
},
"tradingPartnerServiceId": "AHS"
}
],
"name": "march-2024-eligibility-batch"
}
```
### Responses
#### 200
BatchEligibilityChecks 200 response
**Schema:** `BatchEligibilityChecksResponseContent`
**Properties:**
- **`batchId`** (`string`) (required): An identifier for this batch of eligibility checks. You can use this identifier to retrieve the results of this batch using the [Poll Batch Eligibility Checks](https://www.stedi.com/docs/healthcare/api-reference/get-healthcare-polling-eligibility) endpoint.
- **`submittedAt`** (`string`) (required): The date and time that the batch of eligibility checks was submitted to Stedi for processing.
**Example:**
```json
{
"batchId": "01928d19-df25-76c0-8d51-f5351260fa05",
"submittedAt": "2023-11-07T05:31:56Z"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 401
UnauthorizedException 401 response
**Schema:** `UnauthorizedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 409
ResourceConflictException 409 response
**Schema:** `ResourceConflictExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Real-Time Claim Status (276/277) Raw X12
Source: https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-claim-status-raw-x12
You may need to submit a 276 real-time claim status request when you don’t receive a 277CA or 835 ERA response from the payer within your expected timeframe. This endpoint is ideal if you have an existing system that generates X12 EDI files and you want to send them through Stedi.
1. Call this endpoint with a payload in [276 X12 EDI format](https://portal.stedi.com/app/guides/view/hipaa/claim-status-request-x212/01GRYB6A4XEJQ61Y2K2KT606E5).
* The request must be for a production claim that has entered the payer's processing system. Requests for test claims or claims that the payer hasn't yet accepted won't return results.
* Providing too much information can negatively affect the results. You should start with our [recommended base request](/healthcare/check-claim-status#x12-base-request).
2. Stedi validates the EDI and sends the transaction to the payer.
3. The endpoint returns a synchronous 277 claim status response from the payer in JSON format. The response contains information about the claims matching the criteria you provided in the request and their current status.
The response may contain information about more than one claim, if the payer has multiple claims on file that match the information you provided.
## API Specification
Submit a 276/277 real-time claim status check in raw X12 EDI format
**Endpoint:** `POST /change/medicalnetwork/claimstatus/v2/raw-x12`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Request Body
**Schema:** `ClaimStatusRawX12RequestContent`
**Properties:**
- **`x12`** (`string`) (required)
**Example:**
```json
{
"x12": "ISA*00* *00* *ZZ*SENDER *ZZ*RECEIVER *250916*2048*^*00501*000000001*0*T*>~GS*HR*SENDERGS*RECEIVERGS*20250916*204811*1*X*005010X212~ST*276*0001*005010X212~BHT*0010*13*ABC276XXX*20250915*1425~HL*1**20*1~NM1*PR*2*UNITEDHEALTHCARE*****PI*87726~HL*2*1*21*1~NM1*41*2*PROVIDER NAME*****46*123456789~HL*3*2*19*1~NM1*1P*2*PROVIDER NAME*****XX*1999999984~HL*4*3*22*0~DMG*D8*19710101~NM1*IL*1*DOE*JANE****MI*UHC123456~TRN*1*123456789~DTP*472*RD8*20250630-20250702~SE*14*0001~GE*1*1~IEA*1*000000001~"
}
```
### Responses
#### 200
ClaimStatusRawX12 200 response
**Schema:** `ClaimStatusRawX12ResponseContent`
**Properties:**
- **`claims`** (`array`): The status information for the claim referenced in the original claim status request.
The payer may return multiple claims in the response if they have more than one claim on file that matches the information you provided.
- Items schema: `Claim`
- **`controlNumber`** (`string`): The control number the payer provided in the claim status response. This is used to identify the transaction.
- **`dependent`** (`object`): Information about the dependent listed in the referenced claim.
- **`errorResponse`** (`object`)
- **`implementationTransactionSetSyntaxError`** (`string`): The syntax error code in the 999 Implementation Acknowledgment. It indicates the type of error (if present) in the EDI request syntax. Visit `IK502` in the [Implementation Acknowledgment specification](https://portal.stedi.com/app/guides/view/hipaa/implementation-acknowledgment-x231/01HRF41ES1DVGCA6X1EHSRPFXZ#properties.heading.properties.transaction_set_response_header_AK2_loop.items.properties.transaction_set_response_trailer_IK5.properties.implementation_transaction_set_syntax_error_code_02) for a complete list.
- **`meta`** (`object`)
- **`payer`** (`object`)
- **`providers`** (`array`): Information about the billing and/or service providers related to the referenced claim.
- Items schema: `StatusResponseProvider`
- **`reassociationKey`** (`string`): The control number for the transaction.
- **`status`** (`string`): The status of the entire claim.
- **`subscriber`** (`object`): Information about the subscriber listed in the referenced claim.
- **`tradingPartnerServiceId`** (`string`): An ID for the payer you identified in the original claim status request. This value may differ from the `tradingPartnerServiceId` you submitted in the original request because it reflects the payer's internal concept of their ID, not necessarily the ID Stedi uses to route requests to this payer.
- **`transactionSetAcknowledgement`** (`string`): The acknowledgment code in the 999 Implementation Acknowledgment, an EDI file generated by the payer to acknowledge receipt of the claim status request. It indicates whether the claim status request was accepted or rejected due to errors in the EDI request syntax.
- **`x12`** (`string`): The raw X12 EDI response, which is either a 277 Status Request Response or a 999 Implementation Acknowledgment. A 999 indicates that the request data failed validation. Common failure reasons are missing required segments and invalid values.
**Example:**
```json
{
"claims": [
{
"claimStatus": {
"amountPaid": "108.77",
"checkIssueDate": "2025-07-17",
"checkNumber": "123456789",
"claimServiceDate": "20250701",
"effectiveDate": "2025-07-17",
"paidDate": "2025-07-15",
"patientAccountNumber": "12345678",
"statusCategoryCode": "F1",
"statusCategoryCodeValue": "Finalized/Payment - The claim/line has been paid.",
"statusCode": "65",
"statusCodeValue": "Claim/line has been paid.",
"submittedAmount": "267.54",
"trackingNumber": "0123456789",
"tradingPartnerClaimNumber": "0123456789"
},
"serviceDetails": [
{
"service": {
"amountPaid": "108.77",
"procedureId": "90837",
"serviceIdQualifier": "Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes",
"serviceIdQualifierCode": "HC",
"submittedAmount": "267.54",
"submittedUnits": "1"
},
"status": [
{
"effectiveDate": "2025-07-17",
"statusCategoryCode": "F1",
"statusCategoryCodeValue": "Finalized/Payment - The claim/line has been paid.",
"statusCode": "107",
"statusCodeValue": "Processed according to contract provisions (Contract refers to provisions that exist between the Health Plan and a Provider of Health Care Services)."
}
]
}
]
}
],
"controlNumber": "123456789",
"payer": {
"organizationName": "UNITEDHEALTHCARE",
"payerIdentification": "87726"
},
"providers": [
{
"npi": "1999999984",
"organizationName": "Provider Name",
"providerType": "BillingProvider"
}
],
"subscriber": {
"firstName": "Jane",
"lastName": "Doe",
"memberId": "UHC123456"
},
"tradingPartnerServiceId": "87726",
"x12": "ISA*00* *00* *ZZ*STEDI *01*117151744 *250912*1718*^*00501*123456789*0*P*:~GS*HN*STEDI*117151744*20250912*171842*1*X*005010X212~ST*277*1001*005010X212~BHT*0010*08*0123456789*20250912*171841*DG~HL*1**20*1~NM1*PR*2*UNITEDHEALTHCARE*****PI*87726~HL*2*1*21*1~NM1*41*2*PROVIDER NAME*****46*1234567890~HL*3*2*19*1~NM1*1P*2*PROVIDER NAME*****XX*1999999984~HL*4*3*22*0~NM1*IL*1*DOE*JANE****MI*UHC123456~TRN*2*0123456789~STC*F1:65*20250717**267.54*108.77*20250715**20250717*123456789~REF*1K*0123456789~REF*EJ*12345678~DTP*472*D8*20250701~SVC*HC:90837:GT*267.54*108.77****1~STC*F1:107*20250717~DTP*472*D8*20250701~SE*19*1001~GE*1*1~IEA*1*123456789~"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`code`** (`string`): A code describing the type of validation failure.
- **`message`** (`string`) (required): A message describing the causes of the validation failure. There may be more than one.
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# Real-Time Claim Status (276/277) JSON
Source: https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-claim-status
You may need to submit a 276 real-time claim status request when you don't receive a 277CA claim acknowledgment or 835 Electronic Remittance Advice (ERA) response from the payer within your expected timeframe.
1. Call this endpoint with a JSON payload.
* The request must be for a production claim that has entered the payer's processing system. Requests for test claims or claims that the payer hasn't yet accepted won't return results.
* Providing too much information can negatively affect the results. You should start with our [recommended base request](/healthcare/check-claim-status#json-base-request).
2. Stedi generates the X12 276 EDI transaction and sends it to the payer.
3. The endpoint returns a synchronous 277 claim status response from the payer in JSON format. The response contains information about the claims matching the criteria you provided in the request and their current status.
The response may contain information about more than one claim, if the payer has multiple claims on file that match the information you provided.
## API Specification
Submit a 276/277 real-time claim status check in JSON format
**Endpoint:** `POST /change/medicalnetwork/claimstatus/v2`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Request Body
**Schema:** `ClaimStatusRequestContent`
**Properties:**
- **`controlNumber`** (`string`): Stedi generates a control number for each claim status check, so you don’t need to include this property in your request.
- **`dependent`** (`object`): Information about the dependent listed in the referenced claim. You must submit the dependent's `firstName`, `lastName`, `dateOfBirth`, and `gender` (if known). If the claim set the dependent's gender to `U` for unknown, you should omit the `gender` property.
- **`encounter`** (`object`)
- **`providers`** (`array`) (required): Information about the billing provider and (optionally) service providers related to the referenced claim.
- Exactly one billing provider is **required** in this array. Requests that include only a service provider are rejected with a `400` error.
- For each provider, you must set the `providerType` and one of the following identifiers: `npi`, `taxId`, or `etin`.
- When the `providerType` = `BillingProvider`, we recommend setting `etin` as the identifier.
- Items schema: `StatusRequestProvider`
- **`serviceLineInformation`** (`object`)
- **`serviceLinesInformation`** (`array`)
- Items schema: `ServiceLineInformation`
- **`subscriber`** (`object`) (required)
- **`tradingPartnerName`** (`string`): This is the payer name, such as Cigna or Aetna.
- **`tradingPartnerServiceId`** (`string`) (required): The payer ID. Visit the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list.
- You can send requests using the primary payer ID, the Stedi payer ID, or any alias listed in the payer record.
- You must include leading `0` characters - payer IDs are alphanumeric strings and must be treated as complete strings, not integers. For example, use `00540` for SISCO, not `540`.
**Example:**
```json
{
"encounter": {
"beginningDateOfService": "20250630",
"endDateOfService": "20250702"
},
"providers": [
{
"npi": "1999999984",
"organizationName": "Provider Name",
"providerType": "BillingProvider"
}
],
"subscriber": {
"dateOfBirth": "19710101",
"firstName": "Jane",
"lastName": "Doe",
"memberId": "UHC123456"
},
"tradingPartnerServiceId": "87726"
}
```
### Responses
#### 200
ClaimStatus 200 response
**Schema:** `ClaimStatusResponseContent`
**Properties:**
- **`claims`** (`array`): The status information for the claim referenced in the original claim status request.
The payer may return multiple claims in the response if they have more than one claim on file that matches the information you provided.
- Items schema: `Claim`
- **`controlNumber`** (`string`): The control number the payer provided in the claim status response. This is used to identify the transaction.
- **`dependent`** (`object`): Information about the dependent listed in the referenced claim.
- **`errorResponse`** (`object`)
- **`implementationTransactionSetSyntaxError`** (`string`): The syntax error code in the 999 Implementation Acknowledgment. It indicates the type of error (if present) in the EDI request syntax. Visit `IK502` in the [Implementation Acknowledgment specification](https://portal.stedi.com/app/guides/view/hipaa/implementation-acknowledgment-x231/01HRF41ES1DVGCA6X1EHSRPFXZ#properties.heading.properties.transaction_set_response_header_AK2_loop.items.properties.transaction_set_response_trailer_IK5.properties.implementation_transaction_set_syntax_error_code_02) for a complete list.
- **`meta`** (`object`)
- **`payer`** (`object`)
- **`providers`** (`array`): Information about the billing and/or service providers related to the referenced claim.
- Items schema: `StatusResponseProvider`
- **`reassociationKey`** (`string`): The control number for the transaction.
- **`status`** (`string`): The status of the entire claim.
- **`subscriber`** (`object`): Information about the subscriber listed in the referenced claim.
- **`tradingPartnerServiceId`** (`string`): An ID for the payer you identified in the original claim status request. This value may differ from the `tradingPartnerServiceId` you submitted in the original request because it reflects the payer's internal concept of their ID, not necessarily the ID Stedi uses to route requests to this payer.
- **`transactionSetAcknowledgement`** (`string`): The acknowledgment code in the 999 Implementation Acknowledgment, an EDI file generated by the payer to acknowledge receipt of the claim status request. It indicates whether the claim status request was accepted or rejected due to errors in the EDI request syntax.
- **`x12`** (`string`): The raw X12 response from the payer.
**Example:**
```json
{
"claims": [
{
"claimStatus": {
"amountPaid": "108.77",
"checkIssueDate": "2025-07-17",
"checkNumber": "123456789",
"claimServiceDate": "20250701",
"effectiveDate": "2025-07-17",
"paidDate": "2025-07-15",
"patientAccountNumber": "12345678",
"statusCategoryCode": "F1",
"statusCategoryCodeValue": "Finalized/Payment - The claim/line has been paid.",
"statusCode": "65",
"statusCodeValue": "Claim/line has been paid.",
"submittedAmount": "267.54",
"trackingNumber": "0123456789",
"tradingPartnerClaimNumber": "0123456789"
},
"serviceDetails": [
{
"service": {
"amountPaid": "108.77",
"procedureId": "90837",
"serviceIdQualifier": "Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes",
"serviceIdQualifierCode": "HC",
"submittedAmount": "267.54",
"submittedUnits": "1"
},
"status": [
{
"effectiveDate": "2025-07-17",
"statusCategoryCode": "F1",
"statusCategoryCodeValue": "Finalized/Payment - The claim/line has been paid.",
"statusCode": "107",
"statusCodeValue": "Processed according to contract provisions (Contract refers to provisions that exist between the Health Plan and a Provider of Health Care Services)."
}
]
}
]
}
],
"controlNumber": "123456789",
"payer": {
"organizationName": "UNITEDHEALTHCARE",
"payerIdentification": "87726"
},
"providers": [
{
"npi": "1999999984",
"organizationName": "Provider Name",
"providerType": "BillingProvider"
}
],
"subscriber": {
"firstName": "Jane",
"lastName": "Doe",
"memberId": "UHC123456"
},
"tradingPartnerServiceId": "87726",
"x12": "ISA*00* *00* *ZZ*STEDI *01*117151744 *250912*1718*^*00501*123456789*0*P*:~GS*HN*STEDI*117151744*20250912*171842*1*X*005010X212~ST*277*1001*005010X212~BHT*0010*08*0123456789*20250912*171841*DG~HL*1**20*1~NM1*PR*2*UNITEDHEALTHCARE*****PI*87726~HL*2*1*21*1~NM1*41*2*PROVIDER NAME*****46*1234567890~HL*3*2*19*1~NM1*1P*2*PROVIDER NAME*****XX*1999999984~HL*4*3*22*0~NM1*IL*1*DOE*JANE****MI*UHC123456~TRN*2*0123456789~STC*F1:65*20250717**267.54*108.77*20250715**20250717*123456789~REF*1K*0123456789~REF*EJ*12345678~DTP*472*D8*20250701~SVC*HC:90837:GT*267.54*108.77****1~STC*F1:107*20250717~DTP*472*D8*20250701~SE*19*1001~GE*1*1~IEA*1*123456789~"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`code`** (`string`): A code describing the type of validation failure.
- **`message`** (`string`) (required): A message describing the causes of the validation failure. There may be more than one.
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# Professional Claims (837P) Raw X12
Source: https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-claims-raw-x12
This endpoint is ideal if you have an existing system that generates X12 EDI files and you want to send them through Stedi.
1. Call this endpoint with a payload in [837 X12 EDI format](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-professional-x222a1/01HR60MDFAGCSEJNKY8J38867Y).
2. Stedi validates the EDI and sends the claim to the payer.
3. The endpoint returns a response from Stedi in JSON format containing information about the claim you submitted and whether the submission was successful.
## CMS-1500 Claim Form PDF [#cms-1500-claim-form-pdf]
When you submit a professional claim, Stedi automatically generates a [1500 claim form](https://www.nucc.org/index.php/1500-claim-form-mainmenu-35) PDF. If you plan to send these PDFs to payers or retain them for your records, we strongly recommend reviewing the [CMS-1500 claim form PDF](/healthcare/cms-1500-claim-form-pdf) documentation to learn how to structure claim submissions for optimal generation, the correct printer settings for generated PDFs, and general best practices.
## API Specification
Submit an 837P professional claim in raw X12 EDI format
**Endpoint:** `POST /change/medicalnetwork/professionalclaims/v3/raw-x12-submission`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Parameters
- **`Idempotency-Key`** (header): A unique string to identify this request to the server. The key can be up to 255 characters. You can safely retry requests with the same idempotency key within 24 hours of making the first request. This prevents you from sending duplicate claims due to network errors or other intermittent failures. [Learn more](https://www.stedi.com/docs/api-reference/index#idempotency-keys).
- Type: `string`
### Request Body
**Schema:** `ClaimsRawX12SubmissionRequestContent`
**Properties:**
- **`x12`** (`string`) (required)
**Example:**
```json
{
"x12": "ISA*00* *00* *ZZ*574183004559 *ZZ*STEDITEST *260213*2039*^*00501*000000039*0*T*>~GS*HC*574183004559*STEDITEST*20260213*203918*39*X*005010X222A1~ST*837*0001*005010X222A1~BHT*0019*00*01KHCBK84E40QQYJVXA5VVXG54*20260213*2038*CH~NM1*41*2*Test Data Health Services, Inc.*****46*123435~PER*IC**TE*5552223333~NM1*40*2*Cigna*****46*6400~HL*1**20*1~PRV*BI*PXC*2084P0800X~NM1*85*2*Therapy Associates*****XX*1999999984~N3*123 Some St*Floor 1~N4*A City*NY*123450000~REF*EI*123456789~PER*IC*Test Data Health Services, Inc.*TE*5553334444~HL*2*1*22*0~SBR*P*18*3335555******CI~NM1*IL*1*Anon*John****MI*U7777788888~N3*2222 Random St~N4*A City*NY*123450000~DMG*D8*20000101*M~NM1*PR*2*Cigna*****PI*6400~CLM*123456789*109.2***02>B>1*Y*A*Y*Y~HI*ABK>F1111~NM1*77*2*Smith Associates~N3*1234 Other St~N4*A City*NY*123450000~LX*1~SV1*HC>90837>95*109.2*UN*1***1~DTP*472*D8*20240101~REF*6R*111222333~SE*29*0001~GE*1*39~IEA*1*000000039~"
}
```
### Responses
#### 200
ClaimsRawX12Submission 200 response
**Schema:** `ClaimsRawX12SubmissionResponseContent`
**Properties:**
- **`claimReference`** (`object`)
- **`controlNumber`** (`string`): An identifier for the transaction.
- **`editResponses`** (`array`): Currently not used.
- Items schema: `EditResponse`
- **`editStatus`** (`string`): This shape is deprecated: Currently not used.
- **`errors`** (`array`): Errors resulting from claim edits. You must review and fix these errors before resubmitting.
- Items schema: `ClaimsError`
- **`failure`** (`object`)
- **`httpStatusCode`** (`object`)
- **`meta`** (`object`)
- **`payer`** (`object`)
- **`status`** (`string`): The status of the claim submission.
- **`tradingPartnerServiceId`** (`string`): An ID for the payer you identified in the original claim. This value may differ from the `tradingPartnerServiceId` you submitted in the original request because it reflects the payer's internal concept of their ID, not necessarily the ID Stedi uses to route requests to this payer.
- **`warnings`** (`array`): A list of warnings. Currently not used.
- Items schema: `ClaimsWarning`
- **`x12`** (`string`): A [277CA claim acknowledgment](https://www.stedi.com/docs/healthcare/claim-responses-overview#277ca-claim-acknowledgment) acceptance or rejection from Stedi in X12 EDI format. It indicates whether the claim has passed Stedi's claim edits.
When the claim fails one or more edits, the 277CA contains `STC` segments with information about each error. These are the same error codes that appear in the `errors` array.
Note that this 277CA only indicates whether Stedi has accepted or rejected the claim submission. You may receive additional 277CA acceptances or rejections as the claim is routed to the payer.
**Example:**
```json
{
"claimReference": {
"correlationId": "01J1M588QT2TAV2N093GNJ998T",
"formatVersion": "5010",
"patientControlNumber": "22266555",
"payerId": "60054",
"rhclaimNumber": "01J1M588QT2TAV2N093GNJ998T",
"serviceLines": [
{
"lineItemControlNumber": "111222333"
}
],
"timeOfResponse": "2024-07-10T22:05:32.203Z"
},
"controlNumber": "000000001",
"httpStatusCode": "200 OK",
"meta": {
"traceId": "b727b8e7-1f00-4011-bc6e-e41444d406d8"
},
"payer": {
"payerId": "60054",
"payerName": "Cigna"
},
"status": "SUCCESS",
"tradingPartnerServiceId": "60054",
"x12": "ISA*00* *00* *ZZ*STEDITEST *ZZ*574183004559 *260213*1951*^*00501*980180479*0*T*>~GS*HN*STEDITEST*574183004559*20260213*195151*1*X*005010X214~ST*277*0001*005010X214~BHT*0085*08*01KHC8YJE8EY6A5HFR00Z5H305*20260213*195151*TH~HL*1**20*1~NM1*AY*2*STEDI INC*****46*117151744~TRN*1*01KHC8YJE8EY6A5HFR00Z5H305~DTP*050*D8*20260213~DTP*009*D8*20260213~HL*2*1*21*1~NM1*41*2*Test Data Health Services, Inc.*****46*123456~TRN*2*01KHC8Y4HNP0GVQ5NSVTPZBC0F~STC*A0>17>AY*20260213*WQ*109.2~QTY*90*1~AMT*YU*109.2~HL*3*2*19*1~NM1*85*2*Therapy Associates*****XX*1234567890~TRN*1*0~REF*TJ*123456789~QTY*QA*1~AMT*YU*109.2~HL*4*3*PT*0~NM1*QC*1*Anon*John****MI*U7777788888~TRN*2*111222333~STC*A1>20*20260213*WQ*109.2~DTP*472*RD8*20240101-20240101~SE*25*0001~GE*1*1~IEA*1*980180479~"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`code`** (`string`): A code describing the type of validation failure.
- **`message`** (`string`) (required): A message describing the causes of the validation failure. There may be more than one.
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 409
ConflictException 409 response
**Schema:** `ConflictExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Unique error code identifying the specific type of error.
- **`message`** (`string`) (required): Human readable error message explaining why the request was rejected.
#### 422
RequestChangedException 422 response
**Schema:** `RequestChangedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Unique error code identifying the specific type of error.
- **`message`** (`string`) (required): Human readable error message explaining why the request was rejected.
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# Professional Claims (837P) JSON
Source: https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-claims
This endpoint sends 837P professional claims to payers.
1. Call this endpoint with a JSON payload.
2. Stedi translates your request to the X12 837 EDI format and sends it to the payer.
3. The endpoint returns a response from Stedi in JSON format containing information about the claim you submitted and whether the submission was successful.
## CMS-1500 Claim Form PDF [#cms-1500-claim-form-pdf]
When you submit a professional claim, Stedi automatically generates a [1500 claim form](https://www.nucc.org/index.php/1500-claim-form-mainmenu-35) PDF. If you plan to send these PDFs to payers or retain them for your records, we strongly recommend reviewing the [CMS-1500 claim form PDF](/healthcare/cms-1500-claim-form-pdf) documentation to learn how to structure claim submissions for optimal generation, the correct printer settings for generated PDFs, and general best practices.
## API Specification
Submit an 837P professional claim in JSON format
**Endpoint:** `POST /change/medicalnetwork/professionalclaims/v3/submission`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Parameters
- **`Idempotency-Key`** (header): A unique string to identify this request to the server. The key can be up to 255 characters. You can safely retry requests with the same idempotency key within 24 hours of making the first request. This prevents you from sending duplicate claims due to network errors or other intermittent failures. [Learn more](https://www.stedi.com/docs/api-reference/index#idempotency-keys).
- Type: `string`
### Request Body
**Schema:** `ClaimsSubmissionRequestContent`
**Properties:**
- **`billing`** (`object`) (required)
- **`claimIdentifier`** (`object`)
- **`claimInformation`** (`object`) (required)
- **`controlNumber`** (`string`): Not currently used.
- **`dependent`** (`object`)
- **`ordering`** (`object`)
- **`payToAddress`** (`object`): Use when the address for payment is different than that of the billing provider for this claim.
This is also where you can provide the billing provider's mailing address when it's a PO Box, lockbox, or other non-physical address. The `billing.address` object must always contain a physical practice location where care is delivered.
- **`payToPlan`** (`object`)
- **`payerAddress`** (`object`): The payer's address. Some payers use this for internal routing. Only provide this address if the payer explicitly requires it.
- **`providers`** (`array`): Information about all providers, with each provider specified by its type (for example, `Referring`). You can't include this array in the same request as dedicated provider objects, such as `referring` or `rendering`.
- Items schema: `ClaimsProvider`
- **`receiver`** (`object`) (required)
- **`referring`** (`object`)
- **`rendering`** (`object`)
- **`submitter`** (`object`) (required)
- **`subscriber`** (`object`) (required)
- **`supervising`** (`object`)
- **`tradingPartnerName`** (`string`): This is the payer's business name, like Cigna or Aetna.
- **`tradingPartnerSecondaryIdentifiers`** (`object`): Secondary identifiers for the payer. You can include up to three properties in this object.
- **`tradingPartnerServiceId`** (`string`) (required): This is the Payer ID. Visit the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list. You can send requests using the Primary Payer ID, the Stedi Payer ID, or any alias listed in the payer record.
- **`usageIndicator`** (`string`): Whether you want to send a test or production claim. This property also allows you to filter claims in the Stedi portal by production or test data. By default, this property is set to `P` for production data. Use `T` to designate a claim as test data.
**Example:**
```json
{
"billing": {
"address": {
"address1": "123 Some St",
"address2": "Floor 1",
"city": "A City",
"postalCode": "123450000",
"state": "NY"
},
"contactInformation": {
"name": "Test Data Health Services, Inc.",
"phoneNumber": "5553334444"
},
"employerId": "123456789",
"npi": "1999999984",
"organizationName": "Therapy Associates",
"providerType": "BillingProvider",
"taxonomyCode": "2084P0800X"
},
"claimInformation": {
"benefitsAssignmentCertificationIndicator": "Y",
"claimChargeAmount": "109.20",
"claimFilingCode": "CI",
"claimFrequencyCode": "1",
"healthCareCodeInformation": [
{
"diagnosisCode": "F1111",
"diagnosisTypeCode": "ABK"
}
],
"patientControlNumber": "",
"placeOfServiceCode": "02",
"planParticipationCode": "A",
"releaseInformationCode": "Y",
"serviceFacilityLocation": {
"address": {
"address1": "1234 Other St",
"city": "A City",
"postalCode": "123450000",
"state": "NY"
},
"npi": "1999999984",
"organizationName": "Smith Associates"
},
"serviceLines": [
{
"professionalService": {
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": [
"1"
]
},
"lineItemChargeAmount": "109.20",
"measurementUnit": "UN",
"procedureCode": "90837",
"procedureIdentifier": "HC",
"procedureModifiers": [
"95"
],
"serviceUnitCount": "1"
},
"providerControlNumber": "111222333",
"renderingProvider": {
"firstName": "Jane",
"lastName": "Smith",
"npi": "1999999984",
"providerType": "RenderingProvider",
"taxonomyCode": "111YP2000X"
},
"serviceDate": "20240101"
}
],
"signatureIndicator": "Y"
},
"receiver": {
"organizationName": "Cigna"
},
"submitter": {
"contactInformation": {
"name": "Test Data Health Services, Inc.",
"phoneNumber": "5552223333"
},
"organizationName": "Test Data Health Services, Inc.",
"submitterIdentification": ""
},
"subscriber": {
"address": {
"address1": "2222 Random St",
"city": "A City",
"postalCode": "123450000",
"state": "NY"
},
"dateOfBirth": "20000101",
"firstName": "John",
"gender": "M",
"groupNumber": "3335555",
"lastName": "Anon",
"memberId": "U7777788888",
"paymentResponsibilityLevelCode": "P",
"subscriberGroupName": "Cigna"
},
"tradingPartnerName": "Cigna",
"tradingPartnerServiceId": "6400",
"usageIndicator": "T"
}
```
### Responses
#### 200
ClaimsSubmission 200 response
**Schema:** `ClaimsSubmissionResponseContent`
**Properties:**
- **`claimReference`** (`object`)
- **`controlNumber`** (`string`): An identifier for the transaction.
- **`editResponses`** (`array`): Currently not used.
- Items schema: `EditResponse`
- **`editStatus`** (`string`): This shape is deprecated: Currently not used.
- **`errors`** (`array`): Errors resulting from claim edits. You must review and fix these errors before resubmitting.
- Items schema: `ClaimsError`
- **`failure`** (`object`)
- **`httpStatusCode`** (`object`)
- **`meta`** (`object`)
- **`payer`** (`object`)
- **`status`** (`string`): The status of the claim submission.
- **`tradingPartnerServiceId`** (`string`): An ID for the payer you identified in the original claim. This value may differ from the `tradingPartnerServiceId` you submitted in the original request because it reflects the payer's internal concept of their ID, not necessarily the ID Stedi uses to route requests to this payer.
- **`warnings`** (`array`): A list of warnings. Currently not used.
- Items schema: `ClaimsWarning`
- **`x12`** (`string`): A [277CA claim acknowledgment](https://www.stedi.com/docs/healthcare/claim-responses-overview#277ca-claim-acknowledgment) acceptance or rejection from Stedi in X12 EDI format. It indicates whether the claim has passed Stedi's claim edits.
When the claim fails one or more edits, the 277CA contains `STC` segments with information about each error. These are the same error codes that appear in the `errors` array.
Note that this 277CA only indicates whether Stedi has accepted or rejected the claim submission. You may receive additional 277CA acceptances or rejections as the claim is routed to the payer.
**Example:**
```json
{
"claimReference": {
"correlationId": "01HTCX97F6XS6F2K22D4KD59TK",
"formatVersion": "5010",
"patientControlNumber": "22266555",
"payerId": "6400",
"rhclaimNumber": "01HTCX97F6XS6F2K22D4KD59TK",
"serviceLines": [
{
"lineItemControlNumber": "111222333"
}
],
"timeOfResponse": "2024-04-01T13:23:54.255Z"
},
"controlNumber": "555123",
"httpStatusCode": "200 OK",
"meta": {
"traceId": "a7f7c912-77f7-489d-96fc-c4ab3b5c33fc"
},
"payer": {
"payerId": "6400",
"payerName": "Cigna"
},
"status": "SUCCESS",
"tradingPartnerServiceId": "6400",
"x12": "ISA*00* *00* *ZZ*STEDITEST *ZZ*574183004559 *260213*1951*^*00501*980180479*0*T*>~GS*HN*STEDITEST*574183004559*20260213*195151*1*X*005010X214~ST*277*0001*005010X214~BHT*0085*08*01KHC8YJE8EY6A5HFR00Z5H305*20260213*195151*TH~HL*1**20*1~NM1*AY*2*STEDI INC*****46*117151744~TRN*1*01KHC8YJE8EY6A5HFR00Z5H305~DTP*050*D8*20260213~DTP*009*D8*20260213~HL*2*1*21*1~NM1*41*2*Test Data Health Services, Inc.*****46*123456~TRN*2*01KHC8Y4HNP0GVQ5NSVTPZBC0F~STC*A0>17>AY*20260213*WQ*109.2~QTY*90*1~AMT*YU*109.2~HL*3*2*19*1~NM1*85*2*Therapy Associates*****XX*1234567890~TRN*1*0~REF*TJ*123456789~QTY*QA*1~AMT*YU*109.2~HL*4*3*PT*0~NM1*QC*1*Anon*John****MI*U7777788888~TRN*2*111222333~STC*A1>20*20260213*WQ*109.2~DTP*472*RD8*20240101-20240101~SE*25*0001~GE*1*1~IEA*1*980180479~"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`code`** (`string`): A code describing the type of validation failure.
- **`message`** (`string`) (required): A message describing the causes of the validation failure. There may be more than one.
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 409
ConflictException 409 response
**Schema:** `ConflictExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Unique error code identifying the specific type of error.
- **`message`** (`string`) (required): Human readable error message explaining why the request was rejected.
#### 422
RequestChangedException 422 response
**Schema:** `RequestChangedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Unique error code identifying the specific type of error.
- **`message`** (`string`) (required): Human readable error message explaining why the request was rejected.
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# Create Claim Attachment (275) JSON
Source: https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-create-claim-attachment
This endpoint is in **beta** and is subject to change.
This endpoint returns a pre-signed URL that you can use to upload a claim attachment file to Stedi. You must complete this step before you can submit an 837 claim with an unsolicited 275 claim attachment.
1. Call this endpoint to initiate the file upload process.
2. The endpoint returns a unique identifier for the attachment file (`attachmentId`) and a pre-signed URL (`uploadURL`). Retain the `attachmentId` so you can include it in your JSON claim submission.
You only need to complete this step when submitting claims through Stedi's JSON APIs. If your system already generates X12 EDI, you can send attachments directly through the [Submit Claim Attachment (275) Raw X12](/healthcare/api-reference/post-healthcare-submit-claim-attachment-raw-x12) endpoint instead.
This endpoint only supports [unsolicited attachments](/healthcare/submit-claim-attachments#solicited-vs-unsolicited-attachments).
## API Specification
Generate a pre-signed URL to upload a 275 claim attachment file
**Endpoint:** `POST /claim-attachments/file`
**Base URL:** `https://claims.us.stedi.com/2025-03-07`
### Request Body
**Schema:** `CreateClaimAttachmentFileRequestContent`
**Properties:**
- **`contentType`** (`object`) (required): The MIME type of the attachment file. For example: `image/png` or `application/pdf`.
**Example:**
```json
{
"contentType": "application/pdf"
}
```
### Responses
#### 201
CreateClaimAttachmentFile 201 response
**Schema:** `CreateClaimAttachmentFileResponseContent`
**Properties:**
- **`attachmentId`** (`string`) (required): Unique identifier for this attachment. You will use this ID to associate the attachment file with the claim when you submit it to the payer.
- **`uploadUrl`** (`string`) (required): A pre-signed URL you can use to upload the file with a `PUT` request. The `PUT` request must include a `Content-Type` header that matches the MIME type you specified for the attachment file.
**Example:**
```json
{
"attachmentId": "d3b3e3e3-3e3e-3e3e-3e3e-3e3e3e3e3e3e",
"uploadUrl": "https://s3.amazonaws.com/bucket/key"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Unique error code identifying the specific type of resource not found error.
- **`message`** (`string`) (required): Human readable error message explaining why the resource could not be found.
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Dental Claims (837D) Raw X12
Source: https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-dental-claims-raw-x12
This endpoint is ideal if you have an existing system that generates X12 EDI files and you want to send them through Stedi.
1. Call this endpoint with a payload in [837 X12 EDI format](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-dental-x224a3/01GRYB6G91ZX6R1XAFGBMRTBBW).
2. Stedi validates the EDI and sends the claim to the payer.
3. The endpoint returns a response from Stedi in JSON format containing information about the claim you submitted and whether the submission was successful.
## API Specification
Submit an 837D dental claim in raw X12 EDI format
**Endpoint:** `POST /dental-claims/raw-x12-submission`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Parameters
- **`Idempotency-Key`** (header): A unique string to identify this request to the server. The key can be up to 255 characters. You can safely retry requests with the same idempotency key within 24 hours of making the first request. This prevents you from sending duplicate claims due to network errors or other intermittent failures. [Learn more](https://www.stedi.com/docs/api-reference/index#idempotency-keys).
- Type: `string`
### Request Body
**Schema:** `DentalClaimsRawX12SubmissionRequestContent`
**Properties:**
- **`x12`** (`string`) (required)
**Example:**
```json
{
"x12": "ISA*00* *00* *ZZ*574183004559 *ZZ*STEDITEST *260213*2050*^*00501*000000042*0*T*>~GS*HC*574183004559*STEDITEST*20260213*205048*42*X*005010X224A2~ST*837*0001*005010X224A2~BHT*0019*00*01KHCCA4V6K00NFPX588G859SJ*20260213*2050*CH~NM1*41*2*ABA Inc*****46*1234567~PER*IC*BILLING DEPARTMENT*TE*3131234567~NM1*40*2*United HealthCare Dental*****46*52133~HL*1**20*1~PRV*BI*PXC*106S00000X~NM1*85*2*ABA Inc*****XX*1999999992~N3*ABA Inc 123 Some St~N4*Denver*CO*802383000~REF*EI*123456789~PER*IC*ABA Inc*TE*3134893157~HL*2*1*22*0~SBR*P*18*1234567890******FI~NM1*IL*1*Doe*John****MI*123412345~N3*1234 Some St~N4*Buckeye*AZ*85326~DMG*D8*20180615*F~NM1*PR*2*United HealthCare Dental*****PI*52133~N3*PO Box 7000~N4*Camden*SC*29000~CLM*12345*832***12>B>1*Y*A*Y*Y~DN2*3*E****JP~REF*G1*20231010012345678~HI*ABK>K081~NM1*82*1*Doe*Jane****XX*1999999992~PRV*PE*PXC*106S00000X~LX*1~SV3*AD>D7140*832**1>2*I*2*****1~TOO*JP*3*M>O~DTP*472*D8*20230428~REF*6R*a0UDo000000dd2dMAA~NM1*82*1*Doe*Jane****XX*1999999992~PRV*PE*PXC*122300000X~SE*35*0001~GE*1*42~IEA*1*000000042~"
}
```
### Responses
#### 200
DentalClaimsRawX12Submission 200 response
**Schema:** `DentalClaimsRawX12SubmissionResponseContent`
**Properties:**
- **`claimReference`** (`object`)
- **`controlNumber`** (`string`): An identifier for the transaction.
- **`editResponses`** (`array`): Currently not used.
- Items schema: `EditResponse`
- **`editStatus`** (`string`): This shape is deprecated: Currently not used.
- **`errors`** (`array`): Errors resulting from claim edits. You must review and fix these errors before resubmitting.
- Items schema: `ClaimsError`
- **`failure`** (`object`)
- **`httpStatusCode`** (`object`)
- **`meta`** (`object`)
- **`payer`** (`object`)
- **`status`** (`string`): The status of the claim submission.
- **`tradingPartnerServiceId`** (`string`): An ID for the payer you identified in the original claim. This value may differ from the `tradingPartnerServiceId` you submitted in the original request because it reflects the payer's internal concept of their ID, not necessarily the ID Stedi uses to route requests to this payer.
- **`warnings`** (`array`): A list of warnings. Currently not used.
- Items schema: `ClaimsWarning`
- **`x12`** (`string`): A [277CA claim acknowledgment](https://www.stedi.com/docs/healthcare/claim-responses-overview#277ca-claim-acknowledgment) acceptance or rejection from Stedi in X12 EDI format. It indicates whether the claim has passed Stedi's claim edits.
When the claim fails one or more edits, the 277CA contains `STC` segments with information about each error. These are the same error codes that appear in the `errors` array.
Note that this 277CA only indicates whether Stedi has accepted or rejected the claim submission. You may receive additional 277CA acceptances or rejections as the claim is routed to the payer.
**Example:**
```json
{
"claimReference": {
"correlationId": "01J1M588QT2TAV2N093GNJ998T",
"formatVersion": "5010",
"patientControlNumber": "22266555",
"payerId": "60054",
"rhclaimNumber": "01J1M588QT2TAV2N093GNJ998T",
"serviceLines": [
{
"lineItemControlNumber": "111222333"
}
],
"timeOfResponse": "2024-07-10T22:05:32.203Z"
},
"controlNumber": "000000001",
"httpStatusCode": "200 OK",
"meta": {
"traceId": "b727b8e7-1f00-4011-bc6e-e41444d406d8"
},
"payer": {
"payerId": "60054",
"payerName": "Cigna"
},
"status": "SUCCESS",
"tradingPartnerServiceId": "60054",
"x12": "ISA*00* *00* *ZZ*STEDITEST *ZZ*574183004559 *260213*1956*^*00501*343800641*0*T*>~GS*HN*STEDITEST*574183004559*20260213*195613*1*X*005010X214~ST*277*0001*005010X214~BHT*0085*08*01KHC96JC6ZRRJ3PB88T7JR7S8*20260213*195613*TH~HL*1**20*1~NM1*AY*2*STEDI INC*****46*117151744~TRN*1*01KHC96JC6ZRRJ3PB88T7JR7S8~DTP*050*D8*20260213~DTP*009*D8*20260213~HL*2*1*21*1~NM1*41*2*ABA Inc*****46*123456789~TRN*2*01KHC96GBNYA14YRBRJGFR13P7~STC*A0>17>AY*20260213*WQ*832.0~QTY*90*1~AMT*YU*832.0~HL*3*2*19*1~NM1*85*2*ABA Inc*****XX*1999999992~TRN*1*0~REF*TJ*123456789~QTY*QA*1~AMT*YU*832.0~HL*4*3*PT*0~NM1*QC*1*Doe*John****MI*123412345~TRN*2*12345~STC*A1>20*20260213*WQ*832.0~DTP*472*RD8*20230428-20230428~SE*25*0001~GE*1*1~IEA*1*343800641~"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`code`** (`string`): A code describing the type of validation failure.
- **`message`** (`string`) (required): A message describing the causes of the validation failure. There may be more than one.
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 409
ConflictException 409 response
**Schema:** `ConflictExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Unique error code identifying the specific type of error.
- **`message`** (`string`) (required): Human readable error message explaining why the request was rejected.
#### 422
RequestChangedException 422 response
**Schema:** `RequestChangedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Unique error code identifying the specific type of error.
- **`message`** (`string`) (required): Human readable error message explaining why the request was rejected.
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# Dental Claims (837D) JSON
Source: https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-dental-claims
This endpoint sends 837D dental claims to payers.
1. Call this endpoint with a JSON payload.
2. Stedi translates your request to the X12 837 EDI format and sends it to the payer.
3. The endpoint returns a response from Stedi in JSON format containing information about the claim you submitted and whether the submission was successful.
## API Specification
Submit an 837D dental claim in JSON format
**Endpoint:** `POST /dental-claims/submission`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Parameters
- **`Idempotency-Key`** (header): A unique string to identify this request to the server. The key can be up to 255 characters. You can safely retry requests with the same idempotency key within 24 hours of making the first request. This prevents you from sending duplicate claims due to network errors or other intermittent failures. [Learn more](https://www.stedi.com/docs/api-reference/index#idempotency-keys).
- Type: `string`
### Request Body
**Schema:** `DentalClaimsSubmissionRequestContent`
**Properties:**
- **`assistantSurgeon`** (`object`)
- **`billing`** (`object`) (required)
- **`claimIdentifier`** (`object`)
- **`claimInformation`** (`object`) (required): Information about the healthcare claim.
Note that the objects and properties marked as required are required for all claims, while others are conditionally required, depending on type of claim and claim circumstances. For example, you must always provide the `placeOfServiceCode` property, but you only need to provide the `otherSubscriberInformation` object in coordination of benefits scenarios. When you include a conditionally required object, you must provide all of its required properties.
- **`dependent`** (`object`)
- **`payToAddress`** (`object`): Use when the address for payment is different than that of the billing provider for this claim.
This is also where you can provide the billing provider's mailing address when it's a PO Box, lockbox, or other non-physical address. The `billing.address` object must always contain a physical practice location where care is delivered.
- **`payToPlan`** (`object`)
- **`payerAddress`** (`object`): The payer's address. Some payers use this for internal routing. Only provide this address if the payer explicitly requires it.
- **`receiver`** (`object`) (required)
- **`referring`** (`object`)
- **`rendering`** (`object`)
- **`submitter`** (`object`) (required): The entity submitting the healthcare claim. This can be either an individual or an organization, such as a doctor, hospital, or insurance company. You must submit at least `organizationName` or `lastName` properties and the `contactInformation` object. If you don't supply the `submitterIdentification` property, Stedi uses the value from `billing.npi` in the request.
- **`subscriber`** (`object`) (required)
- **`supervising`** (`object`)
- **`tradingPartnerName`** (`string`): This is the payer's business name, like Cigna or Aetna.
- **`tradingPartnerSecondaryIdentifiers`** (`object`): Secondary identifiers for the payer. You can include up to three properties in this object.
- **`tradingPartnerServiceId`** (`string`) (required): This is the Payer ID. Visit the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list. You can send requests using the Primary Payer ID, the Stedi Payer ID, or any alias listed in the payer record.
- **`usageIndicator`** (`string`): Whether you want to send a test or production claim. This property also allows you to filter claims in the Stedi portal by production or test data. By default, this property is set to `P` for production data. Use `T` to designate a claim as test data.
**Example:**
```json
{
"billing": {
"address": {
"address1": "ABA Inc 123 Some St",
"city": "Denver",
"postalCode": "802383000",
"state": "CO"
},
"contactInformation": {
"name": "ABA Inc",
"phoneNumber": "3134893157"
},
"employerId": "123456789",
"npi": "1999999992",
"organizationName": "ABA Inc",
"providerType": "BillingProvider",
"taxonomyCode": "106S00000X"
},
"claimInformation": {
"benefitsAssignmentCertificationIndicator": "Y",
"claimChargeAmount": "832.00",
"claimFilingCode": "FI",
"claimFrequencyCode": "1",
"claimSupplementalInformation": {
"priorAuthorizationNumber": "20231010012345678"
},
"healthCareCodeInformation": [
{
"diagnosisCode": "K08101",
"diagnosisTypeCode": "ABK"
}
],
"patientControlNumber": "",
"placeOfServiceCode": "12",
"planParticipationCode": "A",
"releaseInformationCode": "Y",
"serviceFacilityLocation": {
"address": {
"address1": "ABA Inc 123 Some St",
"city": "Denver",
"postalCode": "802383100",
"state": "CO"
},
"npi": "1999999992",
"organizationName": "ABA Inc",
"phoneNumber": "3131234567"
},
"serviceLines": [
{
"dentalService": {
"compositeDiagnosisCodePointers": {
"diagnosisCodePointers": [
"1"
]
},
"lineItemChargeAmount": "832.00",
"oralCavityDesignation": [
"1",
"2"
],
"placeOfServiceCode": "12",
"procedureCode": "D7140",
"procedureCount": 2,
"prosthesisCrownOrInlayCode": "I"
},
"providerControlNumber": "a0UDo000000dd2dMAA",
"renderingProvider": {
"firstName": "Jane",
"lastName": "Doe",
"npi": "1999999992",
"taxonomyCode": "122300000X"
},
"serviceDate": "20230428",
"teethInformation": [
{
"toothCode": "3",
"toothSurfaceCodes": [
"M",
"O"
]
}
]
}
],
"signatureIndicator": "Y",
"toothStatus": [
{
"toothNumber": "3",
"toothStatusCode": "E"
}
]
},
"payerAddress": {
"address1": "PO Box 7000",
"city": "Camden",
"postalCode": "29000",
"state": "SC"
},
"receiver": {
"organizationName": "United HealthCare Dental"
},
"rendering": {
"firstName": "Jane",
"lastName": "Doe",
"npi": "1999999992",
"providerType": "RenderingProvider",
"taxonomyCode": "106S00000X"
},
"submitter": {
"contactInformation": {
"name": "BILLING DEPARTMENT",
"phoneNumber": "3131234567"
},
"organizationName": "ABA Inc",
"submitterIdentification": "~GS*HN*STEDITEST*574183004559*20260213*195613*1*X*005010X214~ST*277*0001*005010X214~BHT*0085*08*01KHC96JC6ZRRJ3PB88T7JR7S8*20260213*195613*TH~HL*1**20*1~NM1*AY*2*STEDI INC*****46*117151744~TRN*1*01KHC96JC6ZRRJ3PB88T7JR7S8~DTP*050*D8*20260213~DTP*009*D8*20260213~HL*2*1*21*1~NM1*41*2*ABA Inc*****46*123456789~TRN*2*01KHC96GBNYA14YRBRJGFR13P7~STC*A0>17>AY*20260213*WQ*832.0~QTY*90*1~AMT*YU*832.0~HL*3*2*19*1~NM1*85*2*ABA Inc*****XX*1999999992~TRN*1*0~REF*TJ*123456789~QTY*QA*1~AMT*YU*832.0~HL*4*3*PT*0~NM1*QC*1*Doe*John****MI*123412345~TRN*2*12345~STC*A1>20*20260213*WQ*832.0~DTP*472*RD8*20230428-20230428~SE*25*0001~GE*1*1~IEA*1*343800641~"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`code`** (`string`): A code describing the type of validation failure.
- **`message`** (`string`) (required): A message describing the causes of the validation failure. There may be more than one.
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 409
ConflictException 409 response
**Schema:** `ConflictExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Unique error code identifying the specific type of error.
- **`message`** (`string`) (required): Human readable error message explaining why the request was rejected.
#### 422
RequestChangedException 422 response
**Schema:** `RequestChangedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Unique error code identifying the specific type of error.
- **`message`** (`string`) (required): Human readable error message explaining why the request was rejected.
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# Real-Time Eligibility Check (270/271) Raw X12
Source: https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-eligibility-raw-x12
[Real-time eligibility checks](/healthcare/send-eligibility-checks) are ideal for in-person patient visits, telehealth appointments, and other scenarios where you need immediate information about a patient's coverage. This endpoint is ideal if you have an existing system that generates X12 EDI files and you want to send them through Stedi.
1. Call this endpoint with payload in [270 X12 EDI format](https://portal.stedi.com/app/guides/view/hipaa/health-care-eligibility-benefit-inquiry-x279a1/01GRYB6GTDJ4MEP5Z16CGMQWT6). Note that the request must include `BHT03` (Submitter Transaction Identifier) and the Payer ID in `Loop 2100A NM109`. We recommend reviewing the requirements for a [basic eligibility request](/healthcare/send-eligibility-checks#body---x12-edi).
2. Stedi validates the EDI and sends the eligibility check to the payer.
3. The endpoint returns a synchronous response from the payer in both JSON and raw X12 EDI format. The response contains the patient's eligibility and benefits information. Note that our documentation lists all enums officially allowed in the eligibility response. Some payers return non-compliant values, which Stedi passes through as is.
## API Specification
Submit a real-time 270/271 eligibility check in raw X12 EDI format
**Endpoint:** `POST /change/medicalnetwork/eligibility/v3/raw-x12`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Parameters
- **`X-Forwarded-For`** (header):
- Type: `string`
### Request Body
**Schema:** `EligibilityRawX12CheckRequestContent`
**Properties:**
- **`eligibilitySearchId`** (`string`): An identifier that allows Stedi to group eligibility checks for the same patient into a unified record in the Stedi portal called an [eligibility search](https://www.stedi.com/docs/healthcare/eligibility-searches-view).
This property is for use by Stedi tools only, such as Stedi's MCP server.
- **`externalPatientId`** (`string`): A unique identifier for the patient that Stedi uses to identify and correlate historical eligibility checks for the same individual. We recommend including this value in all requests.
- **`x12`** (`string`) (required)
**Example:**
```json
{
"x12": "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~"
}
```
### Responses
#### 200
EligibilityRawX12Check 200 response
**Schema:** `EligibilityRawX12CheckResponseContent`
**Properties:**
- **`benefitsInformation`** (`array`): Information about the patient's healthcare benefits, such as coverage level (individual vs. family), coverage type (deductibles, co-pays, etc.), out of pocket maximums, and more.
Payers typically return at least the following properties: `code`, `coverageLevelCode`, `serviceTypeCodes`, and either `benefitAmount` or `benefitPercent`. However, the exact properties returned in this object are up to the payer's discretion.
The payer may send benefits information for service type codes (STCs) you didn't request - this is expected. The STC you send in the request tells the payer the types of benefits information you want, but they aren't required to respond with exactly the same STC(s) in the response. Receiving different STCs than you requested can also mean that the payer is ignoring the STC you sent, which is why we recommend [testing payers](https://www.stedi.com/docs/healthcare/eligibility-stc-procedure-codes#test-payer-stc-support) to determine their support for specific STCs.
Visit [Determine patient benefits](https://www.stedi.com/docs/healthcare/eligibility-active-coverage-benefits) for more information about benefit types, details about how to interpret the `benefitsInformation` array, and additional examples.
- Items schema: `BenefitsInformation`
- **`controlNumber`** (`string`): An identifier for the payer's response.
- **`dependents`** (`array`): Information about the patient when they are a dependent. When the patient is a dependent, this array will contain a single object with the patient's information. When the patient is a subscriber, or considered to be a subscriber because they have a unique member ID, their information is returned in the `subscriber` object, and this array will be empty.
When present, this object will always include the dependent's name for identification, but many payers will also return the date of birth and other identifying information.
- Items schema: `ResponseDependent`
- **`eligibilitySearchId`** (`string`): An identifier that allows Stedi to group eligibility checks for the same patient into a unified record in the Stedi portal called an [eligibility search](https://www.stedi.com/docs/healthcare/eligibility-searches-view).
This property is for use by Stedi tools only, such as Stedi's MCP server.
- **`errors`** (`array`): When a payer rejects your eligibility check, the response contains one or more [`AAA` errors](https://www.stedi.com/docs/healthcare/eligibility-troubleshooting#payer-aaa-errors) that specify the reasons for the rejection and any recommended follow-up actions.
Any errors that occur at the `payer`, `provider`, `subscriber`, or `dependents` levels are also included in this array, allowing you to review all errors in a central location. If there are no `AAA` errors, this array will be empty.
- Items schema: `EligibilityCheckError`
- **`id`** (`string`): A globally unique identifier for this eligibility check across all Stedi accounts. It's formatted as `ec_`. For example: `ec_550e8400-e29b-41d4-a716-446655440000`. You can use this ID to track this eligibility check and to construct deep links to eligibility checks in the Stedi portal.
- **`implementationTransactionSetSyntaxError`** (`string`): The implementation transaction set error code provided in `IK502` of the 999 transaction.
- **`meta`** (`object`)
- **`payer`** (`object`)
- **`planDateInformation`** (`object`)
- **`planInformation`** (`object`)
- **`planStatus`** (`array`): Please use `benefitsInformation` instead.
- Items schema: `PlanStatus`
- **`provider`** (`object`)
- **`reassociationKey`** (`string`)
- **`status`** (`string`): Errors Stedi encountered when generating or sending the final X12 EDI transaction to the payer. These can include validation errors and payer unavailable errors that prevent delivery.
- **`subscriber`** (`object`)
- **`subscriberTraceNumbers`** (`array`): A unique identifier for the eligibility request. It's used to trace the transaction. Stedi always generates a trace number for internal tracking, and the payer may generate one as well. You can also optionally [supply your own trace number](https://www.stedi.com/docs/healthcare/send-eligibility-checks#trn) in a `TRN` segment.
Stedi returns its internal trace number in this array as well as the trace numbers from you and the payer (if provided).
- Items schema: `SubscriberTraceNumber`
- **`tradingPartnerServiceId`** (`string`): An ID for the payer you identified in the original eligibility check request. This value may differ from the `tradingPartnerServiceId` you submitted in the original request because it reflects the payer's internal concept of their ID, not necessarily the ID Stedi uses to route requests to this payer.
- **`transactionSetAcknowledgement`** (`string`): The transaction set acknowledgment code provided in in the [X12 EDI 999 response](https://portal.stedi.com/app/guides/view/hipaa/implementation-acknowledgment-x231/01HRF41ES1DVGCA6X1EHSRPFXZ#properties.heading.properties.transaction_set_response_header_AK2_loop.items.properties.transaction_set_response_trailer_IK5).
- **`warnings`** (`array`): Warnings indicate non-fatal issues with your eligibility check or a non-standard response from the payer.
- Items schema: `Warning`
- **`x12`** (`string`): Typically this property contains the raw X12 EDI [271 Eligibility Benefit Response](https://portal.stedi.com/app/guides/view/hipaa/health-care-eligibility-benefit-response-x279a1/01GS66YHZPB37ABF34DBPSR213) from the payer.
In some circumstances, this property may contain a [999 Implementation Acknowledgment](https://portal.stedi.com/app/guides/view/hipaa/implementation-acknowledgment-x231a1/01HMRQV0N8SPHG58M4ZG1CRHH0) instead of a 271. A 999 indicates validation errors in the X12 EDI transaction, such as improper formatting or missing or invalid values.
If the 999 is returned in this property, many of the other response properties will be empty, as they are mapped to information in the 271.
**Example:**
```json
{
"benefitsInformation": [
{
"additionalInformation": [
{
"description": "Complete Care Management"
}
],
"code": "1",
"name": "Active Coverage",
"planCoverage": "Open Access Plus",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "6000",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"benefitAmount": "500",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "3000",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"benefitAmount": "250",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "15000",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"additionalInformation": [
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "30000",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitPercent": "0.1",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
]
},
{
"benefitAmount": "7500",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"additionalInformation": [
{
"description": "Deductible does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "15000",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Co-Insurance",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Not Applicable",
"inPlanNetworkIndicatorCode": "W",
"name": "Active Coverage",
"serviceTypeCodes": [
"A7",
"BC",
"A8",
"A4",
"A5",
"A6",
"7",
"4",
"BB",
"22"
],
"serviceTypes": [
"Psychiatric - Inpatient",
"Day Care (Psychiatric)",
"Psychiatric - Outpatient",
"Psychiatric",
"Psychiatric - Room and Board",
"Psychotherapy",
"Anesthesia",
"Diagnostic X-Ray",
"Partial Hospitalization (Psychiatric)",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"BC",
"A4",
"A6",
"4",
"22"
],
"serviceTypes": [
"Day Care (Psychiatric)",
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"A8"
],
"serviceTypes": [
"Psychiatric - Outpatient"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"A4",
"A6",
"4",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
]
},
{
"authOrCertIndicator": "N",
"benefitAmount": "20",
"code": "B",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"A4",
"A6",
"4",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Included For Specific Services"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "20",
"code": "B",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Included For Specific Services"
}
],
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"A4",
"A6",
"4",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "20",
"code": "B",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "20",
"code": "B",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "Y",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"7"
],
"serviceTypes": [
"Anesthesia"
]
},
{
"authOrCertIndicator": "Y",
"code": "CB",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Coverage Basis",
"serviceTypeCodes": [
"7",
"BB"
],
"serviceTypes": [
"Anesthesia",
"Partial Hospitalization (Psychiatric)"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "Y",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"7"
],
"serviceTypes": [
"Anesthesia"
]
},
{
"authOrCertIndicator": "Y",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"7"
],
"serviceTypes": [
"Anesthesia"
]
},
{
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"4"
],
"serviceTypes": [
"Diagnostic X-Ray"
]
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"4"
],
"serviceTypes": [
"Diagnostic X-Ray"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "Y",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"BB"
],
"serviceTypes": [
"Partial Hospitalization (Psychiatric)"
]
},
{
"additionalInformation": [
{
"description": " Provider is out of network based on NPI ID provided in request."
}
],
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": [
"MH"
],
"serviceTypes": [
"Mental Health"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "5760",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"benefitAmount": "500",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "2760",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"benefitAmount": "250",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "15000",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"additionalInformation": [
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "30000",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "7500",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"additionalInformation": [
{
"description": "Deductible does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "15000",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
}
],
"controlNumber": "1001",
"eligibilitySearchId": "01922a35-a177-7171-b868-cd4974dd54df",
"errors": [],
"id": "ec_650e8400-e29b-41d4-a716-446655440001",
"meta": {
"applicationMode": "production",
"outboundTraceId": "01J2VZA127GH93JT74HJU",
"senderId": "STEDI",
"submitterId": "117151744",
"traceId": "01J2VZA127GH93JT74HJU"
},
"payer": {
"contactInformation": {
"contacts": [
{
"communicationMode": "Telephone",
"communicationNumber": "1234567890"
},
{
"communicationMode": "Uniform Resource Locator (URL)",
"communicationNumber": "website.company.com"
}
]
},
"entityIdentifier": "Payer",
"entityType": "Non-Person Entity",
"federalTaxpayersIdNumber": "123412345",
"name": "ABCDE"
},
"planDateInformation": {
"eligibilityBegin": "20240102",
"planBegin": "20240101",
"planEnd": "20241231"
},
"planInformation": {
"groupDescription": "ABCDE",
"groupNumber": "12341234",
"priorIdNumber": "1234567890"
},
"planStatus": [
{
"planDetails": "Open Access Plus",
"serviceTypeCodes": [
"30"
],
"status": "Active Coverage",
"statusCode": "1"
},
{
"serviceTypeCodes": [
"A7",
"BC",
"A8",
"A4",
"A5",
"A6",
"7",
"4",
"BB",
"22"
],
"status": "Active Coverage",
"statusCode": "1"
},
{
"serviceTypeCodes": [
"MH"
],
"status": "Active Coverage",
"statusCode": "1"
}
],
"provider": {
"entityIdentifier": "Provider",
"entityType": "Non-Person Entity",
"npi": "1999999984",
"providerName": "ACME HEALTH SERVICES"
},
"reassociationKey": "123456789",
"subscriber": {
"address": {
"address1": "1234 FIRST ST",
"city": "NEW YORK",
"postalCode": "123451111",
"state": "WV"
},
"dateOfBirth": "19000101",
"entityIdentifier": "Insured or Subscriber",
"entityType": "Person",
"firstName": "JANE",
"gender": "F",
"groupNumber": "123456789",
"lastName": "DOE",
"memberId": "123456789",
"middleName": "A"
},
"tradingPartnerServiceId": "123456789",
"x12": "ISA*00* *00* *ZZ*STEDI *01*117151744 *111111*1234*^*00501*123456782*0*P*>~GS*HB*STEDI*117151744*20240326*111000*1*X*005010X279A1~ST*271*1001*005010X279A1~BHT*0022*11*01J2VZA127GH93JT74HJU*20240326*1514~HL*1**20*1~NM1*PR*2*ABCDE*****FI*111000123~PER*IC**TE*123456789*UR*website.company.com~HL*2*1*21*1~NM1*1P*2*ACME HEALTH SERVICES*****XX*1999999984~HL*3*2*22*0~NM1*IL*1*DOE*JANE*A***MI*123456789~REF*6P*123456789*ABCDE~REF*Q4*123456789~N3*1234 FIRST ST~N4*NEW YORK*WV*123451111~DMG*D8*19000101*F~INS*Y*18*001*25~DTP*356*D8*20220102~DTP*346*D8*20240101~DTP*347*D8*20241231~EB*1**30**Open Access Plus~MSG*Complete Care Management~EB*G*FAM*30***23*6000.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*FAM*30***23*500.00*****Y~MSG*Includes services provided by Client Specific Network~EB*G*IND*30***23*3000.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***23*250.00*****Y~MSG*Includes services provided by Client Specific Network~EB*C*FAM*30***23*15000.00*****N~EB*G*FAM*30***23*30000.00*****N~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*A*IND*30*****.10****Y~EB*C*IND*30***23*7500.00*****N~EB*G*IND*30***23*15000.00*****N~MSG*Deductible does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~EB*A*IND*30*****.50****N~EB*1**A7^BC^A8^A4^A5^A6^7^4^BB^22*********W~EB*C*IND*BC^A4^A6^4^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*22~EB*C*IND*A8****0.00****N*Y~MSG*Includes services provided by Client Specific Network~EB*C*IND*A4^A6^4^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*11~EB*C*IND*A4^A6^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*02~EB*B*IND*A4^A6^22***27*20.00****N*Y~III*ZZ*11~EB*A*IND*A4^A6^4^22*****.00***N*Y~III*ZZ*11~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Included For Specific Services~III*ZZ*02~EB*A*IND*A4^A6^22*****.00***N*Y~MSG*Included For Specific Services~III*ZZ*02~EB*A*IND*A4^A6^22*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*02~EB*A*IND*A4^A6^4^22*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*02~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*A*IND*7*****.00***Y*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*CB**7^BB********Y*Y~EB*C*IND*7****0.00****Y*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*11~EB*A*IND*7*****.00***Y*Y~III*ZZ*11~EB*A*IND*4*****.00***N*Y~III*ZZ*22~EB*A*IND*4*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*22~EB*C*IND*BB****0.00****Y*Y~MSG*Includes services provided by Client Specific Network~EB*1**MH~MSG* Provider is out of network based on NPI ID provided in request.~EB*G*FAM*30***29*5760.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*FAM*30***29*500.00*****Y~MSG*Includes services provided by Client Specific Network~EB*G*IND*30***29*2760.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***29*250.00*****Y~MSG*Includes services provided by Client Specific Network~EB*C*FAM*30***29*15000.00*****N~EB*G*FAM*30***29*30000.00*****N~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***29*7500.00*****N~EB*G*IND*30***29*15000.00*****N~MSG*Deductible does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~SE*119*1001~GE*1*1~IEA*1*123456782~"
}
```
#### 400
EligibilityRawX12Check400Error 400 response
**Schema:** `EligibilityRawX12Check400ErrorResponseContent`
**Example:**
```json
{
"eligibilitySearchId": "0198afb0-0e35-7ed3-bc66-6c387c60f4bb",
"errors": [
{
"code": "71",
"description": "Parse errors: Loop has fewer than the minimum of 1 items",
"followupAction": "Please Correct and Resubmit",
"location": "subscriber_level_HL_loop",
"possibleResolutions": "The X12 request could not be parsed. Verify the request is a valid 270 transaction."
}
],
"id": "ec_650e8400-e29b-41d4-a716-446655440002",
"status": "ERROR"
}
```
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# Real-Time Eligibility Check (270/271) SOAP
Source: https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-eligibility-soap
Submit real-time eligibility checks over SOAP using the CAQH CORE vC2.2.0 XML Schema
[Real-time eligibility checks](/healthcare/send-eligibility-checks) are ideal for in-person patient visits, telehealth appointments, and other scenarios where you need immediate information about a patient’s coverage. This endpoint is ideal when you must meet CAQH Core Connectivity Safe Harbor requirements or integrate with systems requiring CAQH CORE-compliant SOAP connectivity.
1. Call this endpoint with a request in XML format. The XML must conform to the [CAQH CORE vC2.2.0 XML Schema](https://www.caqh.org/core/connectivity). The `Payload` element must contain a valid eligibility check in [270 X12 EDI format](https://portal.stedi.com/app/guides/view/hipaa/health-care-eligibility-benefit-inquiry-x279a1/01GRYB6GTDJ4MEP5Z16CGMQWT6). We recommend reviewing the requirements for a [basic eligibility request](/healthcare/send-eligibility-checks#body---x12-edi).
2. Stedi validates your eligibility check and sends it to the payer.
3. The endpoint returns a synchronous SOAP response in [XML format](#response). It contains the full [271 X12 EDI](https://portal.stedi.com/app/guides/view/hipaa/health-care-eligibility-benefit-response-x279a1/01GS66YHZPB37ABF34DBPSR213) response from the payer containing the patient's eligibility and benefits information.
## Headers [#headers]
| Name | Required | Description |
| ----------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Content-Type` | Yes | Set to `application/soap+xml`. |
| `X-Forwarded-For` | No | **(CMS requests only):** Starting November 8, 2025, the Centers for Medicare & Medicaid Services (CMS) requires submitters to include network IP addresses from an eligibility request's point of origin through receipt by the HETS system.- To comply with this requirement, you may need to include the `X-Forwarded-For` header in requests to CMS.
- When present, this header should contain a comma-separated list of upstream IP addresses, starting with the originating system and continuing through every intermediary. You can exclude your IP address from the list.
- Stedi blocks eligibility requests to CMS when any IP address in the chain – the originating IP address or any in the `X-Forwarded-For` header – is located outside the United States.
- Visit [CMS traceability requirements](/healthcare/send-eligibility-checks#cms-traceability-requirements) for details and examples.
|
## Request [#request]
The request payload must be XML that conforms to the [CAQH CORE vC2.2.0 XML Schema](https://www.caqh.org/core/connectivity). It consists of three main parts: the envelope, the header, and the body.
```xml
...
...
```
### Envelope [#envelope]
The SOAP `Envelope` element wraps both the header and body. It defines the message structure according to the SOAP specification.
```xml
```
`Envelope` must declare the following namespaces:
{/* prettier-ignore-start */}
| Namespace declaration | Required | Description |
| --------------------- | -------- | ----------------------------------------------------------------------------------------------------------------- |
| `xmlns:soapenv` | Yes | Declares the XML namespace for the SOAP envelope. Must be set to `http://www.w3.org/2003/05/soap-envelope`. |
| `xmlns:cor` | Yes | Declares the XML namespace for CAQH CORE rules. Must be set to `http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd`. |
{/* prettier-ignore-end */}
### Header [#header]
The `Header` element specifies the WS-Security namespace (`wsse`) and contains the required credentials for authentication.
```xml
STEDI-ACCOUNT-ID
STEDI-API-KEY
```
`Header` must include the following elements:
{/* prettier-ignore-start */}
| Element | Required | Description |
| --------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `wsse:Security` | Yes | The parent container for the security token. It includes: - The `soapenv:mustUnderstand` attribute, set to `true`.
- The `xmlns:wsse` namespace declaration, set to `http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd`
- The `xmlns:wsu` namespace declaration, set to `http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd`
|
| `wsse:Username` | Yes | Set this to your **Stedi Account ID**. You can find your 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`. |
| `wsse:Password` | Yes | Set this to your **API Key**. You can create and manage API keys from the [API Keys page](https://portal.stedi.com/app/settings/api-keys) in the Stedi portal. |
{/* prettier-ignore-end */}
### Body [#body]
The `Body` element contains the request details, and it must conform to the [CAQH CORE XML Schema vC2.2.0](https://www.caqh.org/core/connectivity).
```xml
X12_270_Request_005010X279A1
RealTime
YOUR-PAYLOAD-ID
2007-08-30T10:20:34.000Z
SENDER-ID
RECEIVER-ID
2.2.0
~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~]]>
```
`Body` must include the following elements:
{/* prettier-ignore-start */}
| Element | Required | Description |
| ----------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `PayloadType` | Yes | The type of transaction. Must be set to `X12_270_Request_005010X279A1`. |
| `ProcessingMode` | Yes | The processing mode. Must be set to `RealTime`. |
| `PayloadID` | Yes | A unique identifier for the request. Must be a valid UUID. |
| `TimeStamp` | Yes | UTC time in ISO 8601 format, such as `2024-07-28T12:00:00Z`. |
| `SenderID` | Yes | An identifier for the transaction sender.- Can be up to 50 characters.
- Set this to the value you plan to use in the eligibility check's `ISA06` (Interchange Sender ID) element.
|
| `ReceiverID` | Yes | An identifier for the transaction receiver. - Can be up to 50 characters.
- Set this to the value you plan to use in the eligibility check's `ISA08` (Interchange Receiver ID) element.
|
| `CORERuleVersion` | Yes | The CAQH CORE rule version. Must be set to `2.2.0`. |
| `Payload` | Yes | The X12 EDI 270 eligibility check wrapped in ``.- Must conform to [270 X12 EDI format](https://portal.stedi.com/app/guides/view/hipaa/health-care-eligibility-benefit-inquiry-x279a1/01GRYB6GTDJ4MEP5Z16CGMQWT6).
- We recommend reviewing the requirements for a [basic eligibility request](/healthcare/send-eligibility-checks#body---x12-edi).
|
{/* prettier-ignore-end */}
## Response [#response]
The HTTP response must include the following additional headers:
| Header | Description | Example |
| ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------- |
| `stedi-id` | A Stedi-assigned unique identifier for the eligibility check, formatted as `ec_`. You can use this ID to track the eligibility check and deep link to its results in the Stedi portal. | `ec_f81d4fae-7dec-11d0-a765-00a0c91e6b12` |
| `stedi-eligibility-search-id` | A Stedi-assigned identifier that allows Stedi to group eligibility checks for the same patient into a unified record in the Stedi portal called an [eligibility search](/healthcare/eligibility-searches-view). | `01997873-bebb-7b33-81ef-f408866dfb2cb` |
The response body is a SOAP message, and its structure is similar to the request. The `Payload` element typically contains the payer's X12 EDI 271 response. However, if you send a request that fails X12 EDI validation, it will contain a 999 Implementation Acknowledgment indicating the errors.
```xml
X12_271_Response_005010X279A1
RealTime
f81d4fae-7dec-11d0-a765-00a0c91e6b12
2025-08-06T22:23:50Z
RECEIVER_ID
STEDI
2.2.0
~GS*HB*STEDI*117151744*20240326*111000*1*X*005010X279A1~ST*271*1001*005010X279A1~BHT*0022*11*01J2VZA127GH93JT74HJU*20240326*1514~HL*1**20*1~NM1*PR*2*ABCDE*****FI*111000123~PER*IC**TE*123456789*UR*website.company.com~HL*2*1*21*1~NM1*1P*2*ACME HEALTH SERVICES*****XX*1999999984~HL*3*2*22*0~NM1*IL*1*DOE*JANE*A***MI*123456789~REF*6P*123456789*ABCDE~REF*Q4*123456789~N3*1234 FIRST ST~N4*NEW YORK*WV*123451111~DMG*D8*19000101*F~INS*Y*18*001*25~DTP*356*D8*20220102~DTP*346*D8*20240101~DTP*347*D8*20241231~EB*1**30**Open Access Plus~MSG*Complete Care Management~EB*G*FAM*30***23*6000.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*FAM*30***23*500.00*****Y~MSG*Includes services provided by Client Specific Network~EB*G*IND*30***23*3000.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***23*250.00*****Y~MSG*Includes services provided by Client Specific Network~EB*C*FAM*30***23*15000.00*****N~EB*G*FAM*30***23*30000.00*****N~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*A*IND*30*****.10****Y~EB*C*IND*30***23*7500.00*****N~EB*G*IND*30***23*15000.00*****N~MSG*Deductible does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~EB*A*IND*30*****.50****N~EB*1**A7^BC^A8^A4^A5^A6^7^4^BB^22*********W~EB*C*IND*BC^A4^A6^4^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*22~EB*C*IND*A8****0.00****N*Y~MSG*Includes services provided by Client Specific Network~EB*C*IND*A4^A6^4^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*11~EB*C*IND*A4^A6^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*02~EB*B*IND*A4^A6^22***27*20.00****N*Y~III*ZZ*11~EB*A*IND*A4^A6^4^22*****.00***N*Y~III*ZZ*11~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Included For Specific Services~III*ZZ*02~EB*A*IND*A4^A6^22*****.00***N*Y~MSG*Included For Specific Services~III*ZZ*02~EB*A*IND*A4^A6^22*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*02~EB*A*IND*A4^A6^4^22*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*02~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*A*IND*7*****.00***Y*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*CB**7^BB********Y*Y~EB*C*IND*7****0.00****Y*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*11~EB*A*IND*7*****.00***Y*Y~III*ZZ*11~EB*A*IND*4*****.00***N*Y~III*ZZ*22~EB*A*IND*4*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*22~EB*C*IND*BB****0.00****Y*Y~MSG*Includes services provided by Client Specific Network~EB*1**MH~MSG* Provider is out of network based on NPI ID provided in request.~EB*G*FAM*30***29*5760.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*FAM*30***29*500.00*****Y~MSG*Includes services provided by Client Specific Network~EB*G*IND*30***29*2760.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***29*250.00*****Y~MSG*Includes services provided by Client Specific Network~EB*C*FAM*30***29*15000.00*****N~EB*G*FAM*30***29*30000.00*****N~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***29*7500.00*****N~EB*G*IND*30***29*15000.00*****N~MSG*Deductible does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~SE*119*1001~GE*1*1~IEA*1*123456782~]]>
Success
```
The response body includes the following elements:
{/* prettier-ignore-start */}
| Element | Description |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `PayloadType` | The type of the payload returned in the response.- `X12_271_Response_005010X279A1` for requests that pass X12 EDI validation. A 271 can contain benefits information for the patient or [`AAA` errors](/healthcare/eligibility-troubleshooting#payer-aaa-errors).
- `X12_999_Response_005010X231A1` for requests that fail [X12 EDI validation](/healthcare/eligibility-troubleshooting#x12-edi-validation-errors).
- `CoreEnvelopeError` when there's a [Core-compliant error](/healthcare/eligibility-troubleshooting#core-compliant-errors) or Stedi couldn't parse the X12 EDI envelope.
|
| `ProcessingMode` | The processing mode used for the request. This is always `RealTime`. |
| `PayloadID` | A unique identifier Stedi generated for the transaction. This won't be the same value you submitted as the `PayloadID` in the request. |
| `TimeStamp` | The timestamp when the response was generated in ISO 8601 format. |
| `SenderID` | The ID of the sender of the response. This is always the same as the `ReceiverID` in the request. |
| `ReceiverID` | The ID of the receiver of the response. This is always the same as the `SenderID` in the request. |
| `CORERuleVersion` | The CAQH CORE rule version. This is always `2.2.0`. |
| `Payload` | The X12 EDI response.- 271 Eligibility Benefit Response for requests that pass X12 EDI validation. A 271 can contain benefits information for the patient or [`AAA` errors](/healthcare/eligibility-troubleshooting#payer-aaa-errors).
- 999 Implementation Acknowledgment when the request fails [X12 EDI validation](/healthcare/eligibility-troubleshooting#x12-edi-validation-errors).
- Empty when the request fails due to a [CORE-compliant error](/healthcare/eligibility-troubleshooting#core-compliant-errors) or because Stedi couldn't parse the X12 EDI envelope.
|
| `ErrorCode` | The error code, if any, associated with the response. These errors typically indicate issues with the request body, such as missing or invalid elements. They can also indicate authentication issues and other processing errors. [Learn more](/healthcare/eligibility-troubleshooting#core-compliant-errors). |
| `ErrorMessage` | A description of the error, if any. |
| `Fault` | Only included when there is a [SOAP fault](/healthcare/eligibility-troubleshooting#soap-faults). It includes a `Code` and `Reason` element that describe the error. |
{/* prettier-ignore-end */}
## HTTP status codes [#http-status-codes]
Most errors return SOAP, but some return JSON containing the HTTP status code and a brief message describing the error.
{/* prettier-ignore-start */}
| Status Code | Response | Description |
| --------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `200 OK` | SOAP | Indicates a successful request. Note that Stedi returns a `200` even when the payer returns [`AAA` errors](/healthcare/eligibility-troubleshooting#payer-aaa-errors) in the 271 response. |
| `400 Bad Request` | SOAP | Indicates a [SOAP fault](/healthcare/eligibility-troubleshooting#soap-faults), an error with the [SOAP request body](/healthcare/eligibility-troubleshooting#core-compliant-errors), or an [X12 EDI validation error](/healthcare/eligibility-troubleshooting#x12-edi-validation-errors). |
| `401 Unauthorized` | SOAP | Indicates issues with the Stedi account ID or API key you provided. [Example](/healthcare/eligibility-troubleshooting#authentication-errors) |
| `404 Not Found` | JSON | Indicates that the specified endpoint doesn't exist. Verify that you are using the correct URL for this endpoint: `https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core`. |
| `429 Too Many Requests` | SOAP | Indicates that you have exceeded your [concurrency limit](/healthcare/api-reference#concurrency-limits) for this endpoint. The X12 response will contain an `AAA` error with code `42`. Stedi will continue rejecting additional requests with a `429` status code until one of your previous requests is completed. [Example](/healthcare/eligibility-troubleshooting#too-many-requests) |
| `500 Internal Server Error` | JSON | Indicates an unexpected error on Stedi's side. If you encounter this error, please contact [Stedi Support](https://stedi.com/support) for assistance. |
{/* prettier-ignore-end */}
## API Specification
Submit real-time eligibility checks over SOAP using the CAQH CORE vC2.2.0 XML Schema
**Endpoint:** `POST /protocols/caqh-core`
**Base URL:** `https://healthcare.us.stedi.com/2025-06-01`
### Parameters
- **`X-Forwarded-For`** (header):
- Type: `string`
### Request Body
### Responses
#### 200
200 response
#### 400
Bad Request - The server could not process the request due to invalid syntax or missing required fields.
#### 401
Unauthorized - Authentication failed. Verify the security credentials in the SOAP header.
#### 404
Not Found - The requested resource could not be found.
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`) (required)
#### 429
Too Many Requests
#### 500
Internal Server Error - An unexpected error occurred on the server.
**Properties:**
- **`message`** (`string`) (required)
- **`code`** (`string`) (required)
# Real-Time Eligibility Check (270/271) JSON
Source: https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-eligibility
[Real-time eligibility checks](/healthcare/send-eligibility-checks) are ideal for in-person patient visits, telehealth appointments, and other scenarios where you need immediate information about a patient’s coverage.
1. Call this endpoint with a JSON payload. The required information can vary depending on the circumstances, but we recommend starting with a [basic eligibility request](/healthcare/send-eligibility-checks#body---json).
2. Stedi translates your request to the X12 270 EDI format and sends it to the payer.
3. The endpoint returns a synchronous response from the payer in both JSON and raw X12 EDI format. The response contains the patient's eligibility and benefits information. Note that our documentation lists all enums officially allowed in the eligibility response. Some payers return non-compliant values, which Stedi passes through as is.
## API Specification
Submit a real-time 270/271 eligibility check in JSON format
**Endpoint:** `POST /change/medicalnetwork/eligibility/v3`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Parameters
- **`X-Forwarded-For`** (header):
- Type: `string`
### Request Body
**Schema:** `EligibilityCheckRequestContent`
**Properties:**
- **`controlNumber`** (`string`): Stedi generates a control number for each eligibility check, so you don’t need to include this property in your request.
- **`dependents`** (`array`): A dependent for which you want to retrieve benefits information.
- You can only submit one dependent per eligibility check.
- Only include the patient's information here when they are listed as a dependent on the subscriber's insurance plan AND the payer cannot uniquely identify them through information outside the subscriber's policy. For example, if the dependent has their own member ID number, you should identify them in the `subscriber` object instead. This includes member IDs that differ only by a suffix, such as `01`, because the patient can still be uniquely identified.
- Most Medicaid plans don't support dependents, with a [few exceptions](https://www.stedi.com/docs/healthcare/send-eligibility-checks#medicaid-dependents). Sending this array to payers that don't support dependents will either cause an error, or the payer may ignore the information and return results for the subscriber instead.
- Each payer has different requirements, so you should supply the fields necessary for each payer to identify the dependent in their system. However, we **strongly recommend** including the dependent's date of birth in the request when available because many payers return errors without it.
- Enter the patient's name exactly as written on their insurance card, if available, including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces. Visit [patient names](https://www.stedi.com/docs/healthcare/send-eligibility-checks#patient-names) for all best practices to avoid unnecessary failures.
- Items schema: `RequestDependent`
- **`eligibilitySearchId`** (`string`): An identifier that allows Stedi to group eligibility checks for the same patient into a unified record in the Stedi portal called an [eligibility search](https://www.stedi.com/docs/healthcare/eligibility-searches-view).
This property is for use by Stedi tools only, such as Stedi's MCP server.
- **`encounter`** (`object`)
- **`externalPatientId`** (`string`): A unique identifier for the patient that Stedi uses to identify and correlate historical eligibility checks for the same individual. We recommend including this value in all requests.
- **`informationReceiverName`** (`object`): Use the corresponding properties in the `provider` object instead.
- **`portalPassword`** (`string`): The password that the provider uses to log in to the payer's portal. For payers Medicaid California, AltaMed, and Kern Family Health Care, this property is **required** and should be the [provider's PIN](https://www.stedi.com/docs/healthcare/eligibility-troubleshooting#portal-credentials). Otherwise, this is not commonly used.
- **`portalUsername`** (`string`): The username that the provider uses to log in to the payer's portal. This is not commonly used.
- **`provider`** (`object`) (required): Information about the entity requesting the eligibility check. This may be an individual practitioner, a medical group, a hospital, or another type of healthcare provider.
- You must provide the `organizationName` (if the entity is an organization), or `firstName` and `lastName` (if the provider is an individual).
- You must also provide an identifier - this is typically the provider's [National Provider Identifier](https://www.stedi.com/docs/healthcare/national-provider-identifier) (`npi`). If the provider doesn't have an NPI, you can supply an alternative, such as their `taxId` or `ssn`.
- Don't include additional properties, such as `taxId` or `address`, unless they are specifically required or suggested by the payer.
- **`submitterTransactionIdentifier`** (`string`): This property is only relevant for asynchronous batch eligibility checks.
- **`subscriber`** (`object`) (required)
- **`tradingPartnerName`** (`string`): The payer's name, such as Cigna or Aetna.
- **`tradingPartnerServiceId`** (`string`) (required): The payer ID. Visit the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list.
- You can send requests using the primary payer ID, the Stedi payer ID, or any alias listed in the payer record.
- You must include leading `0` characters - payer IDs are alphanumeric strings and must be treated as complete strings, not integers. For example, use `00540` for SISCO, not `540`.
**Example:**
```json
{
"encounter": {
"serviceTypeCodes": [
"MH"
]
},
"externalPatientId": "UAA111222333",
"provider": {
"npi": "1999999984",
"organizationName": "ACME Health Services"
},
"subscriber": {
"dateOfBirth": "19000101",
"firstName": "Jane",
"lastName": "Doe",
"memberId": "123456789"
},
"tradingPartnerServiceId": "AHS"
}
```
### Responses
#### 200
EligibilityCheck 200 response
**Schema:** `EligibilityCheckResponseContent`
**Properties:**
- **`benefitsInformation`** (`array`): Information about the patient's healthcare benefits, such as coverage level (individual vs. family), coverage type (deductibles, co-pays, etc.), out of pocket maximums, and more.
Payers typically return at least the following properties: `code`, `coverageLevelCode`, `serviceTypeCodes`, and either `benefitAmount` or `benefitPercent`. However, the exact properties returned in this object are up to the payer's discretion.
The payer may send benefits information for service type codes (STCs) you didn't request - this is expected. The STC you send in the request tells the payer the types of benefits information you want, but they aren't required to respond with exactly the same STC(s) in the response. Receiving different STCs than you requested can also mean that the payer is ignoring the STC you sent, which is why we recommend [testing payers](https://www.stedi.com/docs/healthcare/eligibility-stc-procedure-codes#test-payer-stc-support) to determine their support for specific STCs.
Visit [Determine patient benefits](https://www.stedi.com/docs/healthcare/eligibility-active-coverage-benefits) for more information about benefit types, details about how to interpret the `benefitsInformation` array, and additional examples.
- Items schema: `BenefitsInformation`
- **`controlNumber`** (`string`): An identifier for the payer's response.
- **`dependents`** (`array`): Information about the patient when they are a dependent. When the patient is a dependent, this array will contain a single object with the patient's information. When the patient is a subscriber, or considered to be a subscriber because they have a unique member ID, their information is returned in the `subscriber` object, and this array will be empty.
When present, this object will always include the dependent's name for identification, but many payers will also return the date of birth and other identifying information.
- Items schema: `ResponseDependent`
- **`eligibilitySearchId`** (`string`): An identifier that allows Stedi to group eligibility checks for the same patient into a unified record in the Stedi portal called an [eligibility search](https://www.stedi.com/docs/healthcare/eligibility-searches-view).
This property is for use by Stedi tools only, such as Stedi's MCP server.
- **`errors`** (`array`): When a payer rejects your eligibility check, the response contains one or more [`AAA` errors](https://www.stedi.com/docs/healthcare/eligibility-troubleshooting#payer-aaa-errors) that specify the reasons for the rejection and any recommended follow-up actions.
Any errors that occur at the `payer`, `provider`, `subscriber`, or `dependents` levels are also included in this array, allowing you to review all errors in a central location. If there are no `AAA` errors, this array will be empty.
- Items schema: `EligibilityCheckError`
- **`id`** (`string`): A globally unique identifier for this eligibility check across all Stedi accounts. It's formatted as `ec_`. For example: `ec_550e8400-e29b-41d4-a716-446655440000`. You can use this ID to track this eligibility check and to construct deep links to eligibility checks in the Stedi portal.
- **`implementationTransactionSetSyntaxError`** (`string`): The implementation transaction set error code provided in `IK502` of the 999 transaction.
- **`meta`** (`object`)
- **`payer`** (`object`)
- **`planDateInformation`** (`object`)
- **`planInformation`** (`object`)
- **`planStatus`** (`array`): Please use `benefitsInformation` instead.
- Items schema: `PlanStatus`
- **`provider`** (`object`)
- **`reassociationKey`** (`string`)
- **`status`** (`string`): Errors Stedi encountered when generating or sending the final X12 EDI transaction to the payer. These can include validation errors and payer unavailable errors that prevent delivery.
- **`subscriber`** (`object`)
- **`subscriberTraceNumbers`** (`array`): A unique identifier for the eligibility request. It's used to trace the transaction. Stedi always generates a trace number for internal tracking, and the payer may generate one as well. Stedi returns both its internal trace number and the payer's trace number (if present) in this array.
You can't set your own trace number when submitting eligibility checks through this endpoint.
- Items schema: `SubscriberTraceNumber`
- **`tradingPartnerServiceId`** (`string`): An ID for the payer you identified in the original eligibility check request. This value may differ from the `tradingPartnerServiceId` you submitted in the original request because it reflects the payer's internal concept of their ID, not necessarily the ID Stedi uses to route requests to this payer.
- **`transactionSetAcknowledgement`** (`string`): The transaction set acknowledgment code provided in in the [X12 EDI 999 response](https://portal.stedi.com/app/guides/view/hipaa/implementation-acknowledgment-x231/01HRF41ES1DVGCA6X1EHSRPFXZ#properties.heading.properties.transaction_set_response_header_AK2_loop.items.properties.transaction_set_response_trailer_IK5).
- **`warnings`** (`array`): Warnings indicate non-fatal issues with your eligibility check or a non-standard response from the payer.
- Items schema: `Warning`
- **`x12`** (`string`): Typically this property contains the raw X12 EDI [271 Eligibility Benefit Response](https://portal.stedi.com/app/guides/view/hipaa/health-care-eligibility-benefit-response-x279a1/01GS66YHZPB37ABF34DBPSR213) from the payer.
In some circumstances, this property may contain a [999 Implementation Acknowledgment](https://portal.stedi.com/app/guides/view/hipaa/implementation-acknowledgment-x231a1/01HMRQV0N8SPHG58M4ZG1CRHH0) instead of a 271. A 999 indicates validation errors in the X12 EDI transaction, such as improper formatting or missing or invalid values.
If the 999 is returned in this property, many of the other response properties will be empty, as they are mapped to information in the 271.
**Example:**
```json
{
"benefitsInformation": [
{
"additionalInformation": [
{
"description": "Complete Care Management"
}
],
"code": "1",
"name": "Active Coverage",
"planCoverage": "Open Access Plus",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "6000",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"benefitAmount": "500",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "3000",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"benefitAmount": "250",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "15000",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"additionalInformation": [
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "30000",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitPercent": "0.1",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
]
},
{
"benefitAmount": "7500",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"additionalInformation": [
{
"description": "Deductible does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "15000",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Co-Insurance",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Not Applicable",
"inPlanNetworkIndicatorCode": "W",
"name": "Active Coverage",
"serviceTypeCodes": [
"A7",
"BC",
"A8",
"A4",
"A5",
"A6",
"7",
"4",
"BB",
"22"
],
"serviceTypes": [
"Psychiatric - Inpatient",
"Day Care (Psychiatric)",
"Psychiatric - Outpatient",
"Psychiatric",
"Psychiatric - Room and Board",
"Psychotherapy",
"Anesthesia",
"Diagnostic X-Ray",
"Partial Hospitalization (Psychiatric)",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"BC",
"A4",
"A6",
"4",
"22"
],
"serviceTypes": [
"Day Care (Psychiatric)",
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"A8"
],
"serviceTypes": [
"Psychiatric - Outpatient"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"A4",
"A6",
"4",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
]
},
{
"authOrCertIndicator": "N",
"benefitAmount": "20",
"code": "B",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"A4",
"A6",
"4",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Included For Specific Services"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "20",
"code": "B",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Included For Specific Services"
}
],
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"A4",
"A6",
"4",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Diagnostic X-Ray",
"Social Work"
]
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "20",
"code": "B",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Telehealth Provided Other than in Patient’s Home",
"industryCode": "02"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitAmount": "20",
"code": "B",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"serviceTypeCodes": [
"A4",
"A6",
"22"
],
"serviceTypes": [
"Psychiatric",
"Psychotherapy",
"Social Work"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "Y",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"7"
],
"serviceTypes": [
"Anesthesia"
]
},
{
"authOrCertIndicator": "Y",
"code": "CB",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Coverage Basis",
"serviceTypeCodes": [
"7",
"BB"
],
"serviceTypes": [
"Anesthesia",
"Partial Hospitalization (Psychiatric)"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "Y",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"7"
],
"serviceTypes": [
"Anesthesia"
]
},
{
"authOrCertIndicator": "Y",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Office",
"industryCode": "11"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"7"
],
"serviceTypes": [
"Anesthesia"
]
},
{
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"4"
],
"serviceTypes": [
"Diagnostic X-Ray"
]
},
{
"additionalInformation": [
{
"description": "Services rendered thru Client Specific Network"
}
],
"authOrCertIndicator": "N",
"benefitPercent": "0",
"code": "A",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"eligibilityAdditionalInformation": {
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
},
"eligibilityAdditionalInformationList": [
{
"codeListQualifier": "Mutually Defined",
"codeListQualifierCode": "ZZ",
"industry": "Outpatient Hospital",
"industryCode": "22"
}
],
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"serviceTypeCodes": [
"4"
],
"serviceTypes": [
"Diagnostic X-Ray"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"authOrCertIndicator": "Y",
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"BB"
],
"serviceTypes": [
"Partial Hospitalization (Psychiatric)"
]
},
{
"additionalInformation": [
{
"description": " Provider is out of network based on NPI ID provided in request."
}
],
"code": "1",
"name": "Active Coverage",
"serviceTypeCodes": [
"MH"
],
"serviceTypes": [
"Mental Health"
]
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "5760",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"benefitAmount": "500",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
},
{
"description": "Copay does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "2760",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"additionalInformation": [
{
"description": "Includes services provided by Client Specific Network"
}
],
"benefitAmount": "250",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "15000",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"additionalInformation": [
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
},
{
"description": "Deductible does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "30000",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "7500",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"additionalInformation": [
{
"description": "Deductible does apply to member's out-of-pocket maximum"
},
{
"description": "Coinsurance does apply to member's out-of-pocket maximum"
}
],
"benefitAmount": "15000",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
}
],
"controlNumber": "214976898",
"eligibilitySearchId": "01922a35-a177-7171-b868-cd4974dd54df",
"errors": [],
"id": "ec_550e8400-e29b-41d4-a716-446655440000",
"meta": {
"applicationMode": "production",
"outboundTraceId": "01J2VZA127GH93JT74HJU",
"senderId": "030240928",
"submitterId": "117151744",
"traceId": "01J2VZA127GH93JT74HJU"
},
"payer": {
"contactInformation": {
"contacts": [
{
"communicationMode": "Telephone",
"communicationNumber": "1234567890"
},
{
"communicationMode": "Uniform Resource Locator (URL)",
"communicationNumber": "website.company.com"
}
]
},
"entityIdentifier": "Payer",
"entityType": "Non-Person Entity",
"federalTaxpayersIdNumber": "123412345",
"name": "ABCDE"
},
"planDateInformation": {
"eligibilityBegin": "20220102",
"planBegin": "20240101",
"planEnd": "20241231"
},
"planInformation": {
"groupDescription": "ABCDE",
"groupNumber": "12341234",
"priorIdNumber": "1234567890"
},
"planStatus": [
{
"planDetails": "Open Access Plus",
"serviceTypeCodes": [
"30"
],
"status": "Active Coverage",
"statusCode": "1"
},
{
"serviceTypeCodes": [
"A7",
"BC",
"A8",
"A4",
"A5",
"A6",
"7",
"4",
"BB",
"22"
],
"status": "Active Coverage",
"statusCode": "1"
},
{
"serviceTypeCodes": [
"MH"
],
"status": "Active Coverage",
"statusCode": "1"
}
],
"provider": {
"entityIdentifier": "Provider",
"entityType": "Non-Person Entity",
"npi": "1999999984",
"providerName": "ACME HEALTH SERVICES"
},
"reassociationKey": "123456789",
"subscriber": {
"address": {
"address1": "1234 FIRST ST",
"city": "NEW YORK",
"postalCode": "123451111",
"state": "WV"
},
"dateOfBirth": "19000101",
"entityIdentifier": "Insured or Subscriber",
"entityType": "Person",
"firstName": "JANE",
"gender": "F",
"groupNumber": "123456789",
"lastName": "DOE",
"memberId": "123456789",
"middleName": "A"
},
"tradingPartnerServiceId": "123456789",
"x12": "ISA*00* *00* *ZZ*STEDI *01*117151744 *111111*1234*^*00501*123456782*0*P*>~GS*HB*STEDI*117151744*20240326*111000*1*X*005010X279A1~ST*271*1001*005010X279A1~BHT*0022*11*01J2VZA127GH93JT74HJU*20240326*1514~HL*1**20*1~NM1*PR*2*ABCDE*****FI*111000123~PER*IC**TE*123456789*UR*website.company.com~HL*2*1*21*1~NM1*1P*2*ACME HEALTH SERVICES*****XX*1999999984~HL*3*2*22*0~NM1*IL*1*DOE*JANE*A***MI*123456789~REF*6P*123456789*ABCDE~REF*Q4*123456789~N3*1234 FIRST ST~N4*NEW YORK*WV*123451111~DMG*D8*19000101*F~INS*Y*18*001*25~DTP*356*D8*20220102~DTP*346*D8*20240101~DTP*347*D8*20241231~EB*1**30**Open Access Plus~MSG*Complete Care Management~EB*G*FAM*30***23*6000.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*FAM*30***23*500.00*****Y~MSG*Includes services provided by Client Specific Network~EB*G*IND*30***23*3000.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***23*250.00*****Y~MSG*Includes services provided by Client Specific Network~EB*C*FAM*30***23*15000.00*****N~EB*G*FAM*30***23*30000.00*****N~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*A*IND*30*****.10****Y~EB*C*IND*30***23*7500.00*****N~EB*G*IND*30***23*15000.00*****N~MSG*Deductible does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~EB*A*IND*30*****.50****N~EB*1**A7^BC^A8^A4^A5^A6^7^4^BB^22*********W~EB*C*IND*BC^A4^A6^4^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*22~EB*C*IND*A8****0.00****N*Y~MSG*Includes services provided by Client Specific Network~EB*C*IND*A4^A6^4^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*11~EB*C*IND*A4^A6^22****0.00****N*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*02~EB*B*IND*A4^A6^22***27*20.00****N*Y~III*ZZ*11~EB*A*IND*A4^A6^4^22*****.00***N*Y~III*ZZ*11~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Included For Specific Services~III*ZZ*02~EB*A*IND*A4^A6^22*****.00***N*Y~MSG*Included For Specific Services~III*ZZ*02~EB*A*IND*A4^A6^22*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*02~EB*A*IND*A4^A6^4^22*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*02~EB*B*IND*A4^A6^22***27*20.00****N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*A*IND*7*****.00***Y*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*11~EB*CB**7^BB********Y*Y~EB*C*IND*7****0.00****Y*Y~MSG*Includes services provided by Client Specific Network~III*ZZ*11~EB*A*IND*7*****.00***Y*Y~III*ZZ*11~EB*A*IND*4*****.00***N*Y~III*ZZ*22~EB*A*IND*4*****.00***N*Y~MSG*Services rendered thru Client Specific Network~III*ZZ*22~EB*C*IND*BB****0.00****Y*Y~MSG*Includes services provided by Client Specific Network~EB*1**MH~MSG* Provider is out of network based on NPI ID provided in request.~EB*G*FAM*30***29*5760.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*FAM*30***29*500.00*****Y~MSG*Includes services provided by Client Specific Network~EB*G*IND*30***29*2760.00*****Y~MSG*Includes services provided by Client Specific Network~MSG*Copay does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***29*250.00*****Y~MSG*Includes services provided by Client Specific Network~EB*C*FAM*30***29*15000.00*****N~EB*G*FAM*30***29*30000.00*****N~MSG*Coinsurance does apply to member's out-of-pocket maximum~MSG*Deductible does apply to member's out-of-pocket maximum~EB*C*IND*30***29*7500.00*****N~EB*G*IND*30***29*15000.00*****N~MSG*Deductible does apply to member's out-of-pocket maximum~MSG*Coinsurance does apply to member's out-of-pocket maximum~SE*119*1001~GE*1*1~IEA*1*123456782~"
}
```
#### 400
EligibilityCheck400Error 400 response
**Schema:** `EligibilityCheck400ErrorResponseContent`
**Example:**
```json
{
"controlNumber": "000647813",
"eligibilitySearchId": "0198afa8-1610-7602-a436-911cb4bf2a9f",
"errors": [
{
"code": "44",
"description": "Invalid/Missing Provider Name",
"field": "AAA",
"followupAction": "Please Correct and Resubmit",
"location": "Loop 2100B",
"possibleResolutions": "Provider's NPI is registered with incorrect name at the payer. Contact the payer directly using the information in the `payer.contactInformation` object (if available) to resolve the issue."
}
],
"id": "ec_650e8400-e29b-41d4-a716-446655440001",
"meta": {
"applicationMode": "test",
"outboundTraceId": "01K2QTG5GGN7SSM34JMHS7QBDZ",
"senderId": "STEDI",
"submitterId": "117151744",
"traceId": "01K2QTG5GGN7SSM34JMHS7QBDZ"
},
"payer": {
"entityIdentifier": "Payer",
"entityType": "Non-Person Entity",
"name": "100935",
"payorIdentification": "100935"
},
"planDateInformation": {
"plan": "20240726"
},
"provider": {
"aaaErrors": [
{
"code": "44",
"description": "Invalid/Missing Provider Name",
"field": "AAA",
"followupAction": "Please Correct and Resubmit",
"location": "Loop 2100B",
"possibleResolutions": "Provider's NPI is registered with incorrect name at the payer. Contact the payer directly using the information in the `payer.contactInformation` object (if available) to resolve the issue."
}
],
"entityIdentifier": "Provider",
"entityType": "Person",
"npi": "1447848577",
"providerName": "SIMPSON"
},
"reassociationKey": "000647813",
"subscriber": {
"dateOfBirth": "20240606",
"entityIdentifier": "Insured or Subscriber",
"entityType": "Person",
"firstName": "ABE",
"lastName": "STEDI"
},
"subscriberTraceNumbers": [
{
"originatingCompanyIdentifier": "3117151744",
"referenceIdentification": "01K2QTG5GJ8K030SK9QDWF5HD9",
"traceType": "Current Transaction Trace Numbers",
"traceTypeCode": "1"
}
],
"tradingPartnerServiceId": "BS001",
"warnings": [
{
"code": "response::271::invalid_subscriber_insured_id",
"description": "[Subscriber/dependent] ID must use one of these formats: a three character alpha-numeric prefix (no zeros or ones) followed by a maximum of 14 alpha-numeric characters, an `R` followed by exactly 8 numbers, or an `H` followed by exactly 8 or 10 numbers."
}
],
"x12": "ISA*00* *00* *ZZ*STEDI *01*117151744 *250815*1734*^*00501*000647813*0*T*:~GS*HB*STEDI*117151744*20250815*173448*1*X*005010X279A1~ST*271*1001*005010X279A1~BHT*0022*11*01K2QTG5GGN7SSM34JMHS7QBDZ*20250815*1734~HL*1**20*1~NM1*PR*2*100935*****PI*100935~HL*2*1*21*1~NM1*1P*1*SIMPSON*****XX*1447848577~AAA*N**44*C~HL*3*2*22*0~TRN*1*01K2QTG5GJ8K030SK9QDWF5HD9*3117151744~NM1*IL*1*STEDI*ABE~DMG*D8*20240606~DTP*291*D8*20240726~SE*13*1001~GE*1*1~IEA*1*000647813~"
}
```
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# Institutional Claims (837I) Raw X12
Source: https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-institutional-claims-raw-x12
This endpoint is ideal if you have an existing system that generates X12 EDI files and you want to send them through Stedi.
1. Call this endpoint with a payload in [837 X12 EDI format](https://portal.stedi.com/app/guides/view/hipaa/health-care-claim-institutional-x223a2/01JBHW2YXMN2F9KXK2PS0BFP9F).
2. Stedi validates the EDI and sends the claim to the payer.
3. The endpoint returns a response from Stedi in JSON format containing information about the claim you submitted and whether the submission was successful.
## API Specification
Submit an 837I institutional claim in raw X12 EDI format
**Endpoint:** `POST /change/medicalnetwork/institutionalclaims/v1/raw-x12-submission`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Parameters
- **`Idempotency-Key`** (header): A unique string to identify this request to the server. The key can be up to 255 characters. You can safely retry requests with the same idempotency key within 24 hours of making the first request. This prevents you from sending duplicate claims due to network errors or other intermittent failures. [Learn more](https://www.stedi.com/docs/api-reference/index#idempotency-keys).
- Type: `string`
### Request Body
**Schema:** `InstitutionalClaimsRawX12SubmissionRequestContent`
**Properties:**
- **`x12`** (`string`) (required)
**Example:**
```json
{
"x12": "ISA*00* *00* *ZZ*574183004559 *ZZ*STEDITEST *260213*2004*^*00501*000000035*0*T*>~GS*HC*574183004559*STEDITEST*20260213*200422*35*X*005010X223A2~ST*837*0001*005010X223A2~BHT*0019*00*01KHC9KCMYMA7YSW4K1ZM774ZA*20260213*2003*CH~NM1*41*2*Test Facility*****46*123456789~PER*IC**TE*2225551234~NM1*40*2*UnitedHealthcare*****46*87726~HL*1**20*1~NM1*85*2*Test Facility*****XX*1999999976~N3*123 Mulberry Street~N4*Seattle*WA*111135272~REF*EI*123456789~HL*2*1*22*0~SBR*P*18*******ZZ~NM1*IL*1*DOE*JANE****MI*98765~N3*1234 Some St~N4*Buckeye*AZ*85326~DMG*D8*19000101*F~NM1*PR*2*UnitedHealthcare*****PI*87726~CLM*55556666777888*500***11>A>0**C*Y*Y~DTP*434*RD8*20241015-20241015~DTP*435*DT*202409091000~CL1*3*9*30~HI*ABK>R45851~NM1*71*1*Provider*Doctor****XX*1999999976~LX*1~SV2*0800*HC>H0001*500*UN*1~DTP*472*RD8*20241015-20241015~REF*6R*111222333~SE*28*0001~GE*1*35~IEA*1*000000035~"
}
```
### Responses
#### 200
InstitutionalClaimsRawX12Submission 200 response
**Schema:** `InstitutionalClaimsRawX12SubmissionResponseContent`
**Properties:**
- **`claimReference`** (`object`)
- **`controlNumber`** (`string`): An identifier for the transaction.
- **`editResponses`** (`array`): Currently not used.
- Items schema: `EditResponse`
- **`editStatus`** (`string`): This shape is deprecated: Currently not used.
- **`errors`** (`array`): Errors resulting from claim edits. You must review and fix these errors before resubmitting.
- Items schema: `InstitutionalError`
- **`failure`** (`object`)
- **`httpStatusCode`** (`object`)
- **`meta`** (`object`)
- **`payer`** (`object`)
- **`status`** (`string`): The status of the claim submission.
- **`tradingPartnerServiceId`** (`string`): An ID for the payer you identified in the original claim. This value may differ from the `tradingPartnerServiceId` you submitted in the original request because it reflects the payer's internal concept of their ID, not necessarily the ID Stedi uses to route requests to this payer.
- **`warnings`** (`array`): A list of warnings. Currently not used.
- Items schema: `ClaimsWarning`
- **`x12`** (`string`): A [277CA claim acknowledgment](https://www.stedi.com/docs/healthcare/claim-responses-overview#277ca-claim-acknowledgment) acceptance or rejection from Stedi in X12 EDI format. It indicates whether the claim has passed Stedi's claim edits.
When the claim fails one or more edits, the 277CA contains `STC` segments with information about each error. These are the same error codes that appear in the `errors` array.
Note that this 277CA only indicates whether Stedi has accepted or rejected the claim submission. You may receive additional 277CA acceptances or rejections as the claim is routed to the payer.
**Example:**
```json
{
"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",
"x12": "ISA*00* *00* *ZZ*STEDITEST *ZZ*574183004559 *260213*2001*^*00501*929135779*0*T*>~GS*HN*STEDITEST*574183004559*20260213*200134*1*X*005010X214~ST*277*0001*005010X214~BHT*0085*08*01KHC9GC66KDRVHEJC42Q103EQ*20260213*200134*TH~HL*1**20*1~NM1*AY*2*STEDI INC*****46*117151744~TRN*1*01KHC9GC66KDRVHEJC42Q103EQ~DTP*050*D8*20260213~DTP*009*D8*20260213~HL*2*1*21*1~NM1*41*2*Test Facility*****46*123456789~TRN*2*01KHC9G8FMGZ6CA9TQT704RAMB~STC*A0>17>AY*20260213*WQ*500.0~QTY*90*1~AMT*YU*500.0~HL*3*2*19*1~NM1*85*2*Test Facility*****XX*1999999976~TRN*1*0~REF*TJ*123456789~QTY*QA*1~AMT*YU*500.0~HL*4*3*PT*0~NM1*QC*1*DOE*JANE****MI*98765~TRN*2*12345~STC*A1>20*20260213*WQ*500.0~DTP*472*RD8*20241015-20241015~SE*25*0001~GE*1*1~IEA*1*929135779~"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`code`** (`string`): A code describing the type of validation failure.
- **`message`** (`string`) (required): A message describing the causes of the validation failure. There may be more than one.
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 409
ConflictException 409 response
**Schema:** `ConflictExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Unique error code identifying the specific type of error.
- **`message`** (`string`) (required): Human readable error message explaining why the request was rejected.
#### 422
RequestChangedException 422 response
**Schema:** `RequestChangedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Unique error code identifying the specific type of error.
- **`message`** (`string`) (required): Human readable error message explaining why the request was rejected.
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# Institutional Claims (837I) JSON
Source: https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-institutional-claims
This endpoint sends 837I institutional claims to payers.
1. Call this endpoint with a JSON payload.
2. Stedi translates your request to the X12 837 EDI format and sends it to the payer.
3. The endpoint returns a response from Stedi in JSON format containing information about the claim you submitted and whether the submission was successful.
## API Specification
Submit an 837I institutional claim in JSON format
**Endpoint:** `POST /change/medicalnetwork/institutionalclaims/v1/submission`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Parameters
- **`Idempotency-Key`** (header): A unique string to identify this request to the server. The key can be up to 255 characters. You can safely retry requests with the same idempotency key within 24 hours of making the first request. This prevents you from sending duplicate claims due to network errors or other intermittent failures. [Learn more](https://www.stedi.com/docs/api-reference/index#idempotency-keys).
- Type: `string`
### Request Body
**Schema:** `InstitutionalClaimsSubmissionRequestContent`
**Properties:**
- **`attending`** (`object`)
- **`billing`** (`object`)
- **`billingPayToAddressName`** (`object`)
- **`billingPayToPlanName`** (`object`)
- **`claimIdentifier`** (`object`)
- **`claimInformation`** (`object`) (required)
- **`controlNumber`** (`string`): Not currently used.
- **`dependent`** (`object`): Dependent who received the medical care associated with the claim.
- When the dependent has their own member ID for the health plan, you should include the dependent's information in the `subscriber` object instead. To check whether a dependent has a member ID, submit an [Eligibility Check](https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-eligibility) to the payer. The payer returns the dependent's member ID in the `dependents.memberId` property in the response, if present.
- You must include `address` in this object when the patient is a dependent.
- **`operatingPhysician`** (`object`): Information about the individual with primary responsibility for performing the surgical procedure(s) listed in the claim. Required when a surgical procedure code is listed on the claim. Use this object for operating physicians that apply to the entire claim.
This should be an individual, not an organization, and you should supply at least the physician's `lastName` and an identifier, which is typically the `npi`.
- **`otherOperatingPhysician`** (`object`): Information about any other operating physician involved in the surgical procedures listed in the claim. Required when another operating physician is involved in the surgical procedures listed in the claim. Use this object for physicians that apply to the entire claim.
This should be an individual, not an organization, and you should supply at least the physician's `lastName` and an identifier, which is typically the `npi`.
- **`payerAddress`** (`object`): Address information for the entity responsible for payment of the claim, listed in the `receiver` object.
- **`providers`** (`array`): Another way to send information for each provider relevant to the claim. This object overwrites the information you send in the `billing`, `referring`, `rendering`, and `attending` objects. Note that your request **must** include information about the billing provider either here or within the `billing` object.
- Items schema: `InstitutionalProvidersObject`
- **`receiver`** (`object`) (required)
- **`referring`** (`object`)
- **`rendering`** (`object`)
- **`submitter`** (`object`) (required)
- **`subscriber`** (`object`) (required)
- **`tradingPartnerName`** (`string`): This is the payer's business name, like Cigna or Aetna.
- **`tradingPartnerSecondaryIdentifiers`** (`object`): Secondary identifiers for the payer. You can include up to three properties in this object.
- **`tradingPartnerServiceId`** (`string`) (required): This is the Payer ID. Visit the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list. You can send requests using the Primary Payer ID, the Stedi Payer ID, or any alias listed in the payer record.
- **`usageIndicator`** (`string`): Whether you want to send a test or production claim. This property also allows you to filter claims in the Stedi portal by production or test data. By default, this property is set to `P` for production data. Use `T` to designate a claim as test data.
**Example:**
```json
{
"claimInformation": {
"benefitsAssignmentCertificationIndicator": "Y",
"claimChargeAmount": "500.00",
"claimCodeInformation": {
"admissionSourceCode": "9",
"admissionTypeCode": "3",
"patientStatusCode": "30"
},
"claimDateInformation": {
"admissionDateAndHour": "202409091000",
"statementBeginDate": "20241015",
"statementEndDate": "20241015"
},
"claimFilingCode": "ZZ",
"claimFrequencyCode": "0",
"patientControlNumber": "",
"placeOfServiceCode": "11",
"planParticipationCode": "C",
"principalDiagnosis": {
"principalDiagnosisCode": "R45851",
"qualifierCode": "ABK"
},
"releaseInformationCode": "Y",
"serviceLines": [
{
"assignedNumber": "0",
"institutionalService": {
"lineItemChargeAmount": "500.00",
"measurementUnit": "UN",
"procedureCode": "H0001",
"procedureIdentifier": "HC",
"serviceLineRevenueCode": "0800",
"serviceUnitCount": "1"
},
"lineItemControlNumber": "111222333",
"serviceDate": "20241015",
"serviceDateEnd": "20241015"
}
]
},
"controlNumber": "123456789",
"providers": [
{
"address": {
"address1": "123 Mulberry Street",
"city": "Seattle",
"postalCode": "111135272",
"state": "WA"
},
"contactInformation": {
"name": "Test Facility",
"phoneNumber": "2065551234"
},
"employerId": "123456789",
"npi": "1999999976",
"organizationName": "Test Facility",
"providerType": "BillingProvider"
},
{
"contactInformation": {
"name": "name"
},
"firstName": "Doctor",
"lastName": "Provider",
"npi": "1999999976",
"providerType": "AttendingProvider"
}
],
"receiver": {
"organizationName": "UnitedHealthcare"
},
"submitter": {
"contactInformation": {
"name": "Test Facility",
"phoneNumber": "2225551234"
},
"organizationName": "Test Facility",
"taxId": "123456789"
},
"subscriber": {
"address": {
"address1": "1234 Some St",
"city": "Buckeye",
"postalCode": "85326",
"state": "AZ"
},
"dateOfBirth": "19000101",
"firstName": "JANE",
"gender": "F",
"lastName": "DOE",
"memberId": "98765",
"paymentResponsibilityLevelCode": "P"
},
"tradingPartnerName": "UnitedHealthcare",
"tradingPartnerServiceId": "87726",
"usageIndicator": "T"
}
```
### Responses
#### 200
InstitutionalClaimsSubmission 200 response
**Schema:** `InstitutionalClaimsSubmissionResponseContent`
**Properties:**
- **`claimReference`** (`object`)
- **`controlNumber`** (`string`): An identifier for the transaction.
- **`editResponses`** (`array`): Currently not used.
- Items schema: `EditResponse`
- **`editStatus`** (`string`): This shape is deprecated: Currently not used.
- **`errors`** (`array`): Errors resulting from claim edits. You must review and fix these errors before resubmitting.
- Items schema: `InstitutionalError`
- **`failure`** (`object`)
- **`httpStatusCode`** (`object`)
- **`meta`** (`object`)
- **`payer`** (`object`)
- **`status`** (`string`): The status of the claim submission.
- **`tradingPartnerServiceId`** (`string`): An ID for the payer you identified in the original claim. This value may differ from the `tradingPartnerServiceId` you submitted in the original request because it reflects the payer's internal concept of their ID, not necessarily the ID Stedi uses to route requests to this payer.
- **`warnings`** (`array`): A list of warnings. Currently not used.
- Items schema: `ClaimsWarning`
- **`x12`** (`string`): A [277CA claim acknowledgment](https://www.stedi.com/docs/healthcare/claim-responses-overview#277ca-claim-acknowledgment) acceptance or rejection from Stedi in X12 EDI format. It indicates whether the claim has passed Stedi's claim edits.
When the claim fails one or more edits, the 277CA contains `STC` segments with information about each error. These are the same error codes that appear in the `errors` array.
Note that this 277CA only indicates whether Stedi has accepted or rejected the claim submission. You may receive additional 277CA acceptances or rejections as the claim is routed to the payer.
**Example:**
```json
{
"claimReference": {
"claimType": "INST",
"correlationId": "01JABEX6DPF4FCT2J0Y0SGFCY8",
"formatVersion": "5010",
"patientControlNumber": "00001111222233334444",
"payerId": "87726",
"rhClaimNumber": "01JABEX6DPF4FCT2J0Y0SGFCY8",
"serviceLines": [
{
"lineItemControlNumber": "111222333"
}
],
"timeOfResponse": "2024-10-16T20:04:32.962Z"
},
"controlNumber": "123456789",
"httpStatusCode": "200 OK",
"meta": {
"traceId": "a742ab42-a6f3-4232-a88c-197d341afdbe"
},
"payer": {
"payerID": "87726",
"payerName": "UnitedHealthcare"
},
"status": "SUCCESS",
"tradingPartnerServiceId": "87726",
"x12": "ISA*00* *00* *ZZ*STEDITEST *ZZ*574183004559 *260213*2001*^*00501*929135779*0*T*>~GS*HN*STEDITEST*574183004559*20260213*200134*1*X*005010X214~ST*277*0001*005010X214~BHT*0085*08*01KHC9GC66KDRVHEJC42Q103EQ*20260213*200134*TH~HL*1**20*1~NM1*AY*2*STEDI INC*****46*117151744~TRN*1*01KHC9GC66KDRVHEJC42Q103EQ~DTP*050*D8*20260213~DTP*009*D8*20260213~HL*2*1*21*1~NM1*41*2*Test Facility*****46*123456789~TRN*2*01KHC9G8FMGZ6CA9TQT704RAMB~STC*A0>17>AY*20260213*WQ*500.0~QTY*90*1~AMT*YU*500.0~HL*3*2*19*1~NM1*85*2*Test Facility*****XX*1999999976~TRN*1*0~REF*TJ*123456789~QTY*QA*1~AMT*YU*500.0~HL*4*3*PT*0~NM1*QC*1*DOE*JANE****MI*98765~TRN*2*12345~STC*A1>20*20260213*WQ*500.0~DTP*472*RD8*20241015-20241015~SE*25*0001~GE*1*1~IEA*1*929135779~"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`code`** (`string`): A code describing the type of validation failure.
- **`message`** (`string`) (required): A message describing the causes of the validation failure. There may be more than one.
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 409
ConflictException 409 response
**Schema:** `ConflictExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Unique error code identifying the specific type of error.
- **`message`** (`string`) (required): Human readable error message explaining why the request was rejected.
#### 422
RequestChangedException 422 response
**Schema:** `RequestChangedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Unique error code identifying the specific type of error.
- **`message`** (`string`) (required): Human readable error message explaining why the request was rejected.
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
# Submit Claim Attachment (275) Raw X12
Source: https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-submit-claim-attachment-raw-x12
This endpoint is in **beta** and is subject to change.
This endpoint is ideal if you have an existing system that generates X12 EDI files and you want to send them through Stedi's API.
1. Call this endpoint with a payload in [275 X12 EDI format](https://portal.stedi.com/app/guides/view/hipaa/patient-information-x210/01HQ4HZ8ZBY2CZGPCVVM8JTK22).
2. Stedi sends the attachment to the payer, so the payer can use it to adjudicate the referenced 837 professional, dental, or institutional claim.
3. The endpoint returns summary information about the attachment submission.
This endpoint only supports [unsolicited attachments](/healthcare/submit-claim-attachments#solicited-vs-unsolicited-attachments).
## Size limit [#size-limit]
The size limit for attachments submitted in a single request is 6MB. If you need to submit larger attachments, you must submit them through [Stedi SFTP](/healthcare/submit-claims-sftp-connection) or the [JSON endpoints](/healthcare/api-reference/post-healthcare-create-claim-attachment).
## API Specification
Submit a 275 claim attachment in X12 EDI format
**Endpoint:** `POST /claim-attachments/raw-x12-submission`
**Base URL:** `https://claims.us.stedi.com/2025-03-07`
### Request Body
**Schema:** `SubmitClaimAttachmentRawX12RequestContent`
**Properties:**
- **`x12`** (`string`) (required): The X12 EDI data for the claim attachment. This data must conform to the [275 X12 EDI specification](https://portal.stedi.com/app/guides/view/hipaa/patient-information-x210/01HQ4HZ8ZBY2CZGPCVVM8JTK22).
**Example:**
```json
{
"x12": "ISA*00* *00* *ZZ*STEDI *ZZ*CIGNA *250227*2140*^*00501*000000001*0*T*>~GS*PI*STEDI*CIGNA*20250227*214016*1*X*005010X210~ST*275*1001*005010X210~BGN*11*0001*20060915~NM1*PR*2*CIGNA*****XV*62308~NM1*41*2*XYZ SERVICES*****46*1999999976~NM1*1P*2*THE HOSPITAL*****XX*3999000B01~NX1*1P~N3*123 Main~N4*Miami*FL*11111~NM1*QC*1*DOE*JOHN*J***MI*987654320~REF*EJ*DOE123~REF*EA*AAAAA12345~DTP*472*D8*20060812~LX*1~TRN*2*1822634840~STC*R4>18626-2>>LOI~DTP*368*D8*20060915~CAT*AE*TX~EFI*05~BIN*8*U3RlZGk=~SE*20*1001~GE*1*1~IEA*1*000000001~"
}
```
### Responses
#### 200
SubmitClaimAttachmentRawX12 200 response
**Schema:** `SubmitClaimAttachmentRawX12ResponseContent`
**Properties:**
- **`claimAttachmentReference`** (`object`): Information about the claim attachment.
- **`meta`** (`object`): Metadata from Stedi about the request.
- **`tradingPartnerServiceId`** (`string`): An ID for the payer you identified in the related transaction. This value may differ from the `tradingPartnerServiceId` you submitted in the original claim request because it reflects the payer's internal concept of their ID, not necessarily the ID Stedi uses to route requests to this payer.
**Example:**
```json
{
"claimAttachmentReference": {
"correlationId": "att-123456",
"patientControlNumber": "PCN123456",
"timeOfResponse": "2025-03-07T12:34:56Z"
},
"meta": {
"traceId": "4d2b3c4e-1111-4222-b333-5a6f7e8d9a00"
},
"tradingPartnerServiceId": "PAYER123"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`fieldList`** (`array`): A list of specific failures encountered while validating the input.
A member can appear in this list more than once if it failed to satisfy multiple constraints.
- Items schema: `ValidationExceptionField`
- **`message`** (`string`) (required): A summary of the validation failure.
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Unique error code identifying the specific type of resource not found error.
- **`message`** (`string`) (required): Human readable error message explaining why the resource could not be found.
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
# Insurance Discovery Check
Source: https://www.stedi.com/docs/healthcare/api-reference/post-insurance-discovery
Insurance discovery checks search for a patient's active coverage using only their demographic data.
1. Call this endpoint with as much [patient demographic information](/healthcare/insurance-discovery#required-patient-information) as possible.
2. Stedi searches for active coverage for the patient.
3. The endpoint returns an array of potential active coverages along with subscriber details and benefits information.
We recommend using insurance discovery checks as a backup when eligibility checks fail or aren't possible. Because of their limitations, you shouldn't rely on them as your primary method for verifying patient coverage.
## API Specification
Submit an insurance discovery check in JSON format
**Endpoint:** `POST /insurance-discovery/check/v1`
**Base URL:** `https://healthcare.us.stedi.com/2024-04-01`
### Request Body
**Schema:** `InsuranceDiscoveryCheckRequestContent`
**Properties:**
- **`dependent`** (`object`)
- **`encounter`** (`object`)
- **`provider`** (`object`) (required)
- **`subscriber`** (`object`) (required)
**Example:**
```json
{
"encounter": {
"beginningDateOfService": "20240326",
"endDateOfService": "20240326"
},
"provider": {
"npi": "1999999984"
},
"subscriber": {
"address": {
"address1": "123 Main St",
"city": "Springfield",
"postalCode": "62701",
"state": "IL"
},
"dateOfBirth": "19800101",
"firstName": "John",
"gender": "M",
"lastName": "Smith",
"middleName": "Robert",
"ssn": "123456789"
}
}
```
### Responses
#### 200
InsuranceDiscoveryCheck 200 response
**Schema:** `InsuranceDiscoveryCheckResponseContent`
**Properties:**
- **`coveragesFound`** (`integer`): The number of potential coverage matches for the patient. This will be `0` if Stedi didn't find any matching coverage.
- **`discoveryId`** (`string`): A unique ID for this insurance discovery check. You can use it to retrieve the results asynchronously through the [Insurance Discovery Check Results](https://www.stedi.com/docs/healthcare/api-reference/get-insurance-discovery-results) endpoint.
- **`errors`** (`array`): When a payer rejects your eligibility check, the response contains one or more [`AAA` errors](https://www.stedi.com/docs/healthcare/eligibility-troubleshooting#payer-aaa-errors) that specify the reasons for the rejection and any recommended follow-up actions.
Any errors that occur at the `payer`, `provider`, `subscriber`, or `dependents` levels are also included in this array, allowing you to review all errors in a central location. If there are no `AAA` errors, this array will be empty.
- Items schema: `EligibilityCheckError`
- **`items`** (`array`): An array of potential coverage matches for the patient. This will only be populated if the insurance discovery check `status` is `COMPLETE`. Each item in the array contains information about a potential match, including the provider, subscriber, payer, and plan information.
- Items schema: `InsuranceDiscoveryResponseFields`
- **`meta`** (`object`)
- **`status`** (`object`): The status of the discovery check. This is either `PENDING` or `COMPLETE`.
- If the status is `COMPLETE`, the `items` array will contain any potential coverage matches Stedi found for the patient.
- If the status is `PENDING`, the check is still in progress. You can immediately begin polling the [Insurance Discovery Check Results](https://www.stedi.com/docs/healthcare/api-reference/get-insurance-discovery-results) endpoint to retrieve the results asynchronously.
**Example:**
```json
{
"discoveryId": "12345678-abcd-4321-efgh-987654321abc",
"items": [
{
"benefitsInformation": [
{
"additionalInformation": [
{
"description": "To determine if a prior authorization is required, please check the health plan's website."
}
],
"benefitsRelatedEntities": [
{
"entityFirstname": "Jane",
"entityIdentification": "XX",
"entityIdentificationValue": "1234567890",
"entityIdentifier": "Primary Care Provider",
"entityName": "Dough",
"entityType": "Person"
}
],
"code": "1",
"inPlanNetworkIndicator": "Not Applicable",
"inPlanNetworkIndicatorCode": "W",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Not Applicable",
"inPlanNetworkIndicatorCode": "W",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"1"
],
"serviceTypes": [
"Medical Care"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"4"
],
"serviceTypes": [
"Diagnostic X-Ray"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"4"
],
"serviceTypes": [
"Diagnostic X-Ray"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"4"
],
"serviceTypes": [
"Diagnostic X-Ray"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"5"
],
"serviceTypes": [
"Diagnostic Lab"
]
},
{
"additionalInformation": [
{
"description": "per visit"
}
],
"benefitAmount": "20",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"5"
],
"serviceTypes": [
"Diagnostic Lab"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"5"
],
"serviceTypes": [
"Diagnostic Lab"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"12"
],
"serviceTypes": [
"Durable Medical Equipment Purchase"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"12"
],
"serviceTypes": [
"Durable Medical Equipment Purchase"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"12"
],
"serviceTypes": [
"Durable Medical Equipment Purchase"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"13"
],
"serviceTypes": [
"Ambulatory Service Center Facility"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"13"
],
"serviceTypes": [
"Ambulatory Service Center Facility"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"13"
],
"serviceTypes": [
"Ambulatory Service Center Facility"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"18"
],
"serviceTypes": [
"Durable Medical Equipment Rental"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"18"
],
"serviceTypes": [
"Durable Medical Equipment Rental"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"18"
],
"serviceTypes": [
"Durable Medical Equipment Rental"
]
},
{
"additionalInformation": [
{
"description": "Limited to 26 visits per year (visits in excess of 26 require prior authorization)."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"33"
],
"serviceTypes": [
"Chiropractic"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"33"
],
"serviceTypes": [
"Chiropractic"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"33"
],
"serviceTypes": [
"Chiropractic"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"48"
],
"serviceTypes": [
"Hospital - Inpatient"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"48"
],
"serviceTypes": [
"Hospital - Inpatient"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"48"
],
"serviceTypes": [
"Hospital - Inpatient"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"50"
],
"serviceTypes": [
"Hospital - Outpatient"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"50"
],
"serviceTypes": [
"Hospital - Outpatient"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"50"
],
"serviceTypes": [
"Hospital - Outpatient"
]
},
{
"additionalInformation": [
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"51"
],
"serviceTypes": [
"Hospital - Emergency Accident"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"51"
],
"serviceTypes": [
"Hospital - Emergency Accident"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"51"
],
"serviceTypes": [
"Hospital - Emergency Accident"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"51"
],
"serviceTypes": [
"Hospital - Emergency Accident"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"52"
],
"serviceTypes": [
"Hospital - Emergency Medical"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"52"
],
"serviceTypes": [
"Hospital - Emergency Medical"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"52"
],
"serviceTypes": [
"Hospital - Emergency Medical"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"52"
],
"serviceTypes": [
"Hospital - Emergency Medical"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"53"
],
"serviceTypes": [
"Hospital - Ambulatory Surgical"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"53"
],
"serviceTypes": [
"Hospital - Ambulatory Surgical"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"53"
],
"serviceTypes": [
"Hospital - Ambulatory Surgical"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"62"
],
"serviceTypes": [
"MRI/CAT Scan"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"62"
],
"serviceTypes": [
"MRI/CAT Scan"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"62"
],
"serviceTypes": [
"MRI/CAT Scan"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"65"
],
"serviceTypes": [
"Newborn Care"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"65"
],
"serviceTypes": [
"Newborn Care"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"65"
],
"serviceTypes": [
"Newborn Care"
]
},
{
"additionalInformation": [
{
"description": "Covered in accordance with ACA guidelines."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"68"
],
"serviceTypes": [
"Well Baby Care"
]
},
{
"benefitAmount": "0",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"68"
],
"serviceTypes": [
"Well Baby Care"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"68"
],
"serviceTypes": [
"Well Baby Care"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"69"
],
"serviceTypes": [
"Maternity"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"69"
],
"serviceTypes": [
"Maternity"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"69"
],
"serviceTypes": [
"Maternity"
]
},
{
"additionalInformation": [
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"86"
],
"serviceTypes": [
"Emergency Services"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"86"
],
"serviceTypes": [
"Emergency Services"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"86"
],
"serviceTypes": [
"Emergency Services"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"86"
],
"serviceTypes": [
"Emergency Services"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"88"
],
"serviceTypes": [
"Pharmacy"
]
},
{
"additionalInformation": [
{
"description": "per prescription"
}
],
"benefitAmount": "10",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"88"
],
"serviceTypes": [
"Pharmacy"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"88"
],
"serviceTypes": [
"Pharmacy"
]
},
{
"additionalInformation": [
{
"description": "PCP"
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"98"
],
"serviceTypes": [
"Professional (Physician) Visit - Office"
]
},
{
"additionalInformation": [
{
"description": "per visit"
},
{
"description": "PCP"
}
],
"benefitAmount": "15",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"98"
],
"serviceTypes": [
"Professional (Physician) Visit - Office"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "PCP"
}
],
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"98"
],
"serviceTypes": [
"Professional (Physician) Visit - Office"
]
},
{
"additionalInformation": [
{
"description": "Specialist"
},
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"98"
],
"serviceTypes": [
"Professional (Physician) Visit - Office"
]
},
{
"additionalInformation": [
{
"description": "per visit"
},
{
"description": "Specialist"
}
],
"benefitAmount": "30",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"98"
],
"serviceTypes": [
"Professional (Physician) Visit - Office"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Specialist"
}
],
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"98"
],
"serviceTypes": [
"Professional (Physician) Visit - Office"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit. (Primary Care Provider (PCP) and other practitioner office visits do not require prior authorization.) Note| Services (excluding Emergency Room Care / Emergency Services) rendered by an out-of-network provider"
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A4"
],
"serviceTypes": [
"Psychiatric"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A4"
],
"serviceTypes": [
"Psychiatric"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A4"
],
"serviceTypes": [
"Psychiatric"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A6"
],
"serviceTypes": [
"Psychotherapy"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A6"
],
"serviceTypes": [
"Psychotherapy"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A6"
],
"serviceTypes": [
"Psychotherapy"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A7"
],
"serviceTypes": [
"Psychiatric - Inpatient"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A7"
],
"serviceTypes": [
"Psychiatric - Inpatient"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A7"
],
"serviceTypes": [
"Psychiatric - Inpatient"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A8"
],
"serviceTypes": [
"Psychiatric - Outpatient"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A8"
],
"serviceTypes": [
"Psychiatric - Outpatient"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"A8"
],
"serviceTypes": [
"Psychiatric - Outpatient"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AD"
],
"serviceTypes": [
"Occupational Therapy"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AD"
],
"serviceTypes": [
"Occupational Therapy"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AD"
],
"serviceTypes": [
"Occupational Therapy"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AF"
],
"serviceTypes": [
"Speech Therapy"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AF"
],
"serviceTypes": [
"Speech Therapy"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AF"
],
"serviceTypes": [
"Speech Therapy"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Limited to 150 days per year."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AG"
],
"serviceTypes": [
"Skilled Nursing Care"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AG"
],
"serviceTypes": [
"Skilled Nursing Care"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"AG"
],
"serviceTypes": [
"Skilled Nursing Care"
]
},
{
"additionalInformation": [
{
"description": "Covered in accordance with ACA guidelines."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"BZ"
],
"serviceTypes": [
"Physician Visit - Office: Well"
]
},
{
"benefitAmount": "0",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"BZ"
],
"serviceTypes": [
"Physician Visit - Office: Well"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"BZ"
],
"serviceTypes": [
"Physician Visit - Office: Well"
]
},
{
"additionalInformation": [
{
"description": "Prior authorization may be required. Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"MH"
],
"serviceTypes": [
"Mental Health"
]
},
{
"benefitPercent": "0.5",
"code": "A",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Insurance",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"MH"
],
"serviceTypes": [
"Mental Health"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"MH"
],
"serviceTypes": [
"Mental Health"
]
},
{
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"PT"
],
"serviceTypes": [
"Physical Therapy"
]
},
{
"additionalInformation": [
{
"description": "per visit"
}
],
"benefitAmount": "15",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"PT"
],
"serviceTypes": [
"Physical Therapy"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"code": "I",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Non-Covered",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"PT"
],
"serviceTypes": [
"Physical Therapy"
]
},
{
"additionalInformation": [
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"UC"
],
"serviceTypes": [
"Urgent Care"
]
},
{
"additionalInformation": [
{
"description": "per visit"
}
],
"benefitAmount": "10",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"UC"
],
"serviceTypes": [
"Urgent Care"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"additionalInformation": [
{
"description": "Covered No Limit."
}
],
"code": "1",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Active Coverage",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"UC"
],
"serviceTypes": [
"Urgent Care"
]
},
{
"additionalInformation": [
{
"description": "per visit"
}
],
"benefitAmount": "10",
"code": "B",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Co-Payment",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"UC"
],
"serviceTypes": [
"Urgent Care"
],
"timeQualifier": "Visit",
"timeQualifierCode": "27"
},
{
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Deductible",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "0",
"code": "C",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Deductible",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "3000",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "2000",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "6000",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "5000",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "Yes",
"inPlanNetworkIndicatorCode": "Y",
"name": "Out of Pocket (Stop Loss)",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "0",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "0",
"code": "G",
"coverageLevel": "Individual",
"coverageLevelCode": "IND",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
},
{
"benefitAmount": "0",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Calendar Year",
"timeQualifierCode": "23"
},
{
"benefitAmount": "0",
"code": "G",
"coverageLevel": "Family",
"coverageLevelCode": "FAM",
"inPlanNetworkIndicator": "No",
"inPlanNetworkIndicatorCode": "N",
"name": "Out of Pocket (Stop Loss)",
"planCoverage": "Gold Plan",
"serviceTypeCodes": [
"30"
],
"serviceTypes": [
"Health Benefit Plan Coverage"
],
"timeQualifier": "Remaining",
"timeQualifierCode": "29"
}
],
"confidence": {
"level": "REVIEW_NEEDED",
"reason": "This record was identified as a low confidence match due to a DOB partial match"
},
"payer": {
"name": "EXAMPLE INSURANCE CO"
},
"planDateInformation": {
"eligibilityBegin": "20250101",
"planBegin": "20250101",
"service": "20250301"
},
"planInformation": {
"groupDescription": "Individual On-Exchange",
"groupNumber": "123456-78",
"planNumber": "123456-EXMPL9876"
},
"provider": {
"entityType": "Non-Person Entity",
"npi": "1999999984",
"providerName": "provider"
},
"subscriber": {
"address": {
"address1": "123 Main Street",
"city": "ANYTOWN",
"postalCode": "12345",
"state": "CA"
},
"dateOfBirth": "19900115",
"firstName": "John",
"gender": "M",
"groupDescription": "Individual On-Exchange",
"groupNumber": "123456-78",
"lastName": "Doe",
"memberId": "987654321000",
"middleName": "Smith",
"planNumber": "123456-EXMPL9876"
}
}
],
"meta": {
"applicationMode": "production",
"traceId": "1-abcdef12-123456789abcdef123456789"
},
"status": "COMPLETE"
}
```
#### 400
ValidationException 400 response
**Schema:** `ValidationExceptionResponseContent`
**Properties:**
- **`code`** (`string`): A code describing the type of validation failure.
- **`message`** (`string`) (required): A message describing the causes of the validation failure. There may be more than one.
#### 403
AccessDeniedException 403 response
**Schema:** `AccessDeniedExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 404
ResourceNotFoundException 404 response
**Schema:** `ResourceNotFoundExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 429
ThrottlingException 429 response
**Schema:** `ThrottlingExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 500
InternalFailureException 500 response
**Schema:** `InternalFailureExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Error classification code
- **`message`** (`string`) (required): Human-readable error message
#### 503
ServiceUnavailableException 503 response
**Schema:** `ServiceUnavailableExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.
#### 504
GatewayTimeoutException 504 response
**Schema:** `GatewayTimeoutExceptionResponseContent`
**Properties:**
- **`code`** (`string`): Classification of the exception type.
- **`message`** (`string`) (required): Human readable exception message.