Submit professional claims

Use Stedi to send 837P (Professional) claims to payers. You can also check the status of existing claims in real time.

Stedi automatically configures the necessary settings to send test and production claims and receive 277 and 835 responses from payers.

​

Coordination of benefits

You may want to perform a coordination of benefits (COB) check before submitting claims. COB checks can help you ensure that you submit claims to the correct payer and avoid claim denials. Specifically, COB checks can help you determine:

• If a patient is covered by more than one health plan
• Whether coverage overlap requires coordination of benefits
• Each payer’s responsibility for payment (primacy) in coordination of benefits scenarios

Visit Coordination of Benefits (COB) Checks for more information.

​

Manual submission

Manual claim submission can be useful for testing, QA, and debugging your pipeline. You can submit 837P professional claims manually through the Create manual claim page in the Stedi app.

The in-app form is adapted from the CMS-1500 Claim Form. As you build the claim, Stedi validates provider NPIs, diagnosis codes, and other key information to reduce payer rejections. You can also review a live preview of the autogenerated JSON payload for the Professional Claims API to understand how the form relates to the request structure.

​

SFTP submission

You can use Stedi’s fully-managed SFTP server to submit claims to to payers and retrieve claim responses without calling Stedi’s APIs.

You must submit claims in X12 EDI format, and Stedi returns claim responses through the SFTP connection in X12 EDI format. This makes Stedi SFTP a good option if you have an existing system that generates X12 EDI files and you want to send them through Stedi clearinghouse without completing an API integration. Visit SFTP connection for more information.

​

API submission

Call one of the following endpoints to submit 837 professional claims:

• Professional Claims to send requests in JSON
• Professional Claims Raw X12 to send requests in X12 EDI

The endpoint returns a synchronous response from Stedi in JSON format. Later, the payer will respond with a Claim Acknowledgment (277CA).

​

Headers

When constructing the request, you must include the following information in HTTP headers:

• Authorization: Generate an API key to use for authentication.
• Content-Type: Set to application/json.

​

Enhanced validation

You can optionally set the Stedi-Validation header to snip for enhanced validation on your claim submission.

Enhanced validation uses hundreds of additional edits (the industry term for validation rules) to increase claim acceptance rates. These include Strategic National Implementation Process (SNIP) validations. Stedi also automatically fixes common errors and monitors payer rejections to proactively build out new rules.

​

Body

The information you submit for a claim depends on your use case. Refer to the Professional Claims endpoint for a complete list of properties. However, all claims require the following high-level information:

​

Character restrictions

Only use the X12 Basic and Extended character sets in request data. Using characters outside these sets may cause validation and HTTP 400 errors.

In addition, the following characters are reserved for delimiters in the final X12 EDI transaction to the payer: ~, *, :, and ^. X12 doesn’t support using escape sequences to represent delimiters or special characters. Stedi returns a 400 error if you use these restricted characters improperly.

• JSON endpoint: Don’t include delimiter characters anywhere in your request data.
• Raw X12 endpoint: You can use these characters as delimiters, but not in the body of the request data.

​

Identify service lines

A claim can contain multiple service lines. Since the payer may accept, reject, or pay a subset of those lines, you can receive an 835 response that references a patientControlNumber, but only pertains to some of the service lines.

However, the claimInformation.serviceLines.providerControlNumber serves as a unique identifier for each service line in your claim submission. This value appears in the 277CA and 835 ERA responses as the lineItemControlNumber, allowing you to correlate these responses to specific service lines from the original claim. If you don’t set the providerControlNumber for a service line, Stedi uses a random UUID.

Stedi returns service line identifiers in the claimReference.serviceLines object of the synchronous API response.

​

Sample request

The following example sends a professional claim.

curl --request POST \
  --url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/professionalclaims/v3/submission \
  --header 'Authorization: <api-key>' \
  --header 'Content-Type: application/json' \
  --data '{
  "usageIndicator": "T",
  "tradingPartnerServiceId": "6400",
  "submitter": {
    "organizationName": "Test Data Health Services, Inc.",
    "submitterIdentification": "<YOUR-SUBMITTER-ID>",
    "contactInformation": {
      "name": "Test Data Health Services, Inc.",
      "phoneNumber": "5552223333"
    }
  },
  "receiver": {
    "organizationName": "Cigna"
  },
  "subscriber": {
    "memberId": "U7777788888",
    "paymentResponsibilityLevelCode": "P",
    "subscriberGroupName": "Cigna",
    "firstName": "John",
    "lastName": "Anon",
    "gender": "M",
    "dateOfBirth": "20000101",
    "groupNumber": "3335555",
    "address": {
      "address1": "2222 Random St",
      "city": "A City",
      "state": "NY",
      "postalCode": "123450000"
    }
  },
  "billing": {
    "providerType": "BillingProvider",
    "npi": "<YOUR-BILLING-PROVIDER-NPI>",
    "employerId": "123456789",
    "taxonomyCode": "2084P0800X",
    "organizationName": "Therapy Associates",
    "address": {
      "address1": "123 Some St",
      "address2": "Floor 1",
      "city": "A City",
      "state": "NY",
      "postalCode": "123450000"
    },
    "contactInformation": {
      "name": "Test Data Health Services, Inc.",
      "phoneNumber": "5553334444"
    }
  },
  "claimInformation": {
    "claimFilingCode": "CI",
    "patientControlNumber": "<YOUR-PATIENT-ID>",
    "claimChargeAmount": "109.20",
    "placeOfServiceCode": "02",
    "claimFrequencyCode": "1",
    "signatureIndicator": "Y",
    "planParticipationCode": "A",
    "benefitsAssignmentCertificationIndicator": "Y",
    "releaseInformationCode": "Y",
    "healthCareCodeInformation": [
      {
        "diagnosisTypeCode": "ABK",
        "diagnosisCode": "F1111"
      }
    ],
    "serviceFacilityLocation": {
      "organizationName": "Smith Associates",
      "address": {
        "address1": "1234 Other St",
        "city": "A City",
        "state": "NY",
        "postalCode": "123450000"
      },
      "npi": "123456789"
    },
    "serviceLines": [
      {
        "serviceDate": "20240101",
        "professionalService": {
          "procedureIdentifier": "HC",
          "procedureCode": "90837",
          "procedureModifiers": [
            "95"
          ],
          "lineItemChargeAmount": "109.20",
          "measurementUnit": "UN",
          "serviceUnitCount": "1",
          "compositeDiagnosisCodePointers": {
            "diagnosisCodePointers": [
              "1"
            ]
          }
        },
        "providerControlNumber": "111222333",
        "renderingProvider": {
          "providerType": "RenderingProvider",
          "npi": "<YOUR-PROVIDER-NPI>",
          "taxonomyCode": "111YP2000X",
          "firstName": "Jane",
          "lastName": "Smith"
        }
      }
    ]
  },
  "tradingPartnerName": "Cigna"
}'

​

Test claims

All claims you submit through this endpoint are sent to the payer as production claims unless you explicitly designate them as test data.

To send test claims, set the usageIndicator property in the test claim body to T. This allows you to filter for test claims on the Transactions page in the Stedi app.

Note that you will receive a 277 Claim Acknowledgment in response to test claims, allowing you to test your workflow end to end, but you will not receive a test 835 (ERA) response.

​

Cancel or resubmit claims

You may need to resubmit claims for several reasons, including changes to the patient’s coverage, errors in the original claim’s information, or appealing a denied claim. You may also need to cancel duplicate claims or claims that were submitted in error.

We recommend the following for resubmitting or canceling claims:

• Correct or replace claims: Set claimInformation.claimFrequencyCode to 7 - Replacement of Prior Claim. We also recommend setting a new, unique patientControlNumber. The payer includes this value in their 835 ERA response, allowing you to easily correlate that response with your resubmission.
• Cancel claims : Set claimInformation.claimFrequencyCode to 8 - Void/Cancel of Prior Claim.

In both cases, identify the original claim by setting claimInformation.claimSupplementalInformation.claimControlNumber to the Payer Claim Control Number (sometimes called the ICN). This is different from the patientControlNumber you sent in the claim and the Stedi-generated controlNumber returned in the API response. You can retrieve the Payer Claim Control Number from one of the payer’s 277 responses under the key transactions.payers.claimStatusTransactions.claimStatusDetails.patientClaimStatusDetails.claims.claimStatus.tradingPartnerClaimNumber.

​

View submitted claims

You can view the files that Stedi sends and receives in the Files page of the Stedi app.

On the Transactions page, you can review and filter claims by Usage - production or test. Click any claim submission to review its details, including the full request and response payload, processing events, and a link to download the auto-generated 1500 Claim Form PDF.

​

Setting a claim’s correlation ID

A claim’s correlation ID is a business identifier that you can use to track and manage claims.

• When you submit claims through the JSON endpoint, Stedi generates the correlation ID for you, and this value will be unique for each claim.
• When you submit claims in X12 EDI through the API or an SFTP connection, you can specify your own correlation ID in the BHT03 field. This allows you to use the same value for multiple claims if desired.

​

CMS-1500 claim form PDF

Stedi automatically generates a PDF CMS-1500 claim form for each professional claim you submit. Single-page PDFs are editable so you can make any necessary adjustments before printing and sending them to payers.

You can manually download the form on the transaction details page for the claim in Stedi. You can also retrieve the PDF through either of the following endpoints:

• CMS-1500 PDF: Business Identifier: Retrieve PDFs through a claim’s business identifier. You can find the business identifier value in the claimReference.correlationId property Stedi returns in the synchronous claim submission response.
• CMS-1500 PDF: Transaction ID : Retrieve PDFs through the transactionId Stedi assigns to the processed claim. This ID is included in the transaction processed event for the claim, which you can receive automatically through webhooks. You can also retrieve this ID from the transaction’s details page in Stedi.

Both endpoints return a base64 encoded string of the CMS 1500 Claim Form PDF. To render the PDF, you must decode the base64 string and save it to a file with a .pdf extension.

Review these behaviors and recommendations if you plan to send the generated PDFs to payers or retain them for your records:

​

PDF background

You can generate CMS-1500 PDFs with a white background by adding the query parameter ?background=false when calling the PDF generation endpoints.

The National Uniform Claim Committee (NUCC) and CMS provide exact specifications for blank CMS-1500 forms, including paper size and ink color. Many provider offices are accustomed to using these pre-printed forms, and their Practice Management System (PMS) applications are designed to print claim data onto them. Generating PDFs with a white background allows you to print the claim data directly onto official pre-printed forms.

Note that the form boxes and labels must be printed in red ink and the item values must be printed in black ink for the claim form to be read by a scanner. Your vendor may choose not to process claim forms that don’t conform to these specifications.

Due to mechanical variations between printer models, we can’t guarantee that the generated PDFs will align perfectly with pre-printed forms. We recommend testing the alignment with your printer before using the generated PDFs for official submissions.

​

The PDF may truncate claim data.

The maximum length for many fields in the 1500 claim form is less than the maximum length for the corresponding properties in the claim request.

Recommendation: Ensure that your claim data is within the maximum length for claim form fields. We especially recommend using USPS abbreviations to avoid truncated addresses in the generated PDF.

​

The PDF may omit the second line of some addresses.

Some 1500 claim form items contain address fields that can only be mapped to a single address line. If you include the address2 JSON property (X12 EDI N302) in your claim submission, that information may not appear in the PDF.

Recommendation: Put all street address line data into the address1 JSON property (X12 EDI N301), ensuring that you adhere to the claim form length constraints.

​

The PDF won’t populate Item 7 when the patient is a dependent.

Stedi validates the claim data you submit to the API and uses it to generate a compliant X12 EDI transaction to send to the payer. The PDF is generated from the final X12 EDI transaction.

The X12 EDI standard specifies that claims should only contain the insured’s address when the patient is the subscriber. To maintain compliance, Stedi doesn’t include the insured’s address information in the generated X12 EDI transaction when the patient is a dependent, even if you provided the subscriber’s address in the original API request. Since this address information isn’t present in final X12 EDI claim, it’s also not added to Item 7 (Insured’s Address) in the generated PDF.

​

Payer address (Carrier Block)

You can populate the payer’s address on the PDF by providing the payerAddress object in your claim submission API request. Include the payer’s address details that you want to appear on the form.

​

Standard form size

The generated PDFs use the standard 8.5” x 11” format.