Changelog

Introducing automatic transaction enrollment requests for MBI lookups with SSN

Stedi now supports automatic transaction enrollment requests for MBI lookups with a Social Security Number (SSN).

What’s an MBI lookup?

A Medicare Beneficiary Identifier (MBI) is a unique ID for a Medicare beneficiary.

You need an MBI to run Medicare eligibility checks.

If you don’t have the patient’s MBI, you can get it using an MBI lookup with the patient’s demographic details and, optionally, their SSN.

What’s changing

To run MBI lookups with an SSN, you must complete transaction enrollment for the provider with the MBILU payer.

If Stedi receives an AAA error indicating the provider isn't enrolled with the payer, we now automatically create an enrollment request.

You can track and manage these enrollment requests using Stedi's Enrollments API or the Stedi portal.

Note: Automatic enrollment requests are not yet supported for the MBILUNOSSN (MBI lookup without SSN) payer.

For more details, check out our Transaction enrollment docs.

Introducing idempotency keys for Stedi’s Claim Submission API

Stedi’s Claim Submission API now supports an Idempotency-Key request header. The header is available for the following endpoints:

• 837P Professional Claims – JSON and X12

• 837D Dental Claims – JSON and X12

• 837I Institutional Claims – JSON and X12

We strongly recommend including an idempotency key with every claim submission request.

Idempotency keys let you safely retry a failed request. If a claim submission fails mid-flight due to a network error or timeout, resend it with the same key to avoid creating a duplicate claim. You can reuse the same key for up to 24 hours after the original request.

For more details, see our API reference.

Introducing warnings for unsupported SFTP transactions

The Stedi portal’s Transactions page now displays a warning when unsupported X12 transactions are submitted or received over SFTP.

If you use Stedi’s healthcare clearinghouse, your Stedi SFTP connection supports the following transactions:

Supported outbound

• 837P Professional claims

• 837D Dental claims

• 837I Institutional claims

• 275 Claim attachments

Supported inbound

• 277CA Claim acknowledgments

• 835 Electronic Remittance Advice (ERAs)

• 999 Implementation acknowledgments

Unsupported SFTP transactions

Other X12 transactions aren’t supported over SFTP, including:

• 270/271 Eligibility checks

• 276/277 Real-time claim status checks

To run these transactions, use the Stedi portal or the respective APIs:

• Batch Eligibility Check

• Real-time Eligibility Check

• Real-time Claim Status

Previously, unsupported transactions appeared on the Transactions page without any indication that they weren’t delivered. Now, a warning indicates they weren’t processed or sent to the payer.

CMS now requires attestation for Medicare eligibility checks

To run Medicare eligibility checks with CMS, providers must complete an attestation by May 11, 2026.

Without attestation, CMS will reject Medicare eligibility requests for the provider starting on or after May 11, 2026.

What's changing

The Centers for Medicare and Medicaid Services (CMS) now requires providers to attest that clearinghouses – like Stedi – are allowed to run Medicare eligibility checks on their behalf. CMS also refers to this attestation as HETS EDI Enrollment.

This applies to all CMS trading partners, not just Stedi.

Stedi is updating new and existing CMS eligibility enrollments to include a required attestation step.

To avoid disruption to Medicare eligibility checks, attestation must be completed by May 11, 2026.

Important: The requirement doesn’t apply to:

• Medicare Advantage, also called Medicare Part C

• Medicare Part D

Existing enrollments

On February 17, 2026, Stedi moved any existing CMS eligibility check enrollments without an attestation to an enrollment status of PROVIDER_ACTION_REQUIRED. These enrollments now include a task with instructions to complete attestation.

Stedi also sent a notification email to the address in the enrollment's userEmail field (called Person for Stedi to contact in the Stedi portal). The email includes a link to the enrollment.

Stedi checks CMS's records daily. When CMS shows the provider's NPI as attested, Stedi moves the CMS enrollment to the LIVE status.

To move the enrollment to LIVE sooner, mark the related enrollment task as complete. If CMS doesn't show the attestation, the daily check moves the enrollment back to PROVIDER_ACTION_REQUIRED.

How to find affected enrollments

To view these enrollments in the Stedi portal, filter for a Status of Provider Action Required and Transaction of Real-time eligibility checks (270/271) on the Enrollments page:

You can also retrieve the enrollments using the following query parameters for the List Enrollments API endpoint:

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

New enrollments

Starting February 16, 2026, new CMS eligibility check enrollments will require attestation. The process works as follows:

1. 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.

2. After the provider completes attestation, Stedi moves the enrollment to the LIVE status. Stedi checks CMS's records daily and moves the enrollment once CMS shows the NPI as attested.

   To move the enrollment to LIVE sooner, mark the related enrollment task as complete. If CMS doesn't show the attestation, the daily check moves the enrollment back to PROVIDER_ACTION_REQUIRED.

   Note: Once attestation is complete, you can run CMS eligibility checks immediately, even if the enrollment status is not yet LIVE.

Automatic enrollment requests for CMS

If a CMS eligibility check returns AAA error 41 (Authorization/Access Restrictions), indicating the provider is not enrolled for eligibility checks with CMS, Stedi automatically submits a CMS eligibility enrollment request for that provider.

Starting February 16, 2026, these automatic enrollment requests will follow the process for new CMS eligibility enrollments described above and require provider attestation. Previously, Stedi completed these enrollments without requiring provider action.

This feature was previously called “automatic enrollment.” We're now calling it “automatic enrollment requests.”

How to complete attestation

Attestation must be completed for each billing National Provider Identifier (NPI) enrolled with CMS for eligibility checks. There is no bulk attestation across NPIs.

Stedi can't complete this step on the provider’s behalf.

Stedi provides a task and instructions for completing the CMS attestation in:

• The Tasks section of the enrollment request's details page in the Stedi portal.

• The tasks object array of the List Enrollments and Retrieve Enrollment API responses.

You can also view the instructions in our Transaction Enrollments Hub.

How long does attestation take?

Attestation takes approximately 5-15 minutes to complete per NPI.

Timing

CMS has stated they'll enforce attestation requirements on May 11, 2026.

When enforcement begins, CMS will return AAA error 41 (Authorization/Access Restrictions) for Medicare eligibility checks with an NPI that has not completed attestation.

Until then, Medicare eligibility checks will continue to work as normal.

Support

If you have questions or concerns, contact us using your dedicated support channel or at support@stedi.com.

Introducing transaction enrollment tasks

You can now use Stedi’s Transaction Enrollment API or the Stedi portal to complete enrollment tasks.

What are enrollment tasks?

An enrollment task is any action that must be completed by the provider or the provider’s delegate to move an transaction enrollment forward. Examples include:

• Electronic funds transfer (EFT) enrollment with ERA enrollment, which involves giving the payer the provider’s bank information

• Completing an action in the payer’s portal

What's changing?

As part of this release, we’ve:

• Added a tasks object array to List Enrollments and Retrieve Enrollment API responses

• Released a new Update Enrollment Task API endpoint

• Updated the Stedi portal’s Enrollment details page to include enrollment tasks

For more details and examples, check our announcement blog.

Stedi’s Claim Submission API now returns raw X12 277CA claim acknowledgments

Stedi’s Claim Submission API responses now include an X12 277CA claim acknowledgment from Stedi in the x12 field. The x12 field is returned by the JSON and X12 endpoints across professional, institutional, and dental claims. It’s returned for both accepted and rejected claims.

For example, a JSON Professional Claim Submission API response for a rejected claim:

{
  "status": "ERROR",
  "errors": [
    {
      "code": "33",
      "description": "The billing provider tax id (TIN), 1234567893, is invalid. The TIN must be ...",
      "followupAction": "Please Correct and Resubmit"
    }
  ],
  "x12": "ISA*00*          *00*          *ZZ*STEDITEST      *ZZ*284631039151 ...",
  "httpStatusCode": "400 BAD_REQUEST",
  ...
}

You can use the x12 field to debug errors from claim rejections or store Stedi’s claim acknowledgments for tracking. Previously, Claim Submission API responses only included errors as JSON in the errors array.

What’s a claim acknowledgment?

A 277CA claim acknowledgment tells you whether a claim has been accepted or rejected for processing.

Stedi returns a claim acknowledgment after initial validation. Payers also return one or more acknowledgments later in the claim lifecycle.

The x12 field contains Stedi’s initial acknowledgment, generated after validating the claim against our database of edits. These edits – the industry’s term for an automated validation rule – mirror the same edits payers apply later in the process.

Stedi’s edits help catch validation errors early and reduce downstream payer rejections, which can delay payment for providers.

Rejections

If Stedi rejects a claim, the API response’s x12 field includes a descriptive claim status category code, claim status code, and error message in the STC (Status Information) segments of Loop 2200B, 2200B, 2200C, 2200D, or 2220D.

For example:

STC*A7>128>85*[DATE]*U*[AMOUNT]********The billing provider tax id (TIN), 1234567893, is invalid. The TIN must be a string of exactly 9 numbers with no separators. Correct and resubmit.~

You can use this information to correct and resubmit the claim.

Accepted claims

If Stedi accepts a claim, the API response’s x12 field includes the following values in the STC segments of Loop 2200B, 2200C, 2200D, or 2220D:

• Claim status category code is A0 (Acknowledgement/Forwarded)

• Claim status code is 17 (Claim/encounter has been forwarded by third party entity to entity)

• Entity identifier code) is AY (Clearinghouse)

For example:

STC*A0>17>AY*[DATE]*WQ*[AMOUNT]~

Other claim acknowledgements

Stedi’s initial acceptance of a claim doesn’t guarantee payer acceptance. Rejections may occur during downstream validation, including later rejections by Stedi or an intermediary clearinghouse.

Each acceptance or rejection returns a separate claim acknowledgment transaction. You can use a webhook to listen for these additional claim acknowledgments, poll for them using our Poll Transactions API, or monitor them manually in the Stedi portal.

Announcing 100% coverage for transaction enrollment timeframes

You can now see how long transaction enrollment takes – minutes, hours, days, or weeks – for all Stedi payers and transaction types that require enrollment.

For payers and transaction types that don’t require enrollment, no timeframe is shown.

You can view enrollment timeframes using the Payers API or the Stedi Payer Network. For example, in the Stedi Payer Network:

In Payers API responses:

{
  "payer": {
    "displayName": "Blue Cross Blue Shield of Michigan",
    "primaryPayerId": "00710",
    "enrollment": {
      "ptanRequired": false,
      "transactionEnrollmentProcesses": {
        "claimPayment": {                  // This payer requires enrollment for ERAs.
          "timeframe": "INSTANT",          // ERA enrollment typically takes minutes.
          "type": "ONE_CLICK"
        }
      }
    },
    ...
  }
}

Enrollment timeframes are based on Stedi's operational data – using real enrollments completed through our platform – and payer-specific rules.

Previously, enrollment timeframes were available but not populated for every payer.

You can use enrollment timeframes to plan go-live dates and set realistic expectations with providers.

To learn more, see our Introducing timeframes for transaction enrollments blog post.

Claim edit: Invalid place of service code

Stedi now rejects 837P professional and 837D dental claims that contain invalid place of service codes.

How the edit works

Place of service codes are two-digit codes that indicate where a service was delivered. The Centers for Medicare and Medicaid Services (CMS) maintains a list of valid place of service codes. For example: 11 (Office) or 23 (Emergency Room – Hospital).

If a professional or dental claim includes an invalid place of service code, the payer may reject the claim. This can delay payment for the provider.

This edit – the industry term for an automated validation rule – catches the issue before the claim reaches the payer.

Rejection errors

If you submit a claim that fails the edit using Stedi’s Claim Submission API endpoints, you’ll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Place of Service code. The submitted place of service code, A5, is invalid. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7>249*[DATE]*U*[AMOUNT]********Invalid Place of Service code. The place of service code, A5, is not a valid two-digit number or is unassigned. Correct and resubmit.~

Introducing instant enrollment for test ERAs

Electronic Remittance Advice (ERA) enrollments for the Stedi Test Payer (Payer ID: STEDITEST) now go live automatically.

You can submit claims to the Stedi Test Payer to generate realistic ERAs as part of a test workflow. To receive these test ERAs, you must first submit an ERA enrollment request for the Stedi Test Payer.

Previously, these enrollments only went live after an ERA was generated, which required submitting a claim before enrollment was active.

Now, ERA enrollments for the test payer move to the LIVE enrollment status about a minute after you submit the enrollment request.

Batch eligibility CSVs now support MBI lookups

You can now run Medicare Beneficiary Identifier (MBI) lookups – with or without a Social Security Number (SSN) – using a CSV batch eligibility check.

Previously, batch eligibility CSVs didn't support some address or SSN fields required for MBI lookups. We've now added several new supported fields to batch eligibility CSVs.

New fields for batch eligibility CSVs

With this update, batch CSVs now support the following fields.

Provider:

• providerReferenceIdentification

Subscriber:

• subscriberSsn

• subscriberGender

• subscriberSuffix

• subscriberAddress1

• subscriberAddress2

• subscriberCity

• subscriberAddressState

• subscriberPostalCode

Dependent:

• dependentMiddleName

• dependentSsn

• dependentGender

• dependentSuffix

• dependentAddress1

• dependentAddress2

• dependentCity

• dependentAddressState

• dependentPostalCode

For more information, see our batch eligibility docs.

Required fields for MBI lookups

With Stedi, you run MBI lookups as eligibility checks with the respective MBILU (MBI Lookup with SSN) or MBILUNOSSN (MBI Lookup without SSN) payer IDs. You can now run these checks using batch eligibility CSVs.

Note: MBI lookups require setup through transaction enrollment. See our related documentation.

MBI lookup with an SSN

To run an MBI lookup with an SSN, you must provide:

• The patient’s first name – subscriberFirstName or dependentFirstName

• The patient’s last name – subscriberLastName or dependentLastName

• The patient’s date of birth  – subscriberDateOfBirth or dependentDateOfBirth

• The patient’s Social Security Number (SSN) – subscriberSsn or dependentSsn

MBI lookup without an SSN

To run an MBI lookup without an SSN, you must provide:

• The patient’s first name – subscriberFirstName or dependentFirstName

• The patient’s last name – subscriberLastName or dependentLastName

• The patient’s date of birth  – subscriberDateOfBirth or dependentDateOfBirth

• The patient’s U.S. state – subscriberAddressState or dependentAddressState

What to include in MBI lookups

In an eligibility check, the patient may be the subscriber or a dependent. Generally, if the dependent has their own member ID, we recommend providing their information as a subscriber.

We don't recommend including more patient demographic information, such as additional address data, than what's required. Doing so can lower MBI lookup success rates.

For more information, see our MBI lookup docs.

Claim edit: Missing subscriber address or demographics

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims when the subscriber address or demographics are missing and the subscriber is the patient.

Subscribers and patients

In healthcare claims, the subscriber is the person who carries the insurance policy. They’re also called the insured or the primary policyholder.

The subscriber may be different from the patient – the person who receives care – or they may be the same person.

In healthcare claims, a person’s demographics are their date of birth and gender.

When the subscriber address and demographics are required

HIPAA-mandated X12 states that the subscriber’s address and demographics are required when the subscriber is the patient. Payers will use this information to verify the patient’s eligibility. If you submit a claim without this information, the payer may reject the claim, which can delay payment to the provider.

This edit – the industry term for an automated validation rule – catches the issue before the claim reaches the payer.

Note: If the subscriber is not the patient, the subscriber’s address and demographics are optional. 

Rejection errors

If you submit a claim that fails the edit using Stedi’s Claim Submission API, you’ll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Missing subscriber address and/or demographics. When the patient is the subscriber (SBR02 = 18), the subscriber address and demographics are required. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A6>173*[DATE]*U*[AMOUNT]********Missing subscriber address and/or demographics. When the patient is the subscriber (SBR02 = 18), the subscriber address and demographics are required. Correct and resubmit.~

Introducing sorting for the List Enrollments API

You can now control how enrollment records are ordered in List Enrollments API responses using the sortBy query parameter.

Previously, List Enrollments API results were always ordered by createdAt in descending order. That remains the default.

With the new sortBy query parameter, you can now also sort by other fields and set a stable fallback when values are the same. For example, you can sort by statusLastUpdatedAt and fall back to id to ensure consistent, deterministic ordering:

https://enrollments.us.stedi.com/2024-09-01/enrollments?sortBy=statusLastUpdatedAt:desc&sortBy=id:asc

How the sorting works

Each sortBy value uses the property:direction format. If you provide multiple sortBy values, results are sorted in the order they appear.

When you provide a single sortBy value, Stedi automatically adds id as a secondary sort in the same direction. For example, if you provide ?sortBy=updatedAt:desc, Stedi automatically adds id:desc to the query to ensure deterministic results.

To see available sortBy properties, check out our API reference documentation.

Introducing warnings for missing member IDs in eligibility checks

You’ll now get a clear warning in eligibility responses when a required member ID is missing.

Why some payers require member IDs

For eligibility checks, payers can only return coverage when the patient information in the check matches exactly one member in the payer system. To enforce this, many payers require that checks include the patient’s member ID.

When the member ID is required but missing, the payer returns a AAA error, such as 72 (Invalid/Missing Subscriber/Insured ID). These errors are generic and don’t specifically indicate the payer requires a member ID.

Stedi’s new missing member ID warning

Stedi’s new warning indicates the payer requires a member ID for patients in eligibility checks, based on Stedi’s curated sources.

The warning is returned in the warnings array, alongside the AAA error, for eligibility responses from the following endpoints:

• Legacy Real-Time Eligibility Check JSON

• Real-Time Eligibility Check Raw X12

• Poll Batch Eligibility Checks

For example, the following warning indicates the payer requires the patient’s member ID:

{
  "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",
      ...
    }
  ],
  ...
}

The warning is also shown for eligibility responses in the Stedi portal.

Eligibility check requirements vary by payer. If Stedi doesn't know if a payer requires a member ID for eligibility checks, no warning is returned.

For more tips and details, check out Stedi’s Eligibility troubleshooting docs.

Claim edit: ZIP or postal code required for U.S. and Canada addresses

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include a U.S. or Canadian address without a ZIP or postal code.

X12 states that when an address is in the United States or Canada, a ZIP or postal code is required. If it isn’t, the payer may reject the claim, which can delay payment to the provider.

This edit – the industry term for an automated validation rule – catches the issue before the claim reaches the payer.

Rejection errors

If you submit a claim that fails the edit using Stedi’s JSON or X12 Claim Submission API endpoints, you’ll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Postal Code(s). For U.S. addresses, a postal code must also be included. The postal code is missing for the following address fields: Billing Provider. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, entity identifier code, and error message:

STC*A6>500>HK*[DATE]*U*[AMOUNT]********Missing Postal Code(s). For U.S. and Canadian addresses, a postal code must also be included. The postal code is missing for the following address fields: [Subscriber]. Correct and resubmit.~

Addresses outside the U.S. and Canada

If an address is not in the U.S. or Canada, ensure the claim includes the correct country code for the address.

For example, for an 837P professional claim’s billing provider’s address, you can use the billing.address.countryCode field in JSON 837P Professional Claims API endpoint.

Introducing longer retry windows for batch CSV eligibility checks

You can now control how long Stedi retries checks that failed due to payer connectivity issues when submitting batch checks using a CSV upload in the Stedi portal.

When creating a new CSV batch from the portal’s Batch eligibility checks page, click Advance options to set the Retry duration.

Retry windows can be set from 8 to 24 hours. The default is 8 hours.

For details on how retries for batch eligibility checks work, see our Batch eligibility check docs.

Claim edit: Invalid patient control number

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain a patient control number (PCN) longer than 20 characters.

What is a patient control number?

A patient control number (PCN) is a tracking ID for a claim.

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

How the edit works

HIPAA-mandated X12 states that PCNs can be up to 20 characters. If you submit a claim with a PCN longer than 20 characters, the payer may reject the claim, which can delay payment to the provider.

This edit – the industry term for an automated validation rule – catches the issue before the claim reaches the payer.

Rejection errors

If you submit a claim that fails the edit using Stedi’s JSON or X12 Claim Submission API endpoints, you’ll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Patient Control Number. The submitted patient control number, 123456789012345678901234567890, exceeds the maximum allowed length of 20 characters. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A7>21*[DATE]*U*[AMOUNT]********Invalid Patient Control Number. The submitted patient control number, 123456789012345678901234567890, exceeds the maximum allowed length of 20 characters. Correct and resubmit.~

Resolution tips

Follow these best practices when creating PCNs:

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

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

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

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

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

Filter eligibility checks by NPI in the Stedi portal

You can now filter eligibility checks – grouped as eligibility searches – by NPI on the Eligibility searches page in the Stedi portal.

A National Provider Identifier (NPI) is a unique 10-digit ID assigned to every U.S. healthcare provider by the Centers for Medicare & Medicaid Services (CMS). This filter lets you view eligibility checks associated with a specific provider.

Introducing API endpoints for enrollment documents

You can now programmatically upload, download, and delete documents for transaction enrollment requests using Stedi’s new Transaction Enrollment API endpoints:

• Upload Enrollment Document

• Download Enrollment Document

• Delete Enrollment Document

Only PDF documents are supported.

What is transaction enrollment?

Transaction enrollment is the process of registering a provider to exchange a specific type of healthcare transaction with a payer.

Transaction enrollment is always required for Electronic Remittance Advice (ERAs). For other transaction types, like eligibility checks and claim submissions, enrollment requirements vary by payer.

Stedi offers fully managed, API-based transaction enrollment. You can submit and track enrollment requests using Stedi’s Transaction Enrollment API or the Stedi portal, which also supports bulk CSV imports.

When possible, Stedi handles all enrollment paperwork for you and your provider. When we can’t, we give you updates and clear next steps for what’s needed next.

What are enrollment documents?

Enrollment requirements vary by payer. Some payers require additional documents, such as:

• A form with a wet signature

• A practice W-9

• A voided check

In these cases, Stedi updates the enrollment status to PROVIDER_ACTION_REQUIRED and notifies the submitter by email. You can then view next steps and upload the required documents through the Stedi portal or API.

Upload an enrollment document

Previously, you could only upload enrollment documents using the Stedi portal. Now, you can also upload them programmatically using the Upload Enrollment Document endpoint:

1. Call the Upload Enrollment Document endpoint with the enrollment ID for the enrollment request.

   The enrollment ID is returned in the responses for the Create Enrollment and List Enrollments endpoints. It's also listed at the top of the enrollment's details page in the Stedi portal.

   Include the PDF’s file name, including the .pdf file extension, in the request body’s name field:

   curl --request POST \
     --url "https://enrollments.us.stedi.com/2024-09-01/enrollments/{enrollmentId}/documents" \
     --header "Authorization: <api_key>" \
     --header "Content-Type: application/json" \
     --data '{
       "name": "provider-license.pdf"
     }'

   The endpoint returns a pre-signed URL for uploading the PDF. The URL expires in 24 hours.

   {
     "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=...",
     "documentId": "doc-123e4567-e89b-12d3-a456-426614174000"
   }

2. Make a PUT request to the pre-signed URL to upload the PDF. Set the Content-Type HTTP request header to application/pdf.

   curl --request PUT \
   --url "<uploadUrl>" \
   --header "Content-Type: application/pdf" \
   --upload-file /path/to/provider-license.pdf

   Uploaded documents are listed on the enrollment's details page in the Stedi portal.

   

Download and delete enrollment documents

In addition to uploading, you can also download and delete previously uploaded documents using the respective Download Enrollment Document and Delete Enrollment Document endpoints.

Get started

Stedi’s Transaction Enrollment API, including the new enrollment document endpoints, is available on Stedi production accounts.

For complete details, check out our API reference documentation.

Stedi now blocks claim attachments for unsupported payers

If you try to submit a claim with electronic attachments to a payer who doesn't support them, Stedi now blocks the request before it reaches the payer. This affects 837P professional, 837D dental, and 837I institutional claims.

Electronic claim attachments let you send supporting documents – like X-rays and medical records – alongside claims in Stedi. Stedi lets you submit claims and claim attachments electronically using JSON API, X12 API, or SFTP.

However, not every payer supports electronic claim attachments. Previously, if you submitted an attachment to a payer who didn’t support them, the payer would reject the attachment as an error downstream. This could delay payment for the provider.

Now, Stedi checks payer support upfront and catches the issue before the claim reaches the payer. That means faster turnaround times for errors – and faster payments for providers.

Errors

If you submit a claim with attachments to an unsupported payer using Stedi's JSON or X12 Claim Submission APIs, you'll receive an error response with a 400 Bad Request HTTP status code and an error message:

{
  "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."
}

If you submit a claim with attachments to an unsupported payer using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment:

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.~

Check payer support

To avoid errors, check whether a payer supports electronic claim attachments using the Stedi Payer Network site or Stedi’s Payers API.

For example, in a Search Payers API response:

{
  "items": [
    {
      "payer": {
        "stediId": "HGJLR",
        "displayName": "Cigna",
        "primaryPayerId": "62308",
        "transactionSupport": {
          "unsolicitedClaimAttachment": "NOT_SUPPORTED", // Electronic claim attachments not supported
          ...
        },
        ...
      },
      ...
    },
    ...
  ]
}

Stedi's CMS-1500 form now autocompletes patient addresses

When you submit an 837P professional claims using the Stedi portal’s CMS-1500 form, Stedi now autocompletes patient addresses entered in Box 5 - Patient address.