After you submit a professional, dental, or institutional claim, you may receive asynchronous 277 Claim Acknowledgment (277CA) and Electronic Remittance Advice (835 ERA) responses.

If you submitted the claims through the API or UI, there are two steps to retrieve claim responses from Stedi:

  1. Discover responses by polling for processed transactions or listening for event-driven webhooks.
  2. Call Stedi’s APIs to retrieve processed responses from Stedi.

Once you have the responses, you can correlate them with the original claim and specific service lines.

If you’re using a Stedi SFTP connection, you don’t need to poll or call Stedi’s APIs to retrieve responses. Instead, you can download them from the from-stedi directory.

​
Response types

You can receive two types of responses after you submit a professional, institutional, or dental claim.

​
Claim Acknowledgment (277CA)

The 277CA indicates whether the claim was accepted or rejected and (if relevant) the reasons for rejection. Though it can contain claim status information, the 277CA is different from the synchronous 277 Claim Status response you receive after submitting a real-time claim status request.

You may receive multiple separate 277CAs for each claim you submit.

  • You’ll receive the first 277CA from Stedi within about 30 minutes of submitting the claim. This 277 is the result of Stedi’s internal claim validation and may contain rejection message(s) and warnings, if applicable.
  • You may receive a second 277CA from Stedi around the same time. This 277CA can contain additional information from the payer, but is often identical to the first one. You can think of this as an initial validation 277 from the payer.
  • You’ll receive a final 277CA from the payer containing summary counts of transactions received and accepted as well as detailed information for rejected transactions, including payer-specific validations and HIPAA validations. This 277 has the payer’s name in the transactions.payers.organizationName property (Loop 2100A NM103 in the original X12 EDI).

​
Electronic Remittance Advice (835 ERA)

The 835 ERA, also known as a claim payment, contains details about payments for specific services and explanations for any adjustments or denials.

Processing 835 ERAs almost always requires enrollment with the payer.

​
277CA claim status objects

The 277CA response contains two main objects for claim status information:

  • informationClaimStatuses: This is the primary section to examine for detailed acceptance/rejection status of a claim. It contains information that would be useful to the submitter of the claim regarding acceptance/rejection, including:

    • Payer-specific rejection reasons
    • Claim charge amount details
    • The patientControlNumber from the claim (returned as patientAccountNumber)
    • All granular claim processing details

  • providerClaimStatuses: This section contains more generic information that would be useful to the provider regarding rejection/acceptance. It typically only includes basic status information like “accepted for processing” or “denied” without the granular information in informationClaimStatuses.

​
Discover processed responses

You can discover processed responses by either listening for webhooks or polling for transactions.

​
Listen for webhooks

Instead of polling for transactions, you can set up webhooks that automatically send events for processed 277CAs and 835 ERAs to your endpoint. You can either create a single webhook for all inbound transactions or create a separate webhook for each transaction type.

These webhooks are triggered by the transaction processed event Stedi emits after it successfully processes a response from the payer or intermediary clearinghouse.

As these events are emitted, you can:

  • Determine the transaction type from the x12.transactionSetIdentifier field: 277 (Claim Acknowledgment) or 835 (ERA).
  • Use the transactionId to retrieve the transaction from Stedi.

If your webhook doesn’t respond within 5 seconds, Stedi marks that as a failure and then automatically retries up to 5 times. This can result in duplicate deliveries, so we strongly recommend implementing ways to manage duplicates delivered through webhooks.

​
Poll for transactions

Call the Poll Transactions endpoint to return a list of transactions in your Stedi account.

You must include the following information in the request:

  • Your Stedi API key as the Authorization header.
  • Either the startDateTime or pageToken query parameters. To retrieve a list of transactions after a specific date, use startDateTime. To retrieve the next page of transactions, use pageToken (you can find this value in the nextPageToken field in the response).

The following example shows an API call to retrieve transactions after a specific date:

  curl --request GET -L \
    --url https://core.us.stedi.com/2023-08-01/polling/transactions?startDateTime=2023-08-28T00:00:00Z \
    --header "Authorization: ${STEDI_API_KEY}"

Filter for 277CA and 835 ERA transactions

The response includes all transactions that have been sent or received, including all 837 claims you have submitted and all 277CA and 835 ERA responses you have received from payers. You must filter for transactions that match the following criteria:

  • direction: INBOUND - This indicates that the transaction came from the payer or intermediary clearinghouse.
  • x12.transactionSetIdentifier: 277 or 835

The following example shows a response containing a processed 277CA transaction:

For each matching transaction, extract the transactionId and x12.transactionSetIdentifier type to use when mapping the data.

Stedi does not allow you to delete transactions, so make sure you track which transactionIds you have already processed.

​
Retrieve responses from Stedi

Use the following APIs to retrieve 277CA and 835 ERA responses from Stedi in JSON format:

You must include the following information in the request:

  • Your Stedi API key as the Authorization header.
  • The transactionId query parameter, which specifies the processed transaction you want to retrieve. You can find this ID in the response from either the Poll Transactions API or the configured webhook.

​
Correlate responses with original claim

You can use the following identifiers from the original claim to correlate the 277CA and 835 ERA responses.

​
Entire claim

Use the claimInformation.patientControlNumber from the original claim.

  • In the 277CA response, this number is returned as the transactions.payers.claimStatusTransactions.claimStatusDetails.patientClaimStatusDetails.claims.claimStatus.patientAccountNumber.
  • In the 835 response, this number is returned as the transactions.detailInfo.paymentInfo.claimPaymentInfo.patientControlNumber.

​
Specific service lines

The professional and institutional claim types use different names for the same identifier:

  • Professional: Use claimInformation.serviceLines.providerControlNumber from the original claim, if provided.
  • Institutional: Use claimInformation.serviceLines.lineItemControlNumber from the original claim, if provided.

Location in responses:

  • In the 277CA response, this number is sometimes returned as the transactions.payers.claimStatusTransactions.claimStatusDetails.patientClaimStatusDetails.claims.serviceLines.lineItemControlNumber.

    This is because a 277CA only contains a serviceLines object (which contains the lineItemControlNumber) if it was rejected because of issues with the information provided for the service line. The following snippet shows a serviceLines object for a rejected claim containing the lineItemControlNumber property.

  • In the 835 response, this number is always returned as the transactions.detailInfo.paymentInfo.serviceLines.lineItemControlNumber. The following snippet shows a serviceLines object from an 835 ERA response that contains the lineItemControlNumber.

​
ERA code lists

You may need to refer to the following code lists while evaluating the 835 ERA. Note that this page doesn’t list all possible code lists, only those that are too long to properly represent within the API documentation.

​
Claim Adjustment Group Code

This code is returned in the transactions.detailInfo.paymentInfo.claimAdjustments.claimAdjustmentGroupCode property. It categorizes the adjustment reason codes returned in the claimAdjustments object.

​
Claim Filing Indicator Code

This code is returned in the transactions.detailInfo.paymentInfo.claimPaymentInfo.claimFilingIndicatorCode property. It identifies the type of claim submitted.

​
Claim Status Code

This code is returned in the transactions.detailInfo.paymentInfo.claimPaymentInfo.claimStatusCode property. It identifies the status of an entire claim as assigned by the payer, claim review organization, or repricing organization.

​
Credit or Debit Flag Code

This code is returned in the transactions.financialInformation.creditOrDebitFlagCode property. It indicates whether the payment is a credit or a debit.

  • C - Credit | The payer uses this code to indicate a credit to the provider’s account and a debit to the payer’s account, initiated by the payer. In the case of an EFT, no additional action is required of the provider. The payer also uses this code when a check is issued for the payment.
  • D - Debit | The payer uses this code to indicate a debit to the payer’s account and a credit to the provider’s account, initiated by the provider at the instruction of the payer.

​
Payment Method Code

This code is returned in the transactions.financialInformation.paymentMethodCode property. It identifies the payment format. Note that the remaining properties in the financialInformation object contain additional requirements and information about the payment.

​
Transaction Handling Code

This code is returned in the transactions.financialInformation.transactionHandlingCode property. It indicates the actions taken by both the sender and the receiver.

Was this page helpful?