824 Application Reporting For Insurance (008020X321)

JANUARY 2022

Copyright © 2008-22, X12 Incorporated, Format © 2008-22 Washington Publishing Company. Exclusively published by the Washington Publishing Company. No part of this publication may be distributed, posted, reproduced, stored in a retrieval system, or transmitted in any form or by any means without the prior written permission of the copyright owner.

All rights reserved.

Abstract

The Application Reporting for Insurance Implementation Guide describes the use of the X12 Application Advice (824) transaction set for the following business usages:

• To report errors that are outside of the scope of the X12 997 or 999 error reporting
• To report the results of an application system's data content edits of transaction sets.

Preface

X12 standards are developed to identify the broadest data requirements for a transaction set. Type 3 Technical Reports (TR3), also known as implementation guides, define the explicit data requirements for a specific business purpose. Trading partners who implement according to the instructions in this TR3 can exchange data consistently with multiple trading partners.

As X12 does not define transport requirements, trading partners define their specific transport requirements separately.

1.1 Implementation Purpose and Scope

The purpose of this implementation guide is to provide standardized data content and structure to users of the X12 824 transaction set. This implementation guide is intended to report the results of application processing of a Health Care Insurance X12 transaction set.

This implementation guide for the Application Advice transaction set should not be used in place of an acknowledgement designed as a specific response to another transaction set (e.g., Health Care Claim Acknowledgment sent in response to a Health Care Claim or a Health Care Eligibility Benefit Response sent in response to a Health Care Eligibility Benefit Inquiry).

This X12 824 implementation guide does not replace existing X12N approved implementation guides designed to report transaction set errors.

This implementation guide was designed to be usable by the receiver of an X12 transaction set related to health care business processes. It is designed to report transaction set errors related to the use of any X12N-approved implementation guide that does not have another standard vehicle for the reporting of such errors. It has also been developed to supplement other error-reporting vehicles that may not provide for reporting of every transaction set error. It was designed as a standard vehicle to allow users to replace the myriad of proprietary electronic and hard copy formats developed for application reporting. It is not intended for use in place of the X12 999 transaction set. For more information on the relationship between the 824 transaction set and other response transaction sets, refer to the X12 document "X12 Acknowledgement Reference Model".

Trading partners would determine jointly whether to exchange the 824 transaction set to report receipt of a transaction set that complied with the respective business application, in addition to error reporting. Users of this guide include, but are not limited to, insurers, clearinghouses that transfer insurance data in standard transaction sets between users, and providers of services.

1.2 Version Information

This implementation guide is based on the October 2020 X12 standards, referred to as Version 8, Release 2 (008020).

The unique Version/Release/Industry Identifier Code for transaction sets that are defined by this implementation guide is 008020X321.

The two-character Functional Identifier Code for the transaction set included in this implementation guide:

• AG   Application Advice (824)

The Version/Release/Industry Identifier Code and the applicable Functional Identifier Code must be transmitted in the Functional Group Header (GS segment) that begins a functional group of these transaction sets. For more information, see the descriptions of GS01 and GS08 in Appendix C EDI Control Directory.

1.3.1 Batch and Real-Time Usage

There are multiple methods available for sending and receiving business transactions electronically. Two common modes for EDI transactions are batch and real-time.

Batch - In a batch mode the sender does not remain connected while the receiver processes the transactions. Processing is usually completed according to a set schedule. If there is an associated business response transaction (such as a 271 Response to a 270 Request for Eligibility), the receiver creates the response transaction and stores it for future delivery or transmits the response transaction back to the sender of the original transaction. The sender of the original transmission reconnects at a later time and picks up the response transaction. Note: The sender of the original transmission may not always be the entity that picks up the response transaction at a later time (e.g. Provider submitting through a clearinghouse.)

Real-Time - In real-time mode the sender remains connected while the receiver processes the transactions and returns a response transaction to the sender. This implementation guide does not set specific response time parameters for implementers.

This implementation guide was based on requirements for batch mode. Willing trading partners may use batch or real-time mode.

1.3.2 Other Usage Limitations

This implementation guide is not intended for use by non-Insurance entities, such as financial institutions.

1.4 Business Usage

This X12 824 implementation guide is intended to meet the needs of the insurance industry as a whole, for a standard implementation convention designed for reporting of application errors that are not included in the error reporting of the 999, or to report receipt of a transaction set that fully complies with the business application.

For more information on the relationship between the 824 transaction set and other response transaction sets, refer to the X12 document "X12 Acknowledgment Reference Model".

1.4.1 Health Care Transaction Flow

Each X12 implementation guide explains how to use X12 transaction sets to meet a single defined business purpose. The diagrams found at https://www.x12.org/flow depict the business functions supported by the X12 health care implementation guides.

1.5 Business Terminology

To ensure consistent use of terms, definitions, and acronyms across X12 products, X12 maintains the Wordbook, a comprehensive corporate glossary. The included terms are either proprietary to X12, cite definitions published by another authority, or represent common terms and definitions that are relevant to X12's work. The terms and definitions defined in the Wordbook are used in X12 work products when applicable, without modification or revision. The Wordbook can be referenced online at wordbook.x12.org.

1.6 Transaction Acknowledgments

The purpose of transaction acknowledgments is to report to the sender whether the transaction being acknowledged was accepted or rejected.

The X12 Technical Report Type 2, Acknowledgment Reference Model provides guidance on several control structures and transaction set standards intended to augment EDI auditing and control systems.

1.7 Related Transactions

There are no transactions related to the transactions described in this implementation guide.

1.8 Trading Partner Agreements

Trading partner agreements are used to establish and document the relationship between trading partners. A trading partner agreement must not override the specifications in this implementation guide if a transmission is reported in GS08 to be a product of this implementation guide.

1.9 Transaction Compliance

There are three types of compliance that may be relevant to a transmitted transaction.

Compliance with implementation guide requirements

Compliance with state and federal regulation

Compliance with trading partner contractual agreements

1.9.1 Transaction Compliance with Implementation Guide Requirements

A transaction complies with X12 implementation guide requirements if the transaction satisfies all format and content rules and constraints specified in the applicable X12 standards and the implementation guide (also known as a TR3) itself.

Should additional clarification of an X12 implementation guide requirement be desired, two options are available.

• The following X12 work products can be viewed online at https://products.x12.org:
  Interchange Control Structure (X12.5)
  Application Control Structure (X12.6)
  Interconnect Mailbag Control Structures (X12.56)
  Security Structures (X12.58)
  Implementation of EDI Structures - Semantic Impact (X12.59)
  Design Rules and Guidelines (X12.61)
  Acknowledgment Reference Model
  Reference Model for Inclusion of Sender and Receiver Identification in XML
  Compliance in X12.
• The X12 Request for Interpretation (RFI) viewer may be searched: https://rfi.x12.org. If existing RFI responses do not clarify the outstanding issue, a new RFI may be submitted.

X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that are not TR3-compliant based on its own business process.

A receiver may specify its business rules in a trading partner agreement or companion document. As stated in §1.8, these documents do not override TR3 requirements, nor change how transaction compliance with this TR3 is determined.

1.9.2 Transaction Compliance with State and Federal Regulations

This implementation guide has been developed for use as an insurance industry implementation guide. At the time of publication it has not been adopted as a state or federal standard. Should this implementation guide be adopted as a standard, the adopting authority will establish compliance dates for its use by impacted entities.

X12 is not the authority for determining compliance with regulatory requirements that might further constrain implementation guide requirements. Questions of compliance for regulatory requirements should be directed to the governing authority.

X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that do not comply with applicable regulatory requirements as specified by the applicable regulation(s) or governing authority.

1.9.3 Transaction Compliance with Contractual Requirements

X12 is not the authority for determining compliance with contractual requirements that might further constrain implementation guide requirements. Questions of compliance for contractual requirements should be directed to the contracting entity.

X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that do not comply with contractual requirements as specified by the applicable contract or contracting entity.

1.10.1 Overall Data Architecture

NOTE
See X12.6 to review the transaction set structure, including descriptions of segments, data elements, levels and loops.

1.10.1.1 Response Process

The following sequence diagram (sd) shows how the 824 transaction set is used with other X12 response transactions.

Figure 1.1 - Sequence Diagram

For more information on the relationship between the 824 transaction set and other response transaction sets, refer to the X12 document "X12 Acknowledgement Reference Model".

1.10.1.2 Looping Structure

Two N1 loops (Loop 1000A and Loop 1000B) are used in the transaction set to identify the submitter (Loop 1000A) and the receiver (Loop 1000B) of the 824. Loop 2000 (OTI loop) is used to identify the received transaction set to which this 824 is responding (see loop, segment, or element notes for more detailed information of their use.). Loop 2100 (TED loop) is used to report the nature of the errors. As designed, the 824 would identify a particular transaction set and the location of each error within that transaction set, i.e., loop, segment, data element, and composite data element if applicable and identify a code to explain the error. An external code source is used to provide standard codes and messages to facilitate the use of the 824 for reporting of errors included in a wide range of X12 insurance transaction sets.

1.10.1.3 Application Advice

The 824 acknowledgment is divided into two tables, Header and Detail. See Section 2, Transaction Set, for a description of the following presentation format.

The Header level, Table 1, contains general information, such as the transaction set control reference number of the previously sent transaction, date, time, submitter and receiver.

The Detail level, Table 2, reports the results of an application system's data content edits.

The 824 transaction set is intended to be a response to one and only one X12 transaction set related to insurance business processes. A received interchange may contain multiple functional groups, each of which contain their respective transaction set(s). The 824 transaction set is responsive only at the transaction set level. For example, if a received interchange contains 2 functional groups, each containing a single 820, 834 transaction set, respectively, and each received transaction set contains an error that is not intended to be reported on any associated response transaction set, then one 824 transaction set will be created for the erred 820 transaction set, a second 824 transaction set will be created for the erred 834 transaction set.

1.10.2 The BDS Segment (Binary Data Segment)

BDS01 is required and identifies the encoding used on the contents of BDS03. The encoding is the conversion mechanism that was applied to the original data prior to inserting it into BDS03. All data must be Base64 (BDS01=B64) encoded.

BDS02 is required and identifies the length of the BDS03 element in characters. This length must reflect the actual length of the original BDS03 sent by the sender. It has been noted that line constraints, transfer protocols, zip programs or conversion processes may insert additional control characters such as line feeds, carriage returns or other specific characters into a transaction. If this occurs in BDS03, the sender's stated count in BDS02 may no longer be equal to the received contents of the data in BDS03 but in no case should it be less than the count in BDS02.

BDS03 is required and contains the actual attachment.

Base64 Encoding
Details on implementing Base64 encoding are not included within this document, and can be found from other sources. Only a high level description will be provided here in order to focus on certain specific aspects. Base64 encoding converts any binary or textual data into a pure text set of characters that can be decoded back to the original binary by the receiver. The characters used in this encoding are upper case letters, lower case letters, the numbers 0 through 9, and two additional characters. See Request For Comment (RFC) 4648 from www.RFC-Base.org for Base64 technical details. Base64 encoding requires that the sender and receiver support the X12 Basic and Extended character sets.

For implementation under this guide, the two characters to be used as the 62nd and 63rd index in the encoding are to be the plus sign ("+") and the forward slash ("/") respectively, and the equal sign ("=") is to be used as the padding character. Use of these characters as delimiters is not allowed in transactions with Base64 encoded data.

1.10.3 Using the CTX Error Location Context

When reporting errors in the 824, it is critical that the recipient of the 824 understand where the error occurred. When an error is found in a business application, the segment position may not be known by the system generating the error, so an alternative identifier is needed for the submitter to locate the error. The CTX (Error Location Context) allows for a unique business unit identifier to be used.

Each transaction is different and it is the responsibility of the receiver to collect sufficient meta-data to appropriately report error locations. Valid values for the error location context include, but are not limited to:

Example:
Here we have a 275 fragment with an invalid LOINC.

LX✽4~
TRN✽2✽AHL-1234~
STC✽R4:11499-BH::LOI~
DTP✽368✽D8✽20190605~
CAT✽AE✽HL✽POCD_HD000040~
OOI✽1✽47✽ATTACHMENT~
BDS✽B64✽…~
 

If the system identifying the error retains segment position, the TED segment specifies the error location.

TED✽024✽✽STC✽63✽1:2✽✽11499-BH~
RED✽NA✽✽94✽✽IBP✽E079~
 

If the system identifying the error is not aware of the segment position, the CTX (Error Location Context) is used to report the loop containing the error.

TED✽024✽✽✽✽✽11499-BH~
CTX✽LX01:4~
RED✽NA✽✽94✽✽IBP✽E079~

2. Transaction Set

NOTE
See X12 documents X12.5, X12.6, and X12.59 to review transaction set structure, including descriptions of segments, levels, and loops.

2.1 Presentation Examples

The X12 standards are generic. For example, multiple trading communities use the same PER segment to specify administrative communication contacts. Each community decides which elements to use and which code values in those elements are applicable.

This implementation guide uses a format that depicts both the generalized standard and the insurance industry-specific implementation. In this implementation guide, IMPLEMENTATION specifies the requirements for this implementation. X12 STANDARD is included as a reference only.

The transaction set presentation is comprised of two main sections with subsections within the main sections:

Transaction Set Listing

There are two sub-sections under this general title. The first sub-section concerns this implementation of a generic X12 transaction set. The second sub-section concerns the generic X12 standard itself.

This section lists the levels, loops, and segments contained in this implementation. It also serves as an index to the segment detail.

This section is included as a reference.

Segment Detail

There are three sub-sections under this general title. This section repeats once for each segment used in this implementation providing segment specific detail and X12 standard detail.

This section is included as a reference.

This section is included as a reference. It provides a pictorial view of the standard and shows which elements are used in this implementation.

This section specifies the implementation details of each data element.

These illustrations (Figures 2.1 through 2.5) are examples and are not extracted from the Section 2 detail in this implementation guide. Annotated illustrations, presented below in the same order they appear in this implementation guide, describe the format of the transaction set that follows.

Figure 2.1 - Transaction Set Key - Implementation

Figure 2.2 - Transaction Set Key - Standard

Figure 2.3 - Segment Key - Implementation

Figure 2.4 - Segment Key - Diagram

Figure 2.5 - Segment Key - Element Summary

2.2.1 Industry Usage

Industry Usage describes when loops, segments, and elements are to be sent when complying with this implementation guide. The three choices for Usage are required, not used, and situational. To avoid confusion, these are named differently than the X12 standard Condition Designators (mandatory, optional, and relational).

2.2.1.1 Determining Transaction Compliance with Industry Usage Requirements

A transmitted transaction complies with the governing implementation guide when it satisfies the requirements as defined within the implementation guide. Specifically, the presence or absence of an item (loop, segment, or element) complies with the industry usage specified by this implementation guide according to the following table.

2.2.2 Loops

Loop requirements depend on the context or location of the loop within the transaction. See Appendix B for more information on loops.

• A nested loop can be used only when the associated higher level loop is used.
• The usage of a loop is the same as the usage of its beginning segment.
  • If a loop's beginning segment is Required, the loop is Required and must occur at least once unless it is nested in a loop that is not being used.
  • If a loop's beginning segment is Situational, the loop is Situational.
• Subsequent segments within a loop can be sent only when the beginning segment is used.
• Required segments in Situational loops occur only when the loop is used.

3. Examples

Business scenario examples for use of this transaction can be found on the X12 Examples website at http://examples.x12.org. The X12 Examples website provides convenient access to examples of X12 transaction transmissions, including the data stream and a description of the associated scenario.

Appendix A. External Code Sources

Prior to this publication, X12 TR3s contained a subset of the overall Code Source Directory, formerly known as Appendix A of X12.3. External code lists are not part of the X12 standard and are provided for information purposes only. The full listing is available in Glass, X12's On-Line viewer.

Read more about Glass here: https://glasshelp.x12.org/.

Where an external code source is referenced in this publication, the implementer is required to use only the codes from that list. Codes must be reported as listed in the code source (e.g. with leading zeroes). Implementers must follow the instructions for code use that are supplied by the code set owner.

B.1.1 X12 Referenced and Related Standards

This technical report is based on the X12 EDI standard which comprises a series of interdependent publications. Implementers are advised to consult these publications when using this technical report.

The following standards are required to interpret, understand, and use this technical report:

• X12.5 - Interchange Control Structure
• X12.6 - Application Control Structure

The following guideline is useful to interpret, understand, and use this technical report:

• Compliance in X12

The following reference model is useful to interpret, understand, and use this technical report:

• Acknowledgment Reference Model

All of the documents above are available online using links to X12's Online Viewer.

B.1.1.1 Transmission Control Schematic

Refer to X12.5 - Interchange Control Structures, Section 3.5 - Order of Control Segments, and Chapter 5 Interchange Segment Specifications.

Similar transaction sets, called "functional groups," can be sent together within a transmission. Each functional group is prefaced by a group start segment, and a functional group is terminated by a group end segment. One or more functional groups are prefaced by an interchange header and followed by an interchange trailer. Figure B.1 - Transmission Control Schematic, illustrates this interchange control.

Figure B.1 - Transmission Control Schematic

B.1.1.2 Constraints applicable to the suite of TR3s

Refer to X12.6 - Application Control Structure, Section 3.2.8 - Minimums/Maximums.

Data element minimum and maximum lengths are set by the X12 standard. This implementation guide may further restrict minimum and maximum lengths within the bounds set by the standard. Such restrictions may occur implicitly by virtue of the allowed qualifier for the data element, or they may be stated explicitly in a note attached to the element or in the general limitations below.

B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification

The current X12 standard allows a maximum length greater than 50 characters for data element 127. For implementations governed by this implementation guide, unless another value is specified in an attached note, the maximum length of each occurrence of this data element is constrained to 50 characters.

B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount

For implementations governed by this implementation guide, unless another value is specified for an instance of Data Element 782 within Section 2 (Transaction Set), each occurrence of Data Element 782 (Monetary Amount) will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). Note that the decimal point and leading sign, if sent, are not part of the character count.

EXAMPLE

• The following transmitted value represents the largest positive dollar amount that can be sent: 99999999.99
• The following transmitted value is the longest string of characters that can be sent representing whole dollars. 99999999
• The following transmitted value is the longest string of characters that can be sent representing negative dollars and cents. -99999999.99
• The following transmitted value is the longest string of characters that can be sent representing negative whole dollars. -99999999

B.1.1.3 Decimal

While the X12 standard supports usage of exponential notation, this guide prohibits that usage.

Appendix D. Change Summary

This Implementation Guide (008020X321) defines the X12 requirements for the Application Reporting For Insurance. It is based on version/release/subrelease 008020 of the X12 standards.