You now get back a realistic mock 835 Electronic Remittance Advice (ERA) for claims submitted to Stedi’s test payer.
The mock ERAs mirror the type of electronic remittance you’d receive from payers in production. Each ERA contains the same information as if the test claim were paid in full.
For details, check out our announcement blog.
You can now tell which payers support vision coverage using the Stedi Payer Network or the Payers API.
For more details, see our announcement blog.
You can now submit claims as X12 EDI in the Stedi portal. Professional, dental, and institutional claims are supported. Previously, you could only submit claims as X12 using our X12 Claims API or SFTP.
For more information, see our announcement blog.
We’ve redesigned the benefits table for eligibility responses in the Stedi portal to make it faster and easier to read a patient’s benefits.
Benefits are now grouped by health plan. Each plan begins with its general limitations, followed by benefit details. The benefit details are organized by the Service Type Codes (STCs) and procedure codes from the payer’s response.
If present, benefits for STC 30 (Health Benefit Plan Coverage) and STC 35 (Dental Care) – the baseline STCs for medical and dental care – appear first.
The table displays information from the benefitsInformation objects in Stedi’s JSON Eligibility API responses.
Filter benefits
You can filter the table to quickly find benefits for a specific service, procedure, or coverage type – like a deductible or limitation. You can also filter by overage level and whether the benefit applies to in-network or out-of-network services.
For example, you can filter the table to only show individual deductibles for STC 3 (Consultation).
The table displays information from the benefitsInformation objects in Stedi’s JSON Eligibility API responses.
For more information, see our announcement blog.
The Batch Eligibility Check API endpoint now supports up to 10,000 eligibility checks in a single request. Previously, the limit was 1,000 checks per request.
For more information, see our announcement blog.
Required fields are marked with a red asterisk. For example, in the form, the insured's First and Last name is required.
The Stedi Payer Network now displays logos for select payers.
The Payer Network is Stedi's online payer list. The site lets you browse and search Stedi's supported payers for payer IDs, supported transaction types, and transaction enrollment requirements.
Logos make it easier to confirm you’ve found the right payer while browsing or searching.
The payer’s logo also appears on its detail page.
**Logos in the Payers API
**Stedi’s Payers API now returns the URL for a payer’s logo, when available. You can use the URLs to fetch payer logos for use in your own applications and interfaces.
The logo URL appears in the payer.avatarUrl field of the API response. The field is available for the Search Payer, List Payer, and Retrieve Payer endpoints.
Example:
{
"payer": {
"displayName": "Cigna",
"primaryPayerId": "62308",
"avatarUrl": "https://prod-payer-avatars.payers.us.stedi.com/HGJLR/avatar.png?v=1761841671464",
...
}We’ve redesigned the professional claim form in the Stedi portal to make it faster and easier to manually submit 837P professional claims.
The new layout mirrors the CMS-1500 (NUCC) Health Insurance Claim Form, the standard paper form for professional claims in the healthcare industry. If you’ve filled out a CMS-1500 before, the new form will look familiar.
To access the form, sign in to your Stedi account and go to https://portal.stedi.com/app/healthcare/claims/create. You can also open the form from the Stedi portal by going to Claims> Submit claim.
For more details, see our 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_REQUIREDHow 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.