Changelog

Introducing PDF tasks for transaction enrollments

You can now use Stedi's Transaction Enrollment API or the Stedi portal to download, complete, and upload PDF forms during transaction enrollment. Examples of these PDF forms include:

• Legal agreements with the payer.

• W-9 tax forms.

• Bank forms required for EFT enrollment. Some payers require EFT enrollment for ERAs.

If you're building an EHR, RCM, or practice management platform, you can now surface PDF enrollment forms directly in your UI and collect the completed PDFs from providers.

When are PDF enrollment tasks required?

Where possible, Stedi handles transaction enrollment paperwork for you. In many cases, you only need to submit a transaction enrollment request – no other action is needed on your part.

Some payers require providers – and no one else – to complete specific steps to finish enrollment. If these steps require filling out a PDF form, you can now use the Transaction Enrollment API or the Stedi portal to complete them.

Using the Transaction Enrollment API

This release introduces the new provideFilledPdf enrollment task type.

When you retrieve an enrollment using the Retrieve Enrollment API or List Enrollments API endpoints, provideFilledPdf tasks may appear in the tasks array of enrollment records.

Each provideFilledPdf task contains:

• A unique id for the task.

• A rank for the task – the order in which the task should be completed.

• The responsibleParty for completing the task.

• An isComplete status indicating whether the task is complete.

• instructions for filling out the PDF.

• A documentDownloadUrl for the PDF. This URL requires an API key for authentication.

An example object in an enrollment record’s tasks array:

{
  "id": "01937d50-9abc-7890-abcd-567890abcdef",
  "rank": 2,
  "responsibleParty": "PROVIDER",
  "isComplete": false,
  "definition": {
    "provideFilledPdf": {
      "instructions": "Please complete and sign the provider agreement.",
      "documentDownloadUrl": "https://enrollments.us.stedi.com/2024-09-01/documents/019375d0-9876-7890-abcd-567890fedcba/download"
    }
  }
}

How to complete a PDF task using the API

To complete a provideFilledPdf task using the Transaction Enrollment API, you’ll need the task’s id, instructions, and documentDownloadUrl. Follow these steps:

1. Make a GET request to the documentDownloadUrl. Pass your production Stedi API key in the Authorization header.

   curl -X GET "https://enrollments.us.stedi.com/2024-09-01/documents/{documentId}/download" \
     -H "Authorization: <api_key>"

   The response contains a pre-signed S3 downloadUrl.

   {
     "documentId": "019375d0-9876-7890-abcd-567890fedcba",
     "downloadUrl": "https://s3.amazonaws.com/enrollment-documents/...?X-Amz-Algorithm=AWS4-HMAC-SHA256&..."
   }

2. Download the PDF from the downloadUrl.

   curl -o form.pdf "<downloadUrl>"

3. Complete the downloaded PDF form. Follow any instructions from the PDF and the task’s instructions field. This step happens outside the API.

4. Call the Upload Enrollment Document API endpoint. In the request body, provide:

   • The task’s ID in the taskId field.

   • A name for the completed PDF in the name field. Include the .pdf file extension in the name. Store the name value. You’ll use it later.

   curl -X POST "https://enrollments.us.stedi.com/2024-09-01/enrollments/{enrollmentId}/documents" \
     -H "Authorization: <api_key>" \
     -H "Content-Type: application/json" \
     -d '{
       "taskId": "<task_id>",
       "name": "completed-provider-agreement.pdf"
     }'

   The response includes a documentId and pre-signed uploadUrl. The upload URL is valid for 24 hours.

   {
     "enrollmentId": "01936f2a-5678-7890-abcd-1234567890ab",
     "documentId": "019375d0-1234-7890-abcd-567890abcdef",
     "uploadUrl": "https://s3.amazonaws.com/enrollment-documents/...?X-Amz-Algorithm=AWS4-HMAC-SHA256&..."
   }

   Store the response’s documentId. You’ll use it later.

5. Use a PUT request to upload the attachment file to the uploadUrl. The request must include a Content-Type: application/pdf header.

   curl -X PUT "<uploadUrl>" \
     -H "Content-Type: application/pdf" \
     --upload-file /path/to/completed-provider-agreement.pdf

6. Use the Retrieve Enrollment API endpoint to poll the enrollment.

   curl -X GET "https://enrollments.us.stedi.com/2024-09-01/enrollments/{enrollmentId}" \
     -H "Authorization: <api_key>"

   The response contains the enrollment’s documents in the response’s documents array. You can track the status of the document using the documentId you stored earlier.

   {
     "documents": [
       {
         "id": "019375d0-1234-7890-abcd-567890abcdef", // Document Id
         "status": "UPLOADED",
         ...
       }
     ]
   }

   Immediately after upload, the document's status will initially be PENDING. Wait until the status is UPLOADED before continuing. This typically takes less than 10 seconds after upload.

7. Mark the task complete using the Update Enrollment Task API endpoint. In the request body’s responseData object, include:

   • The document ID in the documentId field

   • The uploaded PDF’s name in the name field

   curl -X POST "https://enrollments.us.stedi.com/2024-09-01/tasks/{taskId}" \
     -H "Authorization: <api_key>" \
     -H "Content-Type: application/json" \
     -d '{
       "completed": true,
       "responseData": {
         "documentId": "019375d0-1234-7890-abcd-567890abcdef",
         "name": "completed-provider-agreement.pdf"
       }
     }'

In the Stedi portal

PDF-related tasks assigned to the provider appear in the Tasks section at the top of the enrollment request's details page in the Stedi portal.

You can download, complete, and upload the pre-filled PDFs from this section.

Claim edit: Invalid claim frequency code and patient status code combination

Stedi now rejects 837I institutional claims that contain a conflicting claim frequency code and patient status code combination.

How the edit works

In an institutional claim, the claim frequency code tells the payer whether a claim is an original claim, a correction, or part of an ongoing stay.

Claim frequency code

The claim’s patient status code describes the patient's condition at the end of the claim’s billed period. It tells the payer whether the patient was discharged, transferred, or still admitted.

Patient status code

The claim frequency code and patient status code must be compatible. For example, if a claim uses a claim frequency code of 1 (Admit thru Discharge Claim) – meaning the patient’s stay is finished – the patient status code shouldn’t be 30 (Still a Patient), which means the patient is still in the facility.

If the claim frequency code and patient status code are conflicting, the payer may reject the claim. That rejection can delay payment to the provider.

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

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid combination of claim frequency and patient status. The submitted patient status code 30 indicates the patient is still admitted, which conflicts with the claim frequency code 1 indicating a final bill. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, entity identifier code, and error message:

STC*A7>535>QC*[DATE]*U*[AMOUNT]********Invalid combination of claim frequency and patient status. The submitted patient status code 30 indicates the patient is still admitted, which conflicts with the claim frequency code 1 indicating a final bill. Correct and resubmit.~

Claim edit: Invalid future dates

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain dates later than the claim’s transaction date.

How the edit works

Each claim includes a transaction date – the date the claim was submitted.

Providers always submit claims after care is provided. That means other dates in the claim, such as dates of service, statement periods, and accident dates, should always occur on or before the transaction date. Future dates indicate a data entry error.

If a claim contains a future date, the payer may reject the claim, which can delay payment for the provider.

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

Dates covered by this edit

This edit validates date fields at the claim and service line level, including but not limited to:

• Dates of service

• Accident dates

• Initial treatment dates

• Prescription dates

• Last seen dates

• Discharge dates

This edit does not apply to dates of birth. Stedi validates those separately with the invalid date of birth edit.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The submitted date(s) are invalid. The following dates cannot be later than the transaction date of 20260312: Service (20270101). Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, and error message:

STC*A8>510*[DATE]*U*[AMOUNT]******A7>727**The submitted date(s) are invalid. The following dates cannot be later than the transaction date of 20260312: Service (20270101). Correct and resubmit.~

Claim edit: Invalid NPI format

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain a National Provider Identifier (NPI) with an invalid format.

How the edit works

An NPI is a unique, 10-digit identifier assigned to every healthcare provider in the U.S.

HIPAA-adopted X12 standards require that all NPIs in a claim be 10 digits. If a claim includes an NPI that’s not 10 digits – such as an NPI that’s too short or too long – the payer may reject the claim. This can delay payment for the provider.

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

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid NPI. The Billing Provider NPI of 123456789 is invalid. The National Provider Identifier must be valid with 10 digits and no prefixes or dashes. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, entity identifier code, and error message:

STC*A7>562>85*[DATE]*U*[AMOUNT]******A7>569>85**Invalid NPI. The Billing Provider NPI of 123456789 is invalid. The National Provider Identifier must be valid with 10 digits and no prefixes or dashes. Correct and resubmit.~

Tip: How to handle 15-digit NPIs

Some official NPI documentation references a 15-digit NPI format that includes a 5-digit card issuer prefix. Omit this card issuer prefix when submitting claims.

Introducing branded signup links for Stedi apps

Stedi app developers can now share a co-branded Stedi signup link with their providers.

The link takes providers through a streamlined signup flow that creates an integrated account – a Stedi account that’s linked to your app.

The signup page is branded with your app's name and logo.

To get the signup link for your Stedi app, contact us in your Slack or Microsoft Teams channel. You can also email us or use our contact form.

Create a Stedi app

Stedi apps are prebuilt integrations between your system and Stedi. After you publish your app to the Stedi app directory, your providers can install the app from within their Stedi accounts.

To get started, check out our developer docs or contact us.

Claim edit: Invalid NDC format

Stedi now rejects 837P professional and 837I institutional claims that contain a National Drug Code (NDC) with an invalid format.

How the edit works

National Drug Codes (NDCs) are unique identifiers for drugs or biologics regulated by the U.S. Food and Drug Administration (FDA).

A provider can list an NDC in one or more service lines of a claim to get paid for drugs administered during care.

Payers use NDCs in claims to determine the correct reimbursement amount for these drugs or to apply drug rebates.

HIPAA-adopted X12 standards require that all NDCs in a claim be 11 digits. If a claim includes an NDC that’s not 11 digits – such as an NDC that’s too short or too long – the payer may reject the claim. This can delay payment for the provider.

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

Rejection errors

If you submit a claim that fails the edit using Stedi's Claim Submission API endpoints, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid National Drug Code (NDC). Service line 1 contains an invalid NDC value: 0002606351. NDCs must be 11-digits without any spaces or hyphens and valid per FDA records. 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 include a related claim status category code, claim status code, and error message:

STC*A7>218*[DATE]*U*[AMOUNT]********Invalid National Drug Code (NDC). Service line 1 contains an invalid NDC value: 0002606351. NDCs must be 11-digits without any spaces or hyphens and valid per FDA records. Correct and resubmit.~

Tip: How to handle 10-digit NDCs

The FDA has previously published 10-digit NDCs. X12 standards still require these NDCs to be 11 digits in claims.

Regardless of length, all NDCs have three segments: a labeler, a product, and a package code. In 11-digit NDCs, these segments must be 5, 4, and 2 digits respectively.

To convert a 10-digit NDC to an 11-digit NDC, add a leading zero to whichever segment is short.

Introducing eligibility check PDFs

You can now download a PDF version of your eligibility checks using the Stedi portal or our new Retrieve Eligibility PDF API endpoint.

Eligibility check PDFs are designed to be easy to read, print, and upload to other systems. Their layout mirrors the Stedi portal's eligibility benefits table.

Download a sample PDF.

For details, see our announcement blog.

Claim edit: Invalid Social Security Number

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain an invalid Social Security Number (SSN).

How the edit works

SSNs can only contain 9 digits. If a claim contains an invalid SSN – one longer or shorter than 9 digits – the payer may reject the claim, which can delay payment for the provider.

This edit – the industry term for an automated validation rule – catches invalid SSNs before the claim reaches the payer.

Rejection errors

If you submit a claim that fails the edit using Stedi's Claim Submission API endpoints, you'll get back an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Social Security Number. The submitted social security number does not meet the required format of 9 digits with no separators. 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 include a related claim status category code, claim status code, entity identifier code, and error message:

STC*A7>148>HK*[DATE]*U*[AMOUNT]********Invalid Social Security Number. The submitted social security number does not meet the required format of 9 digits with no separators. Correct and resubmit.~

Introducing automatic transaction enrollment requests for Highmark payers

Stedi now supports automatic transaction enrollment requests for eligibility checks with the following payers:

• Highmark of Pennsylvania (Payer ID: 54771)

• Highmark Senior Health Company (Payer ID: 15460)

• Highmark Blue Cross Blue Shield of Delaware (Payer ID: 030)

• Highmark Blue Cross Blue Shield of West Virginia (Payer ID: 54828)

These payers require you to complete transaction enrollment for the provider to run eligibility checks.

If Stedi receives an AAA error indicating the provider isn't enrolled with the payer, we now automatically create an enrollment request.

Once the enrollment is live, the provider can successfully run eligibility checks with that payer.

You can track and manage these enrollment requests using Stedi's Enrollments API or the Stedi portal.

For more details, check out our Transaction enrollment docs.

Introducing automatic transaction enrollment requests for MBI lookups with SSN

Stedi now supports automatic transaction enrollment requests for MBI lookups with a Social Security Number (SSN).

What’s an MBI lookup?

A Medicare Beneficiary Identifier (MBI) is a unique ID for a Medicare beneficiary.

You need an MBI to run Medicare eligibility checks.

If you don’t have the patient’s MBI, you can get it using an MBI lookup with the patient’s demographic details and, optionally, their SSN.

What’s changing

To run MBI lookups with an SSN, you must complete transaction enrollment for the provider with the MBILU payer.

If Stedi receives an AAA error indicating the provider isn't enrolled with the payer, we now automatically create an enrollment request.

You can track and manage these enrollment requests using Stedi's Enrollments API or the Stedi portal.

Note: Automatic enrollment requests are not yet supported for the MBILUNOSSN (MBI lookup without SSN) payer.

For more details, check out our Transaction enrollment docs.