Changelog

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.

Claim edit: Invalid drug unit count

Stedi now rejects 837P professional and 837I institutional claims that bill for a drug or biologic without a valid unit count.

In professional and institutional claims, you bill for drugs or biologics by adding information about the drug to a service line, specifying what drug was administered and how much.

The line’s unit of measurement code – such as F2 (International Unit) or GR (Gram) – shows how the drug was measured. The line’s unit count reports the quantity administered in that measure.

Payers use the measurement code and unit count to verify dosage and pricing. Without a valid unit count, they can’t confirm the billed amount and may reject the claim, which can delay payment.

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

When this edit applies
A professional or institutional claim will fail this edit in the following cases:

• JSON API
  If you’re using one of Stedi’s JSON claim submission API endpoints, the edit fails if:

  • A service line contains a drugIdentification.measurementUnitCode value.
    AND

  • The service line’s drugIdentification.nationalDrugUnitCount field is less than or equal to ”0”.

• Raw X12
  If you’re using raw X12, the edit fails if:

  • Loop 2410 (Drug Identification) is present
    AND

  • The CTP-05 (Composite Unit of Measure) of Loop 2410 contains a value.
    AND

  • The CTP-04 (National Drug Unit Count)  of Loop 2410  is less than or equal to 0.

• Stedi portal
  If you’re using the Stedi portal’s professional claim form, the edit fails if:

  • Box 24 – Service Lines contains a service line with a Unit/Basis of measurement value and a Quantity less than or equal to zero.

    

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": "Invalid drug unit count. When reporting a drug unit qualifier, the drug count must be greater than zero (0.0). 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.

Claim edit: Missing accident date

Stedi now rejects 837P professional and 837D dental claims that relate to an auto or other accident but don’t include an accident date.

When you submit a professional or dental claim, you can indicate that the patient’s condition is related to an accident using a related causes code. Valid codes are AA (Auto accident), EM (Employment), and OA (Other accident).

If you provide a related causes code of AA or OA, payers also require an accident date – the date the injury occurred. Payers use this date to determine liability, coordinate benefits with other payers, and correctly adjudicate the claim.

If you don’t include the accident date in these cases, the payer may reject the claim, which can delay payment.

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

When this edit applies
A professional or dental claim will fail this edit in the following cases:

• JSON API
  If you’re using one of Stedi’s JSON claim submission API endpoints, the edit fails if:

  • The claimInformation.relatedCausesCode array contains AA (Auto accident) or OA (Other accident).
    AND

  • The claimInformation.claimDateInformation.accidentDate field is empty or missing.

• Raw X12
  If you’re using raw X12, the edit fails if:

  • The CLM11-1 (Related Causes Code)  or CLM11-2 (Related Causes Code) of Loop 2300 (Claim Information) contains AA (Auto accident) or OA (Other accident).
    AND

  • The DTP-03 (Accident Date) of Loop 2300 is empty or missing.

• Stedi portal
  If you’re using the Stedi portal’s professional claim form, the edit fails if:

  • The Auto accident? or Other? field of Box 11 – Is patient's condition related to is Yes.

  • Box 15 – Other Date does not contain a Date with a Qualifier of 439 (Accident)

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 Accident Date is missing. This date is required when the claim is marked as accident-related, Auto Accident, in Related Causes Code. 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.

Claim edit: Invalid revenue code

Stedi now rejects 837I institutional claims that contain an invalid service line revenue code.

Revenue codes are standardized, 4-digit codes that hospitals and other care facilities use to identify the type of room, service, or supply billed on a service line. Example revenue codes include:

• 0450 – Emergency Room

• 0360 – Operating Room Services

• 0300 – Laboratory

Revenue codes are different from procedure codes, such as CPT or HCPCS codes. A procedure code describes what kind of care was delivered. A revenue code describes the type of facility associated with the charge.

Revenue codes are maintained by the National Uniform Billing Committee (NUBC). They are always 4 digits and start with a 0, 1, 2, or 3.

Revenue codes often drive how payers price and reimburse institutional claims. If a claim includes an invalid revenue code, the payers may reject the claim, which can delay payment.

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

When this edit applies
An institutional claim fails this edit if a service line revenue code:

• Is not exactly 4 digits

• Does not start with a 0, 1, 2, or 3

If you're using Stedi’s JSON institutional claim submission endpoint, you provide the revenue code in the serviceLineRevenueCode field for the service line.

In raw X12, you provide the revenue code for a service line in SV2-01 (Service Line Revenue Code) of Loop 2400 (Service Line Number).

Rejection errors
If you submit an institutional 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": "The Revenue Code value does not match the required format. Revenue codes must be 4 digits and have a valid leading digit of 0, 1, 2, or 3. Please review and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit an institutional 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.