You can send 837P professional claims to payers through the Stedi portal, the Professional Claims API, or an SFTP connection. Once you send a claim, Stedi automatically receives and processes 277CA claim acknowledgment and 835 Electronic Remittance Advice (ERA) responses.

​
Before sending claims

You may need to complete the following steps before sending claims.

​
Transaction enrollment

All payers require providers to complete an enrollment process before they can start receiving 835 ERAs. Some payers also require enrollment before allowing providers to submit claims. The Stedi Payer Network lists which payers require transaction enrollment. Visit Transaction Enrollment for details about the transaction enrollment process. We recommend running a coordination of benefits (COB) check to ensure you submit claims to the correct payer. 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 portal. The in-app form is based on the NUCC 1500 claim form but doesn’t support every data element. Specifically, it omits some parts of Item 19 (Additional Claim Information) and all of Item 24 supplemental information (shaded area). If you need this data, use the API endpoints instead. To help prevent rejections, Stedi validates provider NPIs, diagnosis codes, and other key information. You can also see an auto-generated preview of the corresponding JSON payload for the Professional Claims API to understand how the form maps 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 the Stedi clearinghouse without completing an API integration. Visit SFTP connection for more information.

​
API submission

Call one of the following endpoints to submit 837P professional claims: Both endpoints return a synchronous response from Stedi in JSON format. Later, the payer will respond with a 277CA claim acknowledgment.

​
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.

​
Body - JSON

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:
InformationDescription
tradingPartnerServiceIdThis is the payer ID. Visit the Payer Network for a complete list.
tradingPartnerNameThis is the payer’s business name, like Cigna or Aetna.
submitter objectInformation about the entity submitting the claim. This can be either an individual or an organization, such as a doctor, hospital, or insurance company.
receiver objectInformation about the payer, such as an insurance company or government agency.
subscriber and/or dependent objectsInformation about the patient who received the medical services. Note that if a dependent has their own, unique member ID for their health plan, you should submit their information in the subscriber object and omit the dependent object from the request. You can check whether the dependent has a unique member ID by submitting an Eligibility Check to the payer for the dependent. The payer will return the member ID in the dependents.memberId field, if present.
claimInformation objectInformation about the claim, such as the patient control number, claim charge amount, and place of service code. It also includes information about each individual service line included in the claim.
billing objectInformation about the billing provider, such as the NPI, taxonomy code, and organization name.

​
Service line identification

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 ERA 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 claim acknowledgment and 835 ERA 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.

​
Conditional requirements

Note that objects marked as required are required for all requests, while others are conditionally required depending on the circumstances. When you include a conditionally required object, you must include all of its required properties. For example, you must always include the subscriber object in your request, but you only need to include the supervising object when the rendering provider is supervised by a physician.

​
Body - X12 EDI

In addition to sending a payload in 837 X12 EDI format, note the following requirements and behavior when sending professional claims through the raw X12 endpoint.

​
Payer ID

You must submit a payer identifier in Loop 2010BB (Payer Name) NM109 so Stedi can route your claim to the correct payer. This identifier must be a payer ID or payer ID alias listed in the Payer Network. For example, you could use 60054, HPQRS, AETNA, or any other listed payer ID alias for Aetna.

​
CLM01 (Patient Control Number)

We strongly recommend submitting a unique value for Loop 2300 (Claim Information) CLM01 (Patient Control Number). The payer returns this value in related transactions, such as the 277CA and 835 ERA, so you can correlate responses and real-time claim status checks with the original claim. We recommend using only alphanumeric characters and generating unique values that are the shortest possible length. Stedi accepts any valid value, but some payers replace non-alphanumeric characters and truncate shorter than the official 20-character limit. When this happens, the payer returns a different identifier in responses than the one you originally sent, making it more difficult to correlate the claim and perform real-time claim status checks.

​
Service line identification

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 patient control number, but only pertains to some of the service lines. However, the line item control number serves as a unique identifier for each service line in your claim submission.
  • You can set the line item control number in Loop 2400 REF02, when REF01 = 6R. The line item control number 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 line item control number for a service line, Stedi uses a random UUID.
  • Stedi returns service line identifiers in the claimReference.serviceLines object of the synchronous API response.

​
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.

​
Sample request and response

The following examples send a professional claim. The response shape is the same for both the JSON and X12 EDI endpoints. It contains summary information from Stedi about the claim submission and whether it was successful. 
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-CLAIM-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": "1999999984"
    },
    "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 the API are sent to the payer as production claims unless you explicitly designate them as test data. To send test claims:
  • JSON endpoint: Set the usageIndicator property in the test claim body to T.
  • X12 EDI endpoint: Set ISA15 (Interchange Usage Indicator) to T (Test Data) instead of P (Production Data).
When you send a test claim, Stedi does not send it to the payer. Instead, it processes the claim as if it were sent to the payer and returns a response indicating whether the claim was successfully processed. Designating a claim as test data allows you to filter for test claims on the Transactions page in the Stedi portal. Note that you will receive a 277CA 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. You may want to use an API client to make testing and debugging easier. We don’t recommend using Postman for requests containing Protected Health Information (PHI) because Postman defaults to storing request history - including full request payloads - on its cloud servers. You can’t turn this feature off without impractical workarounds. Visit API clients for a list of recommended clients you can use instead.

​
Claim Filing Indicator Code

The Claim Filing Indicator Code indicates how a claim was filed with a payer, such as MC (Medicaid) or CI (Commercial Insurance Co.). Choosing the correct claim filing indicator code is important for successful claim submission. Visit the Claims code lists documentation for best practices for selecting the appropriate code.

​
275 claim attachments

If the claim requires attachments, you must include additional details about the attachments in the appropriate objects: Visit Claim attachments for complete instructions.

​
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, 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 277CA claim acknowledgments in the transactions.payers.claimStatusTransactions.claimStatusDetails.patientClaimStatusDetails.claims.claimStatus.tradingPartnerClaimNumber property.

​
Submit to a secondary or tertiary payer

In coordination of benefits (COB) scenarios, you’ll need to submit a claim to multiple payers. You must set the subscriber.paymentResponsibilityLevelCode to either S (when submitting to the secondary payer) or T (when submitting to the tertiary payer). You must also include the following information about how prior payers have adjudicated the claim. For example, if a patient’s private insurance plan (primary payer) adjusted the requested reimbursement amount and paid for its portion of the services, you must include that information in the claim you submit to Medicare (secondary payer). You can find these details in 835 ERA responses from prior payers.

​
Claim information

You must submit one claimInformation.otherSubscriberInformation object for each prior payer. Supply all the required properties in the object plus the following additional information:
  • claimLevelAdjustments: Provide if the prior payer made adjustments at the claim level. Codes and their associated amounts must come from ERAs sent by the prior payers. You can find these codes in the ERA’s transactions.detailInfo.paymentInfo.claimAdjustments object.
  • medicareInpatientAdjudication (institutional claims only): You must include this if Medicare was one of the prior payers and reported inpatient adjudication information on the ERA.
  • medicareOutpatientAdjudication: You must include this if Medicare was one of the prior payers and reported outpatient adjudication information on the ERA.
  • otherPayerName.otherPayerAdjudicationOrPaymentDate: The date the payer adjudicated or paid the claim. You must provide this if you aren’t providing a value in the claimInformation.serviceLines.lineAdjudicationInformation.adjudicationOrPaymentDate property.
  • payerPaidAmount: This is the total amount in dollars the payer paid on this claim.

​
Service line information

You must submit serviceLines.lineAdjudicationInformation objects when the prior payers provided line-level adjudication information. Submit one object for each prior payer. For each object, you should include the following properties.
  • adjudicationOrPaymentDate: The date the payer adjudicated or paid the claim. Don’t include this if you’re providing a date in the otherPayerName.otherPayerAdjudicationOrPaymentDate property.
  • claimAdjustmentInformation: You can find this information in the ERA’s transactions.detailInfo.paymentInfo.serviceLines.serviceAdjustments object.
  • otherPayerPrimaryIdentifier: The identifier for the other payer. This value should match the identifier you supplied for the payer in the claimInformation.otherSubscriberInformation.otherPayerName.otherPayerIdentifier property.
  • procedureCode: The adjudicated procedure code for the service line.
  • serviceIdQualifier: A code identify the type of procedure code. Visit Claims code lists for a complete list.
  • serviceLinePaidAmount: The total amount in dollars the prior payer paid on this service line.
  • paidServiceUnitCount: The number of paid units for the service line. When paid units are not present on the remittance advice, use the original billed units.
  • remainingPatientLiability: The amount of the service line the patient is responsible for paying.

​
View submitted claims

You can view the files that Stedi sends and receives on the Files page of the Stedi portal. 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.

​
Set 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 element. 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. You can manually download the form on the transaction details page for the claim in the Stedi portal or retrieve them programmatically through 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.
Payers have strict requirements for submitted CMS-1500 claim forms. If you plan to send generated PDFs to payers or retain them for your records, we strongly recommend visiting CMS-1500 Claim Form PDF for information about how to structure claim submissions for optimal generation, the correct printer settings for generated PDFs, and general best practices.