Attachment Submissions API JSON-to-EDI Contents

Use our OpenAPI Spec JSON file as a reference for development. Notes on the data in the following sections include:

• The Constraints column describes the minimum and maximum number of alphanumeric characters that a field entry can occupy: for example, 1/60 R is a Required field with a minimum of one and maximum of 60 characters.
• If a field is required, the Constraints entry notes it.

For the Constraints column in each table, the following letters stand for specific meanings:

• R = Required (must be used if/when the object is part of the transaction);
• S = Situational (may be required depending on how the transaction content is structured).

Situational loops, segments, or elements can be Situational in two forms:

• Required IF a condition is met, but can be used at the discretion of the sender if it is not required (for example, some descriptive notes can be added to a claim if necessary);
• Required IF a condition is met, but if not, the sender must not use it in the request ("Do not send").

📘

NOTE

To obtain a license that also provides access to the full requirements for these transactions, visit https://x12.org/licensing. We make every effort to ensure consistency between our APIs and the X12 TR3. If there is a discrepancy, the X12 TR3 is the final authority.

Table of Mappings Tables

Header

Submitter

Provider

Subscriber

Claim Information

Service Lines

📘

NOTE

The OpenAPI Spec file for this API lists out the complete contents of the Attachment Submission request body. In the file, look for the Request object. Whenever you submit a request with an unsolicited or solicited attachment, it will contain instances of all the other JSON objects that are described in this document and in the OpenAPI Spec.

Header

Table Key: C/R: C= field constraints, R = Required

Submitter

Provider

📘

NOTE

For all REF segment identification values postalCode and state, the TR3 calls them out as Situational in this Guide; these values are required in all United States-based transactions. Elements such as firstName apply when the provider entity type is a person and not a non-person entity, and possesses a first name. In other words, these are required for virtually all transactions and should be treated as such.

Patient

Basic information about the patient.

📘

NOTE

For some Loop 1000D NM segment identification values, the TR3 calls them out as Situational as does this Guide; these values are required in all United States-based transactions. Elements such as firstName are an example. On rare occasions, the patient may not use or have a first name; this field will otherwise be required for virtually all transactions and should be treated as such.

Claim Information

Attachment Details

Service Line Date Information

Service Lines

📘

NOTE

If any standard character delimiters (underscore (_), tilde (~), up caret (^), and pipe (|)) are present in the providerAttachmentControlNumber or payerClaimControlNumber attributes in the inbound file, Optum replaces these characters with a blank in the ACN in the outbound 275.

Related Topic

• JSON-to-EDI API Mapping