> ## Documentation Index
> Fetch the complete documentation index at: https://stedi.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Submit institutional claims
You can send 837I institutional claims to payers through the Stedi API or SFTP connection.
Once you send a claim, Stedi automatically receives and processes 277CA claim acknowledgments 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](https://www.stedi.com/healthcare/network) lists which payers require transaction enrollment. Visit [Transaction Enrollment](/healthcare/transaction-enrollment) for details about the transaction enrollment process.
### Coordination of benefits check (recommended)
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](/healthcare/coordination-of-benefits) for more information.
## 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](/healthcare/submit-claims-sftp-connection) for more information.
## API submission
Call the [Institutional Claims](/api-reference/healthcare/post-healthcare-institutional-claims) endpoint to submit 837I institutional claims in JSON.
The endpoint returns a synchronous response from Stedi in JSON format. Later, Stedi will respond with a 277CA claim acknowledgment, and the payer will respond with both 277CAs and the 835 ERA.
### Headers
When constructing the request, you must include the following information in HTTP headers:
* **`Authorization`:** [Generate an API key](https://portal.stedi.com/app/settings/api-keys) to use for authentication.
* **`Content-Type`:** Set to `application/json`.
### Body
The information you submit for a claim depends on your use case. Refer to the [Institutional Claims](/api-reference/healthcare/post-healthcare-institutional-claims) endpoint for a complete list of properties. However, all claims require the following high-level information:
| Information | Description | |
| --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | - |
| `tradingPartnerServiceId` | This is the payer ID. Visit the [Payer Network](https://www.stedi.com/healthcare/network) for a complete list. | |
| `submitter` object | Information about the entity submitting the claim. This is an organization, such as a hospital or other treatment center. | |
| `receiver` object | Information about the entity responsible for the payment of the claim, such as an insurance company or government agency. | |
| `subscriber` and/or `dependent` objects | Information 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](/api-reference/healthcare/post-healthcare-eligibility) to the payer for the dependent. The payer will return the member ID in the `dependents.memberId` field, if present. | |
| `claimInformation` object | Information about the claim, such as the claim filing code (identifies the type of claim), claim charge amount, and place of service code. It also includes information about each individual service line included in the claim. | |
| Billing provider | You **must** supply information about the billing provider in either the `providers` or `billing` object. This includes the provider's [NPI](/healthcare/national-provider-identifier), name, and other information. | |
#### 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.lineItemControlNumber` 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. We strongly recommend setting the `lineItemControlNumber` to a ULID or other unique identifier for each service line. We recommend using a ULID instead of a UUID because the property has a max of 30 characters.
#### 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.
### 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.
The X12 Basic character set includes uppercase letters, digits, space, and some special characters. Lowercase letters and special language characters like `ñ` are not included.
The following special characters are included:
The Extended character set includes the characters listed in Basic, plus lowercase letters and additional special characters, such as `@`.
The following additional special characters are included:
Don't include the following characters in your request data: `~`, `*`, `:` and `^`. They are reserved for delimiters in the resulting X12 EDI transaction, and X12 doesn't support using escape sequences to represent delimiters or special characters. Stedi returns a `400` error if you include these restricted characters in your request.
### Sample request and response
The following example sends an institutional claim. The response shape contains summary information from Stedi about the claim submission and whether it was successful.
{/* schema:InstitutionalClaimsSubmissionRequestContent */}
```bash Request
curl --request POST \
--url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/institutionalclaims/v1/submission \
--header 'Authorization: ' \
--header 'Content-Type: application/json' \
--data '{
"usageIndicator": "T",
"tradingPartnerName": "UnitedHealthcare",
"tradingPartnerServiceId": "87726",
"submitter": {
"organizationName": "Test Facility",
"contactInformation": {
"name": "Test Facility",
"phoneNumber": "2225551234"
},
"taxId": "123456789"
},
"receiver": {
"organizationName": "UnitedHealthcare"
},
"subscriber": {
"memberId": "98765",
"paymentResponsibilityLevelCode": "P",
"firstName": "JANE",
"lastName": "DOE",
"groupNumber": "67890"
},
"claimInformation": {
"claimFilingCode": "ZZ",
"patientControlNumber": "",
"claimChargeAmount": "500.00",
"placeOfServiceCode": "11",
"claimFrequencyCode": "0",
"planParticipationCode": "C",
"benefitsAssignmentCertificationIndicator": "Y",
"releaseInformationCode": "Y",
"principalDiagnosis": {
"qualifierCode": "ABK",
"principalDiagnosisCode": "R45851"
},
"serviceLines": [
{
"assignedNumber": "0",
"serviceDate": "20241015",
"serviceDateEnd": "20241015",
"lineItemControlNumber": "111222333",
"institutionalService": {
"serviceLineRevenueCode": "90",
"lineItemChargeAmount": "500.00",
"measurementUnit": "UN",
"serviceUnitCount": "1",
"procedureIdentifier": "HC",
"procedureCode": "H0001"
}
}
],
"claimCodeInformation": {
"admissionTypeCode": "3",
"admissionSourceCode": "9",
"patientStatusCode": "30"
},
"claimDateInformation": {
"admissionDateAndHour": "202409091000",
"statementBeginDate": "20241015",
"statementEndDate": "20241015"
}
},
"providers": [
{
"providerType": "BillingProvider",
"npi": "1999999976",
"employerId": "123456789",
"organizationName": "Test Facility",
"address": {
"address1": "123 Mulberry Street",
"city": "Seattle",
"state": "WA",
"postalCode": "111135272"
},
"contactInformation": {
"name": "Test Facility",
"phoneNumber": "2065551234"
}
},
{
"providerType": "AttendingProvider",
"npi": "1999999976",
"firstName": "Doctor",
"lastName": "Provider",
"contactInformation": {
"name": "name"
}
}
]
}'
```
{/* schema:InstitutionalClaimsSubmissionResponseContent */}
```json Response
{
"status": "SUCCESS",
"controlNumber": "123456",
"tradingPartnerServiceId": "87726",
"claimReference": {
"correlationId": "01JABEX6DPF4FCT2J0Y0SGFCY8",
"patientControlNumber": "00001111222233334444",
"timeOfResponse": "2024-10-16T20:04:32.962Z",
"formatVersion": "5010",
"claimType": "INST",
"rhClaimNumber": "01JABEX6DPF4FCT2J0Y0SGFCY8"
},
"httpStatusCode": "200 OK",
"payer": {
"payerName": "UnitedHealthcare",
"payerID": "87726"
},
"meta": {
"traceId": "a742ab42-a6f3-4232-a88c-197d341afdbe"
}
}
```
### 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](https://portal.stedi.com/app/core/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.
### Recommended API clients
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](/api-reference#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](/healthcare/claims-code-lists#choosing-the-right-code) 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:
* Attachments for entire claim: [`claimInformation.claimSupplementalInformation.reportInformation`](/api-reference/healthcare/post-healthcare-institutional-claims#body-claim-information-claim-supplemental-information-report-information)
* Attachments for a specific service line: [`claimInformation.serviceLines.serviceLineSupplementalInformation`](/api-reference/healthcare/post-healthcare-institutional-claims#body-claim-information-service-lines-service-line-supplemental-information)
Visit [Claim attachments](/healthcare/submit-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 claims to a secondary or tertiary payer
In [coordination of benefits (COB)](/healthcare/coordination-of-benefits) 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`](/api-reference/healthcare/get-healthcare-reports-835#response-transactions-detail-info-payment-info-claim-adjustments) 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`](/api-reference/healthcare/get-healthcare-reports-835#response-transactions-detail-info-payment-info-service-lines-service-adjustments) 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](/healthcare/claims-code-lists#composite-medical-procedure-product-or-service-id-qualifier-codes) 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 in the [Transactions](https://portal.stedi.com/app/core/transactions) page of the Stedi portal.
On the [Transactions](https://portal.stedi.com/app/core/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.