Changelog

Claim edit: Missing admission source code

Stedi now rejects 837I institutional claims that are missing a required admission source code.

In an institutional claim, 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 this code. Without it, the payer can’t adjudicate the claim. The one exception is non-patient lab services, where no patient is present.

If the code is missing when required, the payer may reject the claim, which can cause payment delays.

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

**When this edit applies
**An institutional claim will fail this edit in the following cases:

**Rejection errors
**If you submit a claim that fails the edit using Stedi’s institutional claim submission API endpoints, you’ll get back an error message in real time. If you’re using the JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Missing admission source code. This code is required on all institutional claims with the exception of non-patient laboratory claims (Type of Bill 014x). 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Automatically add support users for Stedi apps

Stedi app developers can now configure their apps to automatically add one or more support users – called members – to accounts that install their app. 

App developers can use the support users to provide support or help with implementation.

This new feature is optional. The support user has the Developer role.

**What is a Stedi app?
**A Stedi app is a prebuilt integration between Stedi and a third-party platform. 

Stedi accounts can install Stedi apps to quickly connect their account to a third-party Revenue Cycle Management (RCM) system, Practice Management System (PMS), Electronic Health Record (EHR) platform, or other Stedi Platform Partners

For example, a practice or provider can install a Stedi app to connect their Stedi account to their EHR.

Get started with Stedi apps
To discuss publishing or configuring a Stedi app, contact us. You can also check out Publish your app in our developer docs.

To install a Stedi app, log in the Stedi portal and go to the Apps page. You can also check out our related docs.

Blue Cross Blue Shield of Kansas City is now one-click enrollment

Blue Cross Blue Shield of Kansas City (Payer ID: 47171) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

**What is transaction enrollment?
**Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollments for ERAs.

You can submit and track enrollments using Stedi's transaction enrollment API, the Stedi portal, or a bulk CSV.

One-click enrollment
Enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

If a payer supports one-click enrollment, you only need to submit the enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer requires enrollment – and supports one-click enrollment – for ERAs and other transaction types using the Stedi Payer Network or the Payer APIs.

For details, see our transaction enrollment docs.

Blue Cross Blue Shield of Kansas is now one-click enrollment

Blue Cross Blue Shield of Kansas (Payer ID: 47163) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

**What is transaction enrollment?
**Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollments for ERAs.

You can submit and track enrollments using Stedi's transaction enrollment API, the Stedi portal, or a bulk CSV.

One-click enrollment
Enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

If a payer supports one-click enrollment, you only need to submit the enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer requires enrollment – and supports one-click enrollment – for ERAs and other transaction types using the Stedi Payer Network or the Payer APIs.

For details, see our transaction enrollment docs.

Claim edit: Invalid date of birth

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain an invalid date of birth.

In a claim, you must provide a date of birth for the patient. If the subscriber is a different person, you must also provide the date of birth for the subscriber – the person who carries the insurance policy.

Payers use dates of birth to distinguish between members with similar names. If you provide an invalid date of birth for the patient or subscriber, the payer may reject the claim, which can cause payment delays.

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

**When this edit applies
**A claim will fail this edit when the patient or subscriber’s provided date of birth:

  • Occurs after the claim’s transaction date. – the date the claim is submitted. Providers always submit claims after care is provided. Logically, the date of birth can’t occur after the date the claim is submitted.

    If you’re using Stedi’s JSON claim submission APIs or professional claim form, this is the date you submit the claim to Stedi.  In X12 claims, this date is in segment BHT-04 (Transaction Set Creation Date).

    OR

  • Indicates an age of 150 years or older

**Rejection errors
**If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The subscriber date of birth, 18001231, 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"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Dentaquest - Individual is now one-click enrollment

Dentaquest - Individual (Payer ID: CX014) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

**What is transaction enrollment?
**Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollments for ERAs.

You can submit and track enrollments using Stedi's transaction enrollment API, the Stedi portal, or a bulk CSV.

One-click enrollment
Enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

If a payer supports one-click enrollment, you only need to submit the enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer requires enrollment – and supports one-click enrollment – for ERAs and other transaction types using the Stedi Payer Network or the Payer APIs.

For details, see our transaction enrollment docs.

Highmark Blue Cross Blue Shield of Western New York is now one-click enrollment

Highmark Blue Cross Blue Shield of Western New York (Payer ID: 100948) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

**What is transaction enrollment?
**Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollments for ERAs.

You can submit and track enrollments using Stedi's transaction enrollment API, the Stedi portal, or a bulk CSV.

One-click enrollment
Enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

If a payer supports one-click enrollment, you only need to submit the enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer requires enrollment – and supports one-click enrollment – for ERAs and other transaction types using the Stedi Payer Network or the Payer APIs.

For details, see our transaction enrollment docs.

Highmark Western and Northeastern New York is now one-click enrollment

Highmark Western and Northeastern New York (Payer ID: 55204) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

**What is transaction enrollment?
**Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollments for ERAs.

You can submit and track enrollments using Stedi's transaction enrollment API, the Stedi portal, or a bulk CSV.

One-click enrollment
Enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

If a payer supports one-click enrollment, you only need to submit the enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer requires enrollment – and supports one-click enrollment – for ERAs and other transaction types using the Stedi Payer Network or the Payer APIs.

For details, see our transaction enrollment docs.

Priority Health is now one-click enrollment

Priority Health (Payer ID: PRHTH) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

**What is transaction enrollment?
**Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollments for ERAs.

You can submit and track enrollments using Stedi's transaction enrollment API, the Stedi portal, or a bulk CSV.

One-click enrollment
Enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

If a payer supports one-click enrollment, you only need to submit the enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer requires enrollment – and supports one-click enrollment – for ERAs and other transaction types using the Stedi Payer Network or the Payer APIs.

For details, see our transaction enrollment docs.

Quartz is now one-click enrollment

Healthcare payer Quartz (Payer ID: 39180) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

**What is transaction enrollment?
**Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollments for ERAs.

You can submit and track enrollments using Stedi's transaction enrollment API, the Stedi portal, or a bulk CSV.

One-click enrollment
Enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

If a payer supports one-click enrollment, you only need to submit the enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer requires enrollment – and supports one-click enrollment – for ERAs and other transaction types using the Stedi Payer Network or the Payer APIs.

For details, see our transaction enrollment docs.