278 Transaction Set Listing
008020X342 Health Care Services Review - Request for Review and Response- Loop 2000A - UTILIZATION MANAGEMENT ORGANIZATION (UMO) LEVELRequired1
- Loop 2010A - UTILIZATION MANAGEMENT ORGANIZATION (UMO) NAMERequired1
- Loop 2000B - REQUESTER LEVELRequired1
- Loop 2010B - REQUESTER NAMERequired1
- Loop 2000C - SUBSCRIBER LEVELRequired1
- Loop 2010C - SUBSCRIBER NAMERequired1
- Loop 2000D - DEPENDENT LEVELSituational1
- Loop 2010D - DEPENDENT NAMERequired1
- Loop 2000E - PATIENT EVENT LEVELRequired1
- Loop 2010EA - PATIENT EVENT PROVIDER NAMESituational14
- Loop 2010EB - PATIENT EVENT TRANSPORT INFORMATIONSituational5
- Loop 2010EC - PATIENT EVENT OTHER UMO NAMESituational3
- Loop 2000F - SERVICE LEVELSituational>1
- Loop 2010F - SERVICE PROVIDER NAMESituational10
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*HI - FUNCTIONAL GROUP HEADER
ST*278 - 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 (ST-SE) processing. Providing the information from the GS08 at this level will ensure that the appropriate application mapping is utilized at translation time.
BHT*0007 - BEGINNING OF HIERARCHICAL TRANSACTION
- Use this element to trace the transaction from one point to the next point, such as when the transaction is passed from one clearinghouse to another clearinghouse. This identifier must be returned in the corresponding 278 response transaction's BHT03. This identifier will only be returned by the last entity to handle the 278. This identifier will not be passed through the complete life of the transaction. All recipients of 278 request transactions are required to return the Submitter Transaction Identifier in their 278 response if one is submitted.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
HL - UTILIZATION MANAGEMENT ORGANIZATION (UMO) LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
NM1 - UTILIZATION MANAGEMENT ORGANIZATION (UMO) 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.
HL - REQUESTER LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
NM1 - REQUESTER 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.
OR
Use when the provider is not in the United States or its territories and has received an NPI.
REF - REQUESTER SUPPLEMENTAL IDENTIFICATION
At least one of REF02 or REF03 is required.
The Social Security Number must be a string of exactly nine numbers with no separators.
For example, sending "111002222" would be valid, while sending "111-00-2222" would be invalid.
N3 - REQUESTER ADDRESS
N4 - REQUESTER 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 - REQUESTER CONTACT INFORMATION
- 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 - REQUESTER PROVIDER INFORMATION
If either PRV02 or PRV03 is present, then the other is required.
HL - SUBSCRIBER LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
NM1*IL - SUBSCRIBER 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.
- This segment conveys the name and identification number of the subscriber (who may also be the patient), or the Property & Casualty (including Workers' Compensation) entity.
- The Member Identification Number (NM108/NM109) is required and may be adequate to identify the subscriber to the UMO. However, the UMO can require additional information. The maximum data elements that the UMO can require to identify the subscriber, in addition to the member ID are as follows:
Subscriber Last Name (NM103)
Subscriber First Name (NM104)
Subscriber Birth Date (DMG01 and DMG02) - When a Property and Casualty (including Workers' Compensation) entity is the Subscriber, value the Entity Type Code Qualifier to 2 and the associated Federal Tax ID.
- Refer to the subsection Identifying the Subscriber/Patient within Section 1.11.2 Patient (Loop 2000C and Loop 2000D) for specific information on how to identify an individual to a UMO.
REF - SUBSCRIBER SUPPLEMENTAL IDENTIFICATION
At least one of REF02 or REF03 is required.
- Medicare Beneficiary Identifier (MBI) Number or Medicaid Recipient Identification Numbers are provided in the NM1 segment as a Member Identification Number when it is the primary number a UMO knows a member by (such as for Medicare or Medicaid). Do not use this segment for the Medicare Beneficiary Identifier (MBI) Number or Medicaid Recipient Identification Number unless they are different from the Member Identification Number provided in the NM1 segment.
- The primary identifier is the Member Identification Number in the NM1 segment.
- If the requester values this segment with the Patient Account Number (REF01 = "EJ") on the request, the UMO is required to return the same value in this segment on the response.
The Social Security Number must be a string of exactly nine numbers with no separators.
For example, sending "111002222" would be valid, while sending "111-00-2222" would be invalid.
N3 - SUBSCRIBER ADDRESS
N4 - SUBSCRIBER 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 - SUBSCRIBER DEMOGRAPHIC INFORMATION
- 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.
INS*Y - SUBSCRIBER RELATIONSHIP
If either INS11 or INS12 is present, then the other is required.
HL - DEPENDENT LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
NM1*QC - DEPENDENT 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.
- This segment conveys the name of the dependent who is the patient.
- The maximum data elements in Loop 2010D that can be required by a UMO to identify a dependent are as follows:
Dependent Last Name (NM103)
Dependent First Name (NM104)
Dependent Birth Date (DMG01 and DMG02) - Refer to the subsection Identifying the Subscriber/Patient within Section 1.11.2 Patient (Loop 2000C and Loop 2000D) for specific information on how to identify an individual to a UMO.
REF - DEPENDENT SUPPLEMENTAL IDENTIFICATION
At least one of REF02 or REF03 is required.
- Use the Subscriber Supplemental Identifier (REF) segment in Loop 2010C for supplemental identifiers related to the subscriber's policy or group number.
- If the requester values this segment with the Patient Account Number (REF01 = "EJ") on the request, the UMO is required to return the same value in this segment on the response.
The Social Security Number must be a string of exactly nine numbers with no separators.
For example, sending "111002222" would be valid, while sending "111-00-2222" would be invalid.
N3 - DEPENDENT ADDRESS
N4 - DEPENDENT 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 - DEPENDENT DEMOGRAPHIC INFORMATION
- 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.
INS*N - DEPENDENT RELATIONSHIP
If either INS11 or INS12 is present, then the other is required.
HL - PATIENT EVENT LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
TRN*1 - PATIENT EVENT TRACE NUMBER
- This enables the requester to
• uniquely identify this patient event request
• trace the request
• match the response to the request
• reference this request in any associated attachments containing additional patient information related to this patient event request. - If the transaction is routed through a clearinghouse, the clearinghouse may add their own TRN segment. If the transaction passes through multiple clearinghouses, and the second clearinghouse needs to assign their own TRN segment, they must replace the TRN from the first clearinghouse and retain it to be returned in the 278 response. If the second clearinghouse does not need to assign a TRN segment, they should pass all received TRN segments.
- Each trace number provided in the TRN segment at this level on the request must be returned by the UMO in the TRN segment at the corresponding level of the response.
- Use this element to identify the organization that assigned this trace number. TRN03 must be completed to aid requesters and clearinghouses in identifying their TRN in the 278 response.
- The first position must be either a "1" if an EIN is used, a "3" if a DUNS is used, or a "9" if a user assigned identifier is used.
UM - HEALTH CARE SERVICES REVIEW INFORMATION
- C023-01 does not contain the last position of the Uniform Bill Type Code (the Claim Frequency Code).
- C023-02 qualifies C023-01.
REF*P4 - DEMONSTRATION PROJECT IDENTIFIER
At least one of REF02 or REF03 is required.
REF*BB - PREVIOUS REVIEW AUTHORIZATION NUMBER
At least one of REF02 or REF03 is required.
REF*NT - PREVIOUS REVIEW ADMINISTRATIVE REFERENCE NUMBER
At least one of REF02 or REF03 is required.
DTP*439 - ACCIDENT DATE
DTP*484 - LAST MENSTRUAL PERIOD DATE
DTP*ABC - ESTIMATED BIRTH DATE
DTP*431 - ONSET OF CURRENT SYMPTOMS OR ILLNESS DATE
DTP*AAH - EVENT DATE
DTP*435 - ADMISSION DATE
DTP*096 - DISCHARGE DATE
HI - PATIENT SYMPTOMS, DIAGNOSIS, COMPLAINTS
- Do not transmit the decimal points in the diagnosis codes. The decimal point is assumed.
- Do not use the MSG segment to relay information if it can be codified using a code set in the HI segment.
- There are 2 repetitions of the HI segment to allow for 24 possible occurrences of ICD Diagnosis code information. The first iteration would contain diagnosis code 1-12. When used, the second iteration would contain diagnosis codes 13-24.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
HSD - HEALTH CARE SERVICES DELIVERY
- P0102
If either HSD01 or HSD02 is present, then the other is required. - C0605
If HSD06 is present, then HSD05 is required. - C0905
If HSD09 is present, then HSD05 is required.
HSD01 qualifies HSD02: If the value in HSD02=1 and the value in HSD01=VS (Visits), this means "one visit".
Between HSD02 and HSD03 verbally insert a "per every".
HSD03 qualifies HSD04: If the value in HSD04=3 and the value in HSD03=DA (Day), this means "three days". Between HSD04 and HSD05 verbally insert a "for". HSD05 qualifies HSD06: If the value in HSD06=21 and the value in HSD05=7 (Days), this means "21 days".
The total message reads:
HSD*VS*1*DA*3*7*21~ = "One visit per every three days for 21 days".
Another similar data string of HSD*VS*2*DA*4*7*20~ = "Two visits per every four days for 20 days".
An alternate way to use HSD is to employ HSD07 and/or HSD08. A data string of HSD*VS*1*****SX*D~ means "1 visit on Wednesday and Thursday morning".
- HSD✱VS✱1✱DA✱1✱7✱10~ (This indicates "1 visit every (per) 1 day (daily) for 10 days".)
- HSD✱VS✱1✱DA✱✱✱✱W~ (This indicates "1 visit per day whenever necessary".)
CRC*07 - AMBULANCE CERTIFICATION INFORMATION
CRC*08 - CHIROPRACTIC CERTIFICATION INFORMATION
CRC*09 - DURABLE MEDICAL EQUIPMENT INFORMATION
CRC*11 - OXYGEN THERAPY CERTIFICATION INFORMATION
CRC*75 - FUNCTIONAL LIMITATIONS INFORMATION
CRC*76 - ACTIVITIES PERMITTED INFORMATION
CRC*77 - MENTAL STATUS INFORMATION
CL1 - NURSING HOME RESIDENTIAL STATUS
CR1 - AMBULANCE TRANSPORT INFORMATION
- P0102
If either CR101 or CR102 is present, then the other is required. - P0506
If either CR105 or CR106 is present, then the other is required.
CR2 - SPINAL MANIPULATION SERVICE INFORMATION
- P0102
If either CR201 or CR202 is present, then the other is required. - C0403
If CR204 is present, then CR203 is required. - P0506
If either CR205 or CR206 is present, then the other is required.
CR5 - HOME OXYGEN THERAPY INFORMATION
- Use the UM segment data element UM02 instead of CR501 to specify the Certification Type Code.
- Use the HSD segment instead of CR502 to specify the treatment period.
CR6 - HOME HEALTH CARE INFORMATION
- P0304
If either CR603 or CR604 is present, then the other is required. - P091011
If either CR609, CR610 or CR611 are present, then the others are required. - P151617
If either CR615, CR616 or CR617 are present, then the others are required.
PWK - ADDITIONAL PATIENT INFORMATION
- P0506
If either PWK05 or PWK06 is present, then the other is required. - P1011
If either PWK10 or PWK11 is present, then the other is required.
Refer to Section 1.11.5.1 for more information on using this PWK segment.
MSG - MESSAGE TEXT
If MSG03 is present, then MSG02 is required.
NM1 - PATIENT EVENT 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.
- If Loop 2000F is not valued, this segment conveys the name and identification number of the service provider (person, group, or facility) specialist, or specialty entity to provide services to the patient for this patient event.
- If Loop 2000F is valued, the providers identified in this Loop 2010EA apply to all the services identified in Loop 2000F unless Loop 2010F is valued. Providers identified in Loop 2010F override the providers identified in Loop 2010EA for that service only.
OR
Use when the provider is not in the United States or its territories and has received an NPI.
REF - PATIENT EVENT PROVIDER SUPPLEMENTAL IDENTIFICATION
At least one of REF02 or REF03 is required.
The Social Security Number must be a string of exactly nine numbers with no separators.
For example, sending "111002222" would be valid, while sending "111-00-2222" would be invalid.
N3 - PATIENT EVENT PROVIDER ADDRESS
N4 - PATIENT EVENT 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 - PATIENT EVENT PROVIDER CONTACT INFORMATION
- 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 - PATIENT EVENT PROVIDER INFORMATION
If either PRV02 or PRV03 is present, then the other is required.
NM1 - PATIENT EVENT TRANSPORT INFORMATION
- 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.
- At least two iterations of this loop are necessary to indicate the pick up address, NM101 = PW, and the final scheduled destination, NM101 = FS.
- When the transport includes more than one destination, the following NM101 values are used to determine the sequence of stops:
a. ND is used to indicate the first stop
b. R3 is used to indicate the second stop
c. 45 is used to indicate the third stop
- NM1✱PW✱2✱PATIENT DIALYSIS CENT~
- NM1✱FS✱2~
N3 - PATIENT EVENT TRANSPORT LOCATION ADDRESS
N4 - PATIENT EVENT TRANSPORT LOCATION 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 - PATIENT EVENT OTHER UMO 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.
REF*ZZ - OTHER UMO DENIAL REASON
At least one of REF02 or REF03 is required.
- P0304
If either C04003 or C04004 is present, then the other is required. - P0506
If either C04005 or C04006 is present, then the other is required.
DTP*598 - OTHER UMO DENIAL DATE
HL - SERVICE LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
OR
Required when UM03 (Service Type Code) at the 2000E is used and submitter must submit additional details on the services requested.
If not required by this implementation guide, do not send.
TRN*1 - SERVICE TRACE NUMBER
- This enables the requester to
• uniquely identify this service line request
• trace the request
• match the response to the request
• reference this request in any associated attachments containing additional service information related to this service line request. - If the transaction is routed through a clearinghouse, the clearinghouse may add their own TRN segment. If the transaction passes through multiple clearinghouses, and the second clearinghouse needs to assign their own TRN segment, they must replace the TRN from the first clearinghouse and retain it to be returned in the 278 response. If the second clearinghouse does not need to assign a TRN segment, they should pass all received TRN segments.
- Each trace number provided in the TRN segment at this level on the request must be returned by the UMO in the TRN segment at the corresponding level of the response.
- If the request contains more than one occurrence of Loop 2000F and the requester needs to uniquely identify each service level request this TRN segment is required in each Service loop.
- Use this element to identify the organization that assigned this trace number. TRN03 must be completed to aid requesters and clearinghouses in identifying their TRN in the 278 response.
- The first position must be either a "1" if an EIN is used, a "3" if a DUNS is used, or a "9" if a user assigned identifier is used.
UM - HEALTH CARE SERVICES REVIEW INFORMATION
- Subset 278 of the current version of the Health Care Services Type Codes List represents the codes that are available for use in this element.
- Values at the Service Level override the values entered at the Patient Event Level for this service.
- C023-01 does not contain the last position of the Uniform Bill Type Code (the Claim Frequency Code).
- C023-02 qualifies C023-01.
REF*BB - PREVIOUS REVIEW AUTHORIZATION NUMBER
At least one of REF02 or REF03 is required.
REF*NT - PREVIOUS REVIEW ADMINISTRATIVE REFERENCE NUMBER
At least one of REF02 or REF03 is required.
DTP*472 - SERVICE DATE
HI - ADDITIONAL SERVICE DESCRIPTION
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
SV1 - PROFESSIONAL SERVICE
If either SV103 or SV104 is present, then the other is required.
- C003-01 qualifies C003-02 and C003-08.
- If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
- C003-03 modifies the value in C003-02 and C003-08.
- C003-04 modifies the value in C003-02 and C003-08.
- C003-05 modifies the value in C003-02 and C003-08.
- C003-06 modifies the value in C003-02 and C003-08.
- C003-07 is the description of the procedure identified in C003-02.
- C003-08 represents the ending value in the range in which the code occurs.
- C003-09 modifies the value in C003-02 and C003-08.
- C003-10 modifies the value in C003-02 and C003-08.
- C003-11 modifies the value in C003-02 and C003-08.
- C003-12 modifies the value in C003-02 and C003-08.
Prior to the mandated implementation date for the Unique Device Identifier, willing trading partners may agree to follow an early implementation approach.
Code Source: FDA Global Unique Device Identifier Database (GUDID) http://accessgudid.nlm.nih.gov/
Available from:
National Library of Medicine
8600 Rockville Pike
Bethesda, MD 20894
Acceptable values are 1 through 12, and correspond to the HI01 through HI12 element number that holds the diagnosis values in the Event Loop (2000E).
If no diagnosis pointer is provided, then this procedure applies to all diagnoses.
SV2 - INSTITUTIONAL SERVICE
- R0102
At least one of SV201 or SV202 is required. - P0405
If either SV204 or SV205 is present, then the other is required.
- SV2✱120✱✱1500✱DA✱5✱300~
- SV2✱300✱HC:80019✱73.42✱UN✱1~
- C003-01 qualifies C003-02 and C003-08.
- If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
- C003-03 modifies the value in C003-02 and C003-08.
- C003-04 modifies the value in C003-02 and C003-08.
- C003-05 modifies the value in C003-02 and C003-08.
- C003-06 modifies the value in C003-02 and C003-08.
- C003-07 is the description of the procedure identified in C003-02.
- C003-08 represents the ending value in the range in which the code occurs.
- C003-09 modifies the value in C003-02 and C003-08.
- C003-10 modifies the value in C003-02 and C003-08.
- C003-11 modifies the value in C003-02 and C003-08.
- C003-12 modifies the value in C003-02 and C003-08.
Prior to the mandated implementation date for the Unique Device Identifier, willing trading partners may agree to follow an early implementation approach.
Code Source: FDA Global Unique Device Identifier Database (GUDID) http://accessgudid.nlm.nih.gov/
Available from:
National Library of Medicine
8600 Rockville Pike
Bethesda, MD 20894
SV3 - DENTAL SERVICE
- C003-01 qualifies C003-02 and C003-08.
- If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
- C003-03 modifies the value in C003-02 and C003-08.
- C003-04 modifies the value in C003-02 and C003-08.
- C003-05 modifies the value in C003-02 and C003-08.
- C003-06 modifies the value in C003-02 and C003-08.
- C003-07 is the description of the procedure identified in C003-02.
- C003-08 represents the ending value in the range in which the code occurs.
- C003-09 modifies the value in C003-02 and C003-08.
- C003-10 modifies the value in C003-02 and C003-08.
- C003-11 modifies the value in C003-02 and C003-08.
- C003-12 modifies the value in C003-02 and C003-08.
- A modifier must be from code source 135 (American Dental Association) found in the 'Code on Dental Procedures and Nomenclature'.
- Use this data element for the first procedure code modifier.
- A modifier must be from code source 135 (American Dental Association) found in the 'Code on Dental Procedures and Nomenclature'.
- Use this data element for the second procedure code modifier.
- A modifier must be from code source 135 (American Dental Association) found in the 'Code on Dental Procedures and Nomenclature'.
- Use this data element for the third procedure code modifier.
- A modifier must be from code source 135 (American Dental Association) found in the 'Code on Dental Procedures and Nomenclature'.
- Use this data element for the fourth procedure code modifier.
Use this modifier for the fifth procedure code modifier.
Use this modifier for the sixth procedure code modifier.
Use this modifier for the seventh procedure code modifier.
Use this modifier for the eighth procedure code modifier.
Acceptable values are 1 through 12, and correspond to the HI01 through HI12 element number that holds the diagnosis values in the Event Loop (2000E).
If no diagnosis pointer is provided, then this procedure applies to all diagnoses.
TOO*JP - TOOTH INFORMATION
If either TOO01 or TOO02 is present, then the other is required.
DN2 - TOOTH STATUS
If either DN204 or DN205 is present, then the other is required.
- The Universal National Tooth Designation System must be used to identify tooth numbers for this element. See Code Source 135: American Dental Association.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
DRA - DRUG AUTHORIZATION
- P0405
If either DRA04 or DRA05 is present, then the other is required. - P080910
If either DRA08, DRA09 or DRA10 are present, then the others are required.
Or
When reporting drug/biologic/medical or surgical supply authorization and the SV1 or SV2 was not used. If not required by this implementation guide do not send.
- C003-01 qualifies C003-02 and C003-08.
- If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
- C003-03 modifies the value in C003-02 and C003-08.
- C003-04 modifies the value in C003-02 and C003-08.
- C003-05 modifies the value in C003-02 and C003-08.
- C003-06 modifies the value in C003-02 and C003-08.
- C003-07 is the description of the procedure identified in C003-02.
- C003-08 represents the ending value in the range in which the code occurs.
- C003-09 modifies the value in C003-02 and C003-08.
- C003-10 modifies the value in C003-02 and C003-08.
- C003-11 modifies the value in C003-02 and C003-08.
- C003-12 modifies the value in C003-02 and C003-08.
- C060-01 is the question number from a pre-defined questionnaire.
- C060-02 is the answer to the pre-defined question. A "Y" value indicates the answer to the question is yes. A "N" value indicates the answer to the question is no.
HSD - HEALTH CARE SERVICES DELIVERY
- P0102
If either HSD01 or HSD02 is present, then the other is required. - C0605
If HSD06 is present, then HSD05 is required. - C0905
If HSD09 is present, then HSD05 is required.
HSD01 qualifies HSD02: If the value in HSD02=1 and the value in HSD01=VS (Visits), this means "one visit".
Between HSD02 and HSD03 verbally insert a "per every".
HSD03 qualifies HSD04: If the value in HSD04=3 and the value in HSD03=DA (Day), this means "three days". Between HSD04 and HSD05 verbally insert a "for". HSD05 qualifies HSD06: If the value in HSD06=21 and the value in HSD05=7 (Days), this means "21 days".
The total message reads:
HSD*VS*1*DA*3*7*21~ = "One visit per every three days for 21 days".
Another similar data string of HSD*VS*2*DA*4*7*20~ = "Two visits per every four days for 20 days".
An alternate way to use HSD is to employ HSD07 and/or HSD08. A data string of HSD*VS*1*****SX*D~ means "1 visit on Wednesday and Thursday morning".
- HSD✱VS✱1✱DA✱1✱7✱10~ (This indicates "1 visit every (per) 1 day (daily) for 10 days".)
- HSD✱VS✱1✱DA✱✱✱✱W~ (This indicates "1 visit per day whenever necessary".)
CR8 - IMPLANT CERTIFICATION
PWK - ADDITIONAL SERVICE INFORMATION
- P0506
If either PWK05 or PWK06 is present, then the other is required. - P1011
If either PWK10 or PWK11 is present, then the other is required.
Refer to Section 1.11.5.1 for more information on using this PWK segment.
MSG - MESSAGE TEXT
If MSG03 is present, then MSG02 is required.
NM1 - SERVICE 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.
- Use this segment to convey the name and identification number of the service provider (person, group, or facility) specialist, or specialty entity to provide services to the patient.
- If this loop is not valued, loop 2010EA is required to identify the service provider, specialist, or speciality entity to provide services.
OR
Use when the provider is not in the United States or its territories and has received an NPI.
REF - SERVICE PROVIDER SUPPLEMENTAL IDENTIFICATION
At least one of REF02 or REF03 is required.
The Social Security Number must be a string of exactly nine numbers with no separators.
For example, sending "111002222" would be valid, while sending "111-00-2222" would be invalid.
N3 - SERVICE PROVIDER ADDRESS
N4 - SERVICE 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 - SERVICE PROVIDER CONTACT INFORMATION
- 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 - SERVICE PROVIDER INFORMATION
If either PRV02 or PRV03 is present, then the other is required.
SE - TRANSACTION SET TRAILER
GE - FUNCTIONAL GROUP TRAILER
IEA - INTERCHANGE CONTROL TRAILER
| | 278 Health Care Services Review - Request for Review and Response (008020X342)NOVEMBER 2021 Copyright © 2008-21, X12 Incorporated, Format © 2008-21 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 Health Care Services Review Request and Response Implementation Guide describes the use of the X12 Health Care Services Review Information (278) transaction set for the following business usages:
|
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 to facilitate consistent implementation 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 for all users who request authorizations or certifications or who respond to such requests using the X12, Health Care Services Review Information (278). This implementation guide provides a detailed explanation of the transaction set by defining data content, identifying valid code tables, and specifying values that are applicable for electronic health care service review requests and responses. The intention of the developers of the 278 is represented in this guide. This implementation guide is designed to assist those who request reviews (specialty care, treatment, admission) and those who respond to those requests using the 278 format. |
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 008020X342. 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 was based on requirements for batch mode. Willing trading partners may use batch or real-time mode. |
1.3.2 Other Usage Limitations Batch Delivery of the 278 This implementation supports the sending and receiving of multiple patient events in one transmission, where each patient event represents a single 278 transaction with multiple transactions in a single GS to GE loop. If the Utilization Management Organization (UMO) system cannot process each 278 request upon receipt, the UMO system must return a 278 response to indicate that the health care services review request has been pended. Real-Time Delivery of the 278
This subscriber/patient information is followed by one occurrence of the 2000E Loop. One or more 2000F Loops may follow containing associated services. |
1.4 Business UsageThe 278 has the flexibility to accommodate the exchange of information between providers and UMOs. This section introduces the business events and processes associated with the 278. |
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. Business Events Supported in this Guide - Request and ResponseThis implementation guide covers the following business events:
Figure 1.1 - 278 Review Request and Response As illustrated in Figure 1.1 - 278 Review Request and Response, the exchange of information is between the primary parties, the provider and the UMO. Health care entities that use this implementation of the 278 include the following:
NOTES Dental Referrals and Certifications Drug Authorization NOTES Medical Service Reservations and Cancellations For example, a patient may be limited to two chiropractic services per month. A Medical Service Reservation must be on file and the date of service and procedure code on the claim must match that of the reservation in order for the claim to be paid. If the service is not provided, the Medical Service Reservation must be canceled by the provider who reserved the service to allow the patient to obtain another service. If the provider determines that a patient needs more than the allotted services, authorization is required. Property and Casualty For most P&C claim events, member ID's/policy numbers do not necessarily identify the covered persons, since even strangers to the policy (e.g. passengers in the vehicle, customers, and visitors) can receive medical expense reimbursement coverage under a P&C policy. The P&C insurance card identifies the policyholder(s) and the covered vehicle(s)/property. The policy number may not be used to identify the covered events associated to the service request. Instead, the P&C case number is used to tie the request to a covered event. The case number is the key to associating the patient to a unique event. It is possible to have more than one patient associated to an event and more than one event per patient, each with unique coverage requirements with its associated limits. P&C service requests must include the information related to the event that caused the injury or illness. Information concerning the event is necessary to associate a service request with the P&C claim event. The unique identification number assigned by the payer for the specific event, referred to in P&C as a case number, must be provided. If the patient is the subscriber, the case number is transmitted in a REF segment in the 2010C Loop with REF01 value of 'Y4' and the case number in REF02. If the patient is not the subscriber, the case number is transmitted in a REF segment in the 2010D Loop with REF01 value of 'Y4' and the case number in REF02. The insured reported in the Subscriber detail segments may be a non-person such as an employer or a business. |
1.4.3 Business Events Supported in Other 278 Implementation GuidesThe 278 transaction set accommodates additional health care services review business events that are covered in separate 278 implementation guides. Notifications This implementation guide supports the following categories of notifications. Advance Notification for:
Completion Notification for:
Information Copy for any Health Services Review information sent to primary care provider(s), service provider(s), or other Health Care entities requiring the information for specific purposes. Change Notification to report changes to the detail of a previously sent notification or information copy. As illustrated in Figure 1.2 - Notifications, the information is sent unsolicited from the information source. The information source is the entity that knows the outcome of the service review request, and can be either a UMO or a provider. For example, in a situation where the primary care provider can authorize specialty referrals that do not require review for medical necessity, appropriateness, or level of care, the primary care provider is the information source. This provider might have responsibility for notifying both the UMO and the service provider of the specialty referral. In cases where the UMO is the decision maker, the UMO would send a notice of certification to the requesting provider and the service provider. Figure 1.2 - Notifications Inquiries and Responses Figure 1.3 - Inquiry and Response Examples of the types of inquiries supported in this implementation include the following:
|
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 transactions 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. |
1.10 Data OverviewThe 278 can be exchanged between interested participants in a bi-directional request/response mode of operation. In this mode, a participant requests a certification and a review entity responds to that request. This implementation guide addresses that use. This section provides general information on the structure of the transaction set as represented in this implementation guide. NOTE |
1.10.1 Overall Data ArchitectureThe 278 is divided into two levels, or tables. See Chapter 2, Transaction Set, for a description of the format presented. The Header level, Table 1, contains the purpose code for the transaction set as well as date and time stamps. For this implementation guide, BHT02 is either Cancellation (01), Request (13) or Authority to Deduct (36) on the request transaction, and Response (11) on the response transaction. The Detail level, Table 2, contains all data relating to the requested transaction, including transaction participants, the patient, all providers, and services detail information. Table 2 uses a hierarchical data structure to identify all the information associated with a health care services review for a patient event. For the types of business transactions that this implementation guide addresses, the following hierarchical levels (loops) apply: Loop 2000A contains the UMO Loop 2000B contains the Requester Loop 2000C contains the Subscriber Loop 2000D contains the Dependent Loop 2000E contains the Patient Event and Patient Event Providers Loop 2000F contains the Services and Services Providers Health Service Review Participants Patient Event Refer to wordbook.x12.org For Terms and Definitions. Services |
1.10.2 Sample Table 2 ConfigurationsThe following are sample Table 2 configurations. The following example represents a request for a category of service, such as ambulance transport, for a dependent of a subscriber. UMO (Loop 2000A) Requester (Loop 2000B) Subscriber (Loop 2000C) Dependent (Loop 2000D) Patient Event (Loop 2000E) The following example represents a response to a request for a category of service, such as ambulance transport, for a dependent of a subscriber. UMO (Loop 2000A) Requester (Loop 2000B) Subscriber (Loop 2000C) Dependent (Loop 2000D) Patient Event (with Review Outcome Data) (Loop 2000E) The following example represents a request for multiple services for a subscriber who is the patient. UMO (Loop 2000A) Requester (Loop 2000B) Subscriber (Loop 2000C) Patient Event (Loop 2000E) Service (Loop 2000F) Service (Loop 2000F) The following example represents a response to a request for multiple services for a subscriber who is the patient. UMO (Loop 2000A) Requester (Loop 2000B) Subscriber (Loop 2000C) Patient Event (with Review Outcome Data) (Loop 2000E) Service (with Review Outcome Data) (Loop 2000F) Service (with Review Outcome Data) (Loop 2000F) NOTE |
1.10.3 Intended Segment UseEach hierarchical level (loop) in this implementation consists of multiple segments and is based on the same standard hierarchical structure of segments. An implementation specifies the maximum segments you can include, per hierarchical level, to describe the health service review participants, patient event, and services. Request Table 1.1 - Intended Segment Use for a Request Transaction
Response Table 1.2 - Intended Segment Use for a Response Transaction
|
1.10.4 Matching the Request with Its ResponseThis implementation guide provides several methods to enable requesters, clearinghouses, and UMOs to trace the transaction or match the response to the original request. This section describes the segments and data elements that carry these identifiers. BHT03 - Submitter Transaction Identifier TRN Segment The requester (provider) can use this TRN segment to meet several needs. This enables the requester to accomplish the following:
Clearinghouses can provide their own trace numbers in a separate TRN segment at the Patient Event level and at the Service level on the request to use for transaction tracking and matching purposes. If the TRN segment is used on the request, the UMO must return the trace information supplied with the request transaction in the response transaction. UMOs can add a trace number in their own TRN segment at the Patient Event level (Loop 2000E) and Service level (Loop 2000F) on the response. The UMO cannot use this trace number to identify the certification to the requester. If the 278 request transaction passes through more than one clearinghouse, the second (and subsequent) clearinghouse may choose one of the following options:
A TRN segment at the Patient Event level is required if the requester needs to uniquely identify each patient event. A TRN segment at the service level is required if the request contains more than one service level request and the requester needs to uniquely identify each service request. |
1.10.5 Transaction ResponsesThe UMO must respond to each 278 transaction set received. If the UMO can process the service review request, the UMO must return a 278 response that contains an HCR segment at the Patient Event (Loop 2000E) and/or Service Level (Loop 2000F) in the response to indicate the status of the service review. Rejected Transactions |
1.11 Data Use By Business UseThe segments referenced in Table 1.1 - Intended Segment Use for a Request Transaction and Table 1.2 - Intended Segment Use for a Response Transaction carry the data content of the health care services review. This section provides examples of the segments and data element values used in the hierarchical levels. The use of UMO, requester, subscriber, dependent, patient event, and service is consistent across types of health care services reviews. However, the use of the patient event and service levels differ across types of health care services reviews. Therefore, the patient event level and service level discussions in this section contain multiple examples. Minimum Data Requirements NOTE |
1.11.1 Transaction Participants (Loop 2000A, Loop 2000B)The Loop 2000A and Loop 2000B hierarchical levels are used to convey information about the two primary participants in a health care service review transaction. Figure 1.4 - Information Source and Receiver Levels, presents the Loop 2000A and Loop 2000B levels. Figure 1.4 - Information Source and Receiver Levels Hierarchy Usage Chart for Transaction Participants Table 1.3 - HL Information Sources and Receivers
UMO (Loop 2000A) The following example demonstrates a minimum way of identifying a UMO. HL*1**20*1~ Requester (Loop 2000B) The following example demonstrates a minimum way of identifying a requester. HL*2*1*21*1~ | ||||||||||||||||||||||||||||||||||||||||
1.11.2 Patient (Loop 2000C and Loop 2000D)Subscriber Loop 2000C and Dependent Loop 2000D identify the patient. Loop 2000C is always required on the request and on a response that does not report a reject reason in a AAA segment in Loop 2000A or Loop 2000B. Loop 2000D is used only when necessary to identify a patient who is a dependent. Figure 1.5 - Subscriber and Dependent Levels shows the structure of these loops. Figure 1.5 - Subscriber and Dependent Levels When the subscriber is the patient or when the patient has a unique identification number (different from the subscriber), only Loop 2000C is used. This situation is common when an insurance company issues a unique insurance identification card to each individual insured. In all other cases, Loop 2000C is used to identify the subscriber. Loop 2000D is used to identify the subscriber's dependent, who is the patient. The Subscriber Name Loop 2010C and Dependent Name Loop 2010D contain the segments and data elements that hold this patient identification information. The NM1 and DMG segments contain all the data needed for the requester and UMO to identify the patient. Identifying the Subscriber/Patient Subscriber Last Name (NM103) The data requirements are the same for a dependent patient who has a unique identification number (different from the subscriber). In those cases where the subscriber is the patient or the patient has a unique identification number (different from the subscriber), only Loop 2000C is used. The following example demonstrates a sufficient way of identifying a patient who has a unique identification number. HL*3*2*22*1~ Identifying the Dependent Loop 2010C Loop 2010D If all four of these elements are present the UMO must generate a response if the patient is in the UMO's database. All UMOs are required to support the above search option if their system does not have unique Member Identifiers assigned to dependents. The following example demonstrates a sufficient way of identifying a patient who is the dependent of a subscriber. The example also illustrates the use of other segments. HL*3*2*22*1~ The INS segment enables the requester to provide information on the patient's relationship to the insured. The requester can also use this segment to identify a patient in a multiple birth or differentiate dependents with the same name. Patient Account Number |
1.11.3 Patient Event (Loop 2000E)The Loop 2000E hierarchical level identifies the patient event associated with this health care services review request. It identifies the category of service requested and whether the patient event concerns a referral to a specialist, specialty treatment, or an admission to a facility. Patient event information can include a description of the patient's current health condition, prognosis, and other specific diagnosis indicators. It can also reference electronic or non-EDI attachments that provide additional information related to the patient's condition that is not supported within the 278 transaction set. If the health care services review includes information on specific procedures to be performed, it must provide information on these procedures at the Services Level (Loop 2000F). Figure 1.6 - Patient Event Level Identifying Multiple Providers Loop 2000E (Patient Event) Loop 2010EA (Patient Event Provider 1) The following example represents a single patient event with multiple associated providers, for example physical rehabilitation services to be administered by a specific provider or group practice at a specific facility location. Loop 2000E (Patient Event) Loop 2010EA (Patient Event Provider 1) - Group Practice If the patient event has multiple services/procedures and requires different providers for these procedures, use the Service Level to associate each provider with the respective service. |
1.11.3.1 Specialty Care ReferralsSpecialty care referrals encompass those transactions where a provider requests permission to refer or send a patient to another provider, generally a specialist. These types of transactions generally are shared between a primary care physician and a UMO. However, they may just as easily be shared between any two providers or UMOs. In the following example, the initial service requested is for a single office visit for a consultation at the provider's office. Initial Request HL*4*3*EV*0~ The UM segment is used to identify the type of health care services request. UM01 = SC (Specialty Care Review) The HSD segment identifies the number of visits requested where HSD01 = VS (Visits) and HSD02 indicates the number of visits requested. Response to Initial Request Approval To approve the specialty care referral request as described previously, the following service level would be returned: HL*4*3*EV*0~ The HCR segment provides the results of the review as well as an associated reference number. This set of values indicates approval of the request in full. The response includes the original service level details respecting the services requested to eliminate confusion concerning what the UMO has approved. A Review Identification Number is supplied and is critical if the provider wishes to initiate further transactions concerning this service. HCR01 = A1 (Certified in Total) Approval with Modification of Services If the review entity wished to approve the specialist visits but decided to increase the number of visits to four, the following would be returned: HCR*A6*0081096G~ Denial of Services To completely deny the patient event request the following would be returned: HL*4*3*EV*0~ The A3 value indicates "not certified". Depending on UMO policy, the UMO might not return an authorization or reference number. Some organizations prefer to give no number because a number may imply approval. However, the failure to provide such a number restricts reference to the transaction at a later date. In this case, the UMO has also supplied a Review Decision Reason Code (0Y), "Service Inconsistent with Patient's Age". Pended Response Refer to "HCR Segment" in Section 2.6 for information on valuing the HCR segment when the response is pended. Request for Extension HL*4*3*EV*0~ In a request for an extension to an existing certification (UM02 = 4), HSD02 represents the number of visits by which the certification is extended. In this case, the requester is using the REF segment to refer to a prior certification number. This is the certification number returned by the UMO in HCR02 of the original response. "UM02 = 4" indicates that this is an extension request to a prior approved service. The HSD segment is used to extend the service by six visits. Request for Reconsideration HL*4*3*EV*0~ Normally, a request for reconsideration precedes an appeal. As in the "Request for Appeal" example, if the UMO returned an administrative reference number (REF01 = "NT") in the original response, the requester can use the REF segment to reference the UMO's response in this request for reconsideration. Request for Appeal HL*4*3*EV*0~ In this case, the requester is requesting an immediate appeal of a previously denied request by using the REF segment to refer to an administrative reference number. "UM02 = 1" indicates that this is an immediate appeal request. Although the provider has the ability to initiate an appeal request, this does not change the appeals process already established between the provider and the UMO. Typically, the provider must submit additional documentation that will require review by an appeal review board. The type of information required to return a decision can vary based upon the specific appeal request. In addition, the protocols for responding to an appeal request can vary by state. Therefore, the UMO and provider should establish protocols for communicating required information and ultimately rendering the final appeal decision. Request for Renewal HL*4*3*EV*0~ Request for Revision HL*4*3*EV*0~ To revise a specific procedure code that was previously approved, UM02 in Loop 2000E will equal S (Revised) and the authorization number being revised will appear in the REF Previous Review Authorization Number if the authorization was granted at the Event Level. In the 2000F loop, UM02 will equal 3 (Cancel) in the first iteration of the service loop and the procedure code that is being changed from the original request is reported. If the authorization was granted at the Service Level, the previous review authorization number is reported in the REF Previous Review Authorization Number in this loop. In a second iteration of the 2000F loop, the new procedure code is reported. UM02 will equal S (Revised) to indicate that this loop will contain the revised procedure. 2000E Loop UM*SC*S*3~ First iteration of 2000F Loop UM*SC*3~ Second iteration of 2000F Loop UM*SC*S~ The response will acknowledge the cancellation of the old procedure and the action on the new procedure. |
1.11.3.2 Health Services ReviewsThe term "health services review" identifies requests for specific treatments or more extended care. Extended care refers to treatment for a condition requiring prolonged rehabilitation therapy. This transaction set supports a request for certification of services related to specific treatment or extended care associated with a single patient event. Complex treatment plans represent multiple patient events. Use a separate transaction for each patient event requested. Initial Request UM*HS*I*6~ UM01 = HS (Health Services Review) Other data elements in this segment carry additional information about the type of request and the condition of the patient. Value these additional data elements only if they provide information that is relevant to the medical decision on this health service review request. Response Segments Frequently Used in Association with Health Service Review Patient Events Example - Request for Spinal Manipulation Treatment HI*ABF:S335:D8:20131209*ABF:M62838:D8:20131209*ABF:S238:D8:20131209~ The HI segment provides the associated diagnosis information. HI01-01 = ABF (Diagnosis) The HSD Segment specifies the pattern of delivery for the requested services. The request for spinal manipulation services will include 2 visits per week over a 3 month period. HSD01 = VS (Visits - Type of service count) The CR2 Segment is used to express the subluxation levels. CR203 = T11 (Subluxation level code) NOTE |
1.11.3.3 Admission ReviewThe term "admission review" identifies requests for admission to a facility for treatment (pre-certification). The transaction set enables the requester to specify both the facility and associated physicians within the same transaction. Initial Request HL*4*3*EV*0~ The UM segment identifies the type of health care services request. UM01 = AR (Admission Review) Other segments in this loop carry additional information about the type of request and the condition of the patient. Value these additional data elements only if they provide information that is necessary for processing this request. For example, the request includes an admitting diagnosis of ST elevation (STEMI) myocardial infarction of unspecified site (HI*ABJ:I123~). In this example, the additional elements clarify that the admission is for surgery that will take place in an inpatient setting. It also specifies a specific facility as the provider of services for this patient event. NOTE Response |
1.11.4 Services (Loop 2000F)The Service level (Loop 2000F) is not required on the 278 request. The requester should value this loop only if the health care services review includes specific services or procedures for which authorization is required. If the 278 request does not include this loop, it must specify all the information pertaining to the category of services requested at the Patient Event level (Loop 2000E). As illustrated in Table 1.1 - Intended Segment Use for a Request Transaction and Table 1.2 - Intended Segment Use for a Response Transaction, many of the segments used in Loop 2000F are the same as those available in Loop 2000E. For a detailed explanation of their use, refer to Section 1.11.3 - Patient Event (Loop 2000E). Figure 1.7 - Services Level Guidelines for Using the Service Level
The HI segment "Additional Service Description" is used to further define the service/procedure identified in UM03, SV1, SV2, SV3 or DRA. The segment uses SNOMED codes to provide added granularity regarding the planned, requested or approved service. Use is particularly beneficial for services that are broadly defined such as Consultation, Targeted Medication Review, Chronic Care Coordination Services, Transitional Care Management and Medication Therapy Management. For example: UM03 = 3 (Consultation) Request for a Range of Procedures Response to Request Containing Service Level Information
Example - Request for Spinal Manipulation Treatment and Associated Services Patient Event - Loop 2000E HL*4*3*EV*1~ Loop 2000E provides information on the patient event associated with the health care request. Information provided at this level applies to all the services included in the health care request. The UM segment specifies that this is a health service request for spinal manipulation treatment. Other data elements in this segment carry additional information about the type of request and the condition of the patient. In this example, the provider specified procedures; therefore, there is no need to value UM03 (Type of service). The requested procedures appear in the 2000F Service Loop. The PWK segment is required if the requester has additional documentation associated with the health services review that applies to the patient event and/or all the services requested. The PWK segment provides the following identification information about the attachment. PWK01 = 09 (Progress Report) In this example, the Loop 2010EA NM1 segment identifies the service provider or specialty entity requested. NM101 = SJ (Service Provider) Refer to Section 1.11.3 - Patient Event (Loop 2000E) for a detailed description of the other segments in this loop. Service - Loop 2000F HL*5*4*SS*0~ |
1.11.5 Additional Health Service Review Information (Loops 2000E and 2000F)Under some circumstances, UMOs may require additional patient information to determine the medical necessity of the services requested. This additional information concerns patient condition or service detail data not supported in the 278 (ST to SE). Depending on the type of health care services review, the requester might know of additional information required by the UMO at the time the request is initiated. Or, when the UMO receives the health care services review request, the UMO may determine that additional information is required to complete the review. This section provides guidelines for using these segments and data elements. |
1.11.5.1 Referencing Additional Information on the 278 RequestThe 278 request contains a PWK segment that the requester can use to reference an attachment (paper, electronic, or other medium) associated with the current health care services review. The attachment may be transmitted in a separate X12 functional group (e.g., 275 Attachment). PWK Segments Guidelines for Using the PWK Segment on the Request
|
1.11.5.2 Requesting Additional Information on the 278 ResponseWhen responding to a 278 request, the UMO might determine that additional information is required to complete the health care services review. The 278 response enables the UMO to:
HCR Segment HCR*A4**0U~ Where: HCR01 = "A4" (pended) If the Service Level (Loop 2000F) was also valued on the request, the UMO can value the associated HCR segment in Loop 2000F of the response. If the response contains the outcome of the review for some services but pends others for additional information, the UMO system can value the Loop 2000E HCR with HCR01 = A2 (Certified - partial) to indicate that the event is only partially certified. The HCR segments in Loop 2000F identify why the UMO has partially certified the patient event. For each service with a review outcome, the UMO system can value the Loop 2000F HCR01 to indicate the status of the review outcome. The UMO system can value the HCR segment for each service pended for additional information with HCR01 = "A4" and HCR03 = "0U". PWK Segment The UMO can use this segment to identify the type of documentation needed such as forms that the provider must complete. The UMO can also indicate what medium it has used to send these forms.
HI Segments LOINC codes are used to request specific information. LOINC modifier codes are used to qualify the scope of the request for information. For example, LOINC code 18657-7 requests the Rehabilitation treatment plan, plan of treatment (narrative). A LOINC modifier code of 18803-7 would qualify the requested information to include all data of the selected type that represents observations made 30 days or less before the starting date of service. The LOINC lists are external to X12 standards. See Appendix A, External Code Sources, for how to obtain these lists. The following provides an example of how to value the HI segment to request additional information using LOINC. HI*LOI:18657-7*LOI:18803-7~ "LOI" indicates that the code list used is Logical Observation Identifier Names and Codes and 18657-7 is the high-level grouping and 18803-7 is the modifier. Guidelines for Using HI Segments to Request Additional Information
Use of LOINC codes for requesting additional documentation for Diagnoses
This allows the UMO to return the requested diagnoses on the response and provides a suggested format for identifying which diagnosis requires the additional information. Use of LOINC codes for requesting additional documentation for a Procedure code range Loop 2000F - First Service Loop HI segment
SV1 segment
Loop 2000F - Second Service Loop HI segment
SV1 segment
When the UMO requests additional information for all procedures in the procedure range, structure the response as follows: HI segment
SV1 segment
Use of LOINC codes for requesting additional documentation for a service (SV1, SV2, or SV3 segment) Loop 2000F - First Service Loop HI segment
SV1 segment
Loop 2000F - Second Service Loop HI segment
SV1 segment
Loop 2000F - Third Service Loop If the UMO does not require additional information concerning the procedure specified in the third SV1 segment, the UMO may respond as follows:
NM1 Loops - Additional Information Contact Name Guidelines for Use of NM1 Loops
|
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 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 (008020X342) defines the X12 requirements for the Health Care Services Review - Request for Review and Response. It is based on version/release/subrelease 008020 of the X12 standards. |