Changelog

You can now get free production access to Stedi with the Basic plan.

The Basic plan is our new starter plan for customers who just need to manually process production transactions, such as claims and eligibility checks, in the Stedi portal. It’s great for providers and small practices who are processing a small number of transactions each month.

The Basic plan also allows customers to test API integrations using test API keys. Once they’re finished testing, these customers can upgrade to a Developer plan to send production transactions using real API keys.

For details, see the announcement blog.

We’ve expanded the Stedi Agent with two new conversational features:

• Payer Finder: Ask questions about payers using conversational AI

• Chats: A dedicated page for all your Stedi Agent conversations

You can use these tools to get answers to payer questions faster and easier.

For more information, see the announcement blog.

We’re replacing the SUBMITTED transaction enrollment status with two new statuses that show who needs to act next:

• STEDI_ACTION_REQUIRED – Stedi needs to take action.

• PROVIDER_ACTION_REQUIRED – You or the provider need to take action.

The SUBMITTED status is now deprecated. Any existing requests will keep the SUBMITTED status and use the previous status workflow until they're live, canceled, or rejected.

We've also clarified the PROVISIONING status to mean only thing: the request has been submitted to the payer.

These changes make it easier to see which requests need your attention. You can filter by the PROVIDER_ACTION_REQUIRED status in the Stedi portal or List Enrollments endpoint to see which requests require action by you or your provider. For example, using the endpoint:

https://enrollments.us.stedi.com/2024-09-01/enrollments?status=PROVIDER_ACTION_REQUIRED

How enrollment statuses work now

Requests submitted through the Stedi portal or a bulk CSV now start in the STEDI_ACTION_REQUIRED status. If you’re using the Create Enrollment endpoint, you can set the status to STEDI_ACTION_REQUIRED to start processing the enrollment.

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

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

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

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

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