JULY 2007

Copyright © 2007-22, X12 Incorporated, Format © 2007-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 Additional Information to Support a Health Care Services Review Implementation Guide describes the use of the ASC X12 Patient Information (275) transaction set for the following business usage:

• Provide additional information, such as pre-certifications and prior authorizations

Standards have been developed to enable the health care industry to achieve the potential administrative cost savings associated with Electronic Data Interchange (EDI). To facilitate a smooth transition into the EDI environment, uniform and consistent implementation by all entities is critical.

The purpose of this implementation guide is to provide standardized data requirements and content to all users of ANSI ASC X12 Additional Information to Support a Health Care Services Review (275) Transaction Set that focuses on the use of the 275 to send additional information about a healthcare service review. It provides a detailed explanation of the transaction set by defining uniform data content, identifying valid code tables, and specifying values applicable for the business use of the 275. The intention of the developers of the 275 is represented in this guide.

This implementation guide describes a solution that includes the encapsulation of a Health Level Seven (HL7) Standard (www.HL7.org) within the 275 transaction to support the exchange of clinical data. HL7 is an ANSI Accredited Standards Development Organization (SDO) whose domain is clinical and administrative data. See sections 1.4 and 1.7 for additional details.

This implementation guide is designed to assist those who send or receive additional information in support of a healthcare service review using the 275 format.

Entities that use this implementation of the 275 include insurance companies, utilization management organizations (UMO), third party administrators (TPA), managed care service organizations (HMO), state and federal agencies and their contractors, plan purchasers, and any other entity that processes a healthcare service review. Other business partners affiliated with the 275 include consulting services, vendors of systems software, EDI translators, and EDI network intermediaries such as automated clearinghouses (ACH), value added networks (VAN), and telecommunications services.

This implementation guide is based on the October 2003 ASC X12 standards, referred to as Version 5, Release 1, Sub-release 0 (005010).

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

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

• PI Patient Information (275)

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.

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

Batch - In a batch mode the sender does not remain connected while the receiver processes the transactions. Processing is usually completed according to a set schedule. If there is an associated business response transaction (such as a 271 Response to a 270 Request for Eligibility), the receiver creates the response transaction and stores it for future delivery. The sender of the original transmission reconnects at a later time and picks up the response transaction. This implementation guide does not set specific response time parameters for these activities.

Real Time - In real-time mode the sender remains connected while the receiver processes the transaction 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.

There are other usage limitations.

The 275 transaction structure does not allow submission of additional information in support of more than one request for health care services review. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each request for review. The 275 can support multiple sets of information for a single request for review. See Loop 2110A BIN Segment and the LX segment for additional details.

This implementation guide ONLY addresses using the 275 to support a health care services review or notification. A separate implementation guide was developed for the 275 Additional Information to Support a Health Care Claim or Encounter.

A trading partner agreement may be used to define time parameters for the submission of the solicited 275 and the unsolicited 275 when not sent in the same interchange (ISA/IEA) as the 278. The 275 must be received by the UMO within the specified time frame or the request will proceed through the review process without the needed information. The ultimate disposition of the service review can include, but is not limited to, approval, rejection, or denial.

As a result of the potential impact on transmission and processing times and storage capacity, trading partners may find it necessary to establish size limitations for the BIN Segment. At a minimum, it is recommended that the content of the BIN not exceed 64 megabytes.

The 275 transaction set is intended to meet the particular needs of the health care industry to send additional information about a health care service review either when a) responding to a request for additional information or b) submitting an original 278 Health Care Services Review Request or Response. This 275 is also used in support of a 278 Health Care Services Notification.

The 275 is used to convey the attachment content in the HL7 Clinical Document Architecture (CDA) construct when the specific attachment type is available or is mandated by HIPAA. The CDA is a standard that expresses data using Extensible Markup Language (XML). The sender may alternatively choose to send the attachment content as an image without the use of the CDA construct when the attachment type is not mandated by HIPAA. The 275 supports the following business flows:

• solicited response to a 278 Health Care Services Review Response from a UMO requesting additional information or a paper request for additional information. See Figure 1.1.
• unsolicited additional information to support a 278 Health Care Services Review Request submitted in the same interchange envelope as the associated 278 or within a separate interchange. See Figures 1.2 and 1.3.
• unsolicited additional information to support a 278 Health Care Services Review Notification with patient information for exchange of information between health care entities. It may be submitted in the same interchange envelope as the associated 278 or within a separate interchange. See Figures 1.4 and 1.5.

The 275 Additional Information to Support a Health Care Services Review is used to send specific information to supplement an initial healthcare service review (unsolicited), or to provide information for a service review which requires additional information. In either case, the additional information is required for the approval process to be completed.

When a medical or utilization review is performed during the healthcare service review additional information may be needed. The UMO then requests specific information to supplement or support the provider's request for authorization of the services under review. The UMO request for additional information may be service specific or apply to the entire request. The 278 Health Care Services Review Response is used to transmit the request for additional information. The provider uses the 275 to respond to the 278 request (Figure 1.1).

In order to facilitate the adjudication of the 278 Health Care Services Review Request, the UMO may negotiate with providers or include as part of their Trading Partner Agreement a specified time period in which the provider may respond to the request for additional information. The 275 response must be received by the UMO within the specified time frame or the request will proceed through the review process without the needed information. The ultimate disposition of the service review can include, but is not limited to, approval, rejection, or denial.

When it is known at the time of the request that additional information is required by the UMO in order to complete the healthcare service review, the provider may submit an unsolicited 275. If done at the same time as the 278, the 275 may be sent within the same interchange (ISA/IEA) as the initial 278 (Figure 1.2). This situation requires separate GS/GE Functional Groups for the 278 and the 275. It may also be sent in a separate interchange (Figure 1.3). The unsolicited 275 eliminates the need for the UMO to request additional information via the 278 Health Care Services Review Response. A trading partner agreement may be used to define time parameters for the submission of the solicited 275 and the unsolicited 275 when not sent in the same interchange (ISA/IEA) as the 278. See Section 3, Transmission Examples.

This transaction is used to move information between health care entities to enable referral or transfer of care, support continuity of care and facilitate third party and subrogation processes. A 278 Health Care Services Review Notification provides for the exchange of information provider to provider, UMO to provider, UMO to payer, payer to payer, payer to TPL entity, etc. Exchanged information includes data such as notification of a review or service outcome, documentation of services provided, supporting information for a specialty referral and acknowledgment/error reporting.

Figure 1.1 illustrates the path of information related to the solicited business flow for the 275 Additional Information to Support a Health Care Services Review.

Figure 1.1. Solicited 275 EDI Transaction Flow

Arrow 1
This represents the submission of the 278 Health Care Services Review Request from the provider to the UMO. In this business model the 275 attachment, with the appropriate imbedded HL7 CDA containing the additional information, is not sent at the same time as the review request.

Arrow 2
After the request is received, the UMO may require additional information to complete the health care services review. The UMO then solicits this information by sending the 278 Health Care Services Review Response identifying the information needed.

Arrow 3
The provider responds to the request for additional information by sending to the UMO the 275 Additional Information to Support a Health Care Services Review with the appropriate imbedded HL7 CDA containing the additional information.

Arrow 4
The 278 Health Care Services Review Response is sent to the provider when the review process is completed.

Figure 1.2 illustrates the path of information related to the unsolicited business flow for the 275 Additional Information to Support a Health Care Services Review when the 278 and the 275 are sent in the same interchange.

Figure 1.2. Unsolicited 275 EDI Transaction Flow - 278 and 275 in Same Interchange

Arrow 1
This represents the submission of the 278 Health Care Services Review Request from the provider to the UMO. In this business model the 275 attachment, with the appropriate imbedded HL7 CDA containing the additional information, is sent at the same time as the review request within the same data interchange (ISA/IEA) as the associated 278. Each transaction set is contained within its own Functional Group (GS/GE) within the interchange.

Arrow 2
The 278 Health Care Services Review Response is sent to the provider when the UMO has completed the review process.

Figure 1.3 illustrates the path of information related to the unsolicited business flow for the 275 Additional Information to Support a Health Care Services Review when the 278 and the 275 are sent in a separate interchange.

Figure 1.3. Unsolicited 275 EDI Transaction Flow - 278 and 275 in Separate Interchange

Arrow 1
This represents the submission of the 278 Health Care Services Review Request from the provider to the UMO.

Arrow 2
In this business model the 275 attachment, with the appropriate imbedded HL7 CDA containing the additional information, is sent in a separate data interchange (ISA/IEA) than the associated 278; however, it is sent unsolicited.

Arrow 3
The 278 Health Care Services Review Response is sent to the provider when the UMO has completed the review process.

Figure 1.4 illustrates the path of information related to the business flow for the 275 Additional Information to Support a Health Care Services Review Notification when the 278 and the 275 are sent in the same interchange.

Figure 1.4. Unsolicited 275 EDI Transaction Flow - 278 Notification and 275 in Same Interchange

Arrow 1
This represents the submission of the 278 Health Care Services Review Notification from the Information Source to the Information Receiver. In this business model the 275 attachment, with the appropriate imbedded HL7 CDA containing the additional information, is sent at the same time as the notification within the same data interchange (ISA/IEA) as the associated 278. Each transaction set is contained within its own Functional Group (GS/GE) within the interchange.

Arrow 2
The 278 Health Care Services Review Notification Acknowledgement/Error is sent to the Information Source when the Information Receiver acknowledges receipt.

Figure 1.5 illustrates the path of information related to the business flow for the 275 Additional Information to Support a Health Care Services Review Notification when the 278 and the 275 are sent in separate interchanges.

1.5. Unsolicited 275 EDI Transaction Flow - 278 Notification and 275 in Separate Interchange

Arrow 1
This represents the submission of the 278 Health Care Services Review Notification from the Information Source to the Information Receiver.

Arrow 2
In this business model the 275 attachment, with the appropriate imbedded HL7 CDA containing the additional information, is sent in a separate data interchange (ISA/IEA) than the associated 278; however, it is sent unsolicited.

Arrow 3
The 278 Health Care Services Review Notification Acknowledgment/Error is sent to the Information Source when the Information Receiver acknowledges receipt.

The following business terms are used in this implementation guide.

Attachment Component (Question) - An attachment "component" or "question" is a smaller unit of the full attachment that represents a single concept or question. For example, "What is the EMS transport, reason for scheduled trip?" or "What is the Rehabilitation Treatment Plan, Author of Treatment Plan?" are types of questions that could be asked from the ambulance and rehabilitation services attachments, respectively.

Attachment Component Answer Part (Answer) - An attachment component answer part represents the individual parts that make up the answer to component/ question. An attachment component/question can have one or more answer parts. For example the question "What is the EMS transport, reason for scheduled trip?" has only one answer part which would define the reason for the scheduled trip from a coded value list. The question "What is the Rehabilitation Treatment Plan, Author of Treatment Plan?" has multiple answer parts: the Author Name, the Author ID and the Author Taxonomy Code. The Author Name and Author ID are required and the Author Taxonomy Code is not required per the HL7 Additional Information Specification (AIS). If the requester only needs the Author ID, they do not need to ask for the entire component/question. Any answer part may be requested in the HI segment of the 278 Response, using the appropriate LOINC® for that answer part, for example the LOINC® identified in the HL7 AIS as the answer part "Author ID".

Logical Observation Identifier Names and Codes (LOINC®) Code List
LOINC® codes are universal identifiers for laboratory and other clinical observations designed to facilitate the exchange and pooling of clinical observations and results of diagnostic investigations (such as blood hemoglobin, serum potassium, or vital signs) for clinical care, outcomes management, and research. For attachments, LOINC® identifies both the question (asked by the UMO) and the answer (given by the provider). The LOINC® database and its supporting utilities and documentation are maintained by the Regenstrief Institute.

Patient event
Patient event in this guide refers to the service or group of services associated with a single episode of care. Examples include the following:

• Admission to a facility for treatment related to a specific patient condition or diagnosis or related group of diagnoses
• Referral to a specialty provider for consultation or testing to determine a specific diagnosis and appropriate treatment
• Services administered during a patient visit such as chiropractic treatment delivered in a single patient visit. The same treatment can be approved for a series of visits.

Utilization Management Organization (UMO)
UMO refers to insurance companies, health maintenance organizations, preferred provider organizations, health care purchasers, professional review organizations, third-party administrators, other providers, and other utilization review entities that receive and respond to health care service review requests and inquiries. The UMO may or may not be the organization that makes the medical decision. The UMO might have a relationship with a payer that calls for the payer to make a decision or store information on completed referrals and certifications. It is the role of the UMO to forward that request or inquiry to the payer, receive the response from the payer, and then return the response to the requester. From the requester’s perspective, the exchange of information is between the requester and the UMO.

There are several acknowledgment implementation transactions available for use. The IG developers have noted acknowledgment requirements in this section. Other acknowledgment transactions may be used at the discretion of the trading partners. A statement that the acknowledgment is not required does not preclude its use between willing trading partners.

The 997 informs the submitter that the functional group arrived at the destination. It may include information about the syntactical quality of the functional group.

The Functional Acknowledgment (997) transaction is not required as a response to receipt of a batch transaction compliant with this implementation guide.

The Functional Acknowledgment (997) transaction is not required as a response to receipt of a real-time transaction compliant with this implementation guide.

A 997 Implementation Guide is being developed for use by the insurance industry and is expected to be available for use with this version of this Implementation Guide.

The 999 informs the submitter that the functional group arrived at the destination. It may include information about the syntactical quality of the functional group and the implementation guide compliance.

The Implementation Acknowledgment (999) transaction is not required as a response to receipt of a batch transaction compliant with this implementation guide.

The Implementation Acknowledgment (999) transaction is not required as a response to receipt of a real-time transaction compliant with this implementation guide.

A 999 Implementation Guide is being developed for use by the insurance industry and is expected to be available for use with this version of this Implementation Guide.

The 824 informs the submitter of the results of the receiving application system’s data content edits of transaction sets.

The Application Advice (824) transaction is not required as a response to receipt of a batch transaction compliant with this implementation guide.

The Application Advice (824) transaction is not required as a response to receipt of a real-time transaction compliant with this implementation guide.

An 824 Implementation Guide is being developed for use by the insurance industry and is expected to be available for use with this version of this Implementation Guide.

There are one or more transactions related to the transaction described in this implementation guide.

ASC X12 278 Health Care Services Review - Request for Review and Response, and the ASCX12 278 Health Care Services Review - Notification. Reference to specific versions of the 278 implementation standard is intentionally omitted to enable use of this transaction with any version of the 278.

In addition to the ASC X12 transactions listed above, the HL7 CDA standard is related to the 275.

When a service request fails to complete the UMO's review, the UMO can respond with a 278 Health Care Services Review Response containing a request for additional information. Data from the original request is returned to the provider to facilitate locating the supporting information. The reason for the additional information is to aid in medical necessity decisions regarding the service requested.

When a request needs additional information to complete the review process, the provider can send an unsolicited 275 Additional Information to Support a Health Care Services Review (X211) in support of the 278 Health Care Services Review Request.

The provider or information source can also send additional information in conjunction with a 278 Health Care Services Review Notification. For example, in a notification of discharge, the provider may need to attach information on the condition of the patient at the time of discharge; or a specialist may provide health care services outcome to the referring provider.

The ANSI approved HL7 CDA is the standard being used to represent the attachment content and is imbedded in the 275. The following documents are included in the attachment package and define how to represent attachment content using the HL7 CDA:

• HL7 Additional Information Specification Implementation Guide — this document defines the conceptual approach for attachments using the HL7 CDA and how the HL7 CDA is constructed for health care attachments. This includes the rules for constructing the XML based CDA for attachments, the role of LOINC® in attachments, how the Additional Information Specifications (AIS) are used, and statements that define what constitutes compliance.
• LOINC® Modifiers — defines the modifier categories, LOINC® modifier codes and how they are used in the 278.
• HL7 Additional Information Specifications (AIS) — the AIS document is used to express additional information content (questions and answers). Each attachment type or category of attachments will be represented in a single AIS.

The 824 is an acknowledgement transaction which allows reporting errors that are outside of the scope of the ANSI ASC X12 997 error reporting. In addition to errors in X12N transactions, the 824 can be used to report errors occurring within the BIN Segment and CDA. Use of this and/or other appropriate X12 acknowledgement transactions is recommneded.

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

A trading partner agreement may be used to define time parameters for the submission of the solicited 275 and the unsolicited 275 when not sent in the same interchange (ISA/IEA) as the 278.

Administrative Simplification provisions of the Health Insurance Portability and Accountability Act of 1996 (PL 104-191 - known as HIPAA) direct the Secretary of Health and Human Services to adopt standards for transactions to enable health information to be exchanged electronically and to adopt specifications for implementing each standard.

This implementation guide has been developed for use as an insurance industry implementation guide. At the time of publication it has not been adopted as a HIPAA standard. Should the Secretary adopt this implementation guide as a standard, the Secretary will establish compliance dates for its use by HIPAA covered entities.

This section introduces the structure of the 275 Additional Information to Support a Health Care Services Review and describes the positioning of the business data within that structure. Familiarity with ASC X12 nomenclature, segments, data elements, hierarchical levels, and looping structures is recommended. For a review, see Appendix B Nomenclature, and Appendix C, EDI Control Directory.

This implementation guide assumes the use of the ASCII format. If a format other than ASCII is used, then the appropriate conversions must be applied wherever ASCII is explicitly required. The contents of the BIN segment must be encoded as text.

Note: Data requirements on the request for additional information are consistent between a paper and the 278 electronic request. Within this guide, the data requirements are frequently identified in terms of the ASC X12 278 Health Care Services Review Response transaction set. When necessary, reference that guide for details about the data. The 275 Additional Information to Support a Health Care Services Review transaction uses much of the data on the 278 response.

Two formats or views are used to present the transaction set: the implementation view and the standard view. Figure 1.6. 275 Transaction Set Listing, shows the implementation view. This view displays only the segments and their designated health care names described in this implementation guide. The intent of the implementation view is to clarify the purpose and use of the segments by restricting the view to display only those segments used with their assigned health care names. This implementation view is also repeated in Section 2.

Figure 1.6. 275 Transaction Set Listing

The standard view is presented in Section 2, Transaction Set. The standard view displays all segments available within the transaction set with their assigned ASC X12 names.

When a request for additional information is made, the UMO supplies the parameters that assist the provider in locating the documents needed for the healthcare service review. These parameters are frequently the Patient Account Number, Patient Event Tracking Number, Diagnosis Code and Procedure Code or Revenue Code. The provider is the source of this information. If the information is found on the original 278 Health Care Services Review Request, the UMO returns those data elements in the 278 Health Care Services Review Response that contains the UMO's request for additional information.

If at the time of submitting the request for review, the provider determines that additional information is needed for completion of the review, an unsolicited 275 may be sent. In this usage the provider supplies the parameters to enable the UMO to match the supporting information to the 278 request for review.

When the Additional Information is submitted in the 275, it will either be related to the entire healthcare services review or to a specific revenue line or service line. The segments used to convey the requested information are more clearly identified by specifying whether the information is related to the service line level. The TRN segment is required and will either contain the UMO attachment control number sent in the 278 Response or, if unsolicited, the provider assigned attachment control number.

The 275 is divided into two tables. Table 1 contains transaction control information as presented in 1.10.2.1. Table 2 contains the detail information for the business function of the transaction as presented in 1.10.2.2. The following presents the developers' view of which segments are returned for patient event and service level information.

Table 1 is named the Header Level. The purpose of Table 1 is to identify the transaction, distinguish the business purpose, and identify the participants. See Figure 1.7 for an example of Table 1.

Figure 1.7. Table 1 - Header Level

The Transaction Set Header Segment (ST) identifies the transaction set by using 275 as the data value for the transaction set identifier code data element, ST01. The originator of the transaction set assigns the unique control number ST02 which is shown here as 1001. In this example, the originator is the provider. ST03 carries the same value that is populated in GS08 which is the Implementation Version Identifier. For this 275 transaction the identifier is 005010X211.

The Beginning Segment (BGN) indicates the transaction use. The Transaction Set Purpose Code value of "11" in the BGN01 indicates that this 275 is a response to a 278 Request for Additional Information Response. A value of "02" indicates that this is an unsolicited 275 with additional information for a 278 Healthcare Service Review. A value of "22" indicates that the information is in support of the 278 Health Care Services Review Notification. The originator of the transaction set assigns the unique reference number in BGN02 and the date of creation in BGN03. The Functional Group Header Segment (GS) provides additional identification of the business purpose of multi-functional transaction sets. See Appendix C, EDI Control Directory, for a detailed description of the elements in the GS segment.

A coding example of Table 1 in the 275 Additional Information to Support a Health Care Services Review follows. See Appendix B, Nomenclature, for descriptions of data element separators (e.g., *) and segment terminators (e.g., ~).

ST*275*1001*005010X211~ 
BGN*02*0001*20050724~ 

The Loop ID: 1000 is repeated to define the participants involved in the transaction. The participants identified in the 275 are generally the information source, information receiver, and patient. The implementation guide specifies the participants in the subsequent loops within the transaction set and refers to these participants, respectively, in the following order and terms:

• Information Source — This identifies the person or organization that owns/provides this patient information.
• Information Receiver — This is the person or organization that is in receipt of this additional information.
• Patient — This is the person receiving the services. The additional information supports the health care service review related to these services.

Transaction Participants

Loops 1000A, 1000B and 1000C contain the segments and data elements that describe the participants. The coding examples are presented sequentially as found within an actual transaction set; however, for reading ease each segment begins on a new line.

The following example demonstrates coding for segments and data elements when the 275 is provided in response to a request for additional information.

Loop 1000A - Information Source - Provider
Loop 1000B - Information Receiver - UMO
Loop 1000C - Patient

NM1 Segment

The NM1 segment is mandatory and is used to identify the transaction participants (see NM108 and NM109).

NM1 Information Source

NM1*FA*2*ST HOLY HILLS HOSPITAL*****XX*9987654321~

Within the NM1 segment,

NM101 = FA
This value indicates that the information source is a facility.

NM102 = 2
This value indicates that the entity is a non-person.

NM103 = ST HOLY HILLS HOSPITAL
This value identifies the Information Source as ST HOLY HILLS HOSPITAL. The name of the Information Source is not required.

NM108 = XX
This value identifies the next data element as the entity's National Provider Identifier.

NM109 = 9987654321
The NM109 value is the actual identification code associated with NM108 (e.g., XX). The identification code listed in NM109 refers to St. Holy Hills Hospital.

NM1 Information Receiver

NM1*X3*2*ABC INSURANCE COMPANY*****24*123456789~ 
PER*IC*MEDICAL REVIEW DEPARTMENT~

Within the NM1 segment,

NM101 = X3
This value indicates that the participant is a UMO.

NM102 = 2
This value indicates that the entity is a non-person.

NM103 = ABC INSURANCE COMPANY
This value identifies the Information Receiver as "ABC INSURANCE COMPANY". The name of the receiver is not required.

NM108 = 24
This value identifies the next data element as the Employer's Identification Number.

NM109 = 123456789
The NM109 value is the actual identification code associated with NM108 (e.g., 24). The identification code listed in NM109 refers to ABC INSURANCE COMPANY.

Information Receiver PER Segment
The UMO uses the PER segment in the 278 Health Care Services Review Response containing the request for additional information to specify the administrative communications contact who should receive the additional information when sent back by the provider. The PER segment of the Information Receiver NM1 Loop in the 275 is used to identify the entity who is expecting to receive the additional information from the provider.

The following example demonstrates the identification of the entity to whom the provider should return the additional information:

PER*IC*MEDICAL REVIEW DEPARTMENT~

Within the PER segment,

PER01 = IC
This value indicates that the person or group named is the Information Contact.

PER02 = MEDICAL REVIEW DEPARTMENT
This value is the person or group name.

NM1 Patient Information

NM1*IL*1*SMITH*JOHN****MI*111223333A~ 
REF*21*20022431100~

Within the NM1 segment,

NM101 = IL
This value indicates that the patient is the subscriber.

NM102 = 1
This value indicates that the patient is a person.

NM103 = SMITH
This value indicates that the patient's last name is Smith.

NM103 = JOHN
This value indicates that the patient's first name is John

NM108 = MI
This value indicates that following information is the patient's payer assigned identification number.

NM109 = 111223333A
This value is the patient's identification number.

Patient REF Segment at the NM1 Level
The primary link between this 275 and its associated 278 is the TRN Patient Event Tracking Number assigned by the provider. The TRN enables the provider to link all transactions associated with this patient event. The REF segment can be repeated a maximum of two times at the Patient NM1 loop level for this implementation. The provider's patient account number, and the patient event tracking number are found in the REF segment. The Patient Account number is a supplemental identifier for the provider's use.

The following are coding examples of the REF segment:

REF*EJ*JS960503LAB~ 
REF*2I*20022431100~

Within the REF segment,

REF01 = EJ
This value indicates that the next data element contains the Patient Account Number.

REF02 = JS960503LAB
The value shown is the actual Patient Account Number assigned by the provider for the initial Health Care Services review request.

When REF01 is 2I, REF02 contains the patient event tracking number.

The order of the REF segments is not significant.

The structure used in Table 2 is based on the 2000A LX Loop. The LX Loops (Loop 2000A and its subordinate loops 2100A and 2110A) specify the additional information provided to support a healthcare service review.

Figure 1.8, Table 2 - Detail Level, presents the detail segments that define the specific information that is being sent in the 275.

Figure 1.8. Table 2 - Detail Level

The following is a coding example of the 275 Additional Information to Support a Health Care Services Review when providing patient event or service level additional information.

LX*1~ 
TRN*2*1722634842~ 
STC*R3:11504-8::LOI~ 
REF*FJ*1234~ 
REF*CPT*44397~ 
DTP*368*D8*20050724~ 
CAT*AE*HL~ 
EFI*05~ 
BIN*52*<levelone xmlns="urn:hl7-org:v3/cda" 
xmlns:v3dt …/cda levelone_1.0.attachments.xsd"> 
      X 
         X 
      X 
</levelone>~ 

LX Segment

The LX loop denotes the beginning of a separate response or another type of additional information related to the patient event or to a specific service or procedure.

The following is a coding example of the LX segment:

 LX*1~ 

Within the LX, LX01 is the sequence number assigned to identify the group of segments that follow. It is required that the LX01 sequence number start at 1 and increment by 1.

TRN Segment

The Trace Segment (TRN) is a mandatory segment. The TRN segment serves two scenarios. First, the Attachment Control Number, when transmitted in the unsolicited 275 transaction contains the attachment control number submitted in the PWK segment of the 278 transaction. The second scenario involves a solicited response to a request for additional information from a UMO. In this situation, the attachment control number contains the key in the UMO's system to trace and match the response back to the appropriate request for additional information.

The following is a coding example of the TRN segment:

 TRN*2*1722634842~ 

Within the TRN,

TRN01 = 2
The value in TRN01 will be "2" when this transaction is requested.

TRN01 will be "1" when the additional information is unsolicited.

TRN02 = 1722634842
The value shown is the reference identifier assigned by the UMO for this health care services review. This was given in the previous 278 response. The provider will return the value found in this element to the UMO.

When submitting unsolicited additional information to support a 278 Health Care Services Review Request or Notification, the originator of the transaction will replicate the Attachment Control Number that was given in the PWK segment of the 278 transaction.

STC Segment

The purpose of the STC segment in Loop 2000 is for the provider to return the question received from the UMO in the 278 Health Care Services Review Response.

The following is a coding example when responding to a request for additional information contained in the Service level of the 278 response.

 STC*R4:11504-8::LOI~ 

Within the STC,

STC01-1 = R4
This value indicates that the review has been suspended for additional information/ documentation.

STC01-2 = 11504-8
This value is asking for the description of a surgical procedure.

STC01-4 = LOI
This value indicates the table used for STC01-2 was the Logical Observation Identifier Names and Codes (LOINC®) Code List.

REF Segment at Loop 2000

In this example, the REF Segment is used to identify the Service Trace Number and the procedure for which the information in the BIN Segment is submitted. When information for more than one diagnosis or procedure is required to support a health care services review, the detail segments in 2000A, 2100A and 2110A Loops are repeated.

The following are coding examples of the REF segment:

 REF*FJ*1234~ 

Within the REF,

REF01 = FJ
The value FJ indicates that the next element contains the service trace number.

REF02 = 1234
This is the service trace number.

 REF*CPT*44397~ 

Within the REF,

REF01 = CPT
This value indicates that the next data element contains the procedure code.

REF02 = 44397
The value shown is the procedure code that was submitted on the original health care services review.

DTP Segment - Date Additional Information was Submitted

The DTP segment at the start of the 2100A Loop is an important segment. At this location, the DTP segment identifies the date that the information was submitted to the UMO. This segment is required in order to use the BIN segment.

The following is a coded example of the DTP segment at the service line level:

 DTP*368*D8*20051024~ 

Within the DTP,

DTP01 = 368
This value is the date/time qualifier element. When the value is "368", the date found in DTP03 is known to be the submitted date.

DTP02 = D8
This value is the date/time period format qualifier. When this value is "D8", the format of the date in DTP03 is known to be CCYYMMDD.

DTP03 = 20051024
The date represented in DTP03 is the submitted date for this information, as defined by the prior qualifiers.

CAT Segment

The CAT segment conveys the format type of the information that will be in the BIN segment. It is used to identify if the BIN contains an electronic image, a CDA formatted as a human decision variant or computer decision variant.

The following is a coded example of the CAT segment at the service line level:

 CAT*AE*HL~ 

Within the CAT,

CAT01 = AE
This value indicates that the data in the BIN segment is an attachment.

CAT02 = HL
The value shown indicates that data within the BIN is an HL7 message the contents of the BIN Segment are in the HL7 CDA computer decision variant.

EFI Segment

The EFI segment is required in order to use the BIN segment. It is used to convey the sender assigned level of confidentiality that applies to the information found in the following BIN segment.

The following is a coded example of the EFI segment at the service line level:

 EFI*05~ 

Within the EFI,

EFI01 = 05
This value represents that the security level has been defined as personal.

BIN Segment

The BIN segment is used to place additional information. It allows for the use of HL7 messages standard using the 275 transaction as the envelope. This implementation guide assumes the use of the ASCII format. If a format other than ASCII is used, then the appropriate conversions must be applied wherever ASCII is explicitly required. The contents of the BIN segment must be encoded as text.

 BIN*52*<levelone xmlns="urn:hl7-org:v3/cda" 
xmlns:v3dt …/cda levelone_1.0.attachments.xsd"> 
      X 
         X 
      X 
</levelone>~ 

Within the BIN,

BIN01 = 52
This represents the number of bytes of data that will follow.

Senders must ensure that the count in BIN01 is equal to the byte count of the contents in BIN02.

BIN02 is where the HL7 Message standard begins and is ended by the segment delimiter.

It has been noted that line constraints, transfer protocols, zip programs or conversion processes may insert additional control characters such as, line feeds or carriage returns or other special characters into a transaction. If this occurs in BIN02, the sender's stated count in BIN01 may no longer be equal to the received contents of the data in BIN02.

NOTE
See Appendix B, Nomenclature, to review the transaction set structure, including descriptions of segments, data elements, levels, and loops.

The ASC 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:

2.3 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.

2.4 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

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

A transmitted transaction complies with an implementation guide when it satisfies the requirements as defined within the implementation guide. 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.

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

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

The 275 Additional Information to support a Health Care Services Review enables the requester to electronically send supporting information to justify a request for health care services. The requester can send it with the original 278 Health Care Services Review Request (unsolicited) or at the request of the UMO (solicited). A solicited request for additional information occurs when the UMO responds with the 278 Health Care Services Review Response and communicates a need for additional information as stated in the HI segment of the transaction. The UMO uses LOINC® to convey the information needed.

Part one of the following scenario demonstrates how a provider electronically submits additional information at the time the original request is submitted (unsolicited). Part two of the scenario demonstrates how a provider would submit additional information as a response to a UMO's request for additional information (solicited). Part three depicts the same scenario as part one, however in this instance the provider is submitting a scanned image of the operative report. These examples show the appropriate usage of the 275 Additional Information to Support a Health Care Services Review with the HL7 Clinical Notes and Rehabilitation Additional Information Specification (AIS) booklets. As a result of line constraints some of the XML examples may be word wrapped.

This scenario depicts the utilization of the ANSI ASC X12 275 Additional Information to Support a Health Care Services Review. In this scenario the Clinical Reports AIS was sent to the UMO at the same time as the 278 Health Care Services Review Request and was not solicited by the payer. The request and AIS were accepted into the UMO's system. The UMO processed the request and determined that additional information was needed on the patient's current level of function and recommended modalities to make a decision on the request for rehabilitative services. The UMO returns to the provider a 278 response containing the appropriate questions for the additional information. The provider responds to the request giving the necessary information in a 275 transaction.

All individuals and institutions named in the following assumptions and examples are fictitious as are the details of the services provided or requested.

Assumptions
On 09-21-2005 the requesting provider submits a request for approval of rehabilitation services for Peter Jones. Mr. Jones' member identification number is 123456789A. The requesting provider for these services is Dr. Robert Douglas Fitch, M.D., the orthopedic surgeon. Dr. Fitch's provider number is 3999000086. The provider has included the Clinical AIS with the operative notes from Mr. Jones' 09-20-2005 surgery. Mr. Jones requires 3 - 15 minute neuromuscular reeducation physical therapy sessions a week for a duration of 6 weeks. Dr. Fitch has requested that physical therapy be provided by Stanley and Associates Physical Therapy. The request includes the attached post-operative notes. The provider assigns an Attachment Control Number of JONP56789001.

The UMO, ABC Insurance Company with a payer identifier of 05440, receives the electronic 278 Request and the 275 transaction with the Clinical Report AIS. ABC Insurance responds to Dr. Fitch on 09-26-2005 with a 278 Response containing a request for additional information to support the rehabilitation therapy. ABC Insurance Company has assigned a tracking number of 1822634845.

On September 28, 2005, the Dr. Fitch's practice responds by transmitting the 275 and HL7 Rehabilitation AIS attachment to the UMO.

This example shows the relevant segments of the unsolicited 275 submitted with the 278 Health Care Services Review Request for authorization of rehabilitation services including the HL7 Clinical Reports AIS containing the operative notes. In this example the attachment is in the Human Decision Variant. Refer to the 278 Health Care Services Review implementation guide being utilized for information regarding the construct of the 278 Request.

ST*275*0002*005010X211~

BGN*02*20020926002*20050921*0629~

NM1*1P*1*FITCH*ROBERT*DOUGLAS***XX*3999000086~

NM1*X3*2*ABC INSURANCE COMPANY*****PI*05440~

NM1*QC*1*JONES*PETER*M***MI*123456789A~

REF*2I*200209261~

LX*1~

TRN*1*JONP56789001~

REF*ICD*73681~

DTP*368*D8*20050926~

CAT*AE*TX~

EFI*05~

BIN*3117*

<levelone xmlns="urn:hl7-org:v3/cda" 
xmlns:v3dt="urn:hl7-org:v3/v3dt" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:hl7-org:v3/cda 
levelone_1.0.attachments.xsd"> 
  <clinical_document_header> 
    <id EX="a123" RT="2.16.840.1.113883.3.933"/> 
    <document_type_cd V="11504-8" DN="Provider Unspecified Operative Note"/> 
    <origination_dttm V="2005-09-21"/> 
    <provider> 
      <provider.type_cd V="PRF"/> 
      <person> 
        <id EX="3999000086" RT="2.16.840.1.113883.4.6"/> 
        <id EX="RFD123" RT="2.16.840.1.113883.19.4.1"/> 
        <person_name> 
          <nm> 
            <v3dt:GIV V="Robert"/> 
            <v3dt:FAM V="Fitch"/> 
            <v3dt:MID V="Douglas"/> 
            <v3dt:SFX V="MD" QUAL="PT"/> 
          </nm> 
          <person_name.type_cd V="L" S="2.16.840.1.113883.5.200"/> 
        </person_name> 
      </person> 
    </provider> 
    <patient> 
      <patient.type_cd V="PATSBJ"/> 
      <person> 
        <id EX="JONP56789" RT="2.16.840.1.113883.19.4.2"/> 
        <person_name> 
          <nm> 
            <v3dt:GIV V="Peter"/> 
            <v3dt:FAM V="Jones"/> 
            <v3dt:MID V="M"/> 
          </nm> 
          <person_name.type_cd V="L" S="2.16.840.1.113883.5.200"/> 
        </person_name> 
      </person> 
      <is_known_by> 
        <id EX="JONP56789" RT="2.16.840.1.1138863.19.4.2"/> 
        <is_known_to> 
          <id EX="123456789A" RT="2.16.840.1.113883.19.4.3"/> 
        </is_known_to> 
      </is_known_by> 
    </patient> 
    <local_header descriptor="Att_ACN"> 
      <local_attr name="attachment_control_number" value="JONP56789001"/> 
    </local_header> 
  </clinical_document_header> 
  <body> 
    <section> 
      <caption>Date Surgery</caption> 
      <paragraph> 
        <content>2005-09-20</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption>Pre-operative Diagnosis Narrative</caption> 
      <paragraph> 
        <content>Left leg length discrepancy</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption>Post-operative Diagnosis Narrative</caption> 
      <paragraph> 
        <content>Left leg length discrepancy</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption>Surgical Procedure Narrative</caption> 
      <paragraph> 
        <content>Right distal femoral epiphysiodesis</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption>Anesthesia Narrative</caption> 
      <paragraph> 
        <content>General endotracheal</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption>Fluids</caption> 
      <paragraph> 
        <content>500 cc of lactated ringer's</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption>Estimated Blood Loss Volume</caption> 
      <paragraph> 
        <content>300 cc</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption>Surgical Drains</caption> 
      <paragraph> 
        <content>None</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption>Complications</caption> 
      <paragraph> 
        <content>None</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption>Surgery Description</caption> 
      <paragraph> 
        <content>The patient was brought to the operating room and placed supine on the operating table. Following the administration of general endotracheal anesthetic, a non-sterile tourniquet was placed on the patient's right upper thigh. The patient's right lower extremity was then prepped and draped in the normal sterile fashion. Attention was then turned to the right distal femoral epiphysis. Fluoroscopy was used to isolate the level of the epiphysis. An approximately 1 cm incision was then made on the lateral aspect of the distal thigh. Subcutaneous tissues were incised in line with the skin incision. The dissection was carried bluntly down to the lateral aspect of the femur. A Steinmann pin was then placed to cross the distal femoral site, this using fluoroscopy as a guide. The pin was then over drilled with a 9 mm and then an 11 mm drill bit. Dr. Davidson revascularized the fibular graft set. The Steinmann pin was then removed. The remaining portion of the epiphyseal plate was removed using an angled curette. Incision was made medially when the Steinmann pin was placed across the epiphyseal plate, which also measured approximately 1 cm. This was used to insert the curette to assist with destruction of the medial epiphyseal plate. One epiphyseal plate had been thoroughly destroyed, destruction was confirmed using fluoroscopy. The wounds were then thoroughly irrigated with normal saline containing bacitracin. Deep fascial layer was closed using figure-of-eight sutures of #0 Vicryl. Subcutaneous tissues were reapproximated using interrupted inverted sutures of 20 Vicryl. The skin was closed with a 4-0 subcuticular stitch. The wounds were cleaned and dried and dressed with Steri-Strips, Xeroform, sterile gauze, and a bulky Jones wrap. The tourniquet was deflated prior to application of the bulky Jones wrap. The patient was then placed in a knee immobilizer. There were no intraoperative complications. Dr. Fitch was present for the critical portion of the case. The patient was successfully extubated and transported to the recovery room in stable condition.</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption>Provider Signing Name</caption> 
      <paragraph> 
        <content>Robert Douglas Fitch, MD</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption>Surgeon Resident Name</caption> 
      <paragraph> 
        <content>Robert Douglas Fitch, MD</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption>Surgeon Staff Name</caption> 
      <paragraph> 
        <content>Samuel David Stanley, MD and James D. Davidson, MD</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption>Provider Dictating Practitioner Name</caption> 
      <paragraph> 
        <content>Samuel David Stanley, MD</content> 
      </paragraph> 
    </section> 
  </body> 
</levelone>~ 

SE*14*0002~

Rendered View
On the following page is the above example as rendered with the style sheet included in the HL7 Implementation Guide.

ABC Insurance Company processes the request and determines that additional information is necessary in respect to the patient's medical history and current range of motion. This example depicts the 275 submitted in response the 278 requesting additional information. The HL7 attachment is depicted in the Computer Decision Variant. Refer to the 278 Health Care Services Review implementation guide being utilized for information regarding the construct of the 278 Response.

Dr. Fitch's office responds to the request for additional information and returns the solicited 275 with the appropriate Rehabilitation AIS response.

ST*275*0003*005010X211~

BGN*11*20020926003*20050926*0632~

NM1*1P*1*FITCH*ROBERT*DOUGLAS***XX*3999000086~

NM1*X3*2*ABC INSURANCE COMPANY*****PI*05440~

PER*IC*MEDICAL REVIEW UNIT~

NM1*QC*1*JONES*PETER*M***MI*123456789A~

REF*2I*200209261~

LX*1~

TRN*2*ABCJONES200201~

STC*R4:27685-7::LOI~

REF*CPT*97112~

DTP*368*D8*20050928~

CAT*AE*HL~

EFI*05~

BIN*535*

<levelone xmlns="urn:hl7-org:v3/cda" 
xmlns:v3dt="urn:hl7-org:v3/v3dt" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:hl7-org:v3/cda 
levelone_1.0.attachments.xsd"> 
  <clinical_document_header> 
    <id EX="a123" RT="2.16.840.1.113883.3.933"/> 
    <document_type_cd V="11504-8" DN="Physical Therapy Rehabilitation Attachment"/> 
    <origination_dttm V="2005-09-28"/> 
    <provider> 
      <provider.type_cd V="PRF"/> 
      <person> 
        <id EX="3999000086" RT="2.16.840.1.113883.4.6"/> 
        <id EX="RFD123" RT="2.16.840.1.113883.19.3.1"/> 
        <person_name> 
          <nm> 
            <v3dt:GIV V="Robert"/> 
            <v3dt:FAM V="Fitch"/> 
            <v3dt:MID V="Douglas"/> 
            <v3dt:SFX V="MD" QUAL="PT"/> 
          </nm> 
          <person_name.type_cd V="L" S="2.16.840.1.113883.5.200"/> 
        </person_name> 
      </person> 
    </provider> 
    <patient> 
      <patient.type_cd V="PATSBJ"/> 
      <person> 
        <id EX="JONP56789" RT="2.16.840.1.113883.19.3.2"/> 
        <person_name> 
          <nm> 
            <v3dt:GIV V="Peter"/> 
            <v3dt:FAM V="Jones"/> 
            <v3dt:MID V="M"/> 
          </nm> 
          <person_name.type_cd V="L" S="2.16.840.1.113883.5.200"/> 
        </person_name> 
      </person> 
      <is_known_by> 
        <id EX="JONP56789"  RT="2.16.840.1.1138863.19.3.2"/> 
        <is_known_to> 
          <id EX="123456789A"  RT="2.16.840.1.113883.19.3.3"/> 
        </is_known_to> 
      </is_known_by> 
    </patient> 
    <local_header descriptor="Att_ACN"> 
      <local_attr name="attachment_control_number" value="ABCJONES200201"/> 
    </local_header> 
  </clinical_document_header> 
  <body> 
    <section> 
      <caption> 
        <caption_cd V="18626-2" S="2.16.840.1.113883.6.1">New/Revised 
      </caption> 
      <paragraph> 
        <content>Original 
          <coded_entry> 
            <coded_entry.value V="700" S="2.16.840.1.113883.12.9002" SN="HL79002"/> 
          </coded_entry> 
        </content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18627-0" S="2.16.840.1.113883.6.1"/> 
      Date of Onset or Exacerbation of Primary Diagnosis 
      </caption> 
      <paragraph> 
        <content>20 March 2005 
          <local_markup descriptor="dt_DT" ignore="all">2005-03-20</local_markup> 
        </content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18628-8" S="2.16.840.1.113883.6.1"/> 
        Treatment Plan Start Date 
      </caption> 
      <paragraph> 
        <content>28 September 2005 
          <local_markup descriptor="dt_DT" ignore="all">2005-09-28</local_markup> 
        </content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="19007-4" S="2.16.840.1.113883.6.1"/> 
        Primary Diagnosis 
      </caption> 
      <paragraph> 
        <content>Acquired leg length discrepancy secondary to crushing injury (736.81) 
          <coded_entry> 
            <coded_entry.value V="736.81" S="2.16.840.1.113883.6.2" SN="ICD-9-CM"/> 
          </coded_entry> 
        </content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18631-2" S="2.16.840.1.113883.6.1"/> 
        Diagnosis Addressed by Plan 
      </caption> 
      <paragraph> 
        <content>Acquired leg length discrepancy secondary to crushing injury (736.81) 
          <coded_entry> 
            <coded_entry.value V="736.81" S="2.16.840.1.113883.6.2" SN="ICD-9-CM"/> 
          </coded_entry> 
        </content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18632-0" S="2.16.840.1.113883.6.1"/> 
        Author of Treatment Plan 
      </caption> 
      <paragraph> 
        <caption> 
          <caption_cd V="18633-8" S="2.16.840.1.113883.6.1"/> 
        Author Name 
        </caption> 
        <content>Rober P. Moats, MSPT 
          <local_markup descriptor="dt_PN"> 
            <local_markup descriptor="dt_PN_GIV">Roger 
            </local_markup"> 
            <local_markup descriptor="dt_PN_MID">P 
            </local_markup"> 
            <local_markup descriptor="dt_PN_FAM">Moats 
            </local_markup"> 
            <local_markup descriptor="dt_PN_SFX">MSPT 
            </local_markup"> 
          </local_markup"> 
        </content> 
      </paragraph> 
      <paragraph> 
        <caption> 
          <caption_cd V="18730-2" S="2.16.840.1.113883.6.1"/> 
        Author Identifier 
        </caption> 
        <content>6532157335 (WV) 
          <local_markup descriptor="dt_CX"> 
          <local_attr name="dt_CX_EX" value="6532157335"/> 
          <local_attr name="dt_CX_RT" value="2.16.840.1.113883.5.1"/> 
          <local_markup/> 
        </content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18637-9" S="2.16.840.1.113883.6.1"/> 
        Visit Frequency 
      </caption> 
      <paragraph> 
        <content>Three 15-30 minute sessions per week for 4-6 weeks</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18639-5" S="2.16.840.1.113883.6.1"/> 
        Date Range (From/Through) Described by the Plan 
      </caption> 
      <paragraph> 
        <caption> 
          <caption_cd V="18640-3" S="2.16.840.1.113883.6.1"/> 
        Start Date 
        </caption> 
        <content>28 September 2005 
          <local_markup descriptor="dt_DT" ignore="all">2005-09-28<local_markup> 
        </content> 
      </paragraph> 
      <paragraph> 
        <caption> 
          <caption_cd V="18641-1" S="2.16.840.1.113883.6.1"/> 
        Plan End Date 
        </caption> 
        <content>11 Nov 2005 
          <local_markup descriptor="dt_DT" ignore="all">2005-11-11</local_markup> 
        </content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18642-9" S="2.16.840.1.113883.6.1"/> 
        Date Range (From/Through) of Hospitalization Leading to Treatment 
      </caption> 
      <paragraph> 
        <caption> 
          <caption_cd V="18643-7" S="2.16.840.1.113883.6.1"/> 
        Start Date of Hospitalization Leading to Treatment 
        </caption> 
        <content>19 September 2005 
          <local_markup descriptor="dt_DT" ignore="all">2005-09-19</local_markup> 
        </content> 
      </paragraph> 
      <paragraph> 
        <caption> 
          <caption_cd V="18644-5" S="2.16.840.1.113883.6.1"/> 
        End Date of Hospitalization Leading to Treatment 
        </caption> 
        <content>22 September 2005 
          <local_markup descriptor="dt_DT" ignore="all">2005-09-22</local_markup> 
        </content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18646-0" S="2.16.840.1.113883.6.1"/> 
        Date Attending MD Referred Patient for Treatment 
      </caption> 
      <paragraph> 
        <content>21 September 2005 
          <local_markup descriptor="dt_DT" ignore="all">2005-09-21</local_markup> 
        </content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18647-8" S="2.16.840.1.113883.6.1"/> 
        Date Attending MD Signed 
      </caption> 
      <paragraph> 
        <content>21 September 2005 
          <local_markup descriptor="dt_DT" ignore="all">2005-09-21</local_markup> 
        </content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18649-4" S="2.16.840.1.113883.6.1"/> 
        Signature of Responsible Attending MD on File 
      </caption> 
      <paragraph> 
        <content>Yes 
          <coded_entry> 
            <coded_entry.value V="Y" S="2.16.840.1.113883.12.136" SN="HL70136"/> 
          </coded_entry> 
        </content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18650-2" S="2.16.840.1.113883.6.1"/> 
        Signature of Physical Therapy Professional on File 
      </caption> 
      <paragraph> 
        <content>Yes 
          <coded_entry> 
            <coded_entry.value V="Y" S="2.16.840.1.113883.12.136" SN="HL70136"/> 
          </coded_entry> 
        </content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18652-8" S="2.16.840.1.113883.6.1"/> 
        Prognosis for Physical Therapy 
      </caption> 
      <paragraph> 
        <content>Good 
          <coded_entry> 
            <coded_entry.value V="4" S="2.16.840.1.113883.12.9005" SN="HL79005"/> 
          </coded_entry> 
        </content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18653-6" S="2.16.840.1.113883.6.1"/> 
        Estimated Date of Completion 
      </caption> 
      <paragraph> 
        <content>11 November 2005 
          <local_markup descriptor="dt_DT" ignore="all">2005-11-11</local_markup> 
        </content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18655-1" S="2.16.840.1.113883.6.1"/> 
        Past Medical History + Level of Function 
      </caption> 
      <paragraph> 
        <content>Patient was involved in an automobile accident March 20, 2005 and sustained crushing injuries to his left leg. Surgery at the time restored blood flow and major nerve function. There was complete destruction of the growth plate. Recovery was good with a residual foot drop gait. Over the course of the next 4 months he experienced growth in the uninjured right leg. Subject evaluations evidenced considerable growth potential remaining. It was therefore decided to proceed with an epiphysealectomy of the right leg in order to minimize the leg length differential. Surgery was performed on September 20 and the patient is now in need of physical therapy for pain relief, re-establishing range of motion and to improve the gait.</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18656-9" S="2.16.840.1.113883.6.1"/> 
        Initial Assessment 
      </caption> 
      <paragraph> 
        <content>Post operative right distal femoral epiphysealectomy on 9-20-2005.</content> 
      </paragraph> 
      <paragraph> 
        <content>Subjective Complaints: Patient seen in hospital two days post operative. Patient compliant of moderate pain over incision site and stiffness.</content> 
      </paragraph> 
      <paragraph> 
        <content>Objective Findings: Minor swelling over surgical area being treated with ice packs. Leg held immobile for 24 hours post operative. ROM reduced to 20 degrees.</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="27687-3" S="2.16.840.1.113883.6.1"/> 
        Plan of Treatment, Narrative 
      </caption> 
      <paragraph> 
        <content>Week 1: ROM excercises, 15 minutes each visit. 97110, 1 unit per visit</content> 
      </paragraph> 
      <paragraph> 
        <content>Week 2: ROM exercises, 15 minutes each visit and Neuromuscular reeducation, 15 each visit. 97110, 1 unit and 97112, 1 unit per visit</content> 
      </paragraph> 
      <paragraph> 
        <content>Week 3 and 4: ROM exercises, 15 minutes, if needed otherwise Neuromuscular reeducation 30 minutes Total time each visit. 97110, 1 unit and 97112, 1 or 2 units per visit</content> 
      </paragraph> 
      <paragraph> 
        <content>Week 5:Neuromuscular reeducation, 15 to 30 minutes as needed. 97112, 1 or 2 units per visit</content> 
      </paragraph> 
      <paragraph> 
        <content>Week 6:Neuromuscular reeducation 15 to 30 minutes as needed. 97112, 1 or 2 units per visit</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18658-5" S="2.16.840.1.113883.6.1"/> 
        Progress Note + Attainment of Goals 
      </caption> 
      <paragraph> 
        <content>Short Term Goals: Increase ROM and strengthen supportive muscles. Long Term Goals: Full ROM with weight bearing.</content> 
      </paragraph> 
    </section> 
    <section> 
      <caption> 
        <caption_cd V="18660-1" S="2.16.840.1.113883.6.1"/> 
        Justification 
      </caption> 
      <paragraph> 
        <content>Post operative rehabilitation.</content> 
      </paragraph> 
    </section> 
  </body> 
</levelone>~ 

SE*16*0003~

Rendered View
On the following page is the above solicited Physical Therapy Rehabilitation Attachment as rendered with the style sheet included in the HL7 Implementation Guide.

This example is included to depict the use of the MIME package with a scanned image. It shows the relevant segments of the unsolicited 275 submitted with the 278 Health Care Services Review Request for authorization of rehabilitation services including the HL7 Clinical Reports AIS containing scanned operative notes. In this example the attachment is in the Human Decision Variant. Refer to the 278 Health Care Services Review implementation guide being utilized for information regarding the construct of the 278 Request.

ST*275*0002*005010X211~

BGN*02*20020926002*20050921*0629~

NM1*1P*1*FITCH*ROBERT*DOUGLAS***XX*3999000086~

NM1*X3*2*ABC INSURANCE COMPANY*****PI*05440~

NM1*QC*1*JONES*PETER*M***MI*123456789A~

REF*2I*200209261~

LX*1~

TRN*1*JONP56789001~

REF*ICD*73681~

DTP*368*D8*20050926~

CAT*AE*MB~

EFI*05~

BIN*3117*

<levelone xmlns="urn:hl7-org:v3/cda" 
xmlns:v3dt="urn:hl7-org:v3/v3dt" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:hl7-org:v3/cda 
levelone_1.0.attachments.xsd"> 
  <clinical_document_header> 
    <id EX="a123" RT="2.16.840.1.113883.3.933"/> 
    <document_type_cd V="11504-8" DN="Provider Unspecified Operative Note"/> 
    <origination_dttm V="2005-09-21"/> 
    <provider> 
      <provider.type_cd V="PRF"/> 
      <person> 
        <id EX="3999000086" RT="2.16.840.1.113883.4.6"/> 
        <id EX="RFD123" RT="2.16.840.1.113883.19.4.1"/> 
        <person_name> 
          <nm> 
            <v3dt:GIV V="Robert"/> 
            <v3dt:FAM V="Fitch"/> 
            <v3dt:MID V="Douglas"/> 
            <v3dt:SFX V="MD" QUAL="PT"/> 
          </nm> 
          <person_name.type_cd V="L" S="2.16.840.1.113883.5.200"/> 
        </person_name> 
      </person> 
    </provider> 
    <patient> 
      <patient.type_cd V="PATSBJ"/> 
      <person> 
        <id EX="JONP56789" RT="2.16.840.1.113883.19.4.2"/> 
        <person_name> 
          <nm> 
            <v3dt:GIV V="Peter"/> 
            <v3dt:FAM V="Jones"/> 
            <v3dt:MID V="M"/> 
          </nm> 
          <person_name.type_cd V="L" S="2.16.840.1.113883.5.200"/> 
        </person_name> 
      </person> 
      <is_known_by> 
        <id EX="JONP56789" RT="2.16.840.1.1138863.19.4.2"/> 
        <is_known_to> 
          <id EX="123456789A" RT="2.16.840.1.113883.19.4.3"/> 
        </is_known_to> 
      </is_known_by> 
    </patient> 
    <local_header descriptor="Att_ACN"> 
      <local_attr name="attachment_control_number" value="JONP56789001"/> 
    </local_header> 
  </clinical_document_header> 
  <body> 
    <non_xml MT="image/tif"> 
      <v3dt:REF V="x211OperativeReport.tif"/> 
    </non_xml> 
  </body> 
</levelone> 

———————000709080209080801090909
Content-Type: image/tiff;
name="x211OperativeReport.TIF"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="x211OperativeReport.TIF"

SUkqAITzAACAP+BQOCQWDQeEQmFQuGQ2HQ+IRGJROKRWLReMRmNR
uOR2PR+QSGRSOSSWTSeUSmVSuWS2XS+YTGZTOaTWbTecTmdTueT2fT
+gUGhUOiUWjUekUmlUumU2nU+oVGpVOqVWrVesVmtVuuV2vV+wWGxUVT
2Um2cAWm1Jq2Om3Sq1WqE3G0yG6ACT3e53SDXqC36CYC7XyEYKm4aRYi
x4vGY3HY/IZHJZPKZXLZfMS2yqe1OHPQNs6G1GjSQbPOFGamPYqBayM67
V4SD4jabKB7CNa7cUbAafUozY3HM8PicXjcfkcnlcvmc3nVHd3vhR3dbbqdbE9j
b9qF7Xp9nv33uVLoxHy8/0en1ev2R+AoA/4FA4JBYNB4RCYVC4ZDYdD4hEYl
E4pFYtF4xGY1G45HY9H5BIZFI5JJZNJ5OaJUAJZKjQ4ZhDJZM5pM43NQBCZ
xDFlPSbP5nPVlOprA5dM3hSYHSXhM5dD53CKjBKnA6rApw6a0fK5OEZX606Y
lV6pRYXQp+TaDPYNYa4fK9YK1RJo0LtabfdJxe5Zba1X0ZOJc2cJVrNKMRicVi
8Zjcdj8hkclk8plctl8xmc1m85nc9n9BodFo9JBLs0L4AMBMHDer7HdTsdfB17tZm
x9xu

(( 1146 lines removed for readability ))

A+sAAKfrAABL7AAA7+wAAPHtAADt7gAADwD+AAQAAQAAAAAAAAAAAQM
AAQAAAKsCAAABAQMAAQAAAIwCAAACAQMAAwAAAGbvAAADAQMAAQ
AAAAUAAAAGAQMAAQAAAAIAAAARAQQAgwAAAHjxAAAVAQMAAQAAAA
MAAAAWAQQAAQAAAAUAAAAXAQQAgwAAAGzvAAAaAQUAAQAAAFbvAA
AbAQUAAQAAAF7vAAAcAQMAAQAAAAEAAAAoAQMAAQAAAAIAAAA9AQ
MAAQAAAAEAAAAAAAAA
——————000709080209080801090909

~

SE*14*0002~

The following is a rendered view of the HL7 CDA document and the scanned image.

131 International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)

SIMPLE DATA ELEMENT/CODE REFERENCES

128/ICD, 235/DX, 235/ID, 1270/BF, 1270/BJ, 1270/BK, 1270/BN, 1270/BQ, 1270/BR, 1270/DD, 1270/PR, 1270/SD, 1270/TD, 1270/AAU, 1270/AAV, 1270/AAX

SOURCE

International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM), Volumes I, II and III

AVAILABLE FROM

Superintendent of Documents
U.S. Government Printing Office
P.O. Box 371954
Pittsburgh, PA 15250

ABSTRACT

The International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM), Volumes I, II (diagnoses) and III (procedures) describes the classification of morbidity and mortality information for statistical purposes and for the indexing of healthcare records by diseases and procedures.

133 Current Procedural Terminology (CPT) Codes

SIMPLE DATA ELEMENT/CODE REFERENCES

128/CPT, 235/CJ, 1270/BS, 1270/AAW

SOURCE

Physicians' Current Procedural Terminology (CPT) Manual

AVAILABLE FROM

Order Department
American Medical Association
515 North State Street
Chicago, IL 60610

ABSTRACT

A listing of descriptive terms and identifying codes for reporting medical services and procedures performed by physicians.

507 Health Care Claim Status Category Code

SIMPLE DATA ELEMENT/CODE REFERENCES

1271

SOURCE

Health Care Claim Status Category Code

AVAILABLE FROM

The Blue Cross Blue Shield Association
Interplan Teleprocessing Services Division
676 North St. Clair Street
Chicago, IL 60611

ABSTRACT

Code used to organize the Health Care Claim Status Codes into logical groupings

537 Centers for Medicare & Medicaid Services National Provider Identifier

SIMPLE DATA ELEMENT/CODE REFERENCES

66/XX, 128/HPI

SOURCE

National Provider System

AVAILABLE FROM

Centers for Medicare & Medicaid Services
Office of Financial Management
Division of Provider/Supplier Enrollment
C4-10-07
7500 Security Boulevard
Baltimore, MD 21244-1850

ABSTRACT

The Centers for Medicare & Medicaid Services is developing the National Provider Identifier (NPI), which has been proposed as the standard unique identifier for each health care provider under the Health Insurance Portability and Accountability Act of 1996.

540 Centers for Medicare and Medicaid Services PlanID

SIMPLE DATA ELEMENT/CODE REFERENCES

66/XV, 128/ABY

SOURCE

PlanID Database

AVAILABLE FROM

Centers for Medicare and Medicaid Services
Center of Beneficiary Services, Membership Operations Group
Division of Benefit Coordination
S1-05-06
7500 Security Boulevard
Baltimore, MD 21244-1850

ABSTRACT

The Centers for Medicare and Medicaid Services has joined with other payers to develop a unique national payer identification number. The Centers for Medicare and Medicaid Services is the authorizing agent for enumerating payers through the services of a PlanID Registrar. It may also be used by other payers on a voluntary basis.

663 Logical Observation Identifier Names and Codes (LOINC®)

SIMPLE DATA ELEMENT/CODE REFERENCES

128/LOI, 235/LB, 1270/LOI

SOURCE

Logical Observation Identifier Names and Codes(LOINC®)

AVAILABLE FROM

Regenstrief Institute
Indiana University School of Medicine
1001 West 10th Street
5th Floor RHC
Indianapolis, IN 46202

ABSTRACT

LOINC® codes provide a standard set of universal names and codes for identifying individual laboratory and clinical results as well as other clinical information.

881 Version / Release / Industry Identifier Code

SIMPLE DATA ELEMENT/CODE REFERENCES

480

SOURCE

Data Interchange Standards Association

AVAILABLE FROM

Data Interchange Standards Association
333 John Carlyle Street, Suite 600
Alexandria, VA 22314

ABSTRACT

Code indicating the version, release, sub-release, and industry identifier of the EDI standard being used, including the GS and GE segments; if code in DE455 in GS segment is X, then in DE 480 positions 1-3 are the version number; positions 4-6 are the release and sub-release, level of the version; and positions 7-12 are the industry or trade association identifiers (optionally assigned by user); if code in DE455 in GS segment is T, then other formats are allowed.

Appendix B is provided as a reference to the X12 syntax, usage, and related information. It is not a full statement of Interchange and Control Structure rules. The full X12 Interchange and Control Structures and other rules (X12.5, X12.6, X12.59, X12 dictionaries, other X12 standards and official documents) apply unless specifically modified in the detailed instructions of this implementation guide (see Section B.1.1.3.1.2 for an example of such a modification).

The transmission of data proceeds according to very strict format rules to ensure the integrity and maintain the efficiency of the interchange. Each business grouping of data is called a transaction set. For instance, a group of benefit enrollments sent from a sponsor to a payer is considered a transaction set.

Each transaction set contains groups of logically related data in units called segments. For instance, the N4 segment used in the transaction set conveys the city, state, ZIP Code, and other geographic information. A transaction set contains multiple segments, so the addresses of the different parties, for example, can be conveyed from one computer to the other. An analogy would be that the transaction set is like a freight train; the segments are like the train's cars; and each segment can contain several data elements the same as a train car can hold multiple crates.

The sequence of the elements within one segment is specified by the ASC X12 standard as well as the sequence of segments in the transaction set. In a more conventional computing environment, the segments would be equivalent to records, and the elements equivalent to fields.

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

The interchange header and trailer segments envelop one or more functional groups or interchange-related control segments and perform the following functions:

1. Define the data element separators and the data segment terminator.
2. Identify the sender and receiver.
3. Provide control information for the interchange.
4. Allow for authorization and security information.

A data element corresponds to a data field in data processing terminology. A data segment corresponds to a record in data processing terminology. The data segment begins with a segment ID and contains related data elements. A control segment has the same structure as a data segment; the distinction is in the use. The data segment is used primarily to convey user information, but the control segment is used primarily to convey control information and to group data segments.

The section that follows is designed to have representation in the common character code schemes of EBCDIC, ASCII, and CCITT International Alphabet 5. The ASC X12 standards are graphic-character-oriented; therefore, common character encoding schemes other than those specified herein may be used as long as a common mapping is available. Because the graphic characters have an implied mapping across character code schemes, those bit patterns are not provided here.

The basic character set of this standard, shown in Figure B.2., Basic Character Set, includes those selected from the uppercase letters, digits, space, and special characters as specified below.

Figure B.2 - Basic Character Set

An extended character set may be used by negotiation between the two parties and includes the lowercase letters and other special characters as specified in Figure B.3., Extended Character Set.

Figure B.3 - Extended Character Set

Note that the extended characters include several character codes that have multiple graphical representations for a specific bit pattern. The complete list appears in other standards such as CCITT S.5. Use of the USA graphics for these codes presents no problem unless data is exchanged with an international partner. Other problems, such as the translation of item descriptions from English to French, arise when exchanging data with an international partner, but minimizing the use of codes with multiple graphics eliminates one of the more obvious problems.

For implementations compliant with this guide, either the entire extended character set must be acceptable, or the entire extended character set must not be used. In the absence of a specific trading partner agreement to the contrary, trading partners will assume that the extended character set is acceptable. Use of the extended character set allows the use of the "@" character in email addresses within the PER segment. Users should note that characters in the extended character set, as well as the basic character set, may be used as delimiters only when they do not occur in the data as stated in Section B.1.1.2.5.

Two control character groups are specified; they have restricted usage. The common notation for these groups is also provided, together with the character coding in three common alphabets. In the Matrix B.1., Base Control Set, the column IA5 represents CCITT V.3 International Alphabet 5.

The base control set includes those characters that will not have a disruptive effect on most communication protocols. These are represented by:

Matrix B.1. Base Control Set

The Group Separator (GS) may be an exception in this set because it is used in the 3780 communications protocol to indicate blank space compression.

The extended control set includes those that may have an effect on a transmission system. These are shown in Matrix B.2., Extended Control Set.

Matrix B.2. Extended Control Set

The Group Separator (GS) may be an exception in this set because it is used in the 3780 communications protocol to indicate blank space compression.

A delimiter is a character used to separate two data elements or component elements or to terminate a segment. The delimiters are an integral part of the data.

Delimiters are specified in the interchange header segment, ISA. The ISA segment can be considered in implementations compliant with this guide (see Appendix C, ISA Segment Note 1) to be a 105 byte fixed length record, followed by a segment terminator. The data element separator is byte number 4; the repetition separator is byte number 83; the component element separator is byte number 105; and the segment terminator is the byte that immediately follows the component element separator.

Once specified in the interchange header, the delimiters are not to be used in a data element value elsewhere in the interchange. For consistency, this implementation guide uses the delimiters shown in Matrix B.3., Delimiters, in all examples of EDI transmissions.

Matrix B.3. Delimiters

The delimiters above are for illustration purposes only and are not specific recommendations or requirements. Users of this implementation guide should be aware that an application system may use some valid delimiter characters within the application data. Occurrences of delimiter characters in transmitted data within a data element will result in errors in translation. The existence of asterisks (*) within transmitted application data is a known issue that can affect translation software.

The ASC X12 standards define commonly used business transactions (such as a health care claim) in a formal structure called "transaction sets." A transaction set is composed of a transaction set header control segment, one or more data segments, and a transaction set trailer control segment. Each segment is composed of the following:

• A unique segment ID
• One or more logically related data elements each preceded by a data element separator
• A segment terminator

The data element is the smallest named unit of information in the ASC X12 standard. Data elements are identified as either simple or component. A data element that occurs as an ordinally positioned member of a composite data structure is identified as a component data element. A data element that occurs in a segment outside the defined boundaries of a composite data structure is identified as a simple data element. The distinction between simple and component data elements is strictly a matter of context because a data element can be used in either capacity.

Data elements are assigned a unique reference number. Each data element has a name, description, type, minimum length, and maximum length. For ID type data elements, this guide provides the applicable ASC X12 code values and their descriptions or references where the valid code list can be obtained.

A simple data element within a segment may have an attribute indicating that it may occur once or a specific number of times more than once. The number of permitted repeats are defined as an attribute in the individual segment where the repeated data element occurs.

Each data element is assigned a minimum and maximum length. The length of the data element value is the number of character positions used except as noted for numeric, decimal, and binary elements.

The data element types shown in Matrix B.4., Data Element Types, appear in this implementation guide.

Matrix B.4. Data Element Types

The data element minimum and maximum lengths may be restricted in this implementation guide for a compliant implementation. Such restrictions may occur by virtue of the allowed qualifier for the data element or by specific instructions regarding length or format as stated in this implementation guide.

A numeric data element is represented by one or more digits with an optional leading sign representing a value in the normal base of 10. The value of a numeric data element includes an implied decimal point. It is used when the position of the decimal point within the data is permanently fixed and is not to be transmitted with the data.

This set of guides denotes the number of implied decimal positions. The representation for this data element type is "Nn" where N indicates that it is numeric and n indicates the number of decimal positions to the right of the implied decimal point.

If n is 0, it need not appear in the specification; N is equivalent to N0. For negative values, the leading minus sign (-) is used. Absence of a sign indicates a positive value. The plus sign (+) must not be transmitted.

EXAMPLE
A transmitted value of 1234, when specified as numeric type N2, represents a value of 12.34.

Leading zeros must be suppressed unless necessary to satisfy a minimum length requirement. The length of a numeric type data element does not include the optional sign.

A decimal data element may contain an explicit decimal point and is used for numeric values that have a varying number of decimal positions. This data element type is represented as "R."

The decimal point always appears in the character stream if the decimal point is at any place other than the right end. If the value is an integer (decimal point at the right end) the decimal point must be omitted. For negative values, the leading minus sign (-) is used. Absence of a sign indicates a positive value. The plus sign (+) must not be transmitted.

Leading zeros must be suppressed unless necessary to satisfy a minimum length requirement. Trailing zeros following the decimal point must be suppressed unless necessary to indicate precision. The use of triad separators (for example, the commas in 1,000,000) is expressly prohibited. The length of a decimal type data element does not include the optional leading sign or decimal point.

EXAMPLE
A transmitted value of 12.34 represents a decimal value of 12.34.

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

For implementation of this guide under the rules promulgated under the Health Insurance Portability and Accountability Act (HIPAA), decimal data elements in 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 the statement in the preceding paragraph that the decimal point and leading sign, if sent, are not part of the character count.

EXAMPLE
For implementations mandated under HIPAA rules:

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

An identifier data element always contains a value from a predefined list of codes that is maintained by the ASC X12 Committee or some other body recognized by the Committee. Trailing spaces must be suppressed unless they are necessary to satisfy a minimum length. An identifier is always left justified. The representation for this data element type is "ID."