Skip to main content

Stedi

What's Stedi?​

Stedi is a platform that allows the exchange of X12 HIPAA-compliant X12 with different providers, payers, and EHR systems. Stedi provides Healthcare APIs for eligibility checks and claims processing that are compatible with Change Healthcare (CHC) request and response payloads.

Stedi Inbound/Outbound Flow

Stedi Healthcare​

Stedi provides a set of Change Healthcare compatible APIs:

  • Eligibility Checks: Realtime 270 eligibility and 271 benefit responses in JSON and X12 format.
  • 837P (Professional), 837I (Institutional), and 837D (Dental) claims with real-time 276 claim status checks in JSON and X12 format.
  • Reports API: retrieve processed 277CA Claim Acknowledgment and 835 ERAs files.

Professional Claims (837P)​

Send 837P (Professional) claims to payers providing a Change Healthcare-compatible JSON payload. Alternatively, a raw X12 payload can be used.

This API is very similar to Stedi's Outbound Transaction API; the key difference is the CH-compatible payload.

Supported Payers​

Stedi's Payer Network provides a complete list of the payers supported by Stedi. For each payer, the Stedi Payer ID and its aliases are listed, which services are supported (eligibility checks, claim submission, claim status, claim payment), and if they require enrollment. When submitting a claim, a Stedi-compatible payer ID must be specified.

tip

Stedi's Payer ID mapping can be skipped using the stedi-payer-mapping: passthrough header when sending a request.

Concepts​

Profiles, Partners, and Partnerships​

With whom EDI files will be exchanged

A profile contains the basic information to construct a valid EDI file (ID Qualifier, Identifier, Application ID). There are two types of profiles in Stedi:

  • Local: represents Pair Team.
  • Partner: represents the company that will exchange EDI files with Pair Team. They are also called trading partners.

A partnership associates a local profile with a partner profile.

When exchanging EDI files with a trading partner, a partnership must be specified. The profiles determine the direction of the EDI files:

  • Inbound: The local profile is the receiver.
  • Outbound: The local profile is the sender.

You can manage profiles and partnerships from the Partnerships section in Stedi's portal. Refer to the docs for more information about Partnerships.

Connections​

How EDI files will be exchanged

Connections can be created for a partner to specify how EDI files will be exchanged, for example, FTP, SFTP, or AS2.

You can manage a partnership's connections from the partnership's page in Stedi's portal. Refer to the docs for more information about Connections.

Guides and Transaction settings​

What type of EDI files will be exchanged

A Guide defines the format of a particular EDI transaction set. Stedi uses them to validate and translate (inbound) or generate (outbound) EDI files.

A Transaction Setting specifies the EDI transaction sets that will be exchanged with a trading partner. Both inbound and outbound transaction settings can be specified for a partnership. For outbound transaction settings, a connection must be specified.

You can manage a partnership's transactions settings from the partnership's page in Stedi's portal. Refer to the docs for more information about transaction settings and guides.

File execution​

A File execution represents a raw EDI file in Stedi: a file that has been received from a trading partner or a file that has been generated as a result of an API call.

For example, when a claim is sent using Stedi's Professional Claims API, a file execution ID of the generated EDI file is returned.

You can access the list of file executions in the Files section of Stedi's portal.

Transactions​

Is the processing of a file execution in the context of a Guide:

  • Outbound: Stedi performs validations on the JSON payload and generates an EDI file from it (file execution).
  • Inbound: Stedi receives an EDI file (file execution), validates the file, and translates it to JSON.

When a claim update or a remittance report event is notified to a webhook, a transaction ID is sent in the payload to be able to retrieve it.

You can access the list of transactions in the Transactions section of Stedi's portal.

Mappings​

Mapping can be used to transform Stedi Guide JSON to and from a different JSON format when generating or receiving EDI files. Originally, a mapping was used to transform a JSON payload compatible with Change Healthcare's Professional Claims API to Stedi's EDI X12 837P Guide when submitting claims and receiving events through webhooks.

You can create mappings in the Mappings section of Stedi's portal. Refer to the docs for more information on the topic.

Fragments​

Large EDI files that contain transaction sets with many repeated loops and segments can be split up into more manageable components called fragments. Instead of sending a whole inbound transaction data through a webhook, the data can be delivered in the form of multiple fragments. An outbound transaction can be created by submitting multiple fragments.

Refer to the docs for more information about Fragments.

Events and Webhooks​

Stedi emits events as it processes and generates EDI files. Events can be used to trigger Webhooks. A common use case is to trigger a Webhook on a transaction.processed.v2 event when an X12 EDI 277CA (Claims Acknowledgment) or X12 EDI 835 (Remittance) is received from a trading partner.

You can manage Webhooks in the Webhooks section of Stedi's portal.

Summary​

We can put all the concepts together with the following example: An EDI file is sent to Availity using the Create Outbound Transaction API endpoint.

  1. Pair Team (local profile) sends a JSON payload to Stedi including:
    • An X12 EDI 837P guide-compatible JSON. (*)
    • An outbound transaction-setting-id which indicates which guide and connection should be used.
    • A partnership-id that will be used to generate the envelopes (top segments) of the EDI file.
  2. Stedi creates a File Execution and sends its ID back to Pair Team as a response to the API call.
  3. A Transaction is executed:
    • JSON payload is validated against the guide specified in the transaction setting.
    • Generates EDI file from payload using the guide.
    • A transaction.processed.v2 event is created.
  4. The generated EDI file is sent to Availity (partner profile) using the specified connection.
    • If successful, a file.delivered.v2 event is created.

The events created during the process can be notified to Pair Team using Webhooks. Fragments can be used to split the creation of large transactions into smaller pieces.

(*) A non-compatible JSON could be sent and translated to a compatible one using a mapping.

Stedi concepts in action

Current Configuration Overview.​

Partnerships: Availity and Stedi​

We used to use Availity as our primary clearinghouse to submit claims (X12 EDI 837P) to payers and receive claim updates (X12 EDI 277CA) and remittance reports (X12 EDI 835). The pairteam-availity_availty partnership is set up for communication with Availity with the following transaction settings:

  • pairteam-availity-837-dev: configured to send X12 EDI 837P claims to Stedi's test FTP server (pairteam-availity-dev connection).
  • pairteam-availity-837-qa: configured to send X12 EDI 837P claims to Availity's QA FTP server (pairteam-availity-qa connection - not available).
  • pairteam-availity-837-prod: configured to send X12 EDI 837P claims to Availity's production FTP server (pairteam-availity-prod connection).

To use this clearinghouse We need to specify the Partnership ID and a Transaction Setting ID, also an usageIndicator (T or P) can be specified in the JSON payload to indicate if the claim is a test or production claim, this is a simple indicator it does not affect the claim processing:

Stedi-Transaction-Setting-Id: pairteam-availity-837-dev
Stedi-Partnership-Id: pairteam-availity_availity
...

{
  "usageIndicator": "T",
  ...
}

Stedi can also act as a clearinghouse to send claims to payers directly. Stedi manages two partnerships (local-clearinghouse and local-clearinghouse-test) and its connections. To send a claim through Stedi's partnership, no partnership nor transaction setting needs to be specified in the request's headers. An usageIndicator (T or P) needs to be specified in the JSON payload to indicate if the request is for the test or production partnership.

{
  "usageIndicator": "T",
  ...

}

Webhooks​

There are three webhooks configured to receive events from Stedi:

  • prod-277: binded to 277 transaction set events from production connections and send them to https://api.pairteam.com/api/v0/webhooks/stedi/claims/reports/277 (POST).
  • prod-835: binded to 835 (ERA) transaction set events from production connections and send them to https://api.pairteam.com/api/v0/webhooks/stedi/claims/reports/835 (POST).
  • prod-failed-files: binded to "File failed" events and send them to https://api.pairteam.com/api/v0/webhooks/stedi/claims/file/failed (POST).

All webhooks use the same Credential set: prod-creds (Basic Auth).

An event received in a Webhook includes which partners are involved in the event, the File Execution ID, and the Transaction ID. Stedi offers an API compatible with ChangeHealthcare reports API to retrieve the transaction data in the ChangeHealthcare API-compatible format. The API is available at https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/reports/v2/<TRANSACTION-ID>/<REPORT-TYPE>.

When an event is received in a webhook, a Finance::Stedi::ProcessTransactionEventJob job is enqueued to process the event, including the transaction ID received and the type of event. The job will retrieve the transaction data from Stedi using the Reports API and process it.

Common tasks​

Retrieve a transaction from a submitted claim​

When a claim is submitted to Stedi, a file execution ID is returned as a metadata.traceId. The file execution ID can be used to retrieve the transaction ID from Stedi's portal. Go to https://portal.stedi.com/app/core/file-executions/<FILE-EXECUTION-ID> and click on the Transactions tab to list the transactions associated with the file execution ID or use Stedi's API:

curl --request GET --url https://core.us.stedi.com/2023-08-01/executions/<FILE-EXECUTION-ID> --header 'Authorization: <API-KEY>'

{
  "items": [
      {
         "transactionId": "<TRANSACTION-ID>",
         ...
      }
  ]
  ...
}

And navigate to https://portal.stedi.com/app/core/transactions/<TRANSACTION-ID> to view the transaction details.

From the Transactions page, you can:

  • Access the file content in a human-readable format.
  • Review transaction details, including the environment (production or test), direction (inbound or outbound), and the partnerships involved.
  • Inspect the X12 EDI file received or generated, and utilize the inspector to translate individual segments and elements.
  • Explore related transactions that share the same identification. For instance, for a 277CA, you can view the associated 837P claim and other 277CA transactions linked to the same claim.
  • Examine the list of events associated with the transaction.

Search for a Transaction​

If you lack a transaction ID or file execution ID, you can search for a transaction using Stedi's portal. In the Transactions section, you can search for a transaction using a business identifier. For claims (X12 EDI 837P) and claim status updates (X12 EDI 277CA), the patient_control_number (in uppercase) serves as the business identifier. For remittance reports (X12 EDI 835), the EFT trace number (Finance::RemittanceTransaction#check_or_etf_trace_number) is used as the business identifier.