Changelog

Developers and operations teams can now submit enrollments one at a time or in batches through Stedi’s user-friendly Enrollments dashboard or modern Transaction Enrollment API. 

Both submission methods follow the same streamlined process:

1. Add provider: You add a new provider record with the information required for enrollment, including the provider's name, tax ID, NPI, and contact information.

2. Submit transaction enrollment request: You submit requests to enroll the provider with required payers, one for each transaction type. For example, you’d submit three separate requests to enroll a provider for 837P (professional) claims, 270 real-time eligibility checks, and 835 ERAs (claim payments). You can save requests in DRAFT status until you're ready to submit them to Stedi. Once you submit an enrollment request, its status is set to SUBMITTED, and it enters Stedi’s queue for processing.

3. Provisioning: Stedi begins the enrollment process with the payer and sets the enrollment status to PROVISIONING. Our team leaves clear instructions about what to do next, if required, and provides hands-on help as needed with additional steps.

4. Enrollment is Live: Once the enrollment is approved, the enrollment status is set to LIVE, and the provider can start exchanging the enrolled transactions with the payer.

You can find out if a payer requires enrollment for a particular transaction type in the Stedi Payer Network.

You can use Stedi’s new Dental Claims API to send 837D (dental) claims through the Stedi Clearinghouse:

• Dental Claims: Submit your claim in user-friendly JSON. Stedi translates your request to the X12 EDI 837D format and sends it to the payer.

• Dental Claims Raw X12: Submit your claim in X12 EDI format. This is ideal if you have an existing system that generates X12 EDI files and you want to send them through Stedi’s API.

Both endpoints return a response from Stedi in JSON format containing information about the claim you submitted and whether the submission was successful. Later, the payer will respond with Claim Acknowledgments (277CA) and the ERA (835), which you can retrieve using Stedi’s APIs.

Visit the Stedi Payer Network to find every supported payer for dental claims.

You can now use Stedi’s Batch Eligibility Check API to submit multiple eligibility checks in a single request for Stedi to process asynchronously.

You can submit up to 500 individual eligibility checks within a single batch, and you can submit as many batches as you need to process. After you’ve submitted a batch of eligibility checks, you can use the Poll Batch Eligibility Checks endpoint to retrieve the results.

We recommend using this new API to perform batches of eligibility checks, such as during periodic refreshes for a patient population or when running weekly eligibility checks for upcoming appointments. Asynchronous batch checks don’t count toward your Stedi account concurrency budget, allowing you to stage thousands of batch checks while continuing to send real-time eligibility checks in parallel.

You can use the new Institutional Claims API to send 837I institutional claims through the Stedi clearinghouse.

• Call the endpoint with a JSON payload.

• Stedi translates your request to the X12 EDI 837I format and sends it to the payer.

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

• Later, the payer will respond with Claim Acknowledgments (277CA) and the ERA (835), which you can retrieve using Stedi’s APIs.

You can now submit five new mock requests for dental benefits to the Eligibility Check endpoint, and Stedi returns mock eligibility responses you can use for testing. To send a mock request, you need a Stedi API key for authentication, and you must set the stedi-test header to true.

Try it now for Ameritas, Anthem Blue Cross Blue Shield of CA, Cigna, Metlife, and UnitedHealthcare.

Use the new List Payers API to programmatically retrieve information about thousands of supported payers in our Payer Network. 

The following Blue Cross Blue Shield of North Carolina response example shows that real-time eligibility checks, real-time claim status requests, and professional claims are supported for this payer. The response also indicates that payer enrollment is required for 835 ERAs (claim remittances).

{
  "stediId": "UPICO",
  "displayName": "Blue Cross Blue Shield of North Carolina",
  "primaryPayerId": "BCSNC",
  "aliases": [
    "1411",
    "560894904",
    "61473",
    "7472",
    "7814",
    "BCBS-NC",
    "BCSNC",
    "NCBCBS",
    "NCPNHP"
   ],
   "names": [
     "Blue Cross Blue Shield North Carolina"
   ],
   "transactionSupport": {
     "eligibilityCheck": "SUPPORTED",
     "claimStatus": "SUPPORTED",
     "claimSubmission": "SUPPORTED",
     "claimPayment": "ENROLLMENT_REQUIRED"
   }
}

We adapted the National Uniform Claim Committee (NUCC) 1500 Claim Form into a user-friendly digital form you can use to submit claims manually. 

Our in-app form validates provider NPIs and other key information to reduce errors and payer rejections. You can also review a live preview of the autogenerated JSON payload for our Professional Claims API to understand how the form relates to the request structure.

To submit a manual claim, visit the Create manual claim page in the Stedi app.

You can now use the CMS-1500 Claim Form PDF API to programmatically retrieve auto-generated claim forms for submitted 837 professional claims. All you need is an API Key for authentication and Stedi’s transaction ID for the processed claim. 

curl --request GET \
  --url https://healthcare.us.stedi.com/2024-04-01/export/{transactionId}/1500/pdf \
  --header 'Authorization: <api-key>'

You can use the API to make auto-generated claim form PDFs available for download within an EHR, practice management, or revenue cycle system. You can also automate retrieving them for internal use, such as record-keeping, mailing and faxing claims to payers, or reviewing claim information in a familiar format.

Stedi can now automatically generate and deliver negative TA1s for inbound transactions. TA1 Interchange Acknowledgments indicate receipt of an interchange and identify any errors in the interchange’s envelope (ISA and IEA) information.

Stedi can generate two types of negative TA1s:

• Accepted with errors: TA1s with code E in TA104 indicate that the interchange was accepted with errors. Stedi proceeds with processing the transaction and creates a record in the Stedi app

• Rejected because of errors: TA1s with code R in TA104 indicate that the interchange was rejected and that Stedi won’t continue processing the transaction.

You can enable automatic TA1s in each partnership’s Acknowledgments settings. Visit the Acknowledgments documentation for complete details. 

You can use the new List Payers API to programmatically retrieve information about every supported payer in our Payer Network. The response includes:

• The payer’s name, Payer ID, aliases, and alternative names.

• Whether the following transactions are supported: real-time eligibility checks, professional claims, real-time claim status requests, and ERAs (claim payments).

• Whether payer enrollment is required for each transaction type.

Stedi can now automatically generate positive TA1s for inbound transactions and deliver them to your trading partners. 

TA1 Interchange Acknowledgments indicate receipt of an interchange and identify any errors in the interchange’s envelope (`ISA` and `IEA`) information. Positive TA1s contain code `A` in the `TA104` element to indicate you received the interchange successfully, and it contains no errors.

Enable automatic TA1s for each partnership in the Acknowledgments settings. You can send TA1s for every inbound file or only when your trading partner requests them. Visit the Acknowledgments documentation for complete details. 

The transaction details page has the following improvements:

• For 837P (professional) claims, Stedi automatically puts key details, including subscriber information and the claim value, at the top for easy access. You can also instantly download a PDF of the autogenerated 1500 Claim Form. 

• Transactions with a common business identifier are clearly identified and linked, so you can easily move between related transactions.

• The transaction’s raw input and output are available for review and download. 

• Multiple other UX updates to make the transaction’s data easier to understand and digest.

You can review this information by clicking any transaction on the Transactions page in the Stedi app.

You can now use the following APIs to retrieve payer responses in JSON format:

• Get 277 Report: Retrieve processed 277 Claim Acknowledgments

• Get 835 Report: Retrieve processed 835 Electronic Remittance Advice (ERA) transactions

You can either poll or listen for event-driven webhooks to discover new payer responses. Then, you can call the Report APIs to retrieve the processed responses from Stedi. For convenience, Stedi returns 277s and 835s in the same JSON format as the Change Healthcare (CHC) Convert Reports APIs.

For every claim you submit through our Professional Claims APIs, Stedi now automatically generates a complete 1500 Claim Form. You can download these PDF claim forms from the transaction detail page for that claim in the Stedi app.

This feature is useful when you need to export claim forms for record-keeping purposes, physically mail a claim to a payer, or review specific claim information in a familiar format. 

You can now review a mapping’s version history, compare older versions with the current, and instantly roll back to any published version. This functionality helps you better understand the updates made in each version and debug issues in production mappings.

To review a mapping’s version history, go to the mapping, open the Actions menu, and select Version history. You can choose to publish an older version or compare it with the current version in production. Comparing highlights every difference between the old and current versions to show you what has been added or deleted.

The following APIs are now available for customers who want to send raw X12 EDI to payers. These APIs are ideal for companies that generate X12 EDI internally and want to use Stedi to validate and deliver these transactions to payers.

• Eligibility Check Raw X12: Send raw X12 EDI 270 Eligibility Benefit Inquiry transactions and receive the payer’s raw X12 EDI 271 Eligibility, Coverage, or Benefit Information in the response - all in real time.

• Professional Claims Raw X12: Send raw X12 EDI 837P (professional) Health Care Claims to payers.

• Claim Status Raw X12: Send raw X12 EDI 276 Claim Status requests and receive the payer’s raw X12 EDI 277 Status Request Response - all in real time.

You can now send eligibility checks to more than 200 dental payers through Stedi’s growing Payer Network. New dental payers include Guardian, Delta Dental, UHC Dental, Anthem Blue Cross Blue Shield, Pacificare Dental & Vision Plan, Aetna Dental, Cigna Dental, and more.

Search the Payer Network to instantly find the Payer ID for any payer and use it to start sending real-time eligibility checks through Stedi’s Eligibility Check API.

We redesigned the Stedi Payer Network to make it more comprehensive and user friendly. Improvements include:

• Enhanced searching and filtering capabilities so you can instantly find the payers you need for your use case.

• Alternative payer names to help you 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. 

• UX improvements, including clearly showing all of the transaction types supported for each payer as well as the Payer ID and any Payer ID aliases.

The Mappings UI now autosaves your changes and stages them for publishing. When you’re ready, you can promote changes to production by clicking Publish changes. You can also discard changes to revert back to the previously published version.

You can now submit mock requests to the Eligibility Check endpoint, and Stedi returns mock eligibility responses you can use for testing. To send a mock request, you need a Stedi API key for authentication, and you must set the stedi-test header to true.

Try it for Cigna.