Professional Claims (837P) JSON - Legacy

Submit an 837P professional claim in JSON format

POST/change/medicalnetwork/professionalclaims/v3/submission

This is a legacy endpoint. We won't deprecate it, and you can continue using it in production. If you're building a new integration, or prefer the new schema, we recommend using Create Professional Claim (CMS-1500) JSON. Of course, you're free to upgrade at any time.

This endpoint sends 837P professional claims to payers.

  1. Call this endpoint with a JSON payload.
  2. Stedi translates your request to the X12 837 EDI format and sends it to the payer.
  3. The endpoint returns a response from Stedi in JSON format containing information about the claim you submitted and whether the submission was successful.

CMS-1500 Claim Form PDF

When you submit a professional claim, Stedi automatically generates a 1500 claim form PDF. If you plan to send these PDFs to payers or retain them for your records, we strongly recommend reviewing the CMS-1500 claim form PDF documentation to learn how to structure claim submissions for optimal generation, the correct printer settings for generated PDFs, and general best practices.

Authorization
RequiredHeader

A Stedi API Key for authentication. Supports both test and production API keys.

Headers

Idempotency-Key
StringLength: 1 - 255

A unique string to identify this request to the server. The key can be up to 255 characters. You can safely retry requests with the same idempotency key within 24 hours of making the first request. This prevents you from sending duplicate claims due to network errors or other intermittent failures. Learn more.

Body

application/json
billing
ObjectRequired

Information about the billing provider.

  • You must provide an address that is a physical location such as the office where care is delivered or an administrative facility.
  • For tax identification, you must include either the provider's Social Security Number (SSN) in the ssn property or their Employer Identification Number (EIN) in the employerId property, but not both.
  • If the billing provider has an NPI, you must include it in the npi property. If the billing provider does not have an NPI, you must include either the commercialNumber or the locationNumber for identification. Some payers may require the npi and either the commercialNumber or the locationNumber as a secondary identifier.
  • Some solo providers may use their SSN as their EIN. In this case, submit the SSN in the ssn property and leave the employerId property blank.
Show attributes

A code specifying the type of transaction. Defaults to CH if not provided.

  • 31: Only for use by state Medicaid agencies performing post payment recovery.
  • CH: Use when the transaction contains only fee for service claims or claims with at least one chargeable line item. Also use when it's not clear whether a transaction contains claims or capitated encounters, or if the transaction contains a mix of claims and capitated encounters.
  • RP: Use for capitated encounters. Also use when the transaction is being sent to an entity for purposes other than adjudication of a claim. For example, when you're sending the claim to a state health agency that is using the claim for health data reporting purposes.
Possible values
31
CH
RP
claimInformation
ObjectRequired

Information about the healthcare claim.

Note that the objects and properties marked as required are required for all claims, while others are conditionally required, depending on type of claim and claim circumstances. For example, you must always provide the patient's diagnosis codes in the healthCareCodeInformation object, but you only need to provide the otherSubscriberInformation object in coordination of benefits scenarios. When you include a conditionally required object, you must provide all of its required properties.

Show attributes

Not currently used.

dependent
Object

Dependent who received the medical care associated with the claim.

  • If the dependent has their own member ID for the health plan, you should include the dependent's information in the subscriber object instead. To check whether a dependent has a member ID, submit an Eligibility Check to the payer. The payer returns the dependent's member ID in the dependents.memberId property in the response, if present.
  • You must include address in this object when the patient is a dependent.
Show attributes
ordering
ObjectDeprecated

Deprecated; please use claimInformation.serviceLines[].orderingProvider instead.

Show attributes

Use to specify an address for payment that is different from the billing provider's physical address. This is relevant when the provider expects to receive paper checks at a different location, such as a PO Box, lockbox, or other mailing address.

Show attributes
payToPlan
Object

Use for subrogation payment requests. If you include this information, you must also set the claimInformation.otherSubscriberInformation.payerPaidAmount to the amount the payer (for example, Medicaid) actually paid.

Show attributes

The payer's address. Some payers use this for internal routing. Only provide this address if the payer explicitly requires it.

Show attributes
providers
Array of ObjectsDeprecatedItems: 1 - 2147483647

Information about all providers, with each provider specified by its type (for example, Referring). You can't include this array in the same request as dedicated provider objects, such as referring or rendering.

Array item
receiver
ObjectRequired

The entity responsible for the payment of the claim, such as an insurance company or government agency.

Show attributes
referring
Object

Information about the provider who directed the patient to the rendering provider for care. For example, a primary care physician may refer patients to a specialist. Use when the referring provider applies to the entire claim, not just a specific service line.

This should be an individual, not an organization, and you should supply at least the provider's lastName and an identifier, which is typically the npi.

Show attributes
rendering
Object

Information about the person or company (laboratory or other facility) who rendered the care. Use this object for all types of rendering providers including laboratories. When a substitute provider (locum tenens) was used, enter that provider's information here.

  • Use when the provider applies to the entire claim or to at least one service line. For example, if a claim had two service lines with two different rendering providers, you would include the provider for the first service line here and leave the claimInformation.serviceLines[].renderingProvider object for that service line blank. Then, you would specify the second provider in the appropriate service line's claimInformation.serviceLines[].renderingProvider object.
  • You can omit this object when the rendering provider is the same as the billing provider. In that case, you would include the provider's information in the billing object and leave this object blank.
Show attributes
submitter
ObjectRequired

The entity submitting the healthcare claim. This can be either an individual or an organization, such as a doctor, hospital, or insurance company. You must submit at least organizationName or lastName properties and the contactInformation object. If you don't supply the submitterIdentification property, Stedi uses the value from billing.npi in the request.

Show attributes
subscriber
ObjectRequired

The person or entity who is the primary policyholder for the health plan or a dependent with their own member ID. The subscriber can be an individual or a business entity.

  • When a dependent has a unique, payer-assigned member ID, treat them as the subscriber for the claim submission - include their information here and omit the dependent object from the request. Stedi treats the subscriber as an individual when the request doesn't contain a value for the subscriber.organizationName property.
  • You must set the dateOfBirth and gender properties when the subscriber is the patient. Stedi determines that the subscriber is the patient when the dependent object is not included in the request.
  • If either dateOfBirth or gender is set, you must include both properties. You can either include both properties or neither within a single request.
  • You must include address in this object when the patient is the subscriber. If the patient is a dependent, include address information in the dependent object instead.
Show attributes

The entity responsible for overseeing the rendering provider and the care reported in this claim. Applies when the rendering provider is supervised by a physician. Use when the provider applies to the entire claim, not just a specific service line.

This should be an individual, not an organization, and you should supply at least the provider's lastName and an identifier, which is typically the npi.

Show attributes

This is the payer's business name, like Cigna or Aetna.

Secondary identifiers for the payer. You can include up to three properties in this object.

Show attributes
tradingPartnerServiceId
StringRequiredMin length: 1

The payer ID. Visit the Payer Network for a complete list.

  • You can send requests using the primary payer ID, the Stedi payer ID, or any alias listed in the payer record.
  • You must include leading 0 characters - payer IDs are alphanumeric strings and must be treated as complete strings, not integers. For example, use 00540 for SISCO, not 540.

Whether you want to send a test or production claim. This property also allows you to filter claims in the Stedi portal by production or test data. By default, this property is set to P for production data. Use T to designate a claim as test data.

Response

application/json

Information about the claim.

Show attributes

An identifier for the transaction.

editResponses
Array of Objects

Currently not used.

Array item
editStatus
StringDeprecated

This shape is deprecated: Currently not used.

errors
Array of Objects

Errors resulting from claim edits. You must review and fix these errors before resubmitting.

Array item
failure
Object

Currently not used.

Show attributes

Stedi can return the following status codes:

  • 200: Stedi successfully generated the X12 EDI claim format required by the payer. It does not indicate whether the payer has accepted the claim - the payer will respond later with a 277CA containing this information. Learn more about 277CAs.
  • 400: The request contains one or more problems with the claim data. Examples include missing required fields, invalid values, or incorrect data types. The response includes a message describing the problem.
  • 403: The request is not permitted, such as using a test API key to submit a production transaction.
Possible values
200 OK
400 BAD_REQUEST
403 FORBIDDEN
meta
Object

Metadata from Stedi about the request.

Show attributes
payer
Object

Information about the payer for the submitted claim.

Show attributes
status
String

The status of the claim submission.

An ID for the payer you identified in the original claim. This value may differ from the tradingPartnerServiceId you submitted in the original request because it reflects the payer's internal concept of their ID, not necessarily the ID Stedi uses to route requests to this payer.

warnings
Array of Objects

A list of warnings. Currently not used.

Array item
x12
String

A 277CA claim acknowledgment acceptance or rejection from Stedi in X12 EDI format. It indicates whether the claim has passed Stedi's claim edits.

When the claim fails one or more edits, the 277CA contains STC segments with information about each error. These are the same error codes that appear in the errors array.

Note that this 277CA only indicates whether Stedi has accepted or rejected the claim submission. You may receive additional 277CA acceptances or rejections as the claim is routed to the payer.