Changelog

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain an invalid phone number.

Stedi already fixes common formatting issues for phone numbers in claims. These fixes include:

• Removing non-alphanumeric characters, such as spaces, parentheses, or hyphens.

• Converting vanity letters, such as those in 1-800-MEDICARE, to numbers

• Removing leading country codes, such as 1 from 11-digit numbers.

Sometimes, phone numbers still don’t meet phone number validation requirements even after all fixes have been made. Invalid phone numbers will ultimately be rejected by payers, which delays the ultimate adjudication of the claim.

Stedi has introduced a new edit – the industry term for automated validation rules – to ensure all telephone numbers in a claim are exactly 10 digits after all fixes.

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": "Billing provider phone number is in an invalid format. The expected format is 10 numeric digits (0123456789); no country code, punctuation, or extension. 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.

You can now change how long Stedi retries failed checks in a batch using the new maxRetryHours property of the Batch Eligibility Check API endpoint.

You can set any integer between 8 and 24 hours (inclusive). If you don’t specify a value, the default remains 8 hours.

For example:

curl --request POST \
  --url https://manager.us.stedi.com/2024-04-01/eligibility-manager/batch-eligibility \
  --header 'Authorization: <api-key>' \
  --header 'Content-Type: application/json' \
  --data '{
  "items": [
    ...
  ],
  maxRetryHours: 24  // Retry failed checks for up to 24 hours
}'

Note: You can only set a customer retry window for batch eligibility checks submitted using the Batch Eligibility Check API endpoint.

For more details, see our announcement blog.

You can now filter provider records in the List Providers API endpoint by NPI and Tax ID using the providerNpis and providerTaxIds query parameters.

Both parameters expect exact matches and accept multiple values. They can be combined with other filters. The endpoint uses AND logic to return the intersection of all filters.

Example
The following request returns up to 50 provider records whose name contains Dental and whose NPI matches either 1234567890 or 0987654321 and whose tax ID matches either 111223333 or 444556666.

curl --request GET \
  --header "Authorization: <api_key>" \
  --url "https://enrollments.us.stedi.com/2024-09-01/providers" \
  --data-urlencode "filter=Dental" \
  --data-urlencode "providerNpis=1234567890" \
  --data-urlencode "providerNpis=0987654321" \
  --data-urlencode "providerTaxIds=111223333" \
  --data-urlencode "providerTaxIds=444556666" \
  --data-urlencode "pageSize=50"

The List Providers endpoint is used to filter provider records used in transaction enrollment requests. For more information, see the transaction enrollment docs.

You can now see how long – minutes, hours, days, or weeks – it takes for an enrollment to go from submission to live with a payer in the Stedi Payer Network or the Payers API.

Payer Network
In the Stedi Payer Network, enrollment timeframes are shown in the Payer pane, in the Activation Timeframe field for the transaction type:

Activation Timeframe fields are also listed on the Payer page:

A value of Instant means the enrollment typically goes live within minutes of submission. Other values, like Hours or Days, indicate how long the process usually takes.

Payers API
In Payers API responses, each payer object lists enrollment details, if any, for each transaction type under transactionEnrollmentProcesses. The timeframe field shows the expected enrollment timeline for the transaction type.

{
  "payer": {    "displayName": "Blue Cross Blue Shield of Michigan",
    "primaryPayerId": "00710",
    "enrollment": {
      "ptanRequired": false,
      "transactionEnrollmentProcesses": {
        "claimPayment": {                  // This payer requires enrollment for ERAs.
          "timeframe": "INSTANT",          // ERA enrollment typically takes minutes.
          "type": "ONE_CLICK"
        }
      }
    },
    ...
  }
}

For more details, see our announcement blog.