834 Transaction Set Listing
008020X318 Plan Member Reporting- Loop 1000A - SUBMITTER NAMERequired1
- Loop 1000B - RECEIVER NAMERequired1
- Loop 1000C - INFORMATION SOURCESituational1
- Loop 2000 - MEMBER LEVEL DETAILRequired>1
- Loop 2100A - MEMBER NAMERequired1
- Loop 2100B - PREVIOUSLY SUBMITTED MEMBER NAMESituational1
- Loop 2100C - MEMBER MAILING ADDRESSSituational1
- Loop 2100D - MEMBER EMPLOYERSituational3
- Loop 2100E - RESPONSIBLE PERSONSituational13
- Loop 2200 - DISABILITY INFORMATIONSituational4
- Loop 2300 - BENEFIT COVERAGERequired99
- Loop 2310 - PROVIDER INFORMATIONSituational30
- Loop 2320 - COORDINATION OF BENEFITSSituational4
- Loop 2330 - COORDINATION OF BENEFITS RELATED PAYERSituational3
- Loop 2700 - MEMBER REPORTING CATEGORIESSituational>1
- Loop 2750 - REPORTING CATEGORYRequired1
ISA - INTERCHANGE CONTROL HEADER
- For compliant implementations under this implementation guide, ISA13, the Interchange Control Number, must be a positive unsigned number. Therefore, the ISA segment can be considered a fixed record length segment.
- The first element separator defines the element separator to be used through the entire interchange.
- Spaces in the example interchanges are represented by "." for clarity.
- The ISA segment terminator defines the segment terminator used throughout the entire interchange.
- All positions within each of the data elements must be filled.
- The Interchange Control Number, ISA13, must be identical to the associated Interchange Trailer IEA02.
- Must be a positive unsigned number and must be identical to the value in IEA02.
GS*BE - FUNCTIONAL GROUP HEADER
ST*834 - TRANSACTION SET HEADER
- This element must be populated with the guide identifier named in Section 1.2.
- This field contains the same value as GS08. Some translator products strip off the ISA and GS segments prior to application (STSE) processing. Providing the information from the GS08 at this level will ensure that the appropriate application mapping is utilized at translation time.
BGN - BEGINNING SEGMENT
If BGN05 is present, then BGN04 is required.
If the original transaction set has already been processed, an incoming transaction set using this code may be rejected by the Information Receiver. The rejection must be reported to the sender.
Use when the original transaction set was incorrect and a new corrected transaction set is being sent. This transaction set then can be pended by the Information Receiver for review.
- This element is the transaction set reference number assigned by the Information Source. It uniquely identifies this occurrence of the transaction set for future reference.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
DTP*007 - FILE EFFECTIVE DATE
N1*41 - SUBMITTER NAME
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
N1*40 - RECEIVER NAME
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
N1*ACV - INFORMATION SOURCE
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
INS - MEMBER LEVEL DETAIL
If either INS11 or INS12 is present, then the other is required.
- The value 18 must be used for the subscriber.
- For dependents, this value identifies their relationship to the subscriber. For example, a daughter would be value 19.
REF*0F - SUBSCRIBER IDENTIFIER
At least one of REF02 or REF03 is required.
REF - MEMBER TAXPAYER IDENTIFIER
At least one of REF02 or REF03 is required.
AND
The Member's Taxpayer Identifier (social security number or ITIN) is available in the Information Source's system.
If not required by this implementation guide, do not send.
REF - MEMBER SUPPLEMENTAL IDENTIFIER
At least one of REF02 or REF03 is required.
REF*PID - MEMBER PROGRAM/PLAN IDENTIFIER
At least one of REF02 or REF03 is required.
DTP - MEMBER LEVEL DATES
- This loop is used to report eligibility dates. Use Loop 2300 to report coverage dates.
- When an end date is reported, it represents that day through 11:59 pm.
DTP*303 - MEMBER LEVEL MAINTENANCE DATE
DTP*393 - MEMBER LEVEL PLAN PARTICIPATION SUSPENSION DATES
NM1 - MEMBER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
PER*IP - MEMBER COMMUNICATIONS NUMBERS
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
N3 - MEMBER RESIDENCE STREET ADDRESS
N4 - MEMBER CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
DMG*D8 - MEMBER DEMOGRAPHICS
- P0102
If either DMG01 or DMG02 is present, then the other is required. - P1011
If either DMG10 or DMG11 is present, then the other is required. - C1105
If DMG11 is present, then DMG05 is required.
If either C05602 or C05603 is present, then the other is required.
EC - EMPLOYMENT CLASS
ICM - MEMBER INCOME
HLH - MEMBER HEALTH INFORMATION
- L030405
If C06103 is present, then at least one of C06104 or C06105 are required. - C0403
If C06104 is present, then C06103 is required. - C0503
If C06105 is present, then C06103 is required.
- C061-04 is the beginning date related to the type of date identified in C061-03.
- C061-05 is the end date related to the type of date identified in C061-03.
LUI*LE - MEMBER LANGUAGE
- P0102
If either LUI01 or LUI02 is present, then the other is required. - L040203
If LUI04 is present, then at least one of LUI02 or LUI03 are required.
NM1*70 - PREVIOUSLY SUBMITTED MEMBER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
DMG*D8 - PREVIOUSLY SUBMITTED MEMBER DEMOGRAPHICS
- P0102
If either DMG01 or DMG02 is present, then the other is required. - P1011
If either DMG10 or DMG11 is present, then the other is required. - C1105
If DMG11 is present, then DMG05 is required.
If either C05602 or C05603 is present, then the other is required.
NM1*31 - MEMBER MAILING ADDRESS
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
N3 - MEMBER MAILING STREET ADDRESS
N4 - MEMBER MAILING CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
NM1*36 - MEMBER EMPLOYER
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
NM1 - RESPONSIBLE PERSON
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
This code is used when a Qualified Medical Child Support Order (QMSCO) is present.
PER*RP - RESPONSIBLE PERSON COMMUNICATIONS NUMBERS
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
N3 - RESPONSIBLE PERSON STREET ADDRESS
N4 - RESPONSIBLE PERSON CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
DSB - DISABILITY INFORMATION
If either DSB07 or DSB08 is present, then the other is required.
DTP*360 - DISABILITY ELIGIBILITY BEGIN DATE
Or
Required when disability begin date changes for a previously reported member, and the disability begin date is known by the sender.
If not required by this implementation guide, do not send.
- This segment is used to send the first date of disability.
- If disability was previously reported in error, see section 1.4.9 for instructions on how to correct.
DTP*361 - DISABILITY ELIGIBILITY END DATE
Or
Required when disability end date changes for a previously reported member, and the disability end date is known by the sender.
Or
Required when DSB01 is equal to 4 and member is no longer on disability and the disability end date is known by the sender.
If not required by this implementation guide, do not send.
- This segment is used to send the last date of disability.
- If disability was previously reported in error, see section 1.4.9 for instructions on how to correct.
HD - BENEFIT COVERAGE
DTP*300 - ENROLLMENT SIGNATURE DATE
DTP - PREMIUM PAYMENT DATES
DTP*303 - MAINTENANCE EFFECTIVE DATE
DTP - BENEFIT DATES
DTP*695 - PREVIOUS PERIOD DATES
AMT - HEALTH COVERAGE POLICY AMOUNT
REF - BENEFIT COVERAGE POLICY RELATED INFORMATION
At least one of REF02 or REF03 is required.
IDC - IDENTIFICATION CARD
LX - PROVIDER INFORMATION
NM1 - PROVIDER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
N3 - PROVIDER ADDRESS
N4 - PROVIDER CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
PER*IC - PROVIDER COMMUNICATIONS NUMBERS
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
PRV*OT - PROVIDER TAXONOMY INFORMATION
If either PRV02 or PRV03 is present, then the other is required.
PLA - PROVIDER CHANGE REASON
COB - COORDINATION OF BENEFITS
REF - ADDITIONAL COORDINATION OF BENEFITS IDENTIFIERS
At least one of REF02 or REF03 is required.
DTP*344 - COORDINATION OF BENEFITS BEGIN DATE
DTP*345 - COORDINATION OF BENEFITS END DATE
NM1 - COORDINATION OF BENEFITS RELATED PAYER
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
N3 - COORDINATION OF BENEFITS RELATED PAYER ADDRESS
N4 - COORDINATION OF BENEFITS RELATED PAYER CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
LS - ADDITIONAL REPORTING CATEGORIES
LX - MEMBER REPORTING CATEGORIES
N1*IAE - REPORTING CATEGORY
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
REF - REPORTING CATEGORY REFERENCE
At least one of REF02 or REF03 is required.
REF*F8 - MEMBER RECORD CONTROL NUMBER
At least one of REF02 or REF03 is required.
DTP*007 - REPORTING CATEGORY DATE
LE - ADDITIONAL REPORTING CATEGORIES LOOP TERMINATION
SE - TRANSACTION SET TRAILER
GE - FUNCTIONAL GROUP TRAILER
IEA - INTERCHANGE CONTROL TRAILER
| | 834 Plan Member Reporting (008020X318)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 Plan Member Reporting implementation guide describes the use of the X12 834 transaction set for reporting plan members and member related information, which may or may not be available on a claim transaction, to All Payers Claims Databases for the purpose of enhancing health data reporting. |
PrefaceX12 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 ScopeFor the health care industry to achieve the potential administrative cost savings with Electronic Data Interchange (EDI), standards have been developed and need to be implemented consistently by all organizations. To facilitate a smooth transition into the EDI environment, uniform implementation is critical. The purpose of this implementation guide is to provide standardized data requirements and content to users of Version 008020 of X12, Member Reporting (834). The 834 is used to transfer member information from a submitter of insurance coverage, benefits, or policy to a receiver. This exchange may be performed directly or via transmission intermediaries, such as clearinghouses and value added networks. For further clarification on definitions of the participants, see X12 Wordbook for definitions. This document provides a definitive statement of what trading partners must be able to support in this implementation of the 834. |
1.2 Version InformationThis 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 008020X318. The two-character Functional Identifier Code for the transaction set included in this implementation guide:
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 UsageThere 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 is intended to support use in batch mode. This implementation guide is not intended to support use in real-time mode. A statement that the transaction is not intended to support a specific mode does not preclude its use in that mode between willing trading partners. |
1.3.2 Other Usage LimitationsThere are no other usage limitations. |
1.4.1 Health Care Transaction FlowEach 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.4.2 Information FlowsFigure 1.1 - Health Care Transaction sets included in the information flow diagram:
|
1.4.3 Location of Insurance Benefit IdentifiersIn this implementation of the 834 the Benefit Identifiers, such as policy numbers and group numbers, are reported in the REF segment at the Benefit Coverage level (Loop 2300). |
1.4.4 Linking a Dependent to a SubscriberSubscribers and dependents are sent as separate occurrences of Loop 2000. The initial reporting of benefit coverage for the subscriber must be sent before sending the initial benefit coverage for any of the subscriber's dependents. The reporting of a dependent may follow the reporting of the subscriber's benefit coverage in the same transmission, or it may be sent separately in a later transmission. Information Sources use various means to link dependents to the subscriber. To allow linking between subscribers and dependents without making assumptions about the receiving system, the subscriber's unique identifier is sent in the Subscriber Identifier REF in Loop 2000 for both the subscriber and the dependents. |
1.4.5 CancellationA benefit coverage cancellation, INS03 = 123 (Canceled by Administrator) in Loop 2000, is used to indicate that there should have been no coverage for the individual. This could be as a result of enrollment file corrections, choice on the part of the member or other file reconciliation. |
1.4.6 TerminationA termination date passed at the INS level for an individual (that is, a termination date passed in the DTP segment in Loop 2000) indicates that all coverages for that individual are to be terminated in the receiver's system on the indicated date. A termination date passed at the HD level (that is, a termination date passed in the DTP segment in Loop 2300 of any coverage type) applies to a specific benefit coverage, not the entire contract (or member). |
1.4.7 Updates, Versus Full File Audits, Versus Full File ReplacementsThe 834 transaction can be used to provide either updates, full file audits, or full file replacements. An update is either an "add", "terminate", "cancel", "reinstatement" or "change" request. The transaction only contains information about the changed members. This is identified in BGN08 by a code value of '2' (Change (Update)). A full file audit lists all current members, whether involved in a change or not. The full file audit is intended to identify all active members, at a given point in time and may or may not include terminated members based on the Trading Partner Agreement. This type of transaction is identified by a BGN08 code value of '4' (Verify). In addition, INS03 in Loop 2000 and HD01 in Loop 2300 must be set to a value of '030' (Audit or Compare). A full file replacement identified in BGN08 by a code value of 'RX' (Replace) is intended to identify all active members, at a given point in time and may or may not include terminated members based on the Trading Partner Agreement. |
1.4.8 Coverage Levels and DependentsDifferences exist in how Information Sources manage dependents. Some Information Sources identify a coverage level (HD05) for the subscriber which defines the coverage for eligible dependents as well. Other Information Sources have detailed information on each dependent in order to maintain their databases. Still other Information Sources maintain both types of information. The Trading Partner Agreement between the Information Source and Information Receiver must identify the member reporting requirements for this transaction. |
1.4.9 Information Related to Individuals At RiskIn certain instances reporting of addresses and other individual related information is restricted by regulation or policy to protect the individual. In order to ensure that the Information Receiver can receive and process this information correctly and protect the individual's information, this transaction utilizes the value of 'O' (Other) in INS13 (Confidentiality Code) in Loop 2000 to identify the member as an At Risk individual. The value of 'PJ' (Party to Receive Correspondence) in NM101 (Entity Identifier Code) of loop 2100A is the indication that the address in this loop may not be an actual address associated to the individual. Further restrictions may be defined in the Trading Partner Agreement to facilitate reporting information related to these individuals. An example of this scenario can be found at the external website at http://examples.x12.org. |
1.4.10 Information Related to Disability ReportingWhen the member status meets the definition of disability in X12 Wordbook, then the DSB segment in Loop 2200 is used to report the disability type and the associated dates. The value in DSB01 in Loop 2200 is used in conjunction with a begin date in the DTP segment, when appropriate, to report a member's disability status. When disability status ends, a value of '4' (No Disability) is sent in DSB01 and the disability end date is sent in DTP03 (Disability End Date). If a disability status was reported in error, a value of "4" (No Disability) is used in DSB01 and no DTP segment is sent. |
1.5 Business TerminologyTo 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 AcknowledgmentsThe 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 TransactionsThere are no transactions related to the transaction described in this implementation guide. |
1.8 Trading Partner AgreementsTrading 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 ComplianceThere 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 RequirementsA 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.
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 RegulationsThis 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 RequirementsX12 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. |
2.1 Presentation ExamplesThe 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 UsageIndustry 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 RequirementsA 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 LoopsLoop requirements depend on the context or location of the loop within the transaction. See Appendix B for more information on loops.
|
3. ExamplesBusiness 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 SourcesPrior 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 StandardsThis 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:
The following guideline is useful to interpret, understand, and use this technical report:
The following reference model is useful to interpret, understand, and use this technical report:
All of the documents above are available online using links to X12's Online Viewer. | ||||
| Â | ||||
B.1.1.1 Transmission Control SchematicRefer 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 TR3sRefer 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 IdentificationThe 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 AmountFor 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
| ||||
| Â | ||||
B.1.1.3 DecimalWhile the X12 standard supports usage of exponential notation, this guide prohibits that usage. | ||||
Appendix D. Change SummaryThis Implementation Guide (008020X318) defines the X12 requirements for the Plan Member Reporting. It is based on version/release/subrelease 008020 of the X12 standards. |