[Federal Register: May 7, 1998 (Volume 63, Number 88)] [Proposed Rules] [Page 25271-25320] From the Federal Register Online via GPO Access [wais.access.gpo.gov] [DOCID:fr07my98-25] [[Page 25271]] _______________________________________________________________________ Part II Department of Health and Human Services _______________________________________________________________________ Health Care Financing Administration _______________________________________________________________________ 45 CFR Part 142 Health Insurance Reform: Standards for Electronic Transactions; National Standard Health Care Provider Identifier; Proposed Rules [[Page 25272]] DEPARTMENT OF HEALTH AND HUMAN SERVICES Office of the Secretary 45 CFR Part 142 [HCFA-0149-P] RIN 0938-AI58 Health Insurance Reform: Standards for Electronic Transactions AGENCY: Health Care Financing Administration (HCFA), HHS. ACTION: Proposed rule. ----------------------------------------------------------------------- SUMMARY: This rule proposes standards for eight electronic transactions and for code sets to be used in those transactions. It also proposes requirements concerning the use of these standards by health plans, health care clearinghouses, and health care providers. The use of these standard transactions and code sets would improve the Medicare and Medicaid programs and other Federal health programs and private health programs, and the effectiveness and efficiency of the health care industry in general, by simplifying the administration of the system and enabling the efficient electronic transmission of certain health information. It would implement some of the requirements of Administrative Simplification subtitle of the Health Insurance Portability and Accountability Act of 1996. DATES: Comments will be considered if we receive them at the appropriate address, as provided below, no later than 5 p.m. on July 6, 1998. ADDRESSES: Mail written comments (1 original and 3 copies) to the following address: Health Care Financing Administration, U.S. Department of Health and Human Services, Attention: HCFA-0149-P, P.O. Box 31850, Baltimore, MD 21207-8850. If you prefer, you may deliver your written comments (1 original and 3 copies) to one of the following addresses: Room 309-G, Hubert H. Humphrey Building, 200 Independence Avenue, SW., Washington, DC 20201, or Room C5-09-26, 7500 Security Boulevard, Baltimore, MD 21244-1850. Comments may also be submitted electronically to the following e- mail address: transact@osaspe.dhhs.gov. E-mail comments should include the full name and address of the sender and must be submitted to the referenced address to be considered. All comments should be incorporated in the e-mail message because we may not be able to access attachments. Electronically submitted comments will be available for public inspection at the Independence Avenue address below. Because of staffing and resource limitations, we cannot accept comments by facsimile (FAX) transmission. In commenting, please refer to file code HCFA-0149-P and the specific section of this proposed rule. Comments received timely will be available for public inspection as they are received, generally beginning approximately 3 weeks after publication of a document, in Room 309-G of the Department's offices at 200 Independence Avenue, SW., Washington, DC, on Monday through Friday of each week from 8:30 a.m. to 5 p.m. (phone: (202) 690-7890). Electronic and legible written comments will also be posted, along with this proposed rule, at the following web site: . Copies: To order copies of the Federal Register containing this document, send your request to: New Orders, Superintendent of Documents, P.O. Box 371954, Pittsburgh, PA 15250-7954. Specify the date of the issue requested and enclose a check or money order payable to the Superintendent of Documents, or enclose your Visa or Master Card number and expiration date. Credit card orders can also be placed by calling the order desk at (202) 512-1800 or by faxing to (202) 512- 2250. The cost for each copy is $8. As an alternative, you can view and photocopy the Federal Register document at most libraries designated as Federal Depository Libraries and at many other public and academic libraries throughout the country that receive the Federal Register. This Federal Register document is also available from the Federal Register online database through GPO Access, a service of the U.S. Government Printing Office. Free public access is available on a Wide Area Information Server (WAIS) through the Internet and via asynchronous dial-in. Internet users can access the database by using the World Wide Web; the Superintendent of Documents home page address is http://www.access.gpo.gov/su__docs/, by using local WAIS client software, or by telnet to swais.access.gpo.gov, then login as guest (no password required). Dial-in users should use communications software and modem to call 202-512-1661; type swais, then login as guest (no password required). FOR FURTHER INFORMATION CONTACT: Pat Brooks, (410) 786-5318, for medical diagnosis, procedure, and clinical code sets. Joy Glass, (410) 786-6125, for the following transactions: Health claims or equivalent encounter information; health care payment and remittance advice; coordination of benefits; and health care claim status. Marilyn Abramovitz, (410) 786-5939, for the following transactions: Enrollment and disenrollment in a health plan; eligibility for a health plan; health plan premium payments; and referral certification and authorization. SUPPLEMENTARY INFORMATION: I. Background [Please label written or e-mailed comments about this section with the subject: Background] Electronic data interchange (EDI) is the electronic transfer of information, such as electronic media health care claims, in a standard format between trading partners. EDI allows entities within the health care system to exchange medical, billing, and other information and process transactions in a manner which is fast and cost effective. With EDI there is a substantial reduction in handling and process time, and the risk of lost paper documents is eliminated. EDI can eliminate the inefficiencies of handling paper documents, which will significantly reduce the administrative burden, lower operating costs and improve overall data quality. The health care industry recognizes the benefits of EDI and many entities in that industry have developed proprietary EDI formats. Currently, there are about 400 formats for electronic health care claims being used in the United States. The lack of standardization makes it difficult to develop software, and the efficiencies and savings for health care providers and health plans that could be realized if formats were standardized are diminished. Adopting national standard EDI formats for health care transactions would greatly decrease the burden on health care providers and their billing services, as would standardized data content. Standard EDI format allows data interchange using a common interchange structure, thus eliminating the need for users to reprogram their data processing systems for multiple formats. Standardization of the data content within the interchange structure involves: (1) Uniform definitions of the data elements that will be exchanged in each type of electronic transaction, and [[Page 25273]] (2) for some data elements, identification of the specific codes or values that are valid for each data element. The code sets needed for EDI in the health care industry include large coding and classification systems for medical diagnoses, procedures, and drugs, as well as smaller sets of codes for such items as types of facility, types of currency, types of units, and specified State within the United States. Standardized data content is essential to accurate and efficient EDI between the many producers and users of administrative health data transactions. A. Legislation The Congress included provisions to address the need for electronic transactions and other administrative simplification issues in the Health Insurance Portability and Accountability Act of 1996 (HIPAA), Public Law 104-191, which was enacted on August 21, 1996. Through subtitle F of title II of that law, the Congress added to title XI of the Social Security Act a new part C, entitled ``Administrative Simplification.'' (Public Law 104-191 affects several titles in the United States Code. Hereafter, we refer to the Social Security Act as the Act; we refer to the other laws cited in this document by their names.) The purpose of this part is to improve the Medicare and Medicaid programs in particular and the efficiency and effectiveness of the health care system in general by encouraging the development of a health information system through the establishment of standards and requirements to facilitate the electronic transmission of certain health information. Part C of title XI consists of sections 1171 through 1179 of the Act. These sections define various terms and impose several requirements on HHS, health plans, health care clearinghouses, and certain health care providers concerning the electronic transmission of health information. The first section, section 1171 of the Act, establishes definitions for purposes of part C of title XI for the following terms: code set, health care clearinghouse, health care provider, health information, health plan, individually identifiable health information, standard, and standard setting organization. Section 1172 of the Act makes any standard adopted under part C applicable to (1) all health plans, (2) all health care clearinghouses, and (3) any health care providers that transmit any health information in electronic form in connection with transactions referred to in section 1173(a)(1) of the Act. This section also contains requirements concerning standard setting. The Secretary may adopt a standard developed, adopted, or modified by a standard setting organization (that is, an organization accredited by the American National Standards Institute (ANSI)) that has consulted with the National Uniform Billing Committee (NUBC), the National Uniform Claim Committee (NUCC), the Workgroup for Electronic Data Interchange (WEDI), and the American Dental Association (ADA). The Secretary may also adopt a standard other than one established by a standard setting organization, if the different standard will reduce costs for health care providers and health plans, the different standard is promulgated through negotiated rulemaking procedures, and the Secretary consults with each of the above-named groups. If no standard has been adopted by any standard setting organization, the Secretary is to rely on the recommendations of the National Committee on Vital and Health Statistics (NCVHS) and consult with the above-named groups. In complying with the requirements of part C of title XI, the Secretary must rely on the recommendations of the NCVHS, consult with appropriate State, Federal, and private agencies or organizations, and publish the recommendations of the NCVHS in the Federal Register. Paragraph (a) of section 1173 of the Act requires that the Secretary adopt standards for financial and administrative transactions, and data elements for those transactions, to enable health information to be exchanged electronically. Standards are required for the following transactions: health claims, health encounter information, health claims attachments, health plan enrollments and disenrollments, health plan eligibility, health care payment and remittance advice, health plan premium payments, first report of injury, health claim status, and referral certification and authorization. In addition, the Secretary is required to adopt standards for any other financial and administrative transactions that are determined to be appropriate by the Secretary. Paragraph (b) of section 1173 of the Act requires the Secretary to adopt standards for unique health identifiers for all individuals, employers, health plans, and health care providers and requires further that the adopted standards specify for what purposes unique health identifiers may be used. Paragraphs (c) through (f) of section 1173 of the Act require the Secretary to establish standards for code sets for each data element for each health care transaction listed above, security standards for health care information systems, standards for electronic signatures (established together with the Secretary of Commerce), and standards for the transmission of data elements needed for the coordination of benefits and sequential processing of claims. Compliance with electronic signature standards will be deemed to satisfy both State and Federal requirements for written signatures with respect to the transactions listed in paragraph (a) of section 1173 of the Act. In section 1174 of the Act, the Secretary is required to adopt standards for all of the above transactions, except claims attachments, within 24 months after enactment. The standards for claims attachments must be adopted within 30 months after enactment. Generally, after a standard is established it cannot be changed during the first year except for changes that are necessary to permit compliance with the standard. Modifications to any of these standards may be made after the first year, but not more frequently than once every 12 months. The Secretary must also ensure that procedures exist for the routine maintenance, testing, enhancement, and expansion of code sets and that there are crosswalks from prior versions. Section 1175 of the Act prohibits health plans from refusing to process or delaying the processing of a transaction that is presented in standard format. The Act's requirements are not limited to health plans, however; instead, each person to whom a standard or implementation specification applies is required to comply with the standard within 24 months (or 36 months for small health plans) of its adoption. A plan or person may, of course, comply voluntarily before the effective date. A person may comply by using a health care clearinghouse to transmit or receive the standard transactions. Compliance with modifications to standards or implementation specifications must be accomplished by a date designated by the Secretary. This date may not be earlier than 180 days after the notice of change. Section 1176 of the Act establishes a civil monetary penalty for violation of the provisions in part C of title XI of the Act, subject to several limitations. Penalties may not be more than $100 per person per violation and not more than $25,000 per person per violation of a single standard for a calendar year. The procedural provisions in section 1128A of the Act, ``Civil Monetary Penalties,'' are applicable. [[Page 25274]] Section 1177 of the Act establishes penalties for a knowing misuse of unique health identifiers and individually identifiable health information: (1) A fine of not more than $50,000 and/or imprisonment of not more than 1 year; (2) if misuse is ``under false pretenses,'' a fine of not more than $100,000 and/or imprisonment of not more than 5 years; and (3) if misuse is with intent to sell, transfer, or use individually identifiable health information for commercial advantage, personal gain, or malicious harm, a fine of not more than $250,000 and/ or imprisonment of not more than 10 years. Under section 1178 of the Act, the provisions of part C of title XI of the Act, as well as any standards established under them, supersede any State law that is contrary to them. However, the Secretary may, for statutorily specified reasons, waive this provision. Finally, section 1179 of the Act makes the above provisions inapplicable to financial institutions or anyone acting on behalf of a financial institution when ``authorizing, processing, clearing, settling, billing, transferring, reconciling, or collecting payments for a financial institution''. (Concerning this last provision, the conference report, in its discussion on section 1178, states: ``The conferees do not intend to exclude the activities of financial institutions or their contractors from compliance with the standards adopted under this part if such activities would be subject to this part. However, conferees intend that this part does not apply to use or disclosure of information when an individual utilizes a payment system to make a payment for, or related to, health plan premiums or health care. For example, the exchange of information between participants in a credit card system in connection with processing a credit card payment for health care would not be covered by this part. Similarly sending a checking account statement to an account holder who uses a credit or debit card to pay for health care services, would not be covered by this part. However, this part does apply if a company clears health care claims, the health care claims activities remain subject to the requirements of this part.'') (H.R. Rep. No. 736, 104th Cong., 2nd Sess. 268-269 (1996)) B. Process for Developing National Standards The Secretary has formulated a 5-part strategy for developing and implementing the standards mandated under part C of title XI of the Act: 1. To ensure necessary interagency coordination and required interaction with other Federal departments and the private sector, establish interdepartmental implementation teams to identify and assess potential standards for adoption. The subject matter of the teams includes claims/encounters, identifiers, enrollment/eligibility, systems security, and medical coding/classification. Another team addresses cross-cutting issues and coordinates the subject matter teams. The teams consult with external groups such as the NCVHS'' Workgroup on Data Standards, WEDI, ANSI's Healthcare Informatics Standards Board (HISB), the NUCC, the NUBC, and the ADA. The teams are charged with developing regulations and other necessary documents and making recommendations for the various standards to the HHS'' Data Council through its Committee on Health Data Standards. (The HHS Data Council is the focal point for consideration of data policy issues. It reports directly to the Secretary and advises the Secretary on data standards and privacy issues.) 2. Develop recommendations for standards to be adopted. 3. Publish proposed rules in the Federal Register describing the standards. Each proposed rule provides the public with a 60-day comment period. 4. Analyze public comments and publish the final rules in the Federal Register. 5. Distribute standards and coordinate preparation and distribution of implementation guides. This strategy affords many opportunities for involvement of interested and affected parties in standards development and adoption by enabling them to: Participate with standards setting organizations. Provide written input to the NCVHS. Provide written input to the Secretary of the HHS. Provide testimony at NCVHS' public meetings. Comment on the proposed rules for each of the proposed standards. Invite HHS staff to meetings with public and private sector organizations or meet directly with senior HHS staff involved in the implementation process. The implementation teams charged with reviewing standards for designation as required national standards under the statute have defined, with significant input from the health care industry, a set of principles for guiding choices for the standards to be adopted by the Secretary. These principles are based on direct specifications in HIPAA and the purpose of the law, principles that support the regulatory philosophy set forth in Executive Order 12866 and the Paperwork Reduction Act of 1995. To be designated as an HIPAA standard, each standard should: 1. Improve the efficiency and effectiveness of the health care system by leading to cost reductions for or improvements in benefits from electronic health care transactions. 2. Meet the needs of the health data standards user community, particularly health care providers, health plans, and health care clearinghouses. 3. Be consistent and uniform with the other HIPAA standards--their data element definitions and codes and their privacy and security requirements--and, secondarily, with other private and public sector health data standards. 4. Have low additional development and implementation costs relative to the benefits of using the standard. 5. Be supported by an ANSI-accredited standards developing organization or other private or public organization that will ensure continuity and efficient updating of the standard over time. 6. Have timely development, testing, implementation, and updating procedures to achieve administrative simplification benefits faster. 7. Be technologically independent of the computer platforms and transmission protocols used in electronic health transactions, except when they are explicitly part of the standard. 8. Be precise and unambiguous, but as simple as possible. 9. Keep data collection and paperwork burdens on users as low as is feasible. 10. Incorporate flexibility to adapt more easily to changes in the health care infrastructure (such as new services, organizations, and provider types) and information technology. A master data dictionary providing for common data definitions across the standards selected for implementation under HIPAA will be developed and maintained. We intend for the data element definitions to be precise, unambiguous, and consistently applied. The transaction- specific reports and general reports from the master data dictionary will be readily available to the public. At a minimum, the information presented will include data element names, definitions, and appropriate references to the transactions where they are used. C. ANSI-Accredited Standards Committee Standard Setting Process ANSI chartered the X12 Accredited Standards Committee (ASC) a number of years ago to design national electronic [[Page 25275]] standards for a wide range of business applications. A separate ASC X12N Subcommittee was in turn chartered to develop electronic standards specific to the insurance industry, including health care insurance. Volunteer members of the ASC X12N Subcommittee, including health care providers, health plans, bankers, and vendors involved in software development/billing/transmission of health care data and other business aspects of health care administrative activities, worked to develop standards for electronic health care transactions. ANSI accredits standards setting organizations to ensure that the procedures used meet certain due process requirements and that the process is voluntary, open, and based on obtaining consensus. Both Accredited Standards Committee (ASC) X12 and the National Council for Prescription Drug Programs (NCPDP) are ANSI-accredited standards developers. Each of the two standards setting organizations has written procedures for the establishment of, and revisions to, established standards. All of the X12 Subcommittee N: Insurance (to which we refer hereafter as X12N) standard implementations mentioned in this regulation are ASC X12 standards and are published under the designation ``Draft Standard for Trial Use (DSTU)''. These standards are fully accepted and published national standards for use in electronic data exchanges. The DSTU designation is used to distinguish ASC X12 standards from those standards that have been forwarded to the American National Standards Institute for acceptance as American National Standards. ASC X12 creates a family of standards that are related and therefore only forwards standards to ANSI every five years. Although the official designation of X12 standards includes the word ``Draft'', these standards are final, published national standards. The ASC X12 development process involves negotiation and consensus building, resulting in approval and publication of DSTU and American National Standards. The ASC X12 committee maintains current standards, proposes new standards and embraces new ideas. The ASC X12N Subcommittee is the decision-making body responsible for obtaining consensus, which is necessary for approval of American National Standards in the field of insurance. The ASC X12N Subcommittee has the responsibility for specific standards development and standards maintenance activities, but its work must be ratified by the membership of ASC X12 as a whole. Members of the ASC X12 committee are eligible to vote on ASC X12N issues. ASC X12N votes technical issues by letter ballot. Administrative issues may be voted by letter ballot or at general sessions during ASC X12N meetings. The NCPDP Telecommunication Standard 3.2 specifies the rules regarding the creation of a new version and release. The NCPDP standards development process involves additions of new data elements or additional values to existing data elements. Updated documentation of existing or new data elements and a new version is created with changes to: (1) The definition of an existing data element, (2) deletions of values of an existing data element, (3) deletions of existing data elements, (4) major structural changes to the formats, (5) changes in the size of data elements, or (6) changes in the formats of data elements. These rules were confirmed by the Board of Trustees in June, 1995 and ensure that the health plan explicitly knows which Data Dictionary to apply to the transaction when processing the claim. Likewise, the pharmacy needs to know what are the acceptable fields in the response returned from the health plan. In addition, the Telecommunication Standard Format Version/Release changes anytime there is an approved change to the Professional Pharmacy Services (PPS) standard, Drug Utilization Review (DUR) standard, Billing Unit standard or to the data elements for the claim itself. All NCPDP implementation guides must be reviewed and approved by the Maintenance and Control Work Group prior to release to the membership. All proposed standards will have an implementation guide developed and approved prior to the proposed standard being balloted. Once balloted, the originating committee may work with individual disapproval votes to accommodate their concerns and convert their votes to approval. If the changes made to accommodate disapproval votes are considered substantial, then the item under consideration must be balloted again. After the originating group has reviewed all comments received during the letter ballot period, the Co-Chairs of the originating group make a written request to the Board of Trustees for the ballot results collected from the Standardization Co-chairs and the Board of Directors. The Board of Trustees retains final authority over the certification of these ballot results. Two types of code sets are required for data elements in ASC X12N and NCPDP health transaction standards: (1) Large coding and classification systems for medical data elements (for example, diagnoses, procedures, and drugs), and (2) smaller sets of codes for data elements such as type of facility, type of units, and specified State within address fields. Federal agencies (NCHS, HCFA, FDA) and some private organizations (the AMA and the ADA) have developed and maintained standards for large medical data code sets. In the past, these code sets have been mandated for use in some Federal and State programs, such as Medicare and Medicaid, and the ASC X12N and NCPDP standards setting organizations have adopted these code sets for use in their standards. For the smaller sets of codes needed for various transaction data elements they have designated other de facto standards, such as the 2-character state abbreviations used by the U.S. Postal Service, or developed code sets specifically for their transaction standards. This proposed rule would establish the standards for code sets to be used in seven of the transactions specified in section 1173(a)(2) of the Act, and for a transaction for coordination of benefits. We anticipate publishing several regulations documents altogether to promulgate the various standards required under the HIPAA. The other proposed regulations cover security standards, the seventh and ninth transactions specified in the Act (first report of injury and claims attachments), and the four identifiers. II. Provisions of the Proposed Regulations [Please label written comments or e-mailed comments about this section with the subject: Provisions] In this proposed rule, we propose standards for eight transactions and for code sets to be used in the transactions. We also propose requirements concerning the implementation of these standards. This proposed rule would set forth requirements that health plans, health care clearinghouses, and certain health care providers would have to meet concerning the use of these standards. We propose to add a new part to title 45 of the Code of Federal Regulations for health plans, health care providers, and health care clearinghouses in general. The new part would be part 142 of title 45 and would be titled ``Administrative Requirements.'' Subparts J through R would contain the provisions specifically concerning the standards proposed in this rule. [[Page 25276]] A. Applicability Section 262 of HIPAA applies to all health plans, all health care clearinghouses, and any health care providers that transmit any health information in electronic form in connection with transactions referred to in section 1173(a)(1) of the Act. Our proposed rules (at 45 CFR 142.102) would apply to the health plans and health care clearinghouses as well, but we would clarify the statutory language in our regulations for health care providers: we would have the regulations apply to any health care provider only when electronically transmitting any of the transactions to which section 1173(a)(1) of the Act refers. Electronic transmissions would include transmissions using all media, even when the transmission is physically moved from one location to another using magnetic tape, disk, or CD media. Transmissions over the Internet (wide-open), Extranet (using Internet technology to link a business with information only accessible to collaborating parties), leased lines, dial-up lines, and private networks are all included. Telephone voice response and ``faxback'' systems would not be included. Our regulations would apply to health care clearinghouses when transmitting transactions to, and receiving transactions from, any health care provider or health plan that transmits and receives standard transactions (as defined under ``transaction'') and at all times when transmitting to or receiving transactions from another health care clearinghouse. Entities that offer on-line interactive transmission must comply with the standards. The HyperText Markup Language (HTML) interaction between a server and a browser by which the data elements of a transaction are solicited from a user would not have to use the standards, although the data content must be equal to that required for the standard. Once the data elements are assembled into a transaction by the server, the transmitted transaction would have to comply with the standards. The law would apply to each health care provider when transmitting or receiving any of the specified electronic transactions. Transactions for certain services that are not normally considered health care services, but which may be covered by some health plans, would not be subject to the standards proposed in this rule. These services would include, but not be limited to: nonemergency transportation, physical alterations to living quarters for the purpose of accommodating disabilities, and case management. Other services may be added to this list at the discretion of the Secretary. We invite comments on this list and ask for identification of other types of services that may fall into this category. We will publish a complete list of these services and a process to request an exemption in the final rule. The law applies to health plans for all transactions. Section 142.104 would contain the following provisions (from section 1175 of the Act): If a person conducts a transaction (as defined in Sec. 142.103) with a health plan as a standard transaction, the following apply: (1) The health plan may not refuse to conduct the transaction as a standard transaction. (2) The health plan may not delay the transaction or otherwise adversely affect, or attempt to adversely affect, the person or the transaction on the ground that the transaction is a standard transaction. (3) The information transmitted and received in connection with the transaction must be in the form of standard data elements of health information. As a further requirement, we would provide that a health plan that conducts transactions through an agent assure that the agent meets all the requirements of part 142 that apply to the health plan. Section 142.105 would state that a person or other entity may meet the requirements of Sec. 142.104 by either-- (1) Transmitting and receiving standard data elements, or (2) Submitting nonstandard data elements to a health care clearinghouse for processing into standard data elements and transmission by the health care clearinghouse and receiving standard data elements through the health care clearinghouse. Health care clearinghouses would be able to accept nonstandard transactions for the sole purpose of translating them into standard transactions for sending customers and would be able to accept standard transactions and translate them into nonstandard formats for receiving customers. We would state in Sec. 142.105 that the transmission of nonstandard transactions, under contract, between a health plan or a health care provider and a health care clearinghouse would not violate the law. Transmissions within a corporate entity would not be required to comply with the standards. A hospital that is wholly owned by a managed care company would not have to use the standards to pass encounter information back to the home office, but it would have to use the standard claims transaction to submit a claim to another health plan. Another example might be transactions within Federal agencies and their contractors and between State agencies within the same State. For example, Medicare enters into contracts with insurance companies and common working file sites that process Medicare claims using government furnished software. There is constant communication, on a private network, between HCFA Central Office and the Medicare carriers, intermediaries and common working file sites. This communication may continue in nonstandard mode. However, these contractors must comply with the standards when exchanging any of the transactions covered by HIPAA with an entity outside these ``corporate'' boundaries. Although there are situations in which the use of the standards is not required (for example, health care providers may continue to submit paper claims and employers are not required to use any of the standard transactions), we stress that a standard may be used voluntarily in any situation in which it is not required. B. Definitions Section 1171 of the Act defines several terms and our proposed rules would, for the most part, simply restate the law. The terms that we are defining in this proposed rule follow: 1. ASC X12 stands for the Accredited Standards Committee chartered by the American National Standards Institute to design national electronic standards for a wide range of business applications. 2. ASC X12N stands for the ASC X12 subcommittee chartered to develop electronic standards specific to the insurance industry. 3. Code set. We would define ``code set'' as section 1171(1) of the Act does: ``code set'' means any set of codes used for encoding data elements, such as tables of terms, medical concepts, medical diagnosis codes, or medical procedure codes. 4. Health care clearinghouse. We would define ``health care clearinghouse'' as section 1171(2) of the Act does, but we are adding a further, clarifying sentence. The statute defines a ``health care clearinghouse'' as a public or private entity that processes or facilitates the processing of nonstandard data elements of health information into standard data elements. We would [[Page 25277]] further explain that such an entity is one that currently receives health care transactions from health care providers and other entities, translates the data from a given format into one acceptable to the intended recipient, and forwards the processed transaction to appropriate health plans and other health care clearinghouses, as necessary, for further action. There are currently a number of private clearinghouses that perform these functions for health care providers. For purposes of this rule, we would consider billing services, repricing companies, community health management information systems or community health information systems, value-added networks, and switches performing these functions to be health care clearinghouses. 5. Health care provider. As defined by section 1171(3) of the Act, a ``health care provider'' is a provider of services as defined in section 1861(u) of the Act, a provider of medical or other health services as defined in section 1861(s) of the Act, and any other person who furnishes health care services or supplies. Our regulations would define ``health care provider'' as the statute does and clarify that the definition of a health care provider is limited to those entities that furnish, or bill and are paid for, health care services in the normal course of business. For a more detailed discussion of the definition of health care provider, we refer the reader to our proposed rule, HCFA-0045-P, Standard Health Care Provider Identifier, published elsewhere in this Federal Register. 6. Health information. ``Health information,'' as defined in section 1171 of the Act, means any information, whether oral or recorded in any form or medium, that-- Is created or received by a health care provider, health plan, public health authority, employer, life insurer, school or university, or health care clearinghouse; and Relates to the past, present, or future physical or mental health or condition of an individual, the provision of health care to an individual, or the past, present, or future payment for the provision of health care to an individual. We propose the same definition for our regulations. 7. Health plan. We propose that a ``health plan'' be defined essentially as section 1171 of the Act defines it. Section 1171 of the Act cross refers to definitions in section 2791 of the Public Health Service Act (as added by Public Law 104-191, 42 U.S.C. 300gg-91); we would incorporate those definitions as currently stated into our proposed definitions for the convenience of the public. We note that many of these terms are defined in other statutes, such as the Employee Retirement Income Security Act of 1974 (ERISA), Public Law 93-406, 29 U.S.C. 1002(7) and the Public Health Service Act. Our definitions are based on the roles of plans in conducting administrative transactions, and any differences should not be construed to affect other statutes. For purposes of implementing the provisions of administrative simplification, a ``health plan'' would be an individual or group health plan that provides, or pays the cost of, medical care. This definition includes, but is not limited to, the 13 types of plans listed in the statute. On the other hand, plans such as property and casualty insurance plans and workers compensation plans, which may pay health care costs in the course of administering nonhealth care benefits, are not considered to be health plans in the proposed definition of health plan. Of course, these plans may voluntarily adopt these standards for their own business needs. At some future time, the Congress may choose to expressly include some or all of these plans in the list of health plans that must comply with the standards. Health plans often carry out their business functions through agents, such as plan administrators (including third party administrators), entities that are under ``administrative services only'' (ASO) contracts, claims processors, and fiscal agents. These agents may or may not be health plans in their own right; for example, a health plan may act as another health plan's agent as another line of business. As stated earlier, a health plan that conducts HIPAA transactions through an agent is required to assure that the agent meets all HIPAA requirements that apply to the plan itself. ``Health plan'' includes the following, singly or in combination: a. ``Group health plan'' (as currently defined by section 2791(a) of the Public Health Service Act). A group health plan is a plan that has 50 or more participants (as the term ``participant'' is currently defined by section 3(7) of ERISA) or is administered by an entity other than the employer that established and maintains the plan. This definition includes both insured and self-insured plans. We define ``participant'' separately below. Section 2791(a)(1) of the Public Health Service Act defines ``group health plan'' as an employee welfare benefit plan (as currently defined in section 3(1) of ERISA) to the extent that the plan provides medical care, including items and services paid for as medical care, to employees or their dependents directly or through insurance, or otherwise. It should be noted that group health plans that have fewer than 50 participants and that are administered by the employer would be excluded from this definition and would not be subject to the administrative simplification provisions of HIPAA. b. ``Health insurance issuer'' (as currently defined by section 2791(b) of the Public Health Service Act). Section 2791(b)(2) of the Public Health Service Act currently defines a ``health insurance issuer'' as an insurance company, insurance service, or insurance organization that is licensed to engage in the business of insurance in a State and is subject to State law that regulates insurance. c. ``Health maintenance organization'' (as currently defined by section 2791(b) of the Public Health Service Act). Section 2791(b) of the Public Health Service Act currently defines a ``health maintenance organization'' as a Federally qualified health maintenance organization, an organization recognized as such under State law, or a similar organization regulated for solvency under State law in the same manner and to the same extent as such a health maintenance organization. These organizations may include preferred provider organizations, provider sponsored organizations, independent practice associations, competitive medical plans, exclusive provider organizations, and foundations for medical care. d. Part A or Part B of the Medicare program (title XVIII of the Act). e. The Medicaid program (title XIX of the Act). f. A ``Medicare supplemental policy'' as defined under section 1882(g)(1) of the Act. Section 1882(g)(1) of the Act defines a ``Medicare supplemental policy'' as a health insurance policy that a private entity offers a Medicare beneficiary to provide payment for expenses incurred for services and items that are not reimbursed by Medicare because of deductible, coinsurance, or other limitations under Medicare. The statutory definition of a Medicare supplemental policy excludes a number of plans that are generally considered to be Medicare supplemental plans, such as health plans for employees and former employees and for members and former members of trade associations and unions. A number of these health plans may be included under the [[Page 25278]] definitions of ``group health plan'' or ``health insurance issuer'', as defined in a. and b. above. g. A ``long-term care policy,'' including a nursing home fixed- indemnity policy. A ``long-term care policy'' is considered to be a health plan regardless of how comprehensive it is. We recognize the long-term care insurance segment of the industry is largely unautomated and we welcome comments regarding the impact of HIPAA on the long-term care segment. h. An employee welfare benefit plan or any other arrangement that is established or maintained for the purpose of offering or providing health benefits to the employees of two or more employers. This includes plans and other arrangements that are referred to as multiple employer welfare arrangements (``MEWAs'') as defined in section 3(40) of ERISA. i. The health care program for active military personnel under title 10 of the United States Code. j. The veterans health care program under chapter 17 of title 38 of the United States Code. This health plan primarily furnishes medical care through hospitals and clinics administered by the Department of Veterans Affairs for veterans with a service-connected disability that is compensable. Veterans with non-service-connected disabilities (and no other health benefit plan) may receive health care under this health plan to the extent resources and facilities are available. k. The Civilian Health and Medical Program of the Uniformed Services (CHAMPUS), as defined in 10 U.S.C. 1072(4). CHAMPUS primarily covers services furnished by civilian medical providers to dependents of active duty members of the uniformed services and retirees and their dependents under age 65. l. The Indian Health Service program under the Indian Health Care Improvement Act (25 U.S.C. 1601 et seq.). This program furnishes services, generally through its own health care providers, primarily to persons who are eligible to receive services because they are of American Indian or Alaskan Native descent. m. The Federal Employees Health Benefits Program under 5 U.S.C. chapter 89. This program consists of health insurance plans offered to active and retired Federal employees and their dependents. Depending on the health plan, the services may be furnished on a fee-for-service basis or through a health maintenance organization. Note: Although section 1171(5)(M) of the Act refers to the ``Federal Employees Health Benefit Plan,'' this and any other rules adopting administrative simplification standards will use the correct name, the Federal Employees Health Benefits Program. One health plan does not cover all Federal employees; there are over 350 health plans that provide health benefits coverage to Federal employees, retirees, and their eligible family members. Therefore, we will use the correct name, the Federal Employees Health Benefits Program, to make clear that the administrative simplification standards apply to all health plans that participate in the Program. n. Any other individual or group health plan, or combination thereof, that provides or pays for the cost of medical care. We would include a fourteenth category of health plan in addition to those specifically named in HIPAA, as there are health plans that do not readily fit into the other categories but whose major purpose is providing health benefits. The Secretary would determine which of these plans are health plans for purposes of title II of HIPAA. This category would include the Medicare Plus Choice plans that will become available as a result of section 1855 of the Act as amended by section 4001 of the Balanced Budget Act of 1997 (Pub. L. 105-33) to the extent that these health plans do not fall under any other category. 8. Medical care. ``Medical care,'' which is used in the definition of health plan, would be defined as current section 2791 of the Public Health Service Act defines it: the diagnosis, cure, mitigation, treatment, or prevention of disease, or amounts paid for the purpose of affecting any body structure or function of the body; amounts paid for transportation primarily for and essential to these items; and amounts paid for insurance covering the items and the transportation specified in this definition. 9. Participant. We would define the term ``participant'' as section 3(7) of ERISA currently defines it: a ``participant'' is any employee or former employee of an employer, or any member or former member of an employee organization, who is or may become eligible to receive a benefit of any type from an employee benefit plan that covers employees of such an employer or members of such organizations, or whose beneficiaries may be eligible to receive any such benefits. An ``employee'' would include an individual who is treated as an employee under section 401(c)(1) of the Internal Revenue Code of 1986 (26 U.S.C. 401(c)(1)). 10. Small health plan. We would define a ``small health plan'' as a group health plan with fewer than 50 participants. The HIPAA does not define a ``small health plan'' but instead leaves the definition to be determined by the Secretary. The Conference Report suggests that the appropriate definition of a ``small health plan'' is found in current section 2791(a) of the Public Health Service Act, which is a group health plan with fewer than 50 participants. We would also define small individual health plans as those with fewer than 50 participants. 11. Standard. Section 1171 of the Act defines ``standard,'' when used with reference to a data element of health information or a transaction referred to in section 1173(a)(1) of the Act, as any such data element or transaction that meets each of the standards and implementation specifications adopted or established by the Secretary with respect to the data element or transaction under sections 1172 through 1174 of the Act. Under our definition, a standard would be a set of rules for a set of codes, data elements, transactions, or identifiers promulgated either by an organization accredited by ANSI or the HHS for the electronic transmission of health information. 12. Transaction. ``Transaction'' would mean the exchange of information between two parties to carry out financial and administrative activities related to health care. A transaction would be (a) any of the transactions listed in section 1173(a)(2) of the Act and (b) any determined appropriate by the Secretary in accordance with section 1173(a)(1)(B) of the Act. We present them below in the order in which we propose standards for them in the regulations text. A ``transaction'' would mean any of the following: a. Health claims or equivalent encounter information. This transaction may be used to submit health care claim billing information, encounter information, or both, from health care providers to health plans, either directly or via intermediary billers and claims clearinghouses. b. Health care payment and remittance advice. This transaction may be used by a health plan to make a payment to a financial institution for a health care provider (sending payment only), to send an explanation of benefits or a remittance advice directly to a health care provider (sending data only), or to [[Page 25279]] make payment and send an explanation of benefits remittance advice to a health care provider via a financial institution (sending both payment and data). c. Coordination of benefits. This transaction can be used to transmit health care claims and billing payment information between health plans with different payment responsibilities where coordination of benefits is required or between health plans and regulatory agencies to monitor the rendering, billing, and/or payment of health care services within a specific health care/ insurance industry segment. In addition to the nine electronic transactions specified in section 1173(a)(2) of the Act, section 1173(f) directs the Secretary to adopt standards for transferring standard data elements among health plans for coordination of benefits and sequential processing of claims. This particular provision does not state that there should be standards for electronic transfer of standard data elements among health plans. However, we believe that the Congress, when writing this provision, intended for these standards to apply to the electronic form for coordination of benefits and sequential processing of claims. The Congress expressed its intent on these matters generally in section 1173(a)(1)(B), where the Secretary is directed to adopt ``other financial and administrative transactions * * * consistent with the goals of improving the operation of the health care system and reducing administrative costs.'' d. Health claim status. This transaction may be used by health care providers and recipients of health care products or services (or their authorized agents) to request the status of a health care claim or encounter from a health plan. e. Enrollment and disenrollment in a health plan. This transaction may be used to establish communication between the sponsor of a health benefit and the health plan. It provides enrollment data, such as subscriber and dependents, employer information, and health care provider information. The sponsor is the backer of the coverage, benefit or product. A sponsor can be an employer, union, government agency, association, or insurance company. The health plan refers to an entity that pays claims, administers the insurance product or benefit, or both. f. Eligibility for a health plan. This transaction may be used to inquire about the eligibility, coverage, or benefits associated with a benefit plan, employer, plan sponsor, subscriber, or a dependent under the subscriber's policy. It also can be used to communicate information about or changes to eligibility, coverage, or benefits from information sources (such as insurers, sponsors, and health plans) to information receivers (such as physicians, hospitals, third party administrators, and government agencies). g. Health plan premium payments. This transaction may be used by, for example, employers, employees, unions, and associations to make and keep track of payments of health plan premiums to their health insurers. h. Referral certification and authorization. This transaction may be used to transmit health care service referral information between health care providers, health care providers furnishing services, and health plans. It can also be used to obtain authorization for certain health care services from a health plan. i. First report of injury. This transaction may be used to report information pertaining to an injury, illness, or incident to entities interested in the information for statistical, legal, claims, and risk management processing requirements. Although we are proposing a definition for this transaction, we are not proposing a standard for it in this Federal Register document. (See section E.9 for a more in-depth discussion.) We will publish a separate proposed rule for it. j. Health claims attachments. This transaction may be used to transmit health care service information, such as subscriber, patient, demographic, diagnosis, or treatment data for the purpose of a request for review, certification, notification, or reporting the outcome of a health care services review. Although we are proposing a definition for this transaction, we are not proposing a standard for it in this Federal Register document because the legislation gave the Secretary an additional year to designate this standard. We will publish a separate proposed rule for it. k. Other transactions as the Secretary may prescribe by regulation. Under section 1173(a)(1)(B) of the Act, the Secretary shall adopt standards, and data elements for those standards, for other financial and administrative transactions deemed appropriate by the Secretary. These transactions would be consistent with the goals of improving the operation of the health care system and reducing administrative costs. C. Effective Dates--General Health plans would be required by Part 142 to comply with our requirements as follows: 1. Each health plan that is not a small health plan would have to comply with the requirements of Part 142 no later than 24 months after the effective date of the final rule. 2. Each small health plan would have to comply with the requirements of Part 142 no later than 36 months after the effective date of the final rule. Health care providers and health care clearinghouses would be required to begin using the standard by 24 months after the effective date of the final rule. (The effective date of the final rule will be 60 days after the final rule is published in the Federal Register.) Provisions of trading partner agreements that stipulate data content, format definitions or conditions that conflict with the adopted standard would be invalid beginning 36 months from the effective date of the final rule for small health plans, and 24 months from the effective date of the final rule for all other health plans. If HHS adopts a modification to an implementation specification or a standard, the implementation date of the modification would be no earlier than the 180th day following the adoption of the modification. HHS would determine the actual date, taking into account the time needed to comply due to the nature and extent of the modification. HHS would be able to extend the time for compliance for small health plans. This provision would be at Sec. 142.106. The law does not address scheduling of implementation of the standards; it gives only a date by which all concerned must comply. As a result, any of the health plans, health care clearinghouses, and health care providers may implement a given standard earlier than the date specified in the subpart created for that standard. We realize that this may create some problems temporarily, as early implementers would have to be able to continue using old standards until the new ones must, by law, be in place. At the WEDI Healthcare Leadership Summit held on August 15, 1997, it was recommended that health care providers not be required to use any of the standards during the first year after the adoption of the standard. However, willing trading partners could implement any or all of the standards by mutual agreement at any time during the 2-year implementation phase (3-year implementation phase for small health plans). In addition, it was recommended [[Page 25280]] that a health plan give its health care providers at least 6 months notice before requiring them to use a given standard. We welcome comments specifically on early implementation as to the extent to which it would cause problems and how any problems might be alleviated. D. Data Content [Please label any written comments or e-mailed comments about this section with the subject: Data Content] We propose standard data content for each adopted standard. There are two aspects of data content standardization: (1) Standardization of data elements, including their formats and definition, and (2) standardization of the code sets or values that can appear in selected data elements. A telephone number is an example of a data element that has a standard definition and format, but does not have an enumerated set of valid codes or values. A patient's diagnosis is an example of a data element that has a standard definition, a standard format, and a set of valid codes. Information that would facilitate data content standardization, while also facilitating identical implementations, would consist of implementation guides, data conditions, and data dictionaries, as noted in the addenda to this proposed rule, and the standard code sets for medical data that are part of this rule. Data conditions are rules that define the situations when a particular data element or record/segment can be used. For example, ``the name of the tribe'' applies only to Indian Health Service claims. The defining rule for that data element would be ``must be entered if claim is Indian Health Service''. 1. Data Element and Record/Segment Content Once we publish the final rule in the Federal Register and it is effective, there will be no additional data element or record/segment content modifications in any of the transactions for at least one year. In our evaluation and recommendation for each proposed standard transaction, we have tried to meet as many business needs as possible while retaining our commitment to the guiding principles. We encourage comments on how the standards may be improved. It is important to note that all data elements would be governed by the principle of a maximum defined data set. No one would be able to exceed the data sets defined in the final rule, until that rule is amended one or more years from the effective date of the final rule. This means that if a transaction has all of the data possible--based on the appropriate implementation guide, data content and data conditions specifications, and data dictionary--then a health plan would have to accept the transaction and process it. This does not mean, however, that the health plan would have to store or use information that it does not need in order to process a claim or encounter, except for audit trail purposes or for coordination of benefits if applicable. It does mean that the health plan would not be able to require additional information, and it does mean that the health plan would not be able to reject a transaction because it contains information the health plan does not want. This principle applies to the data elements of all transactions proposed for adoption in this proposed rule. 2. Code Sets [Please label any written comments or e-mailed comments about this section with the subject: Code Sets] a. Background The administrative simplification provisions of HIPAA require the Secretary of HHS to adopt standards for code sets for administrative and financial transactions. Two types of code sets are required for data elements in the transaction standards to be established under HIPAA: (1) Large code sets for medical data, including coding systems for: Diseases, injuries, impairments, other health related problems, and their manifestations; Causes of injury, disease, impairment, or other health- related problems; Actions taken to prevent, diagnose, treat, or manage diseases, injuries, and impairments and any substances, equipment, supplies, or other items used to perform these actions; and (2) smaller sets of codes for other data elements such as race/ethnicity, type of facility, and type of unit. A separate HIPAA implementation team co-chaired by representatives from HCFA, the Centers for Disease Control/National Center for Health Statistics, and the National Institutes of Health/National Library of Medicine, and including members from other interested HHS agencies and Federal Departments, was established to recommend the code sets that should become HIPAA standards for medical data. HHS efforts to identify candidate medical data code sets were coordinated with the NCVHS Subcommittee on Health Data Needs, Standards, and Security. The smaller sets of codes for other data elements in transactions standards are part of the transaction standards themselves and are specified in their implementation guides. The following medical data code sets are already in use in administrative and financial transactions: ICD-9-CM: The International Classification of Diseases, Ninth Revision, Clinical Modification, classifies both diagnoses (Volumes 1 and 2) and procedures (Volume 3). All hospitals and ambulatory care settings use it to capture diagnoses for administrative transactions. The procedure system is used for all in-patient procedure coding for administrative transactions. The ICD-9-CM was adopted for use in January 1979. The ICD-9-CM Coordination and Maintenance Committee is a Federal interdepartmental committee charged with maintaining and updating the ICD-9-CM. Requests for modification are handled through the ICD-9-CM Coordination and Maintenance Committee; no official changes are made without being brought before this committee. Suggestions for modifications come from both the public and private sectors and interested parties are asked to submit recommendations for modification prior to a scheduled meeting. Modifications are not considered without the expert advice of clinicians, epidemiologists, and nosologists (both public and private sectors). The meetings are open to the public and are announced in the Federal Register; all interested members of the public are invited to attend and submit written comments. Meetings are held twice each year. Approved modifications become effective October 1 of the following year. Changes to ICD-9-CM are published on the NCHS and HCFA websites, as well as by the American Hospital Association (AHA) and other private sector vendors. CPT: Physicians' Current Procedural Terminology is used by physicians and other health care professionals to code their services for administrative transactions. CPT is level one of the Health Care Financing Administration Procedure Coding System (HCPCS). CPT codes are updated annually by the AMA. The CPT Panel is comprised of 15 physicians, 10 nominated by the AMA and one each nominated by Blue Cross/Blue Shield of America (BCBSA), HIAA, HCFA, and AHA. Meetings are not open to the public. Alpha-numeric HCPCS: Alpha-numeric Health Care Financing Administration Procedure Coding System (HCPCS) contains codes for medical equipment and supplies; [[Page 25281]] prosthetics and orthotics; injectable drugs; transportation services; and other services not found in CPT. Alpha-numeric codes are level 2 of HCPCS. Its use is generally limited to ambulatory settings. The Omnibus Budget Reconciliation Act of 1986 requires the use of HCPCS in the Medicare program for services in hospital outpatient departments. Level II of HCPCS is updated annually and is maintained jointly by the BCBSA, the Health Insurance Association of America and HCFA. HCFA's regional offices assure coordination of local code assignments among the payers in a State; local codes must be approved by HCFA's central office to assure they do not duplicate national codes in CPT or Level II of HCPCS. Decisions regarding additions, deletions and revisions to Level II of HCPCS are made by the Alpha-Numeric Editorial Panel. This Panel, which meets three times a year, is comprised of representatives of the BCBSA, HIAA, and HCFA; the meetings are not open to the public. There are formal mechanisms to coordinate this Panel's activities with CPT and the American Dental Association's (ADA) procedure coding system. The revised HCPCS is available free of charge as a public use file. CDT: Current Dental Terminology is used in reporting dental services. CDT codes are also included in alpha-numeric HCPCS with a first character of D. Codes are revised on a five-year cycle by the ADA through its Council on Dental Benefits Program. Meetings are not open to the public. NDC: National Drug Codes are used in reporting prescription drugs in pharmacy transactions and some claims by health care professionals. The codes are assigned when the drugs are approved or repackaged and may be found on the packaging of drugs. i. Candidates for the Standards The principal sources of input to the recommendations for medical data code sets were: (a) The ANSI HISB Standards Inventory. The inventoried code sets are: ICD-9-CM, which consists of both diagnoses and procedure sections. The diagnosis system is widely used in the health care industry. All hospitals and ambulatory care settings use it to capture diagnoses. The procedure system is used for all in patient procedure coding. ICD-10-CM for diagnosis, which is under development as a replacement to the diagnosis section of ICD-9-CM and not yet in use in this country. ICD-10 was developed by the World Health Organization and has been implemented in approximately 37 countries to report mortality data. These are data that are taken and coded from death certificates. However, since our country's need for morbidity data cannot be satisfied by ICD-10, the United States is preparing a clinical modification of ICD-10 (ICD-10-CM). The public has been given an opportunity to review and comment on the current draft of ICD-10-CM. The final draft should be available in the summer of 1998. ICD-10-PCS for procedures, which is under development for use in the U.S. only as a replacement to the procedure section of ICD- 9-CM. CPT, which is used by all physicians and many other practitioners to code their services. It is also used by hospital outpatient departments to code certain ambulatory services. SNOMED (Systematized Nomenclature of Medicine), which is being used by the developers of computer-based patient record systems. It is not used in administrative transactions. CDT, which is used by all practicing dentists to code their services for administrative transactions. NIC (Nursing Interventions Classification), which is not used in administrative transactions in this country. LOINC (Logical Observation Identifier Names and Codes), which is being used in a pilot-test by the Centers for Disease Control to report tests as evidence of a communicable disease. It is also being tested in electronic transactions involving detailed clinical laboratory tests and results. It is not used in administrative transactions. HHCC (Home Health Care Classification system), which is not being used as a reporting system in this country. (b) A more extensive inventory of existing coding and classification systems prepared by the coding and classification implementation team itself and evaluated against the general HIPAA standards evaluation criteria (as found in section I.B., Process for developing standards for this proposed rule). This larger inventory (which will be placed on the home page of the National Center for Health Statistics at: http://www.cdc.gov/nchswww/ nchshome.htm) does not include any additional viable candidates for the initial standards for administrative code sets to be established under this proposed rule. It does contain some additional systems that may be applicable to elements of the claims attachments standard (to be issued on a later timetable) and to eventual HIPAA recommendations to the Congress regarding full electronic medical records. (c) The oral and written testimony submitted at an NCVHS public hearing to discuss medical/clinical coding and classification issues in connection with the requirements of HIPAA on April 15-16, 1997. The following entities presented testimony at the hearing: AMA, AHA, American Health Information Management Association, American College of Obstetricians and Gynecologists, American Academy of Pediatrics, American Nurses Association, National Association for Home Care, ADA, Family Practice Primary Care Work Group, National Association of Children's Hospitals and Related Institutions, Food and Drug Administration, College of American Pathologists, the Omaha System, developers of new nomenclature systems, research groups, publishers, consultants in coding, managed care organizations, software vendors, and informatics specialists. (d) The NCVHS' recommendations to the Secretary, HHS regarding codes and classifications. (e) Comments received in response to presentations at professional meetings and at the July 9, 1997, public meeting held by HHS on progress on selecting the initial HIPAA standards. For the hearing on April 15-16, 1997, the NCVHS invited interested organizations representing both the users and developers of medical/ clinical classification systems to present written and/or oral testimony responding to the following questions. ``--What medical/clinical codes and classifications do you use in administrative transactions now? What do you perceive as the main strengths and weaknesses of current methods for coding and classification of encounter and/or enrollment data? ``--What medical/clinical codes and classifications do you recommend as initial standards for administrative transactions, given the time frames in the HIPAA? What specific suggestions would you like to see implemented regarding coding and classification? ``--Prior to the passage of HIPAA, the National Center for Health Statistics initiated development of a clinical modification of the International Classification of Diseases-10 (ICD-10-CM), and HCFA undertook development of a new procedure coding system for inpatient procedures (called ICD-10-PCS), with a plan to implement them simultaneously in the year 2000. On the pre-HIPAA schedule, they will be released to the field for [[Page 25282]] evaluation and testing by 1998. If some version of ICD is to be used for administrative transactions, do you think it should be ICD-9-CM or ICD-10-CM and ICD-10-PCS, assuming that field evaluations are generally positive? ``--Recognizing that the goal of P.L. 104-191 is administrative simplification, how, from your perspective, would you deal with the current coding environment to improve simplification, reduce administrative burden, but also obtain medically meaningful information? ``--How should the ongoing maintenance of medical/clinical code sets and the responsibility, intellectual input and funding for maintenance be addressed for the classification systems included in the standards? What are the arguments for having these systems in the public domain versus in the private sector, with or without copyright? ``--What would be the resource implications of changing from the coding and classification systems that you currently are using in administrative transactions to other systems? How do you weigh the costs and benefits of making such changes? ``--A Coding and Classification Implementation Team has been established within the Department of Health and Human Services to address the requirements of P.L. 104-191; the Team's charge is enclosed. Does your organization have any concerns about the process being undertaken by the Department to carry out the requirements of the law in regard to coding and classification issues? If so, what are those concerns and what suggestions do you have for improvements?'' In general, those testifying at the April 15-16 hearing recommended that systems currently in use be designated as standards for the year 2000, since potential replacements were not yet fully tested and could not be implemented throughout the health care system by 2000. Testimony supported moving to ICD-10-CM for medical diagnoses after the year 2000 (different timetables were mentioned). Testimony provided by representatives from the American Psychiatric Association described the ongoing efforts to make the Diagnostic and Statistical Manual of Mental and Behavioral Disorders (DSM) completely compatible with ICD. The American Psychiatric Association has crosswalked the appropriate ICD-9- CM codes to what appear in the DSM for its diagnostic categories and is doing the same for ICD-10-CM for diagnosis. The mapping between DSM and ICD-10-CM for diagnosis is more precise than is possible for ICD-9-CM so the APA favors moving to ICD-10-CM for diagnosis as soon as possible. Many of those testifying emphasized the need to change to a less fragmented, overlapping, and duplicative approach to procedure coding, but sometime after the year 2000. Different potential approaches to achieving a more integrated procedure coding system were mentioned. Many identified current variations in the implementation of coding systems and the use of local HCPCS codes as problems that should be addressed. In general, those testifying approved the implementation team's charge, which includes an initial focus on the administrative standards for the year 2000 and longer term attention to recommendations for the more clinically-detailed vocabulary needed for full electronic medical records. Some of the developers of vocabularies and classifications who presented testimony emphasized the potential usefulness of their systems for full computer-based patient records, rather than for the administrative transactions that are the focus of the initial HIPAA standards. Comments on codes and classifications sets made at the June 3-4, 1997, Health Data Needs, Standards and Security Subcommittee hearings in San Francisco, California echoed those heard at the April hearing. On June 25, 1997, the NCVHS submitted the following recommendations to the Secretary of HHS regarding standards for codes and classifications for administrative transactions: The Committee recommends that diagnosis and procedure coding continue to use the current code sets because replacements will not be ready for implementation by the year 2000. ICD-9-CM diagnosis codes, ICD-9-CM Volume 3 procedure codes, and HCPCS (including Current Procedural Terminology (CPT) and Current Dental Terminology (CDT)) procedure codes should be adopted as the standards to be implemented by the year 2000. Annual updates to ICD-9-CM and HCPCS should continue to follow the schedule currently used. In addition, we recommend that you advise industry to build and modify their information systems to accommodate a change to ICD-10-CM diagnosis coding in the year 2001 and a major change to a unified approach to coding procedures (yet to be defined) by the year 2002 or 2003. We recommend that you identify and implement an approach for procedure coding that addresses deficiencies in the current systems, including issues of specificity and aggregation, unnecessary redundancy, and incomplete coverage of health care providers and settings. At the July 9, 1997, public meeting on progress on selecting the HIPAA standards, the implementation team presented an overview of its planned recommendations for coding and classification standards for the year 2000. The team's recommendations were similar to those of the NCVHS but included the use of NDC codes for pharmacy transactions that the NCVHS did not address. The implementation team did not recommend a specific timetable for changes in the standards after the year 2000. The team believed that its recommendations for changes after the year 2000 should await the results of field testing of ICD-10-CM for diagnosis and ICD-10-PCS for procedures (which should be available in March 1998) and further consideration of options for moving toward a more integrated approach to procedure coding. One of the coding systems that the implementation team considered to be promising for future implementation was the Universal Product Numbers (UPNs) system. The UPN system is a product numbering technology that uses human readable and bar code formats to identify products. A bar code and human readable number, which is unique to a particular product, is printed on the label or box as part of the production line process. There are currently two separate and different UPN coding systems that are generally accepted and recognized for health care products. One is numeric, a fixed 14 digit number, and the other an alpha-numeric format, a variable length number 8 to 20 digits. The numeric format is the system of the Health Care Uniform Code Council (UCC) and the alpha-numeric format is used by the Health Industry Business Communications Council (HIBCC). The first series of digits are assigned by one of these two private companies and identify the manufacturer or a repackager. The remaining digits are assigned by the manufacturer or repackager and are assigned according to the user's own standards and specifications. A manufacturer or repackager can apply to either one of these companies to use its system. The application fees, which are collected by either UCC or HIBCC, vary based on the manufacturer's or repackager's sales volume. The Department of Defense has started to use UPNs for its prime vendor program. Currently, there are purchasers and providers of medical equipment that are using the UPN system for inventory purposes, but, at this time, there are no insurers that pay for health care products using the UPN system. California Medicaid, however, has plans to begin using UPNs as part of its system. At this time, approximately 30 percent of the health care products do not have a UPN assigned to them. For this reason, in addition to the fact that no insurer currently uses UPNs for reimbursement, UPNs were not included in the initial list of standards. [[Page 25283]] However, it is a coding system that bears close examination during the next few years as a possible replacement for alpha-numeric HCPCS codes for health care products. Some consideration is being given to conducting a demonstration study in the Medicare program on the use of UPNs for reimbursement. Comments on the use of the UPNs as a national coding system are being sought. In particular, comments on issues such as timing of implementation, any complications presented by the existence of multiple bodies issuing UPN codes, the acceptability of varying lengths and formats, and the frequent changes in manufacture and packaging size would be helpful. ii. Changes to HCPCS for Implementation in the Year 2000 In proposing the use of the existing coding systems as the standards for the year 2000, many participants at public meetings voiced concern about overlaps in several of the coding systems, problems with HCPCS local codes, differences in implementation of NDC codes in different systems, and differences between the CDT codes in HCPCS and those issued by the ADA. It was repeatedly suggested that these issues be resolved and overlaps be eliminated for standards adopted in the year 2000. After careful consideration of all public input and of the options for modifying HCPCS in the relatively near term, the implementation team is recommending that changes be implemented in HCPCS in the year 2000 to reduce its overlap with other coding systems. HCPCS contains three levels. Level 1, CPT, is developed and maintained by the AMA and captures physician services. Level 2, alpha- numeric HCPCS, contains codes for products, supplies, and services not included in CPT. Level 3, local codes, includes all the codes developed by insurers and agencies to fulfill local needs. We are proposing the adoption of HCPCS levels 1 and 2 for implementation in the year 2000. In addition, we are proposing to modify HCPCS level 3 for the year 2000 to eliminate overlaps and duplications. Most third-party public and private health insurers (such as Medicare contractors, Medicaid program and fiscal agents, and private commercial health insurers) use HCPCS as a basis for paying claims for medical services provided on a fee-for-service basis and for monitoring the quality and utilization of care. In addition, integrated health systems, such as managed care organizations, also use HCPCS as a basis for monitoring utilization and quality of care and for negotiating prospective fees and capitated payments. Research organizations use the HCPCS data collected by health insurers to monitor and evaluate these programs and regional/national patterns of care. As previously stated, HCPCS alpha-numeric codes capture products, supplies, and services not included in CPT. The ``D'' codes in the HCPCS system are dental codes created by the ADA and published as CDT. However, in HCPCS, the first digit ``0'' in CDT is replaced by a ``D'' to eliminate confusion and overlap with certain CPT codes. The ADA has agreed to replace their first digit ``0'' with a ``D'' so that CDT can become the national standard. There would no longer be dental codes within HCPCS. Consequently, CDT codes will no longer be issued within HCPCS as of the year 2000. The ADA will be the sole source of the authoritative version of CDT. The ``J'' codes within alpha-numeric HCPCS are for drugs. A separate coding system, the NDC developed by the Food and Drug Administration, is also used to report drug claims in the ANSI X12N 837--Health Care Claim: Professional and in pharmacy transactions. The NDC system, which has 11-digit codes, is more precise and more current than the HCPCS ``J'' codes. NDC identifies drugs prescribed down to the manufacturer, product name and package size. NDC codes are assigned on a continuous basis throughout the year as new drug products are issued; ``J'' codes are assigned on an annual basis. Many providers are currently forced to maintain both ``J'' and NDC codes to provide data to different insurers. The majority of the local codes currently created were developed because of the lack of a ``J'' code for a new drug. Local codes are level 3 of the HCPCS and are assigned by local insurers or agencies where there is no national code. By eliminating ``J'' codes from alpha-numeric HCPCS codes and utilizing only NDC codes for drugs, greater national uniformity can be achieved, the workload of providers who previously had to utilize two drug coding systems will be reduced, and the need for local codes will diminish substantially. HHS is, therefore, proposing that NDC codes become the national standard in the year 2000 for all types of transactions requiring drug codes and that ``J'' codes be deleted from alpha-numeric HCPCS. This would require those handling electronic administrative transactions to process 11-digit NDC codes in the year 2000. Level 3 of HCPCS is intended to meet local needs and is established on a local basis by health insurers. There is no national registry for these local codes. We propose that, beginning in the year 2000, local codes be eliminated and that a national process be established for reviewing and approving codes that are needed by any public or private health insurer. The first step in this process would be to ask public and private health insurers to review the local codes they use and to immediately eliminate those that duplicate a national HCPCS code or NDC code already in existence. (See the previous section for a discussion of NDC codes.) They would also be asked to eliminate those local codes for which there are few claims submissions (for example, fewer than 50 per year) and that could reasonably and effectively be reviewed by the health insurer. Health insurers would also be asked to eliminate those local codes which were established for administrative purposes, to facilitate claims payment, rather than to identify and describe medical services, supplies and procedures. (A code for ``administration of immunization at public health clinic'' is an example of a code that includes administrative information in addition to information about the clinical content of the service.) This purging would result in the elimination of the vast majority of local codes now in use. Any remaining local codes would then have to be submitted by the health insurer to HCFA for review and approval as temporary codes. The HCPCS panel currently meets every two to three months to approve requests for temporary codes. This process will be re-examined to determine if more frequent meetings are required. The process would be modeled after the one that is currently used to review and approve code requests from Medicare and its contractors. Codes that are approved by HCFA would be established as national temporary codes that would be posted electronically and would be available for use by all health insurers. National temporary codes would be reviewed on an annual basis to make sure they are not duplicative of CPT codes or alpha-numeric codes that are newly established. This new centralized process for establishing national temporary codes would run parallel to the process for establishing national CPT codes, alpha-numeric HCPCS codes, and NDC codes. It is expected that most of the codes submitted for approval by HCFA in this process would be for new medical technologies and services not yet approved for codes by CPT or the alpha- [[Page 25284]] numeric process or for other medical services/procedures covered by health insurers which have no associated CPT or alpha-numeric codes. These recommendations are based on the following: As stated earlier, many participants at public meetings voiced concerns about overlaps in codes that are used and the proliferation of local codes. Local codes that are duplicative of national codes create extra work and confusion for providers who must submit different codes to different health insurers. Local codes also make it more difficult for researchers and programs such as Medicaid and Medicare to evaluate and monitor patterns of care and the utilization and quality of care on a regional or national basis. The use of local codes established for administrative purposes, to facilitate claims payment rather than to identify medical services, supplies and procedures, is contrary to the intent of the medical coding system, which is intended to describe medical services used to prevent, diagnose, treat or manage diseases, injuries, and impairments. Administrative functions necessary to process and facilitate claims by health insurers can be achieved by using ``administrative'' codes placed in fields other than those used for medical diagnosis and procedure codes or by attaching a modifier to a medical code. Because the need for new temporary codes is not unique to an individual health insurer, the new codes that are created as a result of this centralized process would be useful not just to the health insurer who submitted the original request for a code but also to many other health insurers across the country. By eliminating duplicative and otherwise unnecessary local codes and adding national temporary codes through the centralized process discussed above, we believe we are being consistent with the intent of HIPAA to simplify the administration of the claims review, payment and monitoring process. We welcome comments and suggestions on this proposal for eliminating unnecessary local codes and establishing a centralized, national process for establishing national temporary codes. We seek input specifically on the problems and barriers to creating this type of process. We are also specifically looking for examples of the kinds of local codes that are now being used that would have to be replaced with national codes or for alternatives to the above-described process. iii. Recommended Standards and Implementation Guides The proposed standard code sets for different types of medical data are outlined below: (a) Diseases, injuries, impairments, other health related problems, their manifestations, and causes of injury, disease, impairment, or other health-related problems. The proposed standard code set for these conditions is the International Classification of Diseases, 9th edition, Clinical Modification, (ICD-9-CM), Volumes 1 and 2, as maintained and distributed by the National Center for Health Statistics, Centers for Disease Control and Prevention, U.S. Department of Health and Human Services. The specific data elements for which ICD-9-CM is the required code set are enumerated in the implementation guides for the transactions standards that require its use. An area of weakness of the ICD-9-CM is that it is not always precise or unambiguous. However, there are no viable alternatives for the year 2000. Many problems cannot be resolved within the current structure, but are being addressed in the development of ICD-10-CM for diagnosis, which is expected to be ready for implementation some time after the year 2000. The official coding guidelines for this proposed standard code set are in the public domain and available at no cost on the NCHS website at: http://www.cdc.gov/nchswww/about/otheract/icd9/icd9hp2.htm. Users without access to the Internet may purchase the official version of ICD-9-CM on CD-ROM from the Government Printing Office (GPO) at 1-202- 512-1800 or fax 1-202-512-2250. The CD-ROM contains the ICD-9-CM classification and the coding guidelines. The guidelines are also included in code books and coding manuals published by not-for-profit (for example, the American Hospital Association and the American Health Information Management Association) and other private sector vendors. (b) Procedures or other actions taken to prevent, diagnose, treat, or manage diseases, injuries and impairments. (1) Physician Services The proposed standard code set for these entities is the Current Procedural Terminology (CPT) (level 1 of HCPCS) as maintained and distributed by the AMA. The specific data elements for which CPT (including codes and modifiers) is a required code set are enumerated in the implementation guides for the transaction standards that require its use. Narrative coding guidelines are presented at the beginning of each of the six sections of print edition of CPT and, in addition, special instructions for specific codes or groups of codes appear throughout CPT. CPT is available from the AMA at a charge as well as from several not-for-profit and other private sector vendors. An area of weakness of the CPT is that it is not always precise or unambiguous. However, there are no viable alternatives for the year 2000. (2) Dental Services The proposed standard code set for these services is the Current Dental Terminology (CDT) as maintained and distributed by the ADA for a charge. The specific data elements for which CDT is a required code set are enumerated in the implementation guides for the transaction standards that require its use. The official implementation guidelines for this standard appear in CDT as descriptors that explain the appropriate use of the codes. Copies of the ADA Current Procedural Terminology Second Edition (CDT-2) may be obtained by calling 1-800-947-4746. The ADA is in the process of developing CDT-3 for introduction in the year 2000. (3) Inpatient Hospital Services The proposed standard code set for these services is the International Classification of Diseases, 9th edition, Clinical Modification, Volume 3, as maintained and distributed by the Health Care Financing Administration, U.S. Department of Health and Human Services. The specific data elements for which ICD-9-CM, Volume 3, is a required code set are enumerated in the implementation guides for the transactions standards that require its use. As stated earlier, an area of weakness of the ICD-9-CM is that it is not always precise or unambiguous. However, there are no viable alternatives for the year 2000 that are more precise or less ambiguous. Many problems cannot be resolved within the current structure but are being addressed in the development of ICD-10-PCS for procedures, which is expected to be ready for implementation some time after the year 2000. The official coding guidelines for this standard are in the public domain and available at no cost on the NCHS website at http:// www.cdc.gov/nchswww/about/otheract/icd9/icd9hp2.htm. Users without access to [[Page 25285]] the Internet may purchase the official version of ICD-9-CM on CD-ROM from the Government Printing Office at 1-202-512-1800 or fax 1-202-512- 2250. The CD-ROM contains the ICD-9-CM classification and the coding guidelines. The guidelines are also included in code books and coding manuals published by not-for-profit (for example, the American Hospital Association and the American Health Information Management Association) and private sector vendors. (c) Other Health-Related Services The proposed standard code set for other health-related services is the Health Care Financing Administration Procedure Coding System (alpha-numeric HCPCS) as maintained and distributed by the Health Care Financing Administration, U.S. Department of Health and Human Services. We are proposing to make significant modifications to alpha-numeric HCPCS for the year 2000. These modifications are described in Section II.D.2.a.ii of this proposed rule. The specific data elements for which alpha-numeric HCPCS (including codes and modifiers) is a required code set are enumerated in the implementation guides for the transaction standards that require its use. Alpha-numeric HCPCS codes meet all but one of the guiding principles for choosing standards. An area of weakness is that it is not always precise or unambiguous. However, there are no viable alternatives for the year 2000 that are more precise or less ambiguous. Some of the areas of ambiguity in HCPCS (the ``J'' codes for drugs, local codes, variant CDT codes) have been addressed in the changes recommended for the year 2000. The 1998 alpha-numeric HCPCS file (excluding the D procedure codes copyrighted by the ADA) is available from the HCFA website at http:// www.hcfa.gov/stats/pufiles.htm. Users can also access this page by taking the Stats and Data link to the Browse/Download available PUFs link. The 1998 alpha-numeric HCPCS file is on the HCFA Public Use Files page under the Utilities/Miscellaneous heading. The HCPCS is in an executable format, which includes 1998 alpha- numeric HCPCS in both Excel/ and text, the 1998 Alpha- Numeric Index in both Portable Document Format/ (PDF) and text, the 1998 Table of Drugs in both PDF and text, the 1998 HCPCS record layout in WordPerfect/ and text, and a read me file in WordPerfect/ and text. (d) Drugs The proposed standard code set for these entities is the National Drug Codes as maintained and distributed by the Food and Drug Administration, U.S. Department of Health and Human Services, in collaboration with drug manufacturers. The specific data elements for which NDC is a required code set are enumerated in the implementation guides for the transaction standards that require its use. NDC codes as established by the Food and Drug Administration are made available on the individual drug package inserts and product labeling. The Food and Drug Administration, Center for Drug Evaluation and Research, Office of Management, Division of Database Management, prepares an annual update, with periodic cumulative supplements of the Approved Drug Products with Therapeutic Equivalence Evaluations for prescription drug products, over the counter drug products and discontinued drug products. The supplements are available on diskette, on a quarterly basis, from the National Technical Information Service at 703-487-6430. The files are also available on the Internet's World Wide Web on the CDER Home Page at http://www.fda.gov/cder. The NDC codes are also published in such drug publications as the Physicians' Desk Reference under the individual drug product listings and ``How supplied.'' (e) Other Substances, Equipment, Supplies, or Other Items Used in Health Care Services The proposed standard code set for these entities is the Health Care Financing Administration Procedure Coding System (alpha-numeric HCPCS) as maintained and distributed by the Health Care Financing Administration, U.S. Department of Health and Human Services. We are proposing to make significant modifications to alpha-numeric HPCPS for the year 2000. These modifications are described in Section II.D.2.a.ii of this proposed rule. The specific data elements for which alpha- numeric HCPCS is a required code set are enumerated in the implementation guides for the transactions standards that require its use. The recommended code sets adhere to the principles for guiding choices for the standards to be adopted under HIPAA as follows: Improve the efficiency and effectiveness of the health care system by leading to cost reductions for or improvements in benefits from electronic health care transactions. Improvements in efficiency and effectiveness over the current status quo will result from: (a) The requirement for all those exchanging electronic transactions to use a single official implementation guide for each recommended code set; and (b) the proposed changes to HCPCS, which will eliminate overlap between NDC and HCPCS, eliminate one of the two current versions of CDT codes, and eliminate the use of local HCPCS codes that are known only to institutions that developed them. Meet the needs of the health data standards user community, particularly health care providers, health plans, and health care clearinghouses. The recommended code sets meet some of the needs of the community. To meet all of the community's needs (e.g., elimination of overlap in procedure coding systems and better coverage of nursing and allied health services) will require changes to the code sets recommended or their replacement by newer systems, once these have been fully tested and revised. Essentially all segments of the health care community testified that there was no practical alternative to the recommended code sets for the year 2000, although they recommended changes after that time. Be consistent and uniform with the other HIPAA standards-- their data element definitions and codes and their privacy and security requirements--and, secondarily, with other private and public sector health data standards. All of the recommended code sets are required for selected data elements in more than one of the recommended transaction standards. Have low additional development and implementation costs relative to the benefits of using the standard. The recommended code sets are currently used by many segments of the health care community. Be supported by an ANSI-accredited standards developing organization or other private or public organization that will ensure continuity and efficient updating of the standard over time. All of the recommended code sets are supported by U.S. government agencies or private sector organizations that have demonstrated a commitment to maintaining them over time. Have timely development, testing, implementation, and updating procedures to achieve administrative simplification benefits faster. All of the recommended code sets have existing procedures for updating at [[Page 25286]] least annually. NDC updates continually throughout the year. Be technologically independent of the computer platforms and transmission protocols used in electronic health transactions, except when they are explicitly part of the standard. All of the recommended code sets are technologically independent of computer platforms and transmission protocols. Be precise and unambiguous, but as simple as possible. There are some problems with lack of precision and ambiguity in all the recommended code sets, but there are no viable alternatives for the year 2000. In the case of ICD-9-CM, many problems cannot be resolved within the current structure but are being addressed in the development of ICD-10-CM for diagnosis and ICD-10-PCS for procedures, which are expected to be ready for implementation some time after 2000. Some of the sources of ambiguity in HCPCS (the ``J'' codes for drugs, local codes, variant CDT codes) have been addressed in the changes recommended for the year 2000. The movement to a single framework for procedure coding, sometime after the year 2000, will address other known problems with the procedure codes. Keep data collection and paperwork burdens on users as low as is feasible. Because the recommended code sets are currently used throughout the health care community, they should not add substantially to data collection or paperwork burdens. Incorporate flexibility to adapt more easily to changes in the health care infrastructure (such as new services, organizations, and provider types) and information technology. Some of the recommended code sets lack a desirable level of flexibility; e.g., they use hierarchical codes and may therefore ``run out of room'' for additional codes required by advances in medicine and health care. Since they appear to be the only feasible alternatives for the year 2000, steps should be taken to improve their flexibility--or replace them with more flexible options--sometime after the year 2000. iv. Probable Changes to Coding and Classification Standards After 2000 Although the exact timing and precise nature of changes in the code sets designated as standards for medical data are not yet known, it is inevitable that there will be changes to coding and classification standards after the year 2000. As indicated in testimony at the NCVHS hearings previously discussed, changes will be required to address current coding system deficiencies that adversely affect the efficiency and quality of administrative data creation and to meet international treaty obligations. For example, ICD-10-CM for diagnosis is highly likely to replace ICD-9-CM as the standard for diagnosis data, possibly in 2001. When any of the standard code sets proposed in this rule are replaced by wholly new or substantially revised systems, the new standards may have different code lengths and formats. The current draft of ICD-10-CM for diagnoses contains 6 digit codes; the longest ICD-9-CM codes have 5 digits. In addition to accommodating the initial code sets standards for the year 2000, those that produce and process electronic administrative health transactions should build the system flexibility that will allow them to implement different code formats beyond the year 2000. As also clearly expressed in the hearings and other input to HHS, any major change in administrative coding systems involves significant initial costs and dislocations, as well as some level of discontinuity in data collected before and after the change. These factors must be weighed against expected improvements in the efficiency of data creation and in the accuracy and utility of the data collected. In the future, more flexible health data systems may assist in reducing the costs of implementing changes in administrative coding and classification standards, especially if administrative codes can be generated automatically from more granular clinical data. b. Requirements In Sec. 142.1002, we would state that health plans, health care clearinghouses, and health care providers must use in electronic transactions the diagnosis and procedure code sets as prescribed by HHS. The names of these diagnosis and procedure code sets are published in a notice in the Federal Register. The implementation guides for the transaction standards in part 142, Subparts K through R would specify which of the standard medical data code sets should be used in individual data elements within those transaction standards. In Sec. 142.1004, we would specify that the code sets in the implementation guide for each transaction standard in part 142, subparts K through R, are the standard for the coded nonmedical data elements present in that transaction standard. In Sec. 142.1010, The requirements sections of part 142, subparts K through R, would specify that those who transmit electronic transactions covered by the transaction standards must use the appropriate transaction standard, including the code sets that are required by that standard. These sections would further specify that those who receive electronic transactions covered by the transaction standards must be able to receive and process all standard codes, without regard to local policies regarding reimbursement for certain conditions or procedures, coverage policies, or need for certain types of information that are not part of a standard transaction. E. Transaction Standards The HISB prepared an inventory of candidate standards to be considered by HHS in the standards adoption process. HHS wrote letters to the NUBC, the NUCC, the ADA, and WEDI in order to consult with them as required by the Act. HHS also consulted with them informally and received their support on all the transactions at various meetings and at the public meeting we held on July 9, 1997, in Bethesda, Maryland. The NCVHS held public hearings during which any person could present his or her views. There also were opportunities for those who could not attend the public hearings to provide written advice, and many did take advantage of that opportunity. In addition, HHS welcomed informal advice from any industry member, and that advice was taken into consideration during the decision making process. Recommendations for enrollment and disenrollment in a health plan, eligibility for a health plan, health care payment and remittance advice, health plan premium payments, first report of injury, health claim status, and referral certification and authorization were overwhelmingly in favor of ASC X12N implementations. Also, the recommendation for the National Council of Prescription Drug Programs (NCPDP) version 3.2 telecommunication standard format was not controversial and was nearly unopposed. The recommendations for the professional and institutional claims were quite controversial, with some factions supporting the de facto flat file standards that have been in use for many years and others supporting X12N standards. [[Page 25287]] (A flat file is a file that has fixed-length records and fixed- length fields.) Some associations proposed dual standards with the flat file claim standards (National Standard Format for professional claims and electronic UB-92 for institutional claims) to sunset on a specified date, at which time the parallel ASC X12N claim implementations would become the sole standards to be used. The HHS claims implementation team recommended, and we are proposing for adoption, the following standards as implemented through the appropriate implementation guides, data content and data conditions specifications, and data dictionary: Health care claim and equivalent encounter: + Retail drug: NCPDP Telecommunication Claim version 3.2 or equivalent NCPDP Batch Standard Version 1.0. + Dental claim: ASC X12N 837--Health Care Claim: Dental. + Professional claim: ASC X12N 837--Health Care Claim: Professional. + Institutional claim: ASC X12N 837--Health Care Claim: Institutional. Health care payment and remittance advice: ASC X12N 835-- Health Care Payment/Advice. Coordination of benefits: + Retail drug: NCPDP Telecommunication Standard Format version 3.2 or equivalent NCPDP Batch Standard Version 1.0. + Dental claim: ASC X12N 837--Health Care Claim: Dental. + Professional claim: ASC X12N 837--Health Care Claim: Professional. + Institutional claim: ASC X12N 837--Health Care Claim: Institutional. Health claim status: ASC X12N 276/277--Health Care Claim Status Request and Response. Enrollment and disenrollment in a health plan: ASC X12 834--Benefit Enrollment and Maintenance. Eligibility for a health plan: ASC X12N 270/271--Health Care Eligibility Benefit Inquiry and Response. Health plan premium payments: ASC X12 820--Payment Order/ Remittance Advice. Referral certification and authorization: ASC X12N 278-- Health Care Services Review--Request for Review and Response. We chose version 4010 of X12 for each ASC X12N transaction. Later in this proposed rule is a list of candidates for most transactions. The ASC X12N transactions listed as candidate standards in this section were originally specified as version 3070 because at the time of HISB inventory version 3070 was the most current DSTU version. However, we are proposing that version 4010 would be proposed in lieu of version 3070 for the following reasons: Version 4010 is millennium ready. Version 4010 allows for up-to-date changes to be incorporated into the standards. We will propose a claims attachment standard in a separate document as the statute gives the Secretary an additional year to designate this standard. The attachment standards are likely to be drafted so that health care providers using Health Level 7 (HL7) for their in-house clinical systems would be able to send HL7 clinical data to health plans. Anyone wishing to use the HL7 may want to consider a translator that supports the administrative transactions proposed in this proposed rule and the HL7. We will also propose a standard for first report of injury transactions in a later rule for reasons explained in depth under section II.E.9. 1. Standard: Health Claims or Equivalent Encounter Information (Subpart K) [Please label any written comments or e-mailed comments about this section with the subject: Health Claims] a. Background By the mid-1970s, several health care industry associations had formed committees to attempt to standardize paper health care claim or equivalent encounter forms. By the mid-1980s, those committees were standardizing electronic formats with equivalent data. By the early 1990s, some of these committees were working with the ASC X12N Subcommittee. Nevertheless, many health plans continued to require local formats, revising the formats to suit their own purposes rather than following procedures in order to revise the standards. As a result, it is not unusual for health care providers to support many electronic health care claim formats, either directly or by using clearinghouse services, in order to do business with the many health plans covering their patients. The committees that pursued organizational goals (such as a more cost-efficient environment for the provision of health care, more time and resources for patient care, and fewer resources for administration) were usually sponsored by health care provider associations such as the National Council of Prescription Drug Programs, the AMA, the American Hospital Association, and the ADA. Each association contributed to the development of the four corresponding accredited claims standards proposed for adoption, with content based on de facto standards derived over time. i. Candidates for the Standard The HISB developed an inventory of health care information standards for HHS to consider for adoption. The candidate standards for health claims or equivalent encounter information were: Retail drug: NCPDP Telecommunications Standard Format Version 3.2. Dental claim: ASC X12N 837--health care claim: dental, version 3070 implementation. Professional claim: ASC X12N 837--health care claim: Professional, version 3070 implementation and HCFA National Standard Format (NSF), version 002.00. + Institutional claim: ASC X12N 837--health care claim: institutional, version 3070 implementation and HCFA Uniform Bill (UB- 92) version 4.1 ii. Recommended Standards The four standards for claims or equivalent encounter information we are proposing in this proposed rule are: Retail drug: NCPDP Telecommunications Standard Format Version 3.2 and equivalent NCPDP Batch Standard Version 1.0. The NCPDP was formed in 1977 as the result of a Senate Ad Hoc Committee to study standardization within the pharmacy industry. The NCPDP was specifically named in HIPAA as a standards setting organization accredited by ANSI. The first NCPDP Telecommunications Standard was developed in 1988 and allowed pharmacists to process claims in an interactive environment. The NCPDP developed the Telecommunications Standard Format for electronic communication of claims between pharmacy providers, insurance carriers, third-party administrators, and other responsible parties. The standard addresses the data format and content, the transmission protocol, and other appropriate telecommunications requirements. The NCPDP received input from all aspects of the prescription drug industry and designed the standard to be easy to implement and flexible enough to respond to the changing needs of the industry. The NCPDP also provides changes and additions to the standard to support unique requirements included in government mandates. The NCPDP telecommunications standard for claim and equivalent encounter data is on-line interactive. There is also a batch implementation of this standard, the NCPDP Batch Standard Version 1.0. The [[Page 25288]] telecommunications standard data set includes eligibility/enrollment, claim, and remittance advice information. When the transaction is complete, the sending pharmacy knows whether the customer is covered by the health plan, the health plan knows all of the details of the claim, the pharmacy knows whether the claim will be paid, and how much it will be paid, and any pertinent details regarding the amount of payment or the reason for denial of payment. This standard met all 10 of the criteria used to assess standards. Since retail drug claims are a specialized class and the NCPDP structure contains claims, enrollment/eligibility and remittance advice data, we did not recommend the ASC X12N 837 for the retail drug standard. Dental claim: ASC X12N 837--Health Care Claim: Dental. The ADA recommended adoption of the ASC X12N 837, version 3070. This standard met all of the criteria used to assess standards. Professional claim: ASC X12N 837--Health Care Claim: Professional. HHS consulted with external groups in accordance with the legislation. These groups included the NCVHS, WEDI, the NUCC, the NUBC, the ADA, and many others. In a letter, dated March 12, 1997, the NUCC stated, The NUCC recommends to the Secretary of HHS that the ANSI ASC X12 837 transaction be adopted as a standard for electronically transmitting professional claims or equivalent encounters, including coordination of benefits information, as per the Administrative Simplification provision of the HIPAA. The NUCC recommends that a migration plan be adopted to allow current trading partners who use the National Standard format (NSF) to convert to a standard NSF, which will be implemented by the Secretary per the HIPAA, by February 2000 and to convert to the standard ANSI ASC X12 837 by February 2003. The AMA also supported the NUCC recommendation. However, the NCVHS and WEDI recommended adoption of the ASC X12N 837 transaction. The claims implementation team decided that, since the NUCC was clear that it wanted the ASC X12N 837 transaction in the end, it would be better to invest in migrating to that, rather than support two standards and take more time for the transition. Our recommendation takes into account the advice we received from organizations that we consulted directly and indirectly and from those who testified before the NCVHS subcommittee on Health Data Needs, Standards, and Security. These organizations included entities representing all parts of the health care industry--health care providers, health plans, and vendors/clearinghouses--to which the standard will apply. The ASC X12N 837 standard met all 10 criteria used to assess standards. The NSF met 5 of the criteria. The NSF does not improve the efficiency and effectiveness of the health care system (#1) because a standard implementation does not exist. The NSF meets the needs of many users, particularly Medicare, but not all of the needs of the user community (#2). It is not supported by an ANSI-accredited SDO (#5). There are no testing or implementation procedures in place (#6). Due to its fixed-length structure, it does not incorporate flexibility to adapt easily to change (#10). Institutional claim: ASC X12N 837--Health Care Claim-- Institutional. HHS consulted with the groups identified under our discussion of the standard for professional claims above in this section and also consulted with the NUBC on the selection of an institutional standard. In a letter dated March 11, 1997, the NUBC stated, The NUBC recommends the use of the EMC V.4 (UB-92) as the single electronic standards transaction for institutional health claims and encounters. We recommend the EMC V.4 for the following reasons: --Nearly all institutional providers already use the EMC V.4 with a high level of success. --The EMC V.4 has been in full production for over four years. --There is no additional cost for providers to adopt the EMC V.4. --It reduces the risks associated with the adoption of a new, complex and relatively untested transaction. --It allows for a more successful transition to the 837. We agree with HCFA that coordination of benefits transactions (COB) do not require a fully separate transaction for the health care claim or encounter. The NUBC also believes that the EMC V.4 should be used as the platform for transmitting COB data elements. At the present time, the NUBC cannot recommend the use of the 837 as the electronic institutional claim standard. We recommend that larger scale testing of the 837 proceed. Once the transaction has proven that it can successfully handle the claim/encounter, the NUBC will consider endorsing the 837 as a successor standard. The American Hospital Association also supported NUBC's recommendation. The NCVHS and WEDI recommended adoption of the ASC X12N 837 transaction. Due to the batch nature of the ASC X12N transactions, each transaction type and its corresponding data elements are separated by function. The adoption of the transactions for those functions (such as claims and remittance advice), with the exception of the NCPDP transaction, have all been recommended to be ASC X12N transactions. The ASC X12N 837 met all 10 criteria used to assess the standards. The UB- 92 met 5 of the criteria. The UB92 does not improve the efficiency and effectiveness of the health care system (#1) because a standard implementation does not exist. The UB92 is not supported by an ANSI- accredited SDO (#5). There are no testing or implementation procedures in place (#6). The UB92 documentation is ambiguous in some instances and not always precise (#8). Due to its fixed-length structure, it does not incorporate flexibility to adopt easily to change (#10). The NUBC stated it would consider the 837, once successfully tested. For these reasons, we have concluded that the ASC X12N 837 should be adopted as the standard format implementation of the institutional claim. For the most part, a health care provider would use only one of these four health care claim implementations, although a large institution might use the institutional claim for inpatient and outpatient claims, the professional claim for staff physicians who see private patients within the institution, and the retail pharmacy claim, if applicable, which typically would be administered separately from the rest of the institution. Data elements for the various standards and other information may be found in Addendum 1. b. Requirements In Sec. 142.1102, we would specify the exact standards we are adopting: the NCPDP Telecommunications Standard Format Version 3.2 and equivalent NCPDP Batch Standard Version 1.0; the ASC X12N 837--Health Care Claim: Dental, the ASC X12N 837--Health Care Claim: Professional, and the ASC X12N 837--Health Care Claim: Institutional. We would specify where to find the implementation guide and incorporate it by reference. i. Health plans. In Sec. 142.1104, Requirements: Health plans, we would require health plans to accept only the standards specified in Sec. 142.1102 for electronic health claims or equivalent encounter information. ii. Health care clearinghouses. We would require in Sec. 142.1106 that each health care clearinghouse use the standard specified in Sec. 142.1102 for health claims or equivalent encounter information transactions. iii. Health care providers. [[Page 25289]] In Sec. 142.1108, Requirements: Health care providers, we would require each health care provider that transmits health claims and encounter equivalent electronically to use the standard specified in Sec. 142.1102. c. Implementation Guide and Source The source of implementation guides for the NCPDP telecommunication claim version 3.2 and equivalent NCPDP Batch Standard Version 1.0 is the National Council for Prescription Drug Programs, 4201 North 24th Street, Suite 365, Phoenix, AZ, 85016; telephone 602-957-9105; FAX 602- 955-0749. The web site address is: http://www.ncpdp.org. NCPDP standards are available to the public on a 3\1/2\'' diskette for a fee. A set is defined as containing the Telecommunications Standard, Standard Claims Billing Tape Format, Eligibility Verification and Response, and Enrollment. Membership in the NCPDP is not a requirement for obtaining the standards and associated implementation guides. The website contains information and instructions for obtaining these documents. The implementation guides for the ASC X12N standards are available at no cost from the Washington Publishing Company site at the following Internet address: http://www.wpc-edi.com/hipaa/. Users without access to the Internet may purchase implementation guides from Washington Publishing Company directly: Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878; telephone 301-590-9337; FAX: 301-869-9460. The data definitions and description of data conditions may also be obtained from this website. The names of the implementation guides are: ASC X12N 837--Health Care Claim: Professional (004010X098) ASC X12N 837--Health Care Claim: Institutional (004010X096) ASC X12N 837--Health Care Claim: Dental (004010X097) 2. Standard: Health Care Payment and Remittance Advice (Subpart L) [Please label any written comments or e-mailed comments about this section with the subject: Payment] a. Background The filing of claims for reimbursement (especially when a large number of patients have more than one insurer), control of those claims, association of payments, denials or rejections received with the patient records, posting of adjudication data to those records, reconciliation of payments sent to financial institutions, and storage and retrieval of patient accounts is a very labor intensive process when conducted manually. The process is further complicated by the diverse requirements and processes for activities such as billing, payment, and notification of the large number of health plans, which requires that health care provider staff stock multiple types of forms, be trained in the variety of requirements, be able to interpret the wide range of coding schemes used by each health plan, and maintain billing and payment manuals for each health plan. We believe that automation can greatly reduce the labor required for these processes, especially if every health plan becomes automated around a standard model so that health care providers are not required to deal with different requirements and software. Automation of the payment and remittance advice process can provide many benefits: health care providers can post claim decisions and payments to accounts without manual intervention, eliminating the need for re-keying data; payments can be automatically reconciled with patient accounts; and resources are freed to address patient care rather than paper and electronic administrative work. The ASC X12N Subcommittee established a workgroup in late 1991 to develop the ASC X12N 835--Health Care Claim Payment/Advice, since there was no existing standard capable of handling the large datasets necessary for health care. i. Candidates for the Standards Prior to development of the ASC X12N 835, there were very few electronic formats available for the health care claim payment and remittance advice function. As researched by the HISB, existing standards that could be considered for national implementation under HIPAA for health care claim payment/remittance advice included: ASC X12N 835--Health Care Claim Payment/Advice, version 3070; ASC X12N 820 Payment Order/Remittance Advice; and the National Standard Format (NSF) for Remittance Version 2.0 ii. Recommended Standard The standard for remittance advice proposed in this proposed rule is the ASC X12N 835 Health Care Claim Payment/Advice. HHS chose this standard primarily because of advice received from industry members. Health care providers and health plans in the ASC X12N Subcommittee rejected the ASC X12N 820 due to its lack of health care specific information for this function. The X12N 820 is used for electronic payment of health insurance premiums by employers. Although the NSF is used by a large number of Medicare providers, we rejected it because it is not an ANSI-accredited standard and it lacks an independent, nongovernmental body for maintenance. The ASC X12N 835 may be used in conjunction with payment systems relying either on electronic funds transfer or the creation of paper checks. It may be sent through the banking system or it may be split with the electronic funds transfer portion directed to a bank, and the data portion sent either directly or through a health care clearinghouse to the individual for whom the funds are intended. If paper checks are used, the entire transaction is sent either directly or through a health care clearinghouse to the individual for whom the funds are intended. In all cases, however, the health care provider may use the electronic data in its own system, gaining efficiency by means of automatic posting of patient accounts. Uniformity is just as important as it is for health care claims, since there would be little gain in efficiency for the health care provider who must adapt to multiple formats and multiple data contents for remittance advice. This transaction is suitable for use only in batch mode. HHS, based on recommendations, has determined that the ASC X12N 835--Health Care Claim Payment/Advice is the best candidate for adoption under HIPAA. A wide range of the health care community participated in its initial design, and the ASC X12N is ANSI- accredited. Whereas the NSF met 5 of the criteria against which we evaluated the standards, the ASC X12N standards met all 10. The NSF does not improve the efficiency and effectiveness of the health care system (#1) because a standard implementation does not exist. The NSF was developed primarily for Medicare and, therefore, does not meet all of the needs of the user community (#2). It is not supported by an ANSI-accredited SDO (#5). There are no testing or implementation procedures in place (#6). Due to its fixed-length structure, it does not incorporate flexibility to adapt easily to change (#10). Data elements for the standard and other information may be found in Addendum 2. [[Page 25290]] b. Requirements In Sec. 142.1202, we would specify the ASC X12N 835 Health Care Claim Payment/Advice (004010X091) as the standard for payment and remittance advice transactions. We would also specify the source of the implementation guide and incorporate it by reference. i. Health plans. In Sec. 142.1204, Requirements: Health plans, we would require health plans to use only the standard specified in Sec. 142.1202 for electronically transmitting payment and remittance advice transactions. ii. Health care clearinghouses. We would require in Sec. 142.1206 that each health care clearinghouse use the standard specified in Sec. 142.1202 for payment and remittance advice transactions. c. Implementation Guide and Source The implementation guide for the ASC X12N 835 (004010X091) is available at no cost from the Washington Publishing Company site at the following Internet address: http://www.wpc-edi.com/hipaa/. Users without access to the Internet may purchase implementation guides from Washington Publishing Company directly: Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD 20878; telephone 301-590-9337; FAX: 301-869-9460. The data definitions and description of data conditions may also be obtained from this website. 3. Standard: Coordination of Benefits (Subpart M) [Please label any written comments or e-mailed comments about this section with the subject: COB] a. Background In an effort to provide better service to their customers, many health plans have made arrangements with each other to send claims electronically in the order of payment precedence, thus saving the customer the process of waiting for another health plan's notice. Each health plan in the chain wishes to see the original claim as well as the details of its adjudication by prior health plans that dealt with it. We believe that there should be a coordination of benefits standard to facilitate the interchange of this information between health plans. Adoption of a standard for electronic transmission of standard data elements among health plans for coordination of benefits and sequential processing of claims would serve these goals expressed by the Congress. Currently, the coordination of benefits for patients covered by multiple health plans is a burdensome chore. The COB transaction differs somewhat from the others because there are two models in existence for conducting it. The first model is provider-to-plan, where the provider submits the claim to the primary insurer, receives payment, and resubmits the claim (with the remittance advice from the primary insurer) to the secondary insurer. The second model is plan-to- plan, where the provider supplies the primary insurer with information needed for the primary insurer to then submit the claim directly to the secondary insurer. The choice of model has been made between the providers and plans. Where the first model is used, the primary insurer essentially has no role in the COB transaction. Put another way, in the first model there is no separate COB transaction. Instead, the COB function is accomplished by a health care provider submitting a series of individual claims. This succession of transactions from health care provider to primary health plan to health care provider to secondary health plan, which often involves the production, reproduction, and mailing of paper forms and multiple claim formats, is time consuming and administratively costly. In some instances, it becomes even more burdensome when the provider shifts responsibility for these administrative tasks to the patient. Health plans have been unwilling to take on the full responsibility for coordinating benefits because of the many different forms and formats used for these transactions. Administrative simplification and electronic standards can simplify and smooth this onerous process. The four products of administrative simplification--(1) The uniform standards for electronic claims submissions; (2) an electronic transmission standard for coordination of benefits; (3) a uniform national standard for the data elements necessary for coordination of benefits among health plans; and (4) uniform health plan and provider identification numbers to efficiently route electronic transactions--would combine to remove the barriers that health plans currently face in carrying out transactions. These products would facilitate the process of the second model, direct health plan to health plan coordination of benefits. Once these standards are implemented, coordination of benefits could be completed without provider or patient intervention and at a lower cost to all parties than under current practice. Primary insurers are not required to participate in COB transactions as described in the second model. If, however, a plan does conduct COB through the second model, then it would be required to use the standard format. Primary insurers may determine whether they wish to participate in COB transactions (i.e., use the second model) based on their normal business practices. Where primary insurers do perform COB (using the second model) they must conduct the transaction electronically as standard transactions. The ASC X12N 837 Health Care Claim (refer to E.1. above) is designed to facilitate coordination of benefits. Each health plan responsible for the claim passes the claim on to the next health plan responsible for the claim. This transaction describes the original claim and how previous health plans adjudicated the claim. In October 1994, the ASC X12N Subcommittee modified the ASC X12N 837 Health Care Claim to fully support coordination of benefits. i. Candidates for the Standard a. Retail drug: NCPDP Telecommunications Standard Format version 3.2. b. Dental claim: ASC X12N 837--Health Care Claim: Dental, version 3070. c. Professional claim: ASC X12N 837--Health Care Claim: Professional, version 3070. d. Institutional claim: ASC X12N 837--Health Care Claim: Institutional, version 3070; and the Uniform Bill (UB-92) version 4.1. ii. Recommended Standard The standards for the coordination of benefits exchange we are proposing are: a. Retail drug: NCPDP Telecommunications Standard Format version 3.2 and the equivalent NCPDP Batch Standard Version 1.0. b. Dental claim: ASC X12N 837--Health Care Claim: Dental (004010X097). c. Professional claim: ASC X12N 837--Health Care Claim: Professional (004010X098). d. Institutional claim: ASC X12N 837--Health Care Claim: Institutional (004010X096). Since all recommended transactions for claims or equivalent encounters and the remittance advice are ASC X12N, with the exception of the NCPDP, it was determined that this transaction was the best candidate for national implementation, as it will increase the synergistic effect of the other ASC X12N standards. All health plans who perform COB, using the second model described above, would have to send and receive these standards for coordination of benefits. The data elements added to [[Page 25291]] explain the prior payments on the claim are shown in the implementation guide, data conditions, and data dictionary. This transaction accommodates coordination of benefits through the tertiary health plan. The NCPDP telecommunication claim version 3.2 is interactive. The three X12 standards are designed for use only in batch mode. HHS chose these standards primarily because of advice received from industry members. Data elements for the various standards and other information may be found in Addendum 3. b. Requirements In Sec. 142.1302, we would specify the following as the standards for coordination of benefits: the NCPDP Telecommunications Standard Format Version 3.2 and equivalent NCPDP Batch Standard Version 1.0; the ASC X12N 837--Health Care Claim: Dental (004010X097); the ASC X12N 837--Health Care Claim: Professional (004010X098); and the ASC X12N 837--Health Care Claim--Institutional (004010X096). We would specify where to find the implementation guide and incorporate it by reference. i. Health plans. In Sec. 142.1304, Requirements: Health plans, we would require health plans who perform COB to use only the standards specified in Sec. 142.1302 for electronic coordination of benefits transactions. ii. Health care clearinghouses. We would require in Sec. 142.1306 that each health care clearinghouse use the standards specified in Sec. 142.1302 for coordination of benefits. c. Implementation Guide and Source The source of implementation guides for the NCPDP telecommunication claim version 3.2 and equivalent Standard Claims Billing Tape Format is the National Council for Prescription Drug Programs, 4201 North 24th Street, Suite 365, Phoenix, AZ, 85016; Telephone 602-957-9105, FAX 602- 955-0749. The web site address is: http://www.ncpdp.org. NCPDP standards are available to the public on a 3\1/2\'' diskette. A set is defined as containing the Telecommunications Standard, Standard Claims Billing Tape Format, Eligibility Verification and Response, and Enrollment. Membership in the NCPDP is not a requirement for obtaining the standards and associated implementation guides. The website contains information and instructions for obtaining these formats. The implementation guides for the three ASC X12N health care claim standard implementations are available at no cost from the Washington Publishing Company site at the following Internet address: http:// www.wpc-edi.com/hipaa/. The data definitions and description of data conditions may also be obtained from this website. Users without access to the Internet may purchase implementation guides from Washington Publishing Company directly. Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878; Telephone 301-590-9337; FAX: 301-869-9460. The names of the implementation guides are: ASC X12N 837--Health Care Claim: Professional (004010X098) ASC X12N 837--Health Care Claim: Institutional (004010X096) ASC X12N 837--Health Care Claim: Dental (004010X097) 4. Standard: Health Claim Status (Subpart N) [Please label any written comments or e-mailed comments about this section with the subject: Status] a. Background Health care providers need the ability to obtain up to date information on the status of claims submitted to health plans for payment, and the health plans need a mechanism to respond to these requests for information. The current processes are complicated by the diverse processes within health plan adjudication systems, which permit nonstandard information to be provided on the status of claims submitted. Most health care providers currently request claims status information manually. This requires health plans to provide information through various procedures that are costly and time consuming for all. With the paper model of claims processing, inquirers who want to know the status of a claim they have submitted to a health plan call the health plan. An operator looks up the status via computer terminal or some other means and explains the status to the caller. The health claim status tells the inquirer whether the claim has been received, whether it has been paid, or whether it is stopped in the system because of edit failures, suspense for medical review or some other reason. Many health plans have devised their own electronic claims status transactions since this is a function that is cheaper, easier, and faster to do electronically. This transaction eases administrative burden for both health plan and health care provider. The ASC X12N Subcommittee established a workgroup (Workgroup 5 Claims Status) to develop a standard implementation with standard data content for all users of the ASC X12N 276/277 Health Care Claim Status Request and Response (004010X093). The ASC X12N 276 is used to transmit request(s) for status of specific health care claim(s). Authorized entities involved with processing the claim need to track the claim's current status through the adjudication process. The purpose of generating an ASC X12N 276 is to obtain the current status of the claim. Status information can be requested at various levels. The first level would be for the entire claim. A second level of inquiry would be at the service line level to obtain status of a specific service within the claim. The ASC X12N 277 Health Care Claim Status Response is used by the health plan to transmit the current status within the adjudication process. This can include status in various locations within the adjudication process, such as pre-adjudication (accepted/rejected claim status), claim pending development, suspended claim(s) information, and finalized claims status. Prior to the development of the ASC X12N 276/277 Health Care Claim Status Request and Response, there were very few proprietary or other electronic formats available for this type of claims status, and none were in widespread use. No existing standard was accepted for national use by the health care community. As researched by the HISB, only one standard could be considered for national implementation under HIPAA for health care claim status request and response: the ASC X12N 276/277 Health Care Claim Status Request and Response, version 3070. i. Candidates for the Standard The candidate standard for health care claim status is: ASC X12N 276/277 Health Care Claim Status Request and Response, version 3070. ii. Standard Selected We propose to adopt ASC X12N 276/277 Health Care Claim Status Request and Response (004010X093), as the national standard for uniform use by health plans and health care providers for health care claims status. HHS chose this standard primarily because of advice received from industry members. It met all 10 of the criteria used for assessing standards. Data elements for the standard, and other information, may be found in Addendum 4. [[Page 25292]] b. Requirements In Sec. 142.1402, we would specify the following as the standard for health care claims status: ASC X12N 276/277 Health Care Claim Status Request and Response (004010X093). We would specify where to find the implementation guide and incorporate it by reference. i. Health plans. In Sec. 142.1404, Requirements: Health plans, we would require health plans to use only the standards specified in Sec. 142.1402 for electronic health care claims status transactions. ii. Health care clearinghouses. We would require in Sec. 142.1406 that each health care clearinghouse use the standards specified in Sec. 142.1402 for health care claims status. iii. Health care providers. In Sec. 142.1408, Requirements: Health care providers, we would require each health care provider that transmits health care claim status requests electronically to use standards specified in Sec. 142.1402 for those transactions. c. Implementation Guide and Source The implementation guide for the standard is available at no cost from the Washington Publishing Company site at the following Internet address: http://www.wpc-edi.com/hipaa/. The data definitions and description of data conditions may also be obtained from this website. Users without access to the Internet may purchase implementation guides from Washington Publishing Company directly: Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878; telephone 301-590-9337; FAX: 301-869-9460. 5. Standard: Enrollment and Disenrollment in a Health Plan (Subpart O) [Please label any written comments or e-mailed comments about this section with the subject: Enrollment] a. Background Currently, employers and other sponsors conduct transactions with health plans to enroll and disenroll subscribers and other individuals in a health insurance plan. The transactions are rarely done electronically. However, the ASC X12 834, Benefit Enrollment and Maintenance has been in widespread use within the insurance industry at large since February 1992 when ANSI approved it as a draft standard for trial use. Variants of this transaction standard have been widely used by employers to advise insurance companies of enrollment and maintenance information on their employees for insurance products other than health. It has rarely been used within the health care industry. i. Candidates for the Standard. According to the inventory conducted for HHS by the HISB, only two standards developed and maintained by a standards developing organization for the enrollment transaction exist. The first is the ANSI ASC X12 834. The second is the Member Enrollment Standard developed by the NCPDP. ii. Recommended Standard. The ANSI ASC X12 834--Benefit Enrollment and Maintenance is the standard proposed for electronic exchange of individual, subscriber, and dependent enrollment and maintenance information between sponsors and health plans, either directly or through a vendor, such as a health care clearinghouse. In some instances, this transaction may be used also to exchange enrollment and maintenance information between sponsors and health care providers or between health plans and health care providers. The NCPDP standard, which was developed to enhance the enrollment verification process for pharmaceutical claims, rather than for transmitting information between health plan and sponsor, is not being proposed for adoption in this rule. The NCPDP standard pertains to these specific uses and is therefore not suitable in its current form for the more general uses needed for the enrollment transaction. With the implementation of the ASC X12 834 for health care, sponsors would be able to transmit information on enrollment and maintenance using a single, electronic format; health plans would be required to accept only the standard transaction; neither sponsors nor health plans would have to continue to maintain and use multiple proprietary formats or resort to paper. Adoption of this standard would benefit sponsors, especially, by providing them the ability to convert to electronic transmission formats where paper is still being used today. Many of these sponsors already use X12 standards in their core business activities (for example, purchasing) unrelated to the provision of health care benefits to employees. The utility of this particular standard for health care transactions would be synergistic when considered in combination with the other standards in this proposed rule (for example, ASC X12 820) and other rules (PAYERID, national provider identifier) promulgated under HIPAA. In addition to being the only relevant standard for the enrollment and maintenance process designed for use by sponsors, the ANSI ASC X12 834 met all of the 10 criteria deemed to be applicable in evaluating this potential standard. 1. It will improve the efficiency of enrollment transactions by prescribing a single, standard format. 2. It was designed to meet the needs of health care providers, health plans, and health care clearinghouses by virtue of its development within the ASC X12 consensus process, in which representatives of health care providers, health plans, and health care clearinghouses participate. 3. It is consistent with the other X12 standards detailed in this proposed rule. 4. Its development costs are relatively low, given the ASC X12 development process; its implementation costs would be relatively low as it can be implemented along with a suite of X12 transaction sets, often with a single translator. 5. It was developed and will be maintained by the ANSI-accredited standards setting organization ASC X12. 6. It is ready for implementation, with the official implementation guide to which we refer in Addendum G to this proposed rule. 7. It was designed to be technology neutral by ASC X12. 8. Precise and unambiguous definitions for each data element in the transaction set are documented in the implementation guides. 9. The transaction is designed to keep data collection requirements as low as is feasible. 10. All X12 transactions, including the X12 834, are designed to make it easy to accommodate constantly changing business requirements through flexible data architecture and coding systems. iii. Uses of the ANSI ASC X12 834. Transaction data elements in the implementation guide for the ASC X12 834 are defined as either required or conditional, where the conditions are clearly stated. This transaction would be used to enroll and disenroll not only the subscriber, but also any covered dependents. In some instances, this would be an enhancement to enrollment information maintained by sponsors or health plans, compared with the common practice today of maintaining detailed records on the subscriber alone. In an increasingly value-conscious health care environment, detailed information on subscribers and covered dependents is necessary for the effective management of their health care utilization. Administrative and financial health care transactions such as the ASC X12 834 enrollment transaction may have [[Page 25293]] other, secondary uses that may be important to consider as well. For example, secondary uses of health care claims data are common and include analyses of health care utilization, quality, and cost. The ASC X12 834 enrollment transaction has been discussed (for example, by the NCVHS) as a means to collect demographic information on individuals for use by public health, State data organizations, and researchers. Typically, demographic data elements would be used in combination with information obtained from other health care transactions, such as health care claims and equivalent encounter transactions, and from other sources. Proponents of this approach and these uses have expressed their beliefs that the enrollment transaction includes patient demographic data elements and that this would provide more reliable data on patient demographics than are available currently from health care claims and encounter databases. Proponents also believe that the availability of demographic information is in jeopardy because the X12 837 health care claim transaction proposed elsewhere in this rule includes minimal patient demographic data elements. The use of this standard would be a change from current practice in many States where the health care claim is the vehicle for collecting such information. Some proponents also have indicated a desire to expand the number of demographic data elements contained in the ASC X12 834 enrollment transaction to serve these secondary uses. Opponents of this approach argue that the ASC X12 834 enrollment transaction is not a suitable vehicle for collecting demographic information for these secondary purposes. They also assert that such information would never be available on the uninsured and, since there is no obligation on the part of sponsors to adopt the electronic transactions, would be only intermittently available on the insured. They also state that, although some demographic elements are already contained in the ASC X12 834 enrollment transaction, no business need has been identified that would support the addition of other such data elements. Finally, the opponents argue that secondary uses, while legitimate, should not be allowed to subvert the primary purposes of these transactions nor the goal of administrative simplification. We welcome comments on the practical utility of the ASC X12 834 enrollment transaction as a vehicle for collecting demographic information on individuals and its value as an adjunct to claims and encounter data in this regard. The data elements for this transaction, and other information, may be found in Addendum 5. b. Requirement In Sec. 142.1502, we would specify the ASC X12 834 Benefit Enrollment and Maintenance (004010X095) as the standard for enrollment and disenrollment transactions. We would also specify the source of the implementation guide and incorporate it by reference. i. Health plans. In Sec. 142.1504, Requirements: Health plans, we would require health plans to use only the standard specified in Sec. 142.1502 for electronic enrollment and disenrollment transactions. ii. Health care clearinghouses. We would require in Sec. 142.1506 that each health care clearinghouse use the standard specified in Sec. 142.1502 for enrollment and disenrollment transactions. iii. Sponsors. There would be no requirement for sponsors to use the standard: they are not one of the entities subject to the requirements of HIPAA. However, to the extent a sponsor uses an electronic standard, it would benefit that sponsor to use the standard we adopt for the reasons discussed earlier. In addition, HIPAA contains no provisions that would prohibit a health plan requiring sponsors with which its conducts transactions electronically to use the adopted standard. c. Implementation Guide and Source The implementation guide for the ASC X12N 834 (004010X095) is available at no cost from the Washington Publishing Company site on the World Wide Web at the following address: http://www.wpc-edi.com/hipaa/. The data definitions and description of data conditions may also be obtained from this website. Users without access to the Internet may purchase implementation guides from Washington Publishing Company directly. Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878; telephone 301-590-9337; FAX: 301-869-9460. 6. Standard: Eligibility for a Health Plan (Subpart P) [Please label any written comments or e-mailed comments about this section with the subject: Eligibility] a. Background Often, health care providers may need to verify not only that a patient has health insurance coverage but also what specific benefits are included in that coverage. Having such information helps the health care provider to collect correct patient deductibles, co-insurance amounts, and co-payments and to provide an accurate bill for the patient and all pertinent health plans, including secondary payers. In addition, simple economics dictates that the out-of-pocket cost to the patient may affect treatment choices. The best case is when there are two equally effective treatment options and coverage is only available for one. More often, the question may be whether a particular treatment is covered or not. Here is an example: Jane Doe has cancer and a bone marrow transplant is the treatment of last resort. Since insurance coverage does not extend to ``experimental therapies,'' the question becomes: Does Jane's insurance cover a bone marrow transplant for her diagnosis? If she has leukemia, the treatment may be covered; if she has cervical cancer, it may not be. Whether Jane could afford to pay out-of-pocket for such a treatment could affect her treatment choice. The value of eligibility information is enhanced if it can be acquired quickly. Traditional methods of communication (that is, by phone or mail) are highly inefficient. Patients and health plans find it disturbing when the deductible and co-pays are not correctly applied. When insurance inquiries of this sort are transmitted electronically, health care providers can receive the information from the health plan almost immediately. However, in current practice, each health plan may require that the health care provider's request be in a preferred format, which often does not match the format required by any other health plan. This means that the health care provider must maintain the hardware and software capability to send multiple inquiry formats and receive multiple response formats. Because of this situation, adoption of electronic methods for inquiries has been inhibited, and reliance on paper forms or the telephone for such inquiries has continued. i. Candidates for the Standard The HISB developed an inventory of health care information standards to be considered by the Secretary of HHS in the adoption of standards. The ANSI ASC X12N 270--Health Care Eligibility Benefit Inquiry and companion 271--Health Care Eligibility Benefit Response, the ASC X12N Interactive Health Care Eligibility/Benefit Inquiry (IHCEBI) and its companion the Interactive Health Care Eligibility/ Benefit Response [[Page 25294]] (IHCEBR), the NCPDP Telecommunications Standard Format, and the NCPDP Telecommunication Claim Standard for Pharmaceutical Professional Services are the standards available for the electronic exchange of patient eligibility and coverage information. ii. Recommended Standard We propose to adopt the ANSI ASC X12N 270--Health Care Eligibility Benefit Inquiry and the companion ASC X12N 271--Health Care Eligibility Benefit Response as the standard for the eligibility for a health plan transaction. When evaluated against the criteria (discussed earlier) for choosing a national standard, the ASC X12 Transaction Sets 270/271 met the criteria more often than did the ASC X12 interactive or the NCPDP transactions. The ASC X12N 270/271 transaction set is supported by an accredited standards setting organization ASC X12 (criteria #5). By comparison with the alternatives, the ASC X12N 270/271 would have relatively low additional development and implementation costs and would be consistent with other standards in this proposed rule (criteria #4 and #3). The NCPDP standards, because they are specific to pharmacy transactions, were rejected because they would not meet the needs of the rest of the health care system (criteria #2), whereas the ASC X12N 270/271 would. The X12N subcommittee and its Workgroup 1, which is responsible for the eligibility transaction, recommended in June 1997 that the ASC X12N 270/271 be adopted as the HIPAA standard (criteria #5). There are specific, technical reasons against adoption of the IHCEBI/IHCEBR at this time. The IHCEBI/IHCEBR is based on UNEDIFACT, not ASC X12N, syntax. Because of concurrent changes in UNEDIFACT design rules, the IHCEBI/IHCEBR is not a complete or consistent standard. It has not been classified by UNEDIFACT as ready to implement. In X12N, the current version of IHCEBI/IHCEBR is 3070, and we believe that current use is centered on a prior version (3051), which is not millennium compliant. The IHCEBI/IHCEBR transaction is not ready to be moved into version 4 (4010), as are the other transactions being recommended in this proposed rule. We also believe that current use is quite limited, and not consistent across users; in effect, current uses of this transaction have been implemented in proprietary format(s). For all these reasons, the ICHEBI/ICHEBR is neither technically ready nor stable and cannot be recommended as a standard at this time. Thus, the IHCEBI/IHCEBR would require higher additional development and implementation costs (criteria #4), and they would not be consistent or uniform with the other standards selected (criteria #3). If an interactive eligibility transaction standard were ratified by an accredited standards setting organization sometime in the future, then it could be considered for adoption as a HIPAA standard. However, at this time, we expect that any future standard for an interactive eligibility transaction is likely to differ substantially from the current IHCEBI/IHCEBR and the time to readiness could be substantial as well (criteria #6). The goal of administrative simplification, as expressed in the law, is to improve the efficiency and effectiveness of the health care system (criteria #1). Whereas it might seem that the interactive message would yield greater efficiencies in terms of time saved, similar efficiencies are available with the ASC X12N 270/271. In fact, the ASC X12N 270 can be used to submit a single eligibility inquiry electronically for a very quick turnaround 271 response. Response times, measured in seconds, would compare favorably to a true ``interactive'' transaction and would be a substantial improvement over telephone inquiries or paper methods of eligibility determination. Transactions concerning eligibility for a health plan would be used only to verify the patient's eligibility and benefits; they would not provide a history of benefit use. The electronic exchange using these standards would occur usually between health care providers and health plans, but the standard would support electronic inquiry and response among other entities. In addition to uses by various health care providers (for example, hospitals, laboratories, and physicians), the ASC X12N 270/271 can be used by an insurance company, a health maintenance organization, a preferred provider organization, a health care purchaser, a professional review organization, a third-party administrator, vendors (for example, billing services), service bureaus (such as value-added networks), and government agencies (Medicare, Medicaid, and CHAMPUS). The eligibility transaction is designed to be used for simple status requests as well as more complex requests that may be related to specific clinical procedures. General requests might include queries for: all benefits and coverage conditions, eligibility status (whether the patient is active in the health plan), maximum benefits (policy limits), exclusions, in-plan/out-of-plan benefits, coordination of benefits information, deductibles, and copayments. Specific requests might include procedure coverage dates; procedure coverage maximum; amounts for deductible, co-insurance, co-payment, or patient responsibility; coverage limitations; and noncovered amounts. Another part of the ASC X12N 271 is designed to handle requests for eligibility ``rosters,'' which are essentially lists of entities-- subscribers and dependents, health care providers, employer groups, health plans--and their relationships to each other. For example, this transaction might be used by a health plan to submit a roster of patients to a health care provider to designate a primary care physician or to alert a hospital about forthcoming admissions. We are not recommending this use of the ASC X12N 270/271 at this time because the roster implementation guide is not millennium compliant and the standards development process for the implementation guide is not completed. After the standards development process for the roster implementation guide is completed, it may be considered for adoption as a national standard. The data elements for this transaction, and other information, may be found in Addendum 6. b. Requirements i. Health plans. In Sec. 142.1604, Requirements: Health plans, we would require health plans to use only the standard specified in Sec. 142.1602 for electronic eligibility transactions. ii. Health care clearinghouses. We would require in Sec. 142.1606 that each health care clearinghouse use the standard specified in Sec. 142.1602 for eligibility transactions. iii. Health care providers. In Sec. 142.1608, Requirements: Health care providers, we would require each health care provider that transmits any health plan eligibility transactions electronically to use the standard specified in Sec. 142.1602 for those transactions. c. Implementation Guide and Source The implementation guide is available for the ASC X12N 270/271 (004010X092) at no cost from the Washington Publishing Company site on the World Wide Web at the following address: http://www.wpc-edi.com/ hipaa/. The data definitions and [[Page 25295]] description of data conditions may also be obtained from this website. Users without access to the Internet may purchase implementation guides from Washington Publishing Company directly. Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878; telephone 301-590-9337; FAX: 301-869-9460. 7. Standard: Health Plan Premium Payment (Subpart Q) [Please label any written comments or e-mailed comments about this section with the subject: Premium] a. Background Electronic payment methods have become commonplace for consumers who pay their monthly mortgage, power, or telephone bills electronically. Yet, electronic payment of health insurance premiums by employers is not common at all. Adoption of a standard for electronic payment of health plan premiums would benefit employers and other sponsors, especially, by providing the opportunity to convert to a single electronic transmission format where paper forms and premium payment formats may vary from health plan to health plan. Many of these sponsors already use X12 standards in their core business activities (for example, purchasing) unrelated to the provision of health care benefits to employees. Federal and State governments when acting as employers and other government agencies that transmit premium payments to outside organizations (for example, State Medicaid agencies that pay premiums to outside organizations such as managed care organizations) would also benefit from these electronic transactions. i. Candidates for Standard. According to the inventory conducted for HHS by the HISB, only one standard developed and maintained by a standards developing organization for health plan premium payment transaction exists. It is the ASC X12 820--Payment Order/Remittance Advice. ii. Recommended Standard. The standard we are proposing to adopt for health plan premium payment transactions is the ASC X12 820--Payment Order/Remittance Advice. If we adopt the ASC X12 820, health plans would be able to transmit premium payments either as a summary payment or with individual payment detail, or as payment amount and adjustment amount, using a single, electronic format. Health plans would be required to accept the standard transaction as the electronic transmission; neither sponsors nor health plans would have to continue to maintain and use multiple proprietary premium payment formats or resort to paper. Although the premium order/remittance advice (ASC X12 820), used for health plan premium payments, can be paired with the ASC X12N 811-- Consolidated Service Invoice/Statement, which is used for health plan premium billing, our proposal and the focus of the statute is on a standard only for health plan premium payments. In addition to being the only relevant standard designed for use by sponsors, the ANSI ASC X12 820 met 9 of the 10 criteria deemed to be applicable in evaluating this potential standard. It would improve the efficiency of premium payment transactions by prescribing a single, standard format. It was designed to meet the needs of health care providers, health plans, and health care clearinghouses by virtue of its development within the ASC X12 consensus process, in which representatives of health care providers, health plans, and health care clearinghouses participate. It is consistent with the other ASC X12 standards detailed in this proposed rule. Its development costs are relatively low, given the X12 development process; its implementation costs would be relatively low as it can be implemented along with a suite of X12 transaction sets, often with a single translator. It was developed and will be maintained by the ANSI-accredited standards setting organization X12. It is ready for implementation, with the official implementation guide to which we refer in Addendum 7 to this proposed rule. It was designed to be technology neutral by X12. Precise and unambiguous definitions for each data element in the transaction set are documented in the implementation guides. The ANSI ASC X12 820--Payment Order/Remittance Advice is currently used in applications other than health care. However, it is currently not in widespread use in the health insurance industry because most health plan premium payments are not done electronically. However, some large organizations are using the ASC X12 820 to meet other business requirements, such as automated purchasing. The ASC X12 820 is used in the health care industry for premium payment information exchanged between the sponsor and the health plan; it should not be confused with the ASC X12 834, which includes additional nonpremium payment information. The ASC X12 820 is not intended to be used to carry enrollment or other eligibility information. The data elements for this transaction, and other information, may be found in Addendum 7. b. Requirements In Sec. 142.1702, we would specify the following as the standard for health plan premium payment: ASC X12 820--Payment Order/Remittance Advice (004010X061). We would specify where to find the implementation guide and incorporate it by reference. i. Health plans. In Sec. 142.1704, Requirements: Health plans, we would require health plans to accept only the standard specified in Sec. 142.1702 for electronic health plan premium payments. ii. Health care clearinghouses. We would require in Sec. 142.1706 that each health care clearinghouse use the standards specified in Sec. 142.1702 for health plan premium payment transactions. iii. Sponsors. There would be no requirement for sponsors to use the standard: they are not one of the entities subject to the requirements of HIPAA. However, to the extent a sponsor uses an electronic standard, it would benefit that sponsor to use the standard we adopt for the reasons discussed earlier. In addition, HIPAA contains no provisions that would prohibit a health plan requiring sponsors with which its conducts transactions electronically to use the adopted standard. c. Implementation Guide and Source The implementation guide for this transaction is the ASC X12N 820-- Payroll Deducted and Other Group Premium Payment for Insurance Products (004010X061). The implementation guide is available at no cost from the Washington Publishing Company site on the World Wide Web at the following address: http://www.wpc-edi.com/hipaa/. Users without access to the Internet may purchase implementation guides from Washington Publishing Company directly. Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878; telephone 301-590-9337; FAX: 301-869-9460. 8. Standard: Referral Certification and Authorization (Subpart R) [Please label any written comments or e-mailed comments about this section with the subject: Referral] a. Background Increasingly, the delivery of health care is focused on achieving greater [[Page 25296]] value from each health care dollar, and rigorous monitoring of health care utilization has become a common method adopted by health plans for achieving their value goals. Traditional methods of communication between health care providers and health plans or their designates, which rely on a combination of paper forms and telephone calls, are neither efficient nor cost effective and may impede the delivery of care. The burden and inefficiencies of these communications could be reduced by the adoption of standardized and electronic methods for making the requests and receiving responses. i. Candidates for Standard. According to the inventory of standards produced by the HISB for HHS, there is only one standard available for referral certification and authority. It is the ASC X12N 278, Health Care Services Review Information. ii. Recommended Standard. The ANSI ASC X12N 278--Health Care Services Review Information is the standard proposed for electronic exchange of requests and responses between health care providers and review organizations. These exchanges of information can be initiated by either the health care provider or the health plan. The health care provider requests from a designated review entity authorization or certification for a patient to receive a particular health care service. In turn, the review entity receives and responds to the health care provider's request. In addition to direct electronic inquiry and response, the ASC X12N 278 can be used in connection with point of service terminals. Many different types of organizations may act as a review entity in such an exchange. These include health plans, insurance companies, health maintenance organizations, preferred provider organizations, health care purchasers, managed care organizations providing coverage to Medicare and Medicaid beneficiaries, professional review organizations, other health care providers, and benefit management organizations, to name a few. These requests and responses may pertain to many different health care events, including reviews for: treatment authorization, specialty referrals, pre-admission certifications, certifications for health care services (such as home health and ambulance), extension of certifications, and certification appeals. As with all the other ASC X12 transactions being proposed in this rule, the ASC X12N 278 was developed with widespread input from health care industry representatives in a consensus process taking into account business needs. Further, the standard is fully compatible with the other ASC X12 standards and can be translated to and from native application systems using off-the-shelf software (commonly referred to as ``translators'') that is readily available and used by all industries utilizing ASC X12 standards. The data elements for this transaction, and other information, may be found in Addendum 8. b. Requirements In Sec. 142.1802, we would specify the following as the standard for referral certifications and authorizations: ASC X12N 278--Request for Review and Response (004010X094). We would specify where to find the implementation guide and incorporate it by reference. i. Health plans. In Sec. 142.1804, Requirements: Health plans, we would require health plans to accept and transmit only the standard specified in Sec. 142.1802 for electronic referral certifications and authorizations. ii. Health care clearinghouses. We would require in Sec. 142.1806 that each health care clearinghouse use the standard specified in Sec. 142.1802 for referral certifications and authorizations. iii. Health care providers. In Sec. 142.1808, Requirements: Health care providers, we would require each health care provider that transmits referral certifications and authorizations electronically to use the standard specified in Sec. 142.1802 for the transactions. c. Implementation Guide and Source The implementation guide for the ASC X12N 278 (004010X094) is available at no cost from the Washington Publishing Company site on the World Wide Web at the following address: http://www.wpc-edi.com/hipaa/. Users without access to the Internet may purchase implementation guides from Washington Publishing Company directly. Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878; telephone 301-590-9337; FAX: 301-869-9460. 9. Standard: First Report of Injury [Please label any written comments or e-mailed comments about this section with the subject: Injury] Background ``First report of injury'' is not a general term or transaction in the health care insurance industry. Upon investigation, we found that the property and casualty insurance industry, among whose lines of business is workers compensation insurance, had developed a standard transaction entitled ``Report of Injury, Illness or Incident'' (ASC X12N 148). This transaction set was developed within ASC X12N to encompass more than 30 functions and exchanges that occur among the numerous parties to a workers compensation claim. The transaction can be used by an employer, first, to report an employee injury or illness to the State government agency that administers workers compensation and, second, to report to the employer's workers compensation insurance carrier so that a claim can be established to cover the employee's losses (income, health care, disability). When the employer is the Federal government, the transaction is used to report to the Department of Labor's Office of Workers Compensation Programs. In a few States, the transaction can also be used by health care providers to report an employee's work-related injury to employers and/or the employer's workers compensation insurance carrier. The transaction can be used by State agencies responsible for monitoring the disposition of a workers compensation claim. Other uses include summary reporting of employee injuries and illness to State workers compensation boards, commissions, or agencies; the Federal Bureau of Labor Statistics; the Federal Occupational Safety and Health Administration; and the Federal Environmental Protection Agency. The current, approved version of this transaction is 3070, which is not millennium compliant. There is no approved implementation guide for version 4010, which would be millennium compliant. The ASC X12N workgroup is developing a version 4010 or higher implementation guide and data dictionary. The workgroup hopes to secure ASC X12N approval for its revised standard and implementation guide in the spring of 1998. Current workgroup planning is for a single implementation guide that covers all of the business uses to which we refer above. Recommendation: We do not recommend that the ASC X12N 148--Report of Injury, Illness or Incident be adopted at this time, for the following reasons: a. There is no millennium-compliant version of an implementation guide for this transaction. b. There is no complete data dictionary for this transaction. [[Page 25297]] c. The implementation guide under development covers more business requirements and functions than the ``first report of injury'' specified in the statute. d. Consultation with the transaction's extensive user community is necessary to establish a consensus regarding the scope of the transaction set, and this is not possible in the time available to the Secretary for promulgating a final regulation. e. An alternative to the ASC X12N 148 has been brought to our attention and must be evaluated. The alternative EDI format is that developed and maintained by the International Association of Industrial Accident Boards and Commissions (IAIABC). The IAIABC EDI format was not identified in the ANSI HISB inventory of standards developed for HHS because the IAIABC is not an ANSI-accredited standards setting organization. Under the law, a standard adopted under the administrative simplification provisions of HIPAA is required to be ``a standard that has been developed, adopted, or modified by a standard setting organization'' (section 1172(c) of the Act) (if a standard exists). The Secretary may adopt a different standard if it would substantially reduce administrative costs to health care providers and health plans when compared to the alternatives (section 1172(c)(2)(A)). Accordingly, the IAIABC EDI format must be evaluated before a national standard for first report of injury transactions is adopted because it is reported to be widely used. The IAIABC will be requested to submit documentation so that its first report of injury format can be evaluated according to the ten criteria applied to all other standards. In assessing the utility of this alternative standard, we will follow the Guiding Principles for selecting a standard to evaluate the IAIABC EDI format against that developed and maintained by ANSI ASC X12N. The following questions about the IAIABC standard will be of particular importance: a. To what extent is this format widely accepted and used by organizations performing these transactions? b. Is this format millennium-compliant? c. Does this standard meet the requirements set forth in the Administrative Simplification provisions of HIPAA for improving the efficiency and effectiveness of the health care system? d. Is this a format developed, maintained, or modified by a standard setting organization as specified in Section 1171 (8) or does it meet the exceptions specified in Section 1172 (c)(2) of the Act? We do not recommend that the IAIABC format be adopted at this time. We have asked that the IAIABC provide documentation for their format. In view of these facts, HHS will take the following actions with regard to adopting a standard for ``first report of injury'': a. Continue to monitor the progress of the ASC X12N subcommittee toward development of a final, complete, millennium-compliant standard, implementation guide, and data dictionary for this transaction. b. Request that ASC X12N review the ASC X12N 148 to determine whether all of its broad functionality should be included in a standard to be adopted under HIPAA authority or whether the scope of the transaction should be limited by dividing the functions into separate implementation guides. c. Review and evaluate documentation from the IAIABC on its format so that it can be evaluated according to the ten criteria used to evaluate candidate standards and in relation to the ASC X12N 148 as described above. d. After the ASC X12N subcommittee has completed its standard setting role and approved a 4010 version or higher implementation guide and data definitions for the ASC X12N 148 and after analysis of the IAIABC alternative standard, issue a subsequent proposed rule promulgating a standard for ``first report of injury''. III. Implementation of the Transaction Standards and Code Sets A. Compliance Testing We have identified three levels of testing that must be addressed in connection with the adoption and implementation of the standards we are proposing and their required code sets: Level 1--Developmental Testing--This is the testing done by the standards setting organization during the development process. The conditions for, and results of, this testing are made public by the relevant standards bodies, and are available at the following Internet web site: http://www.disa.org The information on the web site is provided at the discretion of the standards setting organization and could, among other things, refer to pilot, limited, or large-scale production if appropriate. Information regarding code set testing will also be posted to a website. This website will be advertised on the HCFA home page. Level 2--Validation Testing--This is testing of sample transactions to see whether they are being written correctly. We expect that private industry will provide commercial testing at this level. This level of testing would give the participants a sense of whether they are meeting technical specifications of structure and syntax for a transaction, but it may not necessarily test for valid data. This type of testing would inform individuals that the transaction probably meets the specifications. These edits would be less rigorous than those that might be applied by a health plan before payment (in the case of a claim) or by a health care provider prior to posting (in the case of a health care claim payment/advice). The test conditions and results from this level are generally shared only between the parties involved. Level 3--Production Testing--This tests a transaction from a sender through the receiver's system. The test information is exposed to all of the edits, lookups, and checks that the transaction would undergo in a production situation. The test conditions and results from this level are generally shared only between the parties involved. Pilot production--Billions of dollars change hands each year as a result of health care claims processing alone. For that reason, we believe the industry should sponsor pilot production projects to test transaction standards that are not currently in full production prior to the effective date for adoption. Pilot production tests are not necessary for the NCPDP retail pharmacy claim since it is already in widespread use. On the other hand, some of the ASC X12N implementations have not yet been placed in general production. We believe that pilot production results should be posted on a website and show information of general interest to potential users. The information given is at the discretion of the entities conducting the pilot and might contain information regarding the number of claims processed, the identity of the entities participating in the pilot, and the name, telephone number or e-mail address of an individual willing to answer questions from the public. It would be useful to all participants if pilot production projects and the results were posted to a web site for all transactions. For the claim and equivalent encounter transactions, we believe that posting pilot production projects and results to a web site must be mandatory. [[Page 25298]] B. Enforcement Failure to comply with standards may well result in monetary penalties. The Secretary is required by statute to impose penalties of not more than $100 per violation on any person who fails to comply with a standard, except that the total amount imposed on any one person in each calendar year may not exceed $25,000 for violations of one requirement. We are not proposing any enforcement procedures at this time, but we will do so in a future Federal Regulations document, once the industry has some experience with using the standards. We are at this time, however, soliciting input on appropriate mechanisms to permit independent assessment of compliance. We are particularly interested in input from those engaging in health care EDI as well as from independent certification and auditing organizations addressing issues of documentary evidence of steps taken for compliance; need for/desirability of independent verification, validation, and testing of systems changes; and certifications required for off-the-shelf products used to meet the requirements of this regulation. IV. New and Revised Standards A. New Standards To encourage innovation and promote development, we intend to develop a process that would allow an organization to request a replacement to any adopted standard or standards. An organization could request a replacement to an adopted standard by requesting a waiver from the Secretary of HHS to test a new standard. The organization, at a minimum, must demonstrate that the new standard clearly offers an improvement over the adopted standard. If the organization presents sufficient documentation that supports testing of a new standard, we want to be able to grant the organization a temporary waiver to test it while remaining in compliance with the law. We do not intend to establish a process that would allow organizations to request waivers as a tool to avoid using any adopted standard. We would welcome comments on the following: (1) How we should establish this process, (2) the length of time a proposed standard should be tested before we decide whether to adopt it, and (3) other issues and recommendations we should consider in developing this process. Following is one possible process: Any organization that wishes to replace an adopted standard must submit its waiver request to an HHS evaluation committee (not currently established or defined). The organization must do the following for each standard it wishes to replace: + Provide a detailed explanation, no more than 10 pages in length, of how the replacement would be a clear improvement over the current standard in terms of the principles listed in section I.D., Process for developing national standards, of this preamble. + Provide specifications and technical capabilities on the new standard, including any additional system requirements. + Provide an explanation, no more than 5 pages in length, of how the organization intends to test the standard, including the number and types of health care plans and health care providers expected to be involved in the test, geographical areas, and beginning and end dates of the test. The committee's evaluation would, at a minimum, be based on the following: + A cost-benefit analysis. + An assessment of whether the proposed replacement demonstrates a clear improvement to an existing standard. + The extent and length of time of the waiver. The evaluation committee would inform the organization requesting the waiver within 30 working days of the committee's decision on the waiver request. If the committee decides to grant a waiver, the notification may include the following: + Committee comments such as the following: --The length of time for which the waiver applies if it differs from the waiver request. --The sites the committee believes are appropriate for testing if they differ from the waiver request. --Any pertinent information regarding the conditions of an approved waiver. Any organization that receives a waiver would be required to submit a report containing the results of the study, no later than 3 months after the study is completed. The committee would evaluate the report and determine whether the proposed new standard meets the 10 guiding principles and whether the advantages of a new standard would significantly outweigh the disadvantages of implementing it and make a recommendation to the Secretary. B. Revised Standards We recognize the very significant contributions that the traditional content committees (the NUCC, the NUBC, the ADA, and the National Council for Prescription Drug Programs) have made to health care transaction content over the years and, in particular, the work they contributed to the content of the standards proposed in this proposed rule. Other Federal and private entities (the National Center for Health Statistics, the Health Care Financing Administration, the AMA, and the ADA) have developed and maintained the medical data code sets proposed as standards in this proposed rule. In a letter dated June 10, 1997, WEDI recommended that the NUBC, NUCC and ADA be recognized as the appropriate organizations to specify data content. We expect that these current committees would continue to play an important role in maintenance of data content for standard health care transactions. The organizations assigned responsibility for maintenance of data content for standard health care transactions will work with X12N data maintenance committees, ensuring that implementation documentation is updated in a consistent and timely fashion. We intend that the private sector, with public sector involvement, continue to have responsibility for defining the data element content of the administrative transactions. Both Federal agencies and private organizations will continue to be responsible for maintaining medical data code sets. The current data content committees are focused on transactions that involve health care providers and health plans. There may be some organizations that represent employers or other sponsors and health plans and are interested in assuming the burden of maintenance of the data content standards for the X12 820 and 834. We propose to designate content committees in the final rule and to specify the ongoing activities of these content committees pertaining to the data maintenance of all X12N standards identified in this rule, as well as attachments. All approved changes, not including medical code sets, would need to fit into the appropriate ASC X12N implementation guide(s) and receive ASC X12N approval, with the exception of the NCPDP standard. The NCPDP would continue to operate as currently for data content. It is important that data content revisions be made timely in this new standards environment. The Secretary of HHS may not revise any standard more [[Page 25299]] frequently than once a year and must permit no fewer than 180 days for implementation for all participants after adopting a revised standard. New values could be added to the code sets for certain data elements in transaction standards more frequently than once a year. For example, alpha-numeric HCPCS and NDC, two of the proposed standard code sets for medical data, now have mechanisms for ongoing addition to new codes as needed to reflect new health services and new drugs. Such ongoing update mechanisms would continue to be needed in the year 2000 and beyond. The private sector organizations charged with data element content maintenance would have to ensure that the revised standard contains the most recent data maintenance items that have been brought to them and that those new data requirements are adequately documented and communicated to the public. We believe that, at minimum, the data maintenance documentation needs to include the data name, data definition, the status of the data name (that is, required or conditional), written conditions regarding the circumstances under which the data would have to be supplied, a rationale for the new or revised data item, and its placement in an implementation guide. We believe that any data request approved by a body three or more months prior to the adoption of a new or revised standard would have to be included in that new standard implementation, assuming that no major format restructuring would have to be done. (A new data element, code, or segment would not constitute major restructuring.) We believe that any body with responsibility for maintaining a standard under this proposed rule must allow public access to their decision making processes. We plan to engage standards setting organizations and other organizations responsible for maintenance of data element content and standard code sets to establish a process that will enable timely standards development/updates with appropriate industry input. One approach may be as follows: Each of the data maintenance bodies has biannual meetings with the public welcome to attend and participate without payment of fees. + These public meetings are announced to the broadest possible audience, at minimum by means of a website. The announcements of the meetings may also be available via widely read publications, such as the Commerce Business Daily or the Federal Register. + Annual public meeting schedules are posted on a website not later than 90 days after the effective date of the final rule, and annually on that date thereafter. + The data maintenance body establishes a central contact (name and post office and e-mail addresses) to which the public could submit correspondence (such as agenda items or data requests). + During these two open meetings, the public has the opportunity to voice concerns and suggest changes. + Each data maintenance body drafts procedures for the public to follow in regard to its meeting protocols. Each data maintenance body drafts procedures for the public to submit requests for data or for revisions to the standard. These draft procedures are easy to use and are adequately communicated to the public. Each designated data maintenance body is also responsible for communicating actions taken on requests to the requestor and the public, in addition to communicating any changes made to a standard. This may be done via mail, e-mail, publications, or newsletters but, at a minimum, are published on the website. (We believe the Internet is the most cost effective way of communicating this type of information.) Each data maintenance body responds definitively to each request it receives no later than three months after the request is received. An alternative approach would be to require an organization which desired to be designated by the Secretary as the official data content maintenance body for a particular transaction to meet the ANSI criteria for due process found at http://www.ansi.org/proc__1.html. Not only would these criteria meet the intent of HIPAA to advocate an open, balanced, consensus process, but once an organization met these criteria, it would be able to apply for ANSI accreditation if it so desired. It is not our intention to increase any current burdens on data maintenance bodies. Our concern is that the public have a voice in the data maintenance process and that changes to a standard be timely and adequately communicated to the industry. We welcome any comments regarding the approach outlined above and recommendations for data maintenance committees for each X12N transaction standard identified in this rule. We also solicit comments on the appropriateness of ongoing Federal oversight/monitoring of maintenance processes and procedures. V. Collection of Information Requirements Under the Paperwork Reduction Act of 1995 (PRA), we are required to provide 60-day notice in the Federal Register and solicit public comment before a collection of information requirement is submitted to the Office of Management and Budget (OMB) for review and approval. In order to fairly evaluate whether an information collection should be approved by OMB, section 3506(c)(2)(A) of the Paperwork Reduction Act of 1995 requires that we solicit comment on the following issues: The need for the information collection and its usefulness in carrying out the proper functions of our agency. The accuracy of our estimate of the information collection burden. The quality, utility, and clarity of the information to be collected. Recommendations to minimize the information collection burden on the affected public, including automated collection techniques. Subpart K--Health Claims or Equivalent Encounter Information Standard 142.1104 Requirements: Health plans. 142.1108 Requirements: Health care providers. Subpart L--Health Care Payment and Remittance Advice 142.1204 Requirements: Health plans. Subpart M--Coordination of Benefits 142.1304 Requirements: Health plans. Subpart N--Health Claims Status 142.1404 Requirements: Health plans. 142.1408 Requirements: Health care providers. Subpart O--Enrollment and Disenrollment in a Health Plan 142.1504 Requirements: Health plans. Subpart P--Eligibility for a Health Plan 142.1604 Requirements: Health plans. 142.1608 Requirements: Health care providers. Subpart Q--Health Plan Premium Payments 142.1704 Requirements: Health plans. Subpart R--Referral Certification and Authorization 142.1804 Requirements: Health plans. 142.1808 Requirements: Health care providers. Discussion: In summary, each of the sections identified above require health care plans, and/or health care providers to use any given standard proposed in this regulation for all electronically transmitted standard transactions that require it on and after the effective date given to it. The emerging and increasing use of health care EDI standards and [[Page 25300]] transactions raises the issue of the applicability of the PRA. The question arises whether a regulation that adopts an EDI standard used to exchange certain information constitutes an information collection subject to the PRA. However, for the purpose of soliciting useful public comment we provide the following burden estimates. In particular, the initial burden on the estimated 4 million health plans and 1.2 million health care providers to modify their current computer systems software would be 10 hours/$300 per entity, for a total burden of 52 million hours/$1.56 billion. While this burden estimate may appear low, on average, we believe it to be accurate. This is based on the assumption that these and the other burden calculations associated with the HIPAA administrative simplification systems modifications may overlap. This average also takes into consideration that: (1) One or more of these standards may not be used; (2) some of the these standards may already be in use by several of the estimated entities; (3) modifications may be performed in an aggregate manner during the course of routine business and/or; (4) modifications may be made by contractors such as practice management vendors, in a single effort for a multitude of affected entities. We solicit comment on whether the requirements to which we refer above constitute a one-time or an ongoing, usual and customary business practice as defined 5 CFR 1320.3(b)(2), the Paperwork Reduction regulations. We invite public comment on the issues discussed above. If you comment on these information collection and recordkeeping requirements, please e-mail comments to JBurke1@hcfa.gov (Attn:HCFA-0149) or mail copies directly to the following: Health Care Financing Administration, Office of Information Services, Information Technology Investment Management Group, Division of HCFA Enterprise Standards, Room C2-26-17, 7500 Security Boulevard, Baltimore, MD 21244-1850. Attn: John Burke HCFA-0149 and Office of Information and Regulatory Affairs, Office of Management and Budget, Room 10235, New Executive Office Building, Washington, DC 20503, Attn: Allison Herron Eydt, HCFA Desk Officer. VI. Response to Comments Because of the large number of items of correspondence we normally receive on Federal Register documents published for comment, we are not able to acknowledge or respond to them individually. We will consider all comments we receive by the date and time specified in the DATES section of this preamble, and, if we proceed with a subsequent document, we will respond to comments in the preamble to that document. VII. Impact Analysis As the effect of any one standard is affected by the implementation of other standards, it can be misleading to discuss the impact of one standard by itself. Therefore, we did an impact analysis on the total effect of all the standards in the proposed rule concerning the national provider identifier (HCFA-0045-P), which can be found elsewhere in this Federal Register. We intend to publish in each proposed rule an impact analysis that is specific to the standard or standards proposed in that rule, but the impact analysis will assess only the relative cost impact of implementing a given standard. Thus, the following discussion contains the impact analysis for each of the transactions proposed in this rule. As stated in the general impact analysis in HCFA-0045-P, we do not intend to associate costs and savings to specific standards. Although we cannot determine the specific economic impact of the standards being proposed in this rule (and individually each standard may not have a significant impact), the overall impact analysis makes clear that, collectively, all the standards will have a significant impact of over $100 million on the economy. Also, while each standard may not have a significant impact on a substantial number of small entities, the combined effects of all the proposed standards may have a significant effect on a substantial number of small entities. Therefore, the following impact analysis should be read in conjunction with the overall impact analysis. In accordance with the provisions of Executive Order 12866, this proposed rule was reviewed by the Office of Management and Budget. Guiding Principles for Standard Selection The implementation teams charged with designating standards under the statute have defined, with significant input from the health care industry, a set of common criteria for evaluating potential standards. These criteria are based on direct specifications in the HIPAA, the purpose of the law, and principles that support the regulatory philosophy set forth in Executive Order 12866 of September 30, 1993, and the Paperwork Reduction Act of 1995. In order to be designated as a standard, a proposed standard should: Improve the efficiency and effectiveness of the health care system by leading to cost reductions for or improvements in benefits from electronic HIPAA health care transactions. This principle supports the regulatory goals of cost-effectiveness and avoidance of burden. Meet the needs of the health data standards user community, particularly health care providers, health plans, and health care clearinghouses. This principle supports the regulatory goal of cost-effectiveness. Be consistent and uniform with the other HIPAA standards (that is, their data element definitions and codes and their privacy and security requirements) and, secondarily, with other private and public sector health data standards. This principle supports the regulatory goals of consistency and avoidance of incompatibility, and it establishes a performance objective for the standard. Have low additional development and implementation costs relative to the benefits of using the standard. This principle supports the regulatory goals of cost-effectiveness and avoidance of burden. Be supported by an ANSI-accredited standards developing organization or other private or public organization that would ensure continuity and efficient updating of the standard over time. This principle supports the regulatory goal of predictability. Have timely development, testing, implementation, and updating procedures to achieve administrative simplification benefits faster. This principle establishes a performance objective for the standard. Be technologically independent of the computer platforms and transmission protocols used in HIPAA health transactions, except when they are explicitly part of the standard. This principle establishes a performance objective for the standard and supports the regulatory goal of flexibility. Be precise and unambiguous but as simple as possible. This principle supports the regulatory goals of predictability and simplicity. Keep data collection and paperwork burdens on users as low as is feasible. This principle supports the regulatory goals of cost- effectiveness and avoidance of duplication and burden. Incorporate flexibility to adapt more easily to changes in the health care infrastructure (such as new services, organizations, and provider types) and information technology. This principle [[Page 25301]] supports the regulatory goals of flexibility and encouragement of innovation. General The effect of implementing standards on health care clearinghouses is basically the same for all the standards. Currently, health care clearinghouses receive and transmit various transactions using a variety of formats. The implementation of standard transactions may reduce the variability in the data received from some groups, such as health care providers. The implementation of any standard will require some one-time changes to health care clearinghouse systems. Health care clearinghouses should be able to make modifications that meet the deadlines specified in the legislation, but some temporary disruption of processing could result. Once the transition is made, health care clearinghouses may have less ongoing system maintenance. Costs may vary according to the complexity of the standard, but costs may be recouped from customers. Health care clearinghouses would face impacts (both positive and negative) similar to those experienced by health plans (which we discuss in more detail in the discussions for specific transactions). However, implementation would likely be more complex, because health care clearinghouses deal with many health care providers and health plans and may have to accommodate additional nonstandard formats (in addition to those formats they currently support), as well as standards we adopt. (The additional nonstandard formats would be from those health care providers that choose to stop submitting directly to an insurer and submit through a health care clearinghouse.) This would also mean increased business for the health care clearinghouse. Converting to any standard will result in one-time conversion costs for health care providers, health care clearinghouses, and health plans as well. Some health care providers and health plans would incur those costs directly and others may incur them in the form of a fee from health care clearinghouses or, for health care providers, other agents. Each standard compares favorably with typical ASC X12 standards in terms of complexity and ease of use. No one in the ASC X12 subcommittee assumes that every entity that sends or receives an ASC X12 transaction has reprogrammed its information systems in order to do so. Every transaction is designed, and the technical review process assures, that it will be compatible with the commercial, off-the-shelf translator programs that are widely available in the United States. These translators significantly reduce the cost and complexity of achieving and maintaining compliance with all ASC X12 standards. Universal communication with all parties in the health care industry is thus assured. Specific technology limitations of existing systems could affect the complexity of conversion. Also, some existing health care provider systems may not have the resources to house a translator to convert from one format to another. Following is the portion of the impact analysis that relates specifically to the standards that are the subject of this regulation. A. Code Sets--Specific Impact of Adoption of Code Sets for Medical Data Affected Entities Standard codes and classifications are required in some segments of administrative and financial transactions. Those that create and process administrative transactions must implement the standard codes according to the official implementation guides designated for each coding system and each transaction. Those that receive standard electronic administrative transactions must be able to receive and process all standard codes (and modifiers, in the cases of HCPCS and CPT), irrespective of local policies regarding reimbursement for certain conditions or procedures, coverage policies, or need for certain types of information that are part of a standard transaction. The adoption of standard code sets and coding guidelines for medical data supports the regulatory goals of cost-effectiveness and the avoidance of duplication and burden. The code sets that are being proposed as initial HIPAA standards are all de facto standards already in use by most health plans, health care clearinghouses, and health care providers. Health care providers currently use the recommended code set for reporting diagnoses and one or more of the recommended procedure coding systems for reporting procedures/services. Since health plans can differ on the codes they accept, many health care providers use different coding guidelines for dealing with different health plans, sometimes for the same patient. (Anecdotal information leads us to believe that use of other codes is widespread, but we cannot quantify the number.) Some of these differences reflect variations in covered services that will continue to exist irrespective of data standardization. Others reflect differences in a health plan's ability to accept as valid a claim that may include more information than is needed or used by that health plan. The requirement to use standard coding guidelines will eliminate this latter category of differences and should simplify claims submission for health care providers that deal with multiple health plans. Currently, there are health plans that do not adhere to official coding guidelines and have developed their own plan-specific guidelines for use with the standard code sets, which do not permit the use of all valid codes. (Again, we cannot quantify how many health plans do this, but we are aware of some instances.) When the HIPAA code set standards become effective, these health plans would have to receive and process all standard codes, irrespective of local policies regarding reimbursement for certain conditions or procedures, coverage policies, or need for certain types of information that are part of a standard transaction. We believe that there is significant variation in the reporting of anesthesia services, with some health plans using the anesthesia section of CPT and others requiring the anesthesiologist or nurse anesthetist to report the code for the surgical procedure itself. When the HIPAA code sets become effective, health plans following the latter convention will have to begin accepting codes from the anesthesia section. We note that by adopting standards for code sets we are requiring that all parties accept these codes within their electronic transactions. We are not requiring payment for all these services. Those health plans that do not adhere to official coding guidelines must therefore undertake a one-time effort to modify their systems to accept all valid codes in the standard code sets or engage a health care clearinghouse to preprocess the standard claims data for them. Health plans should be able to make modifications to meet the deadlines specified in the legislation, but some temporary disruption of claims processing could result. There may be some temporary disruption of claims processing as health plans and health care clearinghouses modify their systems to accept all valid codes in the standard code sets. [[Page 25302]] B. Transaction Standards 1. Specific Impact of Adoption of the National Council of Prescription Drug Programs (NCPDP) Telecommunication Claim a. Affected Entities Health care providers that submit retail pharmacy claims, and health care plans that process retail pharmacy claims, currently use the NCPDP format. The NCPDP claim and equivalent encounter is used either in on-line interactive or batch mode. Since all pharmacy health care providers and health plans use the NCPDP claim format, there are no specific impacts to health care providers. b. Effects of Various Options The NCPDP format met all the principles and there are no known options for a standard retail pharmacy claim transaction. 2. Specific Impact of Adoption of the ASC X12N 837 for Submission of Institutional Health Care Claims, Professional Health Care Claims, Dental Claims, and Coordination of Benefits a. Affected Entities All health care providers and health plans that conduct EDI directly and use other electronic format(s), and all health care providers that decide to change from a paper format to an electronic one, would have to begin to use the ASC X12N 837 for submitting electronic health care claims (hospital, physician/supplier and dental). (Currently, about 3 percent of Medicare providers use this standard for claims; it is used less for non-Medicare claims.) There would be a potential for disruption of claims processes and timely payments during a particular health plan's transition to the ASC X12N 837. Some health care providers could react adversely to the increased cost and revert to submitting hard copy claims. After implementation, health care providers would no longer have to keep track of and use different electronic formats for different insurers. This would simplify provider billing systems and processes and reduce administrative expenses. Health plans would be able to schedule their implementation of the ASC X12N 837 in a manner that best fits their needs, thus allaying some costs (through coordination of conversion to other standards) as long as they meet the deadlines specified in the legislation. Although the costs of implementing the ASC X12N 837 are generally one-time costs related to conversion, the systems upgrades for some smaller health care providers, health plans, and health care clearinghouses may be cost prohibitive. Health care providers and health plans have the option of using a clearinghouse. The cost may also cause some smaller health plans that have trading partner agreements today to discontinue that partnership. That same audience of health care providers, health care clearinghouses, and health plans could conceivably be forced out of the partnerships of transmitting and accepting claims data. In these instances patients may be affected, in that, without trading partner agreements for electronic crossover of claims data for the processing of the supplemental benefit, the patient may be responsible for filing his or her own supplemental claims that are filed electronically today. Coordination of Benefits Once the ASC X12N 837 has been implemented, health plans that perform coordination of benefits would be able to eliminate support of multiple proprietary electronic claim formats, thus simplifying claims receipt and processing as well as reducing administrative costs. Coordination of benefits activities would also be greatly simplified because all health plans would use the same standard format. There is no doubt that standardization in coordination of benefits will greatly enhance and improve efficiency in the overall claims process and the coordination of benefits. From a nonsystems perspective, we do not foresee an impact to the coordination of benefits process. The COB transaction will continue to consist of the incoming electronic claim and the data elements provided on a remittance advice. Standardization in the coordination of benefits process will clearly increase efficiency in the electronic processes utilized by the health care providers, health care clearinghouses, and health plans as they work with standardized codes and processes. b. Effects of Various Options We assessed the various options for a standard claim transaction against the principles, listed at the beginning of this impact analysis above, with the overall goal of achieving the maximum benefit for the least cost. We found that the ASC X12N 837 for institutional claims, professional claims, dental claims, and coordination of benefits met all the principles, but no other candidate standard transaction met all the principles. Since the majority of dental claims are submitted on paper and those submitted electronically are being transmitted using a variety of proprietary formats, the only viable choice of a standard is the ASC X12N 837. The American Dental Association (ADA) also recommended the ASC X12N 837 for the dental claim standard. The ASC X12N 837 was selected as the standard for the professional (physician/supplier) claim because it met the principles above. The only other candidate standard, the National Standard Format, was developed primarily by HCFA for Medicare claims. While it is widely used, it is not always used in a standard manner. Many variations of the National Standard Format are in use. The NUCC, the AMA, and WEDI recommended the ASC X12N 837 for the professional claim standard. The ASC X12N 837 was selected as the standard for the institutional (hospital) claim because it met the principles above. The only other candidate standard is the UB-92 Format. While it is widely used, it is not always used in a standard manner. The selection of the ASC X12N 837 does not impose a greater burden on the industry than the nonselected options because the nonselected formats are not used in a standard manner by the industry and they do not incorporate flexibility in order to adapt easily to change. The ASC X12N 837 presents significant advantages in terms of universality and flexibility. 3. Specific Impact of Adoption of the ASC X12N 835 for Receipt of Health Care Remittance a. Affected Entities Health care providers that conduct EDI with health plans and do not wish to change their internal systems would have to convert the ASC X12N 835 transactions received from health plans into a format compatible with their internal systems. Health plans that want to transmit remittance advice directly to health care providers and that do not use the ASC X12N 835 would also incur costs to convert. Many health care providers and health plans do not use this standard at this time. (We do not have information to quantify the standard's use outside the Medicare program. However, in 1996, 15.9 percent of part B health care providers and 99.4 percent of part A health care providers were able to receive this standard. All Medicare contractors must be able to send the standard.) There would be a potential for the delay in payment or the issuance of electronic remittance advice [[Page 25303]] transactions during a particular health plan's transition to the ASC X12N 835. Some health care providers could react adversely to the increased cost and revert to use of hard copy remittance advice notices in lieu of an electronic transmission. After implementation, health care providers would no longer have to keep track of or accept different electronic payment/remittance advice formats issued by different health care payers. This would simplify automatic posting of all electronic payment/remittance advice data, reducing administrative expenses. This would also reduce or eliminate the practice of posting payment/remittance advice data manually from hard copy notices, again reducing administrative expenses. Most manual posting occurs currently in response to the problem of multiple formats, which the standard would eliminate. Once the ASC X12N 835 has been implemented, health plans' coordination of benefits activities, which would use the ASC X12N 837 format supplemented with limited data from the ASC X12N 835, would be greatly simplified because all health plans would use the same standard format. Health plans would be able to schedule their implementation of the ASC X12N 835 in a manner that best fits their needs, thus allaying some costs (through coordination of conversion to other standards), as long as they meet the deadlines specified in the legislation. The selection of the ASC X12N 835 does not impose a greater burden on the industry than the nonselected option because the nonselected formats are not used in a standard manner by the industry and they do not incorporate flexibility in order to adapt easily to change. The ASC X12N 835 presents significant advantages in terms of universality and flexibility. b. Effects of Various Options We assessed the various options for a standard payment/remittance advice transaction against the principles listed above, with the overall goal of achieving the maximum benefit for the least cost. We found that the ASC X12N 835 met all the principles, but no other candidate standard transaction met all the principles, or even those principles supporting the regulatory goal of cost-effectiveness. The ASC X12N 835 was selected as it met the principles above. The only other candidate standard, the ASC X12N 820, was not selected because, although it was developed for payment transactions, it was not developed for health care payment purposes. The ASC X12N subcommittee itself recognized this in its decision to develop the ASC X12N 835. 4. Specific Impact of Adoption of the ASC X12N 276/277 for Health Care Claim Status/Response a. Affected Entities Most health care providers that are currently using an electronic format (of which there are currently very few) and that wish to request claim status electronically using the ASC X12N 276/277 will incur conversion costs. We cannot quantify the number of health care providers that would have to convert to the proposed standard, but we do know that no Medicare contractors use it; thus, we assume that few health care providers are able to use it at this time. After implementation, health care providers would be able to request and receive the status of claims in one standard format, from all health care plans. This would eliminate their need to maintain redundant software and would make electronic claim status requests and receipt of responses feasible for small providers, eliminating their need to manually send and review claim status requests and responses. Health care plans that do not currently directly accept electronic claim status requests and do not directly send electronic claims status responses would have to modify their systems to accept the ASC X12N 276 and to send the ASC X12N 277. No disruptions in claims processing or payment would occur. After implementation, health care plans would be able to submit claim status responses in one standard format to all health care providers. Administrative costs incurred by supporting multiple formats and manually responding to claim status requests would be greatly reduced. b. Effects of Various Options There are no known options for a standard claims status and response transaction. 5. Specific Impact of Adoption of the ASC X12N 834 for Enrollment and Disenrollment in a Health Plan a. Affected Entities The ASC X12N 834 may be used by an employer or other sponsor to electronically enroll or disenroll its subscribers into or out of a health plan. Currently, most small and medium size employers and other sponsors conduct their subscriber enrollments using paper forms. (We cannot quantify how many of these sponsors use paper forms, but anecdotal information indicates that most use paper.) We understand that large employers and other sponsors are more likely to conduct subscriber enrollment transactions electronically because of the many changes that occur in a large workforce; for example, hirings, firings, retirements, marriages, births, and deaths, to name a few. To do this, the large employers must use the proprietary electronic data interchange formats that differ among health plans. Nonetheless, it is our understanding, based on anecdotal information, that health plans still use paper to conduct most of their enrollment transactions. We expect that the impact of the ASC X12N 834 transaction standard would differ, at least in the beginning, according to the current use of electronic transactions. As stated earlier, most small and medium size employers and other sponsors do not use electronic transactions currently and would therefore experience little immediate impact from adoption of the ASC X12N 834 transaction. The ASC X12N 834 would offer large employers that currently conduct enrollment transactions electronically the opportunity to shift to a single standard format. A single standard will be most attractive to those large employers that offer their subscribers choices among multiple health plans. Thus, we expect that the early benefits of the ASC X12N 834 would accrue to large employers and other sponsors that would be able to eliminate redundant hardware, software, and human resources required to support multiple proprietary electronic data interchange formats. In the long run, we expect that the standards would lower the cost of conducting enrollment transactions and make it possible for small and medium size companies to convert from paper to electronic transactions and achieve significant additional savings. Overall, employers and other sponsors, and the health plans with which they deal, stand to benefit from adoption of the ASC X12N 834 and electronic data interchange. The ASC X12N 834 and electronic data interchange would facilitate the performance of enrollment and disenrollment functions. Further, the ASC X12N 834 supports detailed enrollment information on the subscriber's dependents, which is often lacking in current practice. Ultimately, reductions in administrative overhead may be passed along in lower premiums to subscribers and their dependents. We invite commenters to provide us with data on the extent to which [[Page 25304]] employers and other sponsors conduct their health plan enrollments using paper proprietary formats rather than the ASC X12N 834 electronic data interchange standards. b. Effects of Various Options The only other option, the NCPDP Member Enrollment Standard, does not meet the selection criteria and would not be implementable. 6. Specific Impact of Adoption of the ASC X12N 270/271 for Eligibility for a Health Plan a. Affected Entities The ASC X12N 270/271 transaction may be used by a health care provider to electronically request and receive eligibility information from a health care plan prior to providing or billing for a health care service. Many health care providers routinely verify health insurance coverage and benefit limitations prior to providing treatment or before preparing claims for submission to the insured patient and his or her health plan. Currently, health care providers secure most of these eligibility determinations through telephone calls, proprietary point of sale terminals, or using proprietary electronic formats that differ from health plan to health plan. Since many health care providers participate in multiple health plans, these health care providers must maintain redundant software, hardware, and human resources to obtain eligibility information. This process is inefficient, often burdensome, and takes valuable time that could otherwise be devoted to patient care. We believe that the lack of a health care industry standard may have imposed a cost barrier to the widespread use of electronic data interchange. The ASC X12N 270/271 is used widely, but not exclusively, by health care plans and health care providers. This may be due, in part, to the lack of an industry-wide implementation guide for these transactions in health care. We expect that adoption of the ASC X12N 270/271 and its implementation guide would lower the cost of using electronic eligibility verifications. This would benefit health care providers that can move to a single standard format and, for the first time, make electronic data interchange feasible for small health plans and health care providers that rely currently on the telephone, paper forms, or proprietary point of sale terminals and software. b. Effect of Various Options There were two other options, the ASC X12N IHCEBI, and its companion, IHCEBR, and the NCPDP Telecommunications Standard Format. None of these meet the selection criteria and thus they would not be implementable. 7. Specific Impact of Adoption of the ASC X12N 820 for Payroll Deducted and Other Group Premium Payment for Insurance Product a. Affected Entities The ASC X12N 820 may be used by an employer or sponsor to electronically transmit a remittance notice to accompany a payment for health insurance premiums in response to a bill from the health plan. Payment may be in the form of a paper check or an electronic funds transfer transaction. The ASC X12N 820 can be sent with electronic funds transfer instructions that are routed directly to the Federal Reserve System's automated health care clearinghouses or with payments generated directly by the employer's or other sponsor's bank. The ASC X12 820 transaction is very widely used by many industries (manufacturing, for instance) and government agencies (Department of Defense) in addition to the insurance industry in general. However, the ASC X12N 820 is not widely used in the health insurance industry and is not widely used by employers and other sponsors to make premium payments to their health insurers. This may be due, in part, to the lack of an implementation guide specifically for health insurance. Currently, most payment transactions are conducted on paper, and those that are conducted electronically use proprietary electronic data interchange standards that differ across health plans. (We cannot quantify how many of these transactions are conducted on paper, but anecdotal information suggests that most are.) We believe that the lack of a health care industry standard may have imposed a cost barrier to the use of electronic data interchange; larger employers and other sponsors, that often transact business with multiple health plans, need to retain redundant hardware, software, and human resources to support multiple proprietary electronic premium payment standards. We expect that adoption of national standards will lower the cost of using electronic premium payments. This will benefit large employers that can move to a single standard format, and, for the first time, will make electronic transmissions of premium payments feasible for smaller employers and other sponsors whose payment transactions today are performed almost exclusively using paper. At some point, an organization's size and complexity will require it to consider switching its business transactions from paper to electronic. The ASC X12N 820 would facilitate that by eliminating redundant proprietary formats that are certain to crop up when there are no widely accepted standards. By eliminating the software, hardware, and human resources associated with redundancy, a business may reach the point where it becomes cost beneficial to convert from paper to electronic transactions. Those other sponsors and health care plans that already support more than one proprietary format would incur some additional expense in the conversion to the standard, but they would enjoy longer term savings that result from eliminating the redundancies. We invite comments on the extent to which employers and other sponsors conduct their health plan premium payments using paper versus proprietary formats, compared to the ASC X12N 820 electronic data interchange standards. b. Effects of Various Options There are no known options for premium payment transactions. 8. Specific Impact of Adoption of ASC X12N 278 for Referral Certification and Authorization a. Affected Entities The ASC X12N 278 may be used by a health care provider to request and receive approval from a health plan through an electronic transaction prior to providing a health care service. Prior approvals have become standard operating procedure for most hospitals, physicians and other health care providers due to the rapid growth of managed care. Health care providers secure most of their prior approvals through telephone calls, paper forms or proprietary electronic formats that differ from health plan to health plan. Since many health care providers participate in multiple managed care plans, they must devote redundant software, hardware, and human resources to obtaining prior authorization. This process is often untimely and inefficient. We believe that the lack of a health care industry standard may have imposed a cost barrier to the widespread use of electronic data interchange. The ASC X12N 278 is not widely used by health care plans and health care providers, which may be due, in part, to the lack of an industry-wide implementation guide for it. We expect that adoption of ASC X12N 278 and its [[Page 25305]] implementation guide would lower the cost of using electronic prior authorizations. This would benefit health care providers that can move to a single standard format and, for the first time, make electronic data interchange feasible for smaller health plans and health care providers that perform these transactions almost exclusively using the telephone or paper. At some point, an organization's size and complexity will require it to consider switching its business transactions from paper to electronic. The ASC X12N 278 would facilitate that by eliminating redundant proprietary formats that are certain to crop up when there are no widely accepted standards. By eliminating the software, hardware, and human resources associated with redundancy, a business may reach the point where it becomes cost beneficial to convert from paper to electronic transactions. Health care plans and health care providers that already support more than one proprietary format would incur some additional expense in the conversion to the standard but would enjoy longer term savings that result from eliminating the redundancies. b. Effects of Various Options There are no known options for referral and certification authorization transactions. List of Subjects in 45 CFR Part 142 Administrative practice and procedure, Health facilities, Health insurance, Hospitals, Incorporation by reference, Medicare, Medicaid. Accordingly, 45 CFR subtitle A, subchapter B, would be amended by adding Part 142 to read as follows: Note to Reader: This proposed rule and another proposed rule found elsewhere in this Federal Register are two of several proposed rules that are being published to implement the administrative simplification provisions of the Health Insurance Portability and Accountability Act of 1996. We propose to establish a new 45 CFR Part 142. Proposed Subpart A--General Provisions is exactly the same in each rule unless we have added new sections or definitions to incorporate additional general information. The subparts that follow relate to the specific provisions announced separately in each proposed rule. When we publish the first final rule, each subsequent final rule will revise or add to the text that is set out in the first final rule. PART 142--ADMINISTRATIVE REQUIREMENTS Subpart A--General Provisions Sec. 142.101 Statutory basis and purpose. 142.102 Applicability. 142.103 Definitions. 142.104 General requirements for health plans. 142.105 Compliance using a health care clearinghouse. 142.106 Effective dates of a modification to a standard or implementation specification. 142.110 Availability of implementation guides. Subparts B-I--[Reserved] Subpart J--Code Sets 142.1002 Medical data code sets. 142.1004 Code sets for nonmedical data elements. 142.1010 Effective dates of the initial implementation of code sets. Subpart K--Health Claims or Equivalent Encounter Information 142.1102 Standards for health claims or equivalent encounter information. 142.1104 Requirements: Health plans. 142.1106 Requirements: Health care clearinghouses. 142.1108 Requirements: Health care providers. 142.1110 Effective dates of the initial implementation of the health claim or equivalent encounter information. Subpart L--Health Claims and Remittance Advice 142.1202 Standard for health claims and remittance advice. 142.1204 Requirements: Health plans. 144.1206 Requirements: Health care clearinghouses. 142.1210 Effective dates of the initial implementation of the health claims and remittance advice. Subpart M--Coordination of Benefits 142.1302 Standard for coordination of benefits. 142.1304 Requirements: Health plans. 144.1306 Requirements: Health care clearinghouses. 142.1308 Effective dates of the initial implementation of the standard for coordination of benefits. Subpart N--Health Claim Status 142.1402 Standard for health claim status. 142.1404 Requirements: Health plans. 144.1406 Requirements: Health care clearinghouses. 142.1408 Requirements: Health care providers. 142.1410 Effective dates of the initial implementation of the standard for health claims status. Subpart O--Enrollment and Disenrollment in a Health Plan 142.1502 Standard for enrollment and disenrollment in a health plan. 142.1504 Requirements: Health plans. 144.1506 Requirements: Health care clearinghouses. 142.1508 Effective dates of the initial implementation of the standard for enrollment and disenrollment in a health plan. Subpart P--Eligibility for a Health Plan 142.1602 Standard for eligibility for a health plan. 142.1604 Requirements: Health plans. 144.1606 Requirements: Health care clearinghouses. 142.1608 Requirements: Health care providers. 142.1610 Effective dates of the initial implementation of the standard for eligibility for a health plan. Subpart Q--Health Plan Premium Payments 142.1702 Standard for health plan premium payments. 142.1704 Requirements: Health plans. 144.1706 Requirements: Health care clearinghouses. 142.1708 Effective dates of the initial implementation of the standard for health plan premium payments. Subpart R--Referral Certification and Authorization 142.1802 Referral certification and authorization. 142.1804 Requirements: Health plans. 144.1806 Requirements: Health care clearinghouses. 142.1808 Requirements: Health care providers. 142.1810 Effective dates of the initial implementation of the standard for referral certifications and authorizations. Authority: Sections 1173 and 1175 of the Social Security Act (42 U.S.C. 1320d-2 and 1320d-4) Subpart A--General Provisions Sec. 142.101 Statutory basis and purpose. Sections 1171 through 1179 of the Social Security Act, as added by section 262 of the Health Insurance Portability and Accountability Act of 1996, require HHS to adopt national standards for the electronic exchange of health information in the health information system. The purpose of these sections is to promote administrative simplification. Sec. 142.102 Applicability. (a) The standards adopted or designated under this part apply, in whole or in part, to the following: (1) A health plan. (2) A health care clearinghouse when doing the following: (i) Transmitting a standard transaction (as defined in Sec. 142.103) to a health care provider or health plan. (ii) Receiving a standard transaction from a health care provider or health plan. (iii) Transmitting and receiving the standard transactions when interacting with another health care clearinghouse. (3) A health care provider when transmitting an electronic transaction as defined in Sec. 142.103. (b) Means of compliance are stated in greater detail in Sec. 142.105. [[Page 25306]] Sec. 142.103 Definitions. For purposes of this part, the following definitions apply: ASC X12 stands for the Accredited Standards Committee chartered by the American National Standards Institute to design national electronic standards for a wide range of business applications. ASC X12N stands for the ASC X12 subcommittee chartered to develop electronic standards specific to the insurance industry. Code set means any set of codes used for encoding data elements, such as tables of terms, medical concepts, medical diagnostic codes, or medical procedure codes. Health care clearinghouse means a public or private entity that processes or facilitates the processing of nonstandard data elements of health information into standard data elements. The entity receives transactions from health care providers, health plans, other entities, or other clearinghouses, translates the data from a given format into one acceptable to the intended recipient, and forwards the processed transaction to the appropriate recipient. Billing services, repricing companies, community health management information systems, community health information systems, and ``value-added'' networks and switches are considered to be health care clearinghouses for purposes of this part. Health care provider means a provider of services as defined in section 1861(u) of the Social Security Act, a provider of medical or other health services as defined in section 1861(s) of the Social Security Act, and any other person who furnishes or bills and is paid for health care services or supplies in the normal course of business. Health information means any information, whether oral or recorded in any form or medium, that-- (1) Is created or received by a health care provider, health plan, public health authority, employer, life insurer, school or university, or health care clearinghouse; and (2) Relates to the past, present, or future physical or mental health or condition of an individual, the provision of health care to an individual, or the past, present, or future payment for the provision of health care to an individual. Health plan means an individual or group plan that provides, or pays the cost of, medical care. Health plan includes the following, singly or in combination: (1) Group health plan. A group health plan is an employee welfare benefit plan (as currently defined in section 3(l) of the Employee Retirement Income and Security Act of 1974 (29 U.S.C. 1002(l)), including insured and self-insured plans, to the extent that the plan provides medical care, including items and services paid for as medical care, to employees or their dependents directly or through insurance, or otherwise, and (i) Has 50 or more participants; or (ii) Is administered by an entity other than the employer that established and maintains the plan. (2) Health insurance issuer. A health insurance issuer is an insurance company, insurance service, or insurance organization that is licensed to engage in the business of insurance in a State and is subject to State law that regulates insurance. (3) Health maintenance organization. A health maintenance organization is a Federally qualified health maintenance organization, an organization recognized as a health maintenance organization under State law, or a similar organization regulated for solvency under State law in the same manner and to the same extent as such a health maintenance organization. (4) Part A or Part B of the Medicare program under title XVIII of the Social Security Act. (5) The Medicaid program under title XIX of the Social Security Act. (6) A Medicare supplemental policy (as defined in section 1882(g)(1) of the Social Security Act). (7) A long-term care policy, including a nursing home fixed- indemnity policy. (8) An employee welfare benefit plan or any other arrangement that is established or maintained for the purpose of offering or providing health benefits to the employees of two or more employers. (9) The health care program for active military personnel under title 10 of the United States Code. (10) The veterans health care program under 38 U.S.C., chapter 17. (11) The Civilian Health and Medical Program of the Uniformed Services (CHAMPUS), as defined in 10 U.S.C. 1072(4). (12) The Indian Health Service program under the Indian Health Care Improvement Act (25 U.S.C. 1601 et seq.). (13) The Federal Employees Health Benefits Program under 5 U.S.C. chapter 89. (14) Any other individual or group health plan, or combination thereof, that provides or pays for the cost of medical care. Medical care means the diagnosis, cure, mitigation, treatment, or prevention of disease, or amounts paid for the purpose of affecting any body structure or function of the body; amounts paid for transportation primarily for and essential to these items; and amounts paid for insurance covering the items and the transportation specified in this definition. Participant means any employee or former employee of an employer, or any member or former member of an employee organization, who is or may become eligible to receive a benefit of any type from an employee benefit plan that covers employees of that employer or members of such an organization, or whose beneficiaries may be eligible to receive any of these benefits. ``Employee'' includes an individual who is treated as an employee under section 401(c)(1) of the Internal Revenue Code of 1986 (26 U.S.C. 401(c)(1)). Small health plan means a group health plan or individual health plan with fewer than 50 participants. Standard means a set of rules for a set of codes, data elements, transactions, or identifiers promulgated either by an organization accredited by the American National Standards Institute or HHS for the electronic transmission of health information. Transaction means the exchange of information between two parties to carry out financial and administrative activities related to health care. It includes the following: (1) Transactions specified in section 1173(a)(2) of the Act, which are as follows: (i) Health claims or equivalent encounter information. (ii) Health care payment and remittance advice. (iii) Health claims status. (iv) Enrollment and disenrollment in a health plan. (v) Eligibility for a health plan. (vi) Health plan premium payments. (vii) First report of injury. (viii) Referral certification and authorization. (ix) Health claims attachments. (2) Other transactions as the Secretary may prescribe by regulation. Coordination of benefits is a transaction under this authority. Sec. 142.104 General requirements for health plans. If a person conducts a transaction (as defined in Sec. 142.103) with a health plan as a standard transaction, the following apply: (a) The health plan may not refuse to conduct the transaction as standard transaction. (b) The health plan may not delay the transaction or otherwise adversely [[Page 25307]] affect, or attempt to adversely affect, the person or the transaction on the basis that the transaction is a standard transaction. (c) The health information transmitted and received in connection with the transaction must be in the form of standard data elements of health information. (d) A health plan that conducts transactions through an agent must assure that the agent meets all the requirements of this part that apply to the health plan. Sec. 142.105 Compliance using a health care clearinghouse. (a) Any person or other entity subject to the requirements of this part may meet the requirements to accept and transmit standard transactions by either-- (1) Transmitting and receiving standard data elements, or (2) Submitting nonstandard data elements to a health care clearinghouse for processing into standard data elements and transmission by the health care clearinghouse and receiving standard data elements through the health care clearinghouse. (b) The transmission, under contract, of nonstandard data elements between a health plan or a health care provider and its agent health care clearinghouse is not a violation of the requirements of this part. Sec. 142.106 Effective dates of a modification to a standard or implementation specification. If HHS adopts a modification to a standard or implementation specification, the implementation date of the modified standard or implementation specification may be no earlier than 180 days following the adoption of the modification. HHS determines the actual date, taking into account the time needed to comply due to the nature and extent of the modification. HHS may extend the time for compliance for small health plans. Sec. 142.110 Availability of implementation guides. The implementation guides specified in subparts K through R of this part are available as set forth in paragraphs (a) through (c) of this section. Entities requesting copies or access for inspection must specify the standard by name, number, and version. (a) The implementation guides for ASC X12 standards may be obtained from the Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878; telephone 301-590-9337; and FAX: 301-869-9460. They are also available, at no cost, through the Washington Publishing Company on the Internet at http://www.wpc-edi.com/hipaa/. (b) The implementation guide for pharmacy claims may be obtained from the National Council for Prescription Drug Programs, 4201 North 24th Street, Suite 365, Phoenix, AZ, 85016; telephone 602-957-9105; and FAX 602-955-0749. It may also be obtained through the Internet at http://www.ncpdp.org. (c) A copy of the guides may be inspected at the Office of the Federal Register, 800 North Capitol Street, NW., Suite 700, Washington, DC and at the Health Care Financing Administration. Subparts B-I--[Reserved] Subpart J--Code Sets Sec. 142.1002 Medical data code sets. Health plans, health care clearinghouses, and health care providers must use on electronic transactions the diagnostic and procedure code sets as prescribed by HHS. These code sets are published in a notice in the Federal Register. The implementation guides for the transaction standards in part 142, Subparts K through R specify which of the standard medical data code sets are to be used in individual data elements within those transaction standards. Sec. 142.1004 Code sets for nonmedical data elements. The code sets for nonmedical data that must be used in a transaction specified in subparts K through R of this part are the code sets described in the implementation guide for the transaction standard. Sec. 142.1010 Effective dates of the initial implementation of code sets. (a) Health plans. (1) Each health plan that is not a small health plan must comply with the requirements of Secs. 142.104, 142.1002, and 142.1004 by (24 months after the effective date of the final rule in the Federal Register). (2) Each small health plan must comply with the requirements of Secs. 142.104, 142.1002, and 142.1004 by [36 months after the effective date of the final rule in the Federal Register]. (b) Health care clearinghouses and health care providers. Each health care clearinghouse and health care provider must begin to use the standards specified in Secs. 142.1002 and 142.1004 by (24 months after the effective date of the final rule in the Federal Register). Subpart K--Health Claims or Equivalent Encounter Information Sec. 142.1102 Standards for health claims or equivalent encounter information. The health claims or equivalent encounter information standards that must be used under this subpart are as follows: (a) For pharmacy claims, the NCPDP Telecommunications Standard Format Version 3.2 and equivalent Standard Claims Billing Tape Format batch implementation, version 2.0. The Director of the Federal Register approves this incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is available at the addresses specified in Sec. 142.108(b) and (c) of this part. (b) The ASC X12N 837--Health Care Claim: Dental, Version 4010, Washington Publishing Company, 004010X097. The Director of the Federal Register approves this incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is available at the addresses specified in Sec. 142.108(a) and (c) of this part. (c) The ASC X12N 837--Health Care Claim: Professional, Version 4010, Washington Publishing Company, 004010X098. The Director of the Federal Register approves this incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is available at the addresses specified in Sec. 142.108(a) and (c) of this part. (d) The ASC X12N 837--Health Care Claim--Institutional, Version 4010, Washington Publishing Company, 004010X096. The Director of the Federal Register approves this incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is available at the addresses specified in Sec. 142.108(a) and (c) of this part. Sec. 142.1104 Requirements: Health plans. Each health plan must accept the standard specified in Sec. 142.1102 when conducting transactions concerning health claims and equivalent encounter information. Sec. 142.1106 Requirements: Health care clearinghouses. Each health care clearinghouse must use the standard specified in Sec. 142.1102 when accepting or transmitting health claims or equivalent encounter information transactions. Sec. 142.1108 Requirements: Health care providers. Any health care provider that transmits health claims or equivalent encounter information electronically must use the standard specified in Sec. 142.1102. [[Page 25308]] Sec. 142.1110 Effective dates of the initial implementation of the health claim or equivalent encounter information standard. (a) Health plans. (1) Each health plan that is not a small health plan must comply with the requirements of Secs. 142.104 and 142.1104 by (24 months after the effective date of the final rule in the Federal Register). (2) Each small health plan must comply with the requirements of Secs. 142.104 and 142.1104 by (36 months after the effective date of the final rule in the Federal Register). (b) Health care clearinghouses and health care providers. Each health care clearinghouse and health care provider must begin to use the standard specified in Sec. 142.1102 by (24 months after the effective date of the final rule in the Federal Register). Subpart L--Health Claims and Remittance Advice Sec. 142.1202 Standard for health claims and remittance advice. The standard for health claims and remittance advice that must be used under this subpart is the ASC X12N 835--Health Care Claim Payment/ Advice, Version 4010, Washington Publishing Company, 004010X091. The Director of the Federal Register approves this incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is available at the addresses specified in Sec. 142.108(a) and (c) of this part. Sec. 142.1204 Requirements: Health plans. Each health plan must transmit the standard specified in Sec. 142.1202 when conducting health claims and remittance advice transactions. Sec. 142.1206 Requirements: Health care clearinghouses. Each health care clearinghouse must use the standard specified in Sec. 142.1202 when accepting or transmitting health claims and remittance advice. Sec. 142.1210 Effective dates of the initial implementation of the health claims and remittance advice. (a) Health plans. (1) Each health plan that is not a small health plan must comply with the requirements of Secs. 142.104 and 142.1204 by (24 months after the effective date of the final rule in the Federal Register). (2) Each small health plan must comply with the requirements of Secs. 142.104 and 142.1204 by (36 months after the effective date of the final rule in the Federal Register). (b) Health care clearinghouses. Each health care clearinghouse must begin to use the standard specified in Sec. 142.1204 by (24 months after the effective date of the final rule in the Federal Register). Subpart M--Coordination of Benefits Sec. 142.1302 Standard for coordination of benefits. The coordination of benefits information standards that must be used under this subpart are as follows: (a) For pharmacy claims, the NCPDP Telecommunications Standard Format Version 3.2 and equivalent Standard Claims Billing Tape Format batch implementation, version 2.0. The Director of the Federal Register approves this incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is available at the addresses specified in Sec. 142.108(b) and (c) of this part. (b) For dental claims, the ASC X12N 837--Health Care Claim: Dental, Version 4010, Washington Publishing Company, 004010X097. The Director of the Federal Register approves this incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is available at the addresses specified in Sec. 142.108(a) and (c) of this part. (c) For professional claims, the ASC X12N 837--Health Care Claim: Professional, Version 4010, Washington Publishing Company, 004010X098. The Director of the Federal Register approves this incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is available at the addresses specified in Sec. 142.108(a) and (c) of this part. (d) For institutional claims, the ASC X12N 837--Health Care Claim-- Institutional, Version 4010, Washington Publishing Company, 004010X096. The Director of the Federal Register approves this incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is available at the addresses specified in Sec. 142.108(a) and (c) of this part. Sec. 142.1304 Requirements: Health plans. Each health plan that performs coordination of benefits must accept and transmit the standard specified in Sec. 142.1302 when accepting or transmitting coordination of benefits transactions. Sec. 142.1306 Requirements: Health care clearinghouses. Each health care clearinghouse must use the standard specified in Sec. 142.1302 when accepting or transmitting coordination of benefits transactions. Sec. 142.1308 Effective dates of the initial implementation of the standard for coordination of benefits. (a) Health plans. (1) Each health plan that performs coordination of benefits and is not a small health plan must comply with the requirements of Secs. 142.104 and 142.1304 by (24 months after the effective date of the final rule in the Federal Register). (2) Each small health plan that performs coordination of benefits must comply with the requirements of Secs. 142.104 and 142.1304 by (36 months after the effective date of the final rule in the Federal Register). (b) Health care clearinghouses. Each health care clearinghouse must begin to use the standard specified in Sec. 142.1302 by (24 months after the effective date of the final rule in the Federal Register). Subpart N--Health Claim Status Sec. 142.1402 Standard for health claim status. The standard for health claim status that must be used under this subpart is the ASC X12N 276/277 Health Care Claim Status Request and Response, Version 4010, Washington Publishing Company, 004010X093. The Director of the Federal Register approves this incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is available at the addresses specified in Sec. 142.108(a) and (c) of this part. Sec. 142.1404 Requirements: Health plans. Each health plan must accept and transmit the standard specified in Sec. 142.1402 when accepting or transmitting health claim status in transactions with health care providers. Sec. 142.1406 Requirements: Health care clearinghouses. Each health care clearinghouse must use the standard specified in Sec. 142.1402 when accepting or transmitting health claims status transactions. Sec. 142.1408 Requirements: Health care providers. Any health care provider that transmits or accepts health claims status electronically must use the standard specified in Sec. 142.1402. Sec. 142.1410 Effective dates of the initial implementation of the standard for health claims status. (a) Health plans. (1) Each health plan that is not a small health plan must comply with the requirements of Secs. 142.104 and 142.1404 by (24 months after the effective date of the final rule in the Federal Register). (2) Each small health plan must comply with the requirements of [[Page 25309]] Sec. Sec. 142.104 and 142.1404 by (36 months after the effective date of the final rule in the Federal Register). (b) Health care clearinghouses and health care providers. Each health care clearinghouse and health care provider must begin to use the standard specified in Sec. 142.1402 by (24 months after the effective date of the final rule in the Federal Register). Subpart O--Enrollment and Disenrollment in a Health Plan Sec. 142.1502 Standard for enrollment and disenrollment in a health plan. The standard for enrollment and disenrollment in a health plan that must be used under this subpart is the ASC X12 834--Benefit Enrollment and Maintenance, [date], Version 4010, Washington Publishing Company, (004010X095). The Director of the Federal Register approves this incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is available at the addresses specified in Sec. 142.110(a) and (c). Sec. 142.1504 Requirements: Health plans. Each health plan must accept the standard specified in Sec. 142.1502 when accepting transactions for enrollment and disenrollment in a health plan. Sec. 142.1506 Requirements: Health care clearinghouses. Each health care clearinghouse must use the standard specified in Sec. 142.1502 when accepting or transmitting transactions for enrollment and disenrollment in a health plan. Sec. 142.1508 Effective dates of the initial implementation of the standard for enrollment and disenrollment in a health plan. (a) Health plans. (1) Each health plan that is not a small health plan must comply with the requirements of Secs. 142.104 and 142.1504 by (24 months after the effective date of the final rule in the Federal Register). (2) Each small health plan must comply with the requirements of Secs. 142.104 and 142.1504 by (36 months after the effective date of the final rule in the Federal Register). (b) Health care clearinghouses. Each health care clearinghouse must begin to use the standard specified in Sec. 142.1502 by (24 months after the effective date of the final rule in the Federal Register). Subpart P--Eligibility for a Health Plan Sec. 142.1602 Standard for eligibility for a health plan. The standard for eligibility for a health plan transaction that must be used under this subpart is ASC X12N 270--Health Care Eligibility Benefit Inquiry and ASC X12N 271--Health Care Eligibility Benefit Response, [date], Version 4010, Washington Publishing Company, (004010X092). The Director of the Federal Register approves this incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is available at the addresses specified in Sec. 142.108(a) and (c) of this part. Sec. 142.1604 Requirements: Health plans. Each health plan must accept and transmit the standard specified in Sec. 142.1602 when accepting or transmitting transactions for eligibility for a health plan. Sec. 142.1606 Requirements: Health care clearinghouses. Each health care clearinghouse must use the standard specified in Sec. 142.1602 when accepting or transmitting transactions for eligibility for a health plan. Sec. 142.1608 Requirements: Health care providers. Any health care provider that transmits or receives transactions for eligibility for a health plan electronically must use the standard specified in Sec. 142.1602. Sec. 142.1610 Effective dates of the initial implementation of the standard for eligibility for a health plan. (a) Health plans. (1) Each health plan that is not a small health plan must comply with the requirements of Secs. 142.104 and 142.1604 by (24 months after the effective date of the final rule in the Federal Register). (2) Each small health plan must comply with the requirements of Secs. 142.104 and 142.1604 by (36 months after the effective date of the final rule in the Federal Register). (b) Health care clearinghouses and health care providers. Each health care clearinghouse and health care provider must begin to use the standard specified in Sec. 142.1602 by (24 months after the effective date of the final rule in the Federal Register). Subpart Q--Health Plan Premium Payments Sec. 142.1702 Standard for health plan premium payments. The standard for health plan premium payments that must be used under this subpart is the ASC X12 820--Payment Order/Remittance Advice, (date), Version 4010, Washington Publishing Company, (004010X061). The Director of the Federal Register approves this incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is available at the addresses specified in Sec. 142.108(a) and (c) of this part. Sec. 142.1704 Requirements: Health plans. Each health plan must accept the standard specified in Sec. 142.1702 when accepting electronically transmitted health plan premium payments. Sec. 142.1706 Requirements: Health care clearinghouses. Each health care clearinghouse must use the standard specified in Sec. 142.1702 when accepting or transmitting health plan premium payments. Sec. 142.1708 Effective dates of the initial implementation of the standard for health plan premium payments. (a) Health plans. (1) Each health plan that is not a small health plan must comply with the requirements of Secs. 142.104 and 142.1704 by (24 months after the effective date of the final rule in the Federal Register). (2) Each small health plan must comply with the requirements of Secs. 142.104 and 142.1704 by (36 months after the effective date of the final rule in the Federal Register). (b) Health care clearinghouses. Each health care clearinghouse must begin to the use the standard specified in Sec. 142.1702 by (24 months after the effective date of the final rule in the Federal Register). Subpart R--Referral Certification and Authorization Sec. 142.1802 Referral certification and authorization. The standard for referral certification and authorization transactions that must be used under this subpart is the ASC X12N 278-- Request for Review and Response, (date), Version 4010, Washington Publishing Company, (004010X094). The Director of the Federal Register approves this incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is available at the addresses specified in Sec. 142.108(a) and (c) of this part. Sec. 142.1804 Requirements: Health plans. Each health plan must accept and transmit the standard specified in Sec. 142.1802 when accepting or transmitting referral certifications and authorizations. Sec. 142.1806 Requirements: Health care clearinghouses. Each health care clearinghouse must use the standard specified in Sec. 142.1902 [[Page 25310]] when accepting or transmitting referral certifications and authorizations. Sec. 142.1808 Requirements: Health care providers. Any health care provider that transmits or accepts referral certifications and authorizations electronically must use the standard specified in Sec. 142.1902. Sec. 142.1810 Effective dates of the initial implementation of the standard for referral certifications and authorizations. (a) Health plans. (1) Each health plan that is not a small health plan must comply with the requirements of Secs. 142.104 and 142.1804 by (24 months after the effective date of the final rule in the Federal Register). (2) Each small health plan must comply with the requirements of Secs. 142.104 and 142.1804 by (36 months after the effective date of the final rule in the Federal Register). (b) Health care clearinghouses and health care providers. Each health care clearinghouse and health care provider must begin to use the standard specified in Sec. 142.1802 by (24 months after the effective date of the final rule in the Federal Register). Dated: March 27, 1998. Donna E. Shalala, Secretary. Note: These Addenda will not appear in the Code of Federal Regulations. Addendum 1--Health Claims or Equivalent Encounter Information A. Retail Drug Claim or Equivalent Encounter The transactions selected for retail drug claims are accredited by the American National Standards Institute (ANSI). The transactions are: NCPDP Telecommunications Standard Format version 3.2 and the equivalent NCPDP Batch Standard Version 1.0. 1. Implementation Guide and Source The source of the implementation guide for the NCPDP Telecommunication Standard Format Version 3.2 and the equivalent NCPDP Batch Standard Version 1.0 is the National Council for Prescription Drug Programs, 4201 North 24th Street, Suite 365, Phoenix, AZ, 85016, Telephone 602-957-9105, FAX 602-955-0749. The web site address is http://www.ncpdp.org 2. Data Elements Accumulated Deductible Amount Additional Message Information Adjustment/reject Code--1 Adjustment/reject Code--2 Adjustment/reject Code--3 Alternate Product Code Alternate Product Type Amount Attributed to Sales Tax Amount Billed Amount of Co-pay/co-insurance Amount Rejected Amt. Applied to Periodic Deduct Amt. Attrib. To Prod. Selection Amt. Exceed. Periodic Benefit Max Authorization Number Basis of Cost Determination Basis of Days Supply Determination Basis of Reimb. Determination Batch Number Bin Number Cardholder First Name Cardholder Id Number Cardholder Last Name Carrier Address Carrier Correction Notice Fields Carrier Identification Number Carrier Location City Carrier Location State Carrier Name Carrier Telephone Number Carrier Zip Code Claim Count Claim/reference Id Number Clinic Id Number Co-pay Amount Comments-1 Comments-2 Compound Code Contract Fee Paid Customer Location Date Filled Date of Birth Date of Injury Date Prescription Written Days Supply Destination Name Destination Processor Number Diagnosis Code Diskette Record Id Dispense as Written (Daw) Dispensing Fee Submitted Dollar Count Dollars Adjusted Dollars Billed Dollars Rejected Drug Name Drug Type Dur Conflict Code Dur Intervention Code Dur Outcome Code Dur Response Data Eligibility Clarification Code Employer City Address Employer Contact Name Employer Name Employer Phone Number Employer State Address Employer Street Address Employer Zip Code Fee or Markup Gross Amount Due Group Number Home Plan Host Plan Incentive Amount Submitted Incentive Fee Paid Ingredient Cost Billed Ingredient Cost Paid Ingredient Cost Level of Service Master Sequence Number Message Metric Decimal Quantity Metric Quantity Ndc Number New/refill Code Number of Refills Authorized Other Coverage Code Other Payor Amount Patient City Address Patient First Name Patient Last Name Patient Paid Amount Patient Pay Amount Patient Phone Number Patient Social Security Patient State Address Patient Street Address Patient Zip Code Payment Processor Id Person Code Pharmacy Address Pharmacy Count Pharmacy Location City Pharmacy Location State Pharmacy Name Pharmacy Number Pharmacy Telephone Number Pharmacy Zip Code Plan Identification Postage Amount Claimed Postage Amount Paid Prescriber Id Prescriber Last Name Prescription Denial Clarification Prescription Number Prescription Origin Code Primary Prescriber Prior Authorization/medical Certification Code And Number Processor Address Processor Control Number Processor Location City Processor Location State Processor Name Processor Number Processor Telephone Number Processor Zip Code Record Identifier Reject Code Reject Count Relationship Code Remaining Benefit Amount Remaining Deductible Amount Response Data Response Status Resubmission Cycle Count Run Date Sales Tax Paid Sales Tax Sex Code System Id Terminal Id Third Party Type Total Amount Paid Transaction Code Unit Dose Indicator Usual And Customary Charge Version Release Number B. Professional Health Claim or Equivalent Encounter The transaction selected for the professional (non- institutional) health claim or equivalent encounter information is ASC X12N 837--Health Care Claim: Professional (004010X098) 1. Implementation Guide and Source The source of the implementation guide for the professional health care claim or equivalent encounter is: Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, Telephone 301-590-9337, FAX: 301-869- [[Page 25311]] 9460. The web site address is http://www.wpc-edi.com/hipaa/ 2. Data Elements Accident Date Acute Manifestation Date Additional Submitter or Receiver Name Adjudication or Payment Date Adjusted Repriced Claim Reference Number Adjusted Repriced Line Item Reference Number Adjustment Amount Adjustment Quantity Adjustment Reason Code Agency Qualifier Code Allowed Amount Ambulatory Patient Group Number Amino Acid Name Amount Qualifier Code Anesthesia or Oxygen Minute Count Approved Ambulatory Patient Group Amount Approved Ambulatory Patient Group Code Approved Service Unit Count Arterial Blood Gas Quantity Arterial Blood Gas Test Date Assigned Number Assumed or Relinquished Care Date Attachment Control Number Attachment Description Text Attachment Report Type Code Attachment Transmission Code Auto Accident State or Province Code Benefits Assignment Certification Indicator Billing Provider Additional Name Billing Provider City Name Billing Provider Contact Name Billing Provider Credit Card Identifier Billing Provider First Address Line Billing Provider First Name Billing Provider Identifier Billing Provider Last or Organizational Name Billing Provider Middle Name Billing Provider Name Suffix Billing Provider Postal Zone or ZIP Code Billing Provider Second Address Line Billing Provider State or Province Code Bundled or Unbundled Line Number Certification Form Number Certification Period Projected Visit Count Certified Registered Nurse Anesthetist Supervision Indicator Claim Adjustment Group Code Claim Encounter Identifier Claim Filing Indicator Code Claim Frequency Code Claim Note Text Claim Payment Remark Code Claim Submission Reason Code Clinical Laboratory Improvement Amendment Number Code Category Code List Qualifier Code Coinsurance Amount Communication Number Qualifier Communication Number Complication Indicator Condition Codes Condition Indicator Contact Function Code Contact Inquiry Reference Continuous Passive Motion Date Contract Amount Contract Code Contract Percentage Contract Type Code Contract Version Identifier Country Code Coverage Certification Period Count Creation Date Credit or Debit Card Holder Additional Name Credit or Debit Card Holder First Name Credit or Debit Card Holder Last or Organizational Name Credit or Debit Card Holder Middle Name Credit or Debit Card Holder Name Suffix Credit or Debit Card Maximum Amount Credit or Debit Card Number Credit/Debit Flag Code Currency Code Current Illness or Injury Date CHAMPUS Non-availability Indicator Daily Amino Acid Gram Use Count Daily Amino Acid Prescription Milliliter Use Count Daily Dextrose Prescription Milliliter Use Count Daily Prescribed Nutrient Calorie Count Daily Prescribed Product Calorie Count Date of Surgical Procedure Date Time Period Format Qualifier Date/Time Qualifier Deductible Amount Diagnosis Associated Amount Diagnosis Code Pointer Diagnosis Code Disability Type Code Disability-From Date Disability-To Date Discipline Type Code Drug Formulary Number Drug Unit Price Emergency Indicator Emergency Medical Technician (EMT) or Paramedic First Name Emergency Medical Technician or Paramedic Middle Name Emergency Medical Technician or Paramedic City Name Emergency Medical Technician or Paramedic First Address Line Emergency Medical Technician or Paramedic Last Name Emergency Medical Technician or Paramedic Name Additional Text Emergency Medical Technician or Paramedic Primary Identifier Emergency Medical Technician or Paramedic Second Address Line Emergency Medical Technician or Paramedic Secondary Identifier Emergency Medical Technician or Paramedic State Code Emergency Medical Technician or Paramedic ZIP Code Employment Status Code End Stage Renal Disease Payment Amount Enteral or Parenteral Indicator Entity Identifier Code Entity Type Qualifier Exception Code Exchange Rate Explanation of Benefits Indicator EPSDT Indicator Facility Type Code Family Planning Indicator Feeding Count File Creation Time First Visit Date Fixed Format Information Functional Status Code Group or Policy Number Hierarchical Child Code Hierarchical ID Number Hierarchical Level Code Hierarchical Parent ID Number Hierarchical Structure Code Homebound Indicator Hospice Employed Provider Indicator HCPCS Payable Amount Identification Code Qualifier Immunization Status Code Immunization Type Code Independent Lab Charge Amount Individual Relationship Code Information Release Code Information Release Date Ingredient Cost Claimed Amount Initial Treatment Date Insurance Type Code Insured Employer Additional Name Insured Employer City Name Insured Employer Contact Name Insured Employer First Address Line Insured Employer First Name Insured Employer Identifier Insured Employer Middle Name Insured Employer Name Suffix Insured Employer Name Insured Employer Second Address Line Insured Employer State Code Insured Employer ZIP Code Insured Group Name Insured Group Number Investigational Device Exemption Identifier Laboratory or Facility City Name Laboratory or Facility Contact Name Laboratory or Facility First Address Line Laboratory or Facility Name Additional Text Laboratory or Facility Name Laboratory or Facility Postal ZIP or Zonal Code Laboratory or Facility Primary Identifier Laboratory or Facility Second Address Line Laboratory or Facility Secondary Identifier Laboratory or Facility State or Province Code Last Certification Date Last Menstrual Period Date Last Seen Date Last Worked Date Last X-Ray Date Legal Representative Additional Name Legal Representative City Name Legal Representative First Address Line Legal Representative First Name Legal Representative Last or Organization Name Legal Representative Middle Name Legal Representative Second Address Line Legal Representative State Code Legal Representative Suffix Name Legal Representative ZIP Code Line Item Control Number Line Note Text Mammography Certification Number Measurement Qualifier Measurement Reference Identification Code Medical Justification Text Medical Record Number Medicare Assignment Code Medicare Coverage Indicator Multiple Procedure Indicator National Drug Code National Drug Unit Count Nature of Condition Code Non-Payable Professional Component Billed Amount Non-Visit Code Note Reference Code [[Page 25312]] Nutrient Administration Method Code Nutrient Administration Technique Code Onset Date Ordering Provider City Name Ordering Provider Contact Name Ordering Provider First Address Line Ordering Provider First Name Ordering Provider Identifier Ordering Provider Last Name Ordering Provider Middle Name Ordering Provider Name Additional Text Ordering Provider Name Suffix Ordering Provider Second Address Line Ordering Provider Secondary Identifier Ordering Provider State Code Ordering Provider ZIP Code Original Line Item Reference Number Originator Application Transaction Identifier Other Employer Additional Name Other Employer City Name Other Employer First Address Line Other Employer First Name Other Employer Last or Organization Name Other Employer Middle Name Other Employer Second Address Line Other Employer State Code Other Employer ZIP Code Other Insured Additional Identifier Other Insured Additional Name Other Insured Birth Date Other Insured City Name Other Insured First Address Line Other Insured First Name Other Insured Gender Code Other Insured Identifier Other Insured Last Name Other Insured Middle Name Other Insured Name Suffix Other Insured Plan Name or Program Name Other Insured Second Address Line Other Insured State Code Other Insured ZIP Code Other Payer Additional Name Text Other Payer City Name Other Payer Covered Amount Other Payer Discount Amount Other Payer Federal Mandate Amount Other Payer First Address Line Other Payer Interest Amount Other Payer Last or Organization Name Other Payer Patient Paid Amount Other Payer Patient Responsibility Amount Other Payer Per Day Limit Amount Other Payer Pre-Tax Claim Total Amount Other Payer Primary Identifier Other Payer Second Address Line Other Payer Secondary Identifier Other Payer State Code Other Payer Tax Amount Other Payer ZIP Code Oxygen Saturation Quantity Oxygen Saturation Test Date Paid Service Unit Count Paramedic Contact Name Patient Account Number Patient Additional Name Patient Age Patient Amount Paid Patient Birth Date Patient City Name Patient Death Date Patient Facility Additional Name Text Patient Facility City Name Patient Facility First Address Line Patient Facility Name Patient Facility Second Address Line Patient Facility State Code Patient Facility Zip Code Patient First Address Line Patient First Name Patient Gender Code Patient Height Patient Last Name Patient Marital Status Code Patient Middle Name Patient Name Suffix Patient Primary Identifier Patient Second Address Line Patient Secondary Identifier Patient Signature Source Code Patient State Code Patient ZIP Code Pay-to Provider Additional Name Pay-to Provider City Name Pay-to Provider Contact Name Pay-to Provider First Address Line Pay-to Provider First Name Pay-to Provider Identifier Pay-to Provider Last or Organizational Name Pay-to Provider Middle Name Pay-to Provider Name Suffix Pay-to Provider Second Address Line Pay-to Provider State Code Pay-to Provider ZIP Code Payer Additional Identifier Payer Additional Name Payer City Name Payer First Address Line Payer Identifier Payer Name Payer Paid Amount Payer Responsibility Sequence Number Code Payer Second Address Line Payer State Code Payer ZIP Code Period Count Place of Service Code Policy Compliance Code Postage Claimed Amount Prescription Amino Acid Concentration Percent Prescription Date Prescription Dextrose Concentration Percent Prescription Lipid Concentration Percent Prescription Lipid Milliliter Use Count Prescription Number Prescription Period Count Pricing Methodology Prior Authorization Number Procedure Modifier Product Name Product/Service ID Qualifier Product/Service Procedure Code Prognosis Code Property Casualty Claim Number Provider or Supplier Signature Indicator Provider Code Provider Identifier Provider Organization Code Provider Signature Date Provider Specialty Certification Code Provider Specialty Code Purchase Price Amount Purchase Service Charge Amount Purchase Service Provider Identifier Purchase Service State Code Purchased Service Provider City Name Purchased Service Provider Contact Name Purchased Service Provider First Address Line Purchased Service Provider First Name Purchased Service Provider Last or Organization Name Purchased Service Provider Middle Name Purchased Service Provider Name Additional Text Purchased Service Provider Second Address Line Purchased Service Provider Secondary Identifier Purchased Service Provider State Code Purchased Service Provider ZIP Code Quantity Qualifier Record Format Code Reference Identification Qualifier Referral Number Referring Provider City Name Referring Provider Contact Name Referring Provider First Address Line Referring Provider First Name Referring Provider Identification Number Referring Provider Last Name Referring Provider Middle Name Referring Provider Name Additional Text Referring Provider Name Suffix Referring Provider Second Address Line Referring Provider Secondary Identifier Referring Provider State Code Referring Provider ZIP Code Reimbursement Rate Reject Reason Code Related Hospitalization Admission Date Related Hospitalization Discharge Date Related Nursing Home Admission Date Related-Causes Code Rendering Provider City Name Rendering Provider Contact Name Rendering Provider First Address Line Rendering Provider First Name Rendering Provider Identifier Rendering Provider Last Name Rendering Provider Middle Name Rendering Provider Name Additional Text Rendering Provider Name Suffix Rendering Provider Second Address Line Rendering Provider Secondary Identifier Rendering Provider State Code Rendering Provider ZIP Code Rental Equipment Billing Frequency Code Rental Price Amount Repriced Claim Reference Number Repriced Line Item Reference Number Repricing Organization Identifier Repricing Per Diem or Flat Rate Amount Resource Utilization Group Number Resubmission Number Retirement or Insurance Card Date Review By Code Indicator Sales Tax Amount Sample Selection Modules Saving Amount School City Name School Contact Name School First Address Line School Name Additional Text School Name School Primary Identifier School Second Address Line School State Code School ZIP Code Second Admission Date Second Discharge Date Service Date Service From Date Service Line Paid Amount Service Type Code Service Unit Count Ship/Delivery or Calendar Pattern Code Ship/Delivery Pattern Time Code [[Page 25313]] Shipped Date Similar Illness or Symptom Date Special Program Indicator Statement Covers Period End Date Statement Covers Period Start Date Student Status Code Submittal Date Submitted Charge Amount Submitter or Receiver Address Line Submitter or Receiver City Name Submitter or Receiver Contact Name Submitter or Receiver First Name Submitter or Receiver Identifier Submitter or Receiver Last or Organization Name Submitter or Receiver Middle Name Submitter or Receiver State Code Submitter or Receiver ZIP Code Submitter Additional Name Subscriber or Dependent Death Date Subscriber Additional Identifier Subscriber Birth Date Subscriber Contact Name Subscriber First Name Subscriber Gender Code Subscriber Identifier Subscriber Last Name Subscriber Marital Status Code Subscriber Middle Name Subscriber Name Suffix Subscriber Postal ZIP Code Subscriber Second Address Line Subscriber State Supervising Provider City Name Supervising Provider Contact Name Supervising Provider First Address Line Supervising Provider First Name Supervising Provider Identification Number Supervising Provider Last Name Supervising Provider Middle Name Supervising Provider Name Additional Text Supervising Provider Name Suffix Supervising Provider Second Address Line Supervising Provider Secondary Identifier Supervising Provider State Code Supervising Provider ZIP Code Supporting Document Question Identifier Supporting Document Response Code Surgical Procedure Code Terms Discount Percentage Test Performed Date Test Results Time Period Qualifier Total Claim Charge Amount Total Purchased Service Amount Total Visits Rendered Count Transaction Segment Count Transaction Set Control Number Transaction Set Identifier Code Transaction Set Purpose Code Treatment or Therapy Date Treatment Length Unit or Basis for Measurement Code Value Added Network Trace Number Version Identification Code Version Identifier Weekly Prescription Lipid Use Count Work Return Date X-Ray Availability Indicator Code C. Institutional Claim or Equivalent Encounter The transaction selected for the institutional health care claim or equivalent encounter information is ASC X12N 837--Health Care Claim: Institutional (004010X096). 1. Implementation Guide and Source The source of the implementation guide for the institutional health care claim or equivalent encounter is: Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, Telephone 301-590-9337, FAX: 301-869-9460. The web site address is http://www.wpc-edi.com/hipaa/ 2. Data Elements Activities Permitted Adjusted Repriced Claim Reference Number Adjustment Amount Adjustment Quantity Adjustment Reason Code Admission Date and Hour Admission Source Code Admission Type Code Allowed Amount Amount Qualifier Code Approved Amount Approved Diagnosis Related Group Code Approved HCPCS Code Approved Revenue Code Approved Service Unit Count Assigned Number Attachment Control Number Attachment Description Text Attachment Report Type Code Attachment Transmission Code Attending Physician First Name Attending Physician Last Name Attending Physician Middle Name Attending Physician Primary Identifier Auto Accident State or Province Code Benefits Assignment Certification Indicator Billing Note Text Billing Provider City Name Billing Provider Contact Name Billing Provider First Address Line Billing Provider Identifier Billing Provider Last or Organizational Name Billing Provider Postal Zone or ZIP Code Billing Provider Second Address Line Billing Provider State or Province Code Certification Condition Indicator Certification Type Code Claim Adjustment Group Code Claim Days Count Claim Disproportionate Share Amount Claim DRG Amount Claim DRG Outlier Amount Claim Encounter Identifier Claim ESRD Payment Amount Claim Filing Indicator Code Claim Frequency Code Claim HCPCS payable amount Claim Indirect Teaching Amount Claim MSP Pass-through amount Claim Note Text Claim Original Reference Number Claim Payment Remark Code Claim PPS capital amount Claim PPS capital outlier amount Claim Total Denied Charge Amount Code Associated Amount Code Associated Date Code Associated Quantity Code Category Code List Qualifier Code Contact Function Code Contract Amount Contract Code Contract Percentage Contract Type Code Contract Version Identifier Cost Report Day Count Country Code Covered Days or Visits Count Creation Date Credit or Debit Card Authorization Number Credit or Debit Card Holder First Name Credit or Debit Card Holder Last or Organizational Name Credit or Debit Card Holder Middle Name Credit or Debit Card Maximum Amount Credit or Debit Card Number Currency Code Date Time Period Format Qualifier Date/Time Qualifier Diagnosis Date Discharge Hour Discipline Type Code Document Control Identifier Employer Identification Number Employment Status Code Entity Identifier Code Entity Type Qualifier Estimated Amount Due Estimated Claim Due Amount Exception Code Explanation of Benefits Indicator Facility Code Qualifier Facility Type Code File Creation Time Frequency Number Functional Limitation Code Group or Policy Number Hierarchical Child Code Hierarchical ID Number Hierarchical Level Code Hierarchical Parent ID Number Hierarchical Structure Code Home Health Certification Period HCPCS Modifier Code HCPCS/CPT-4 Code Identification Code Qualifier Implant Date Implant Status Code Implant Type Code Individual Relationship Code Industry Code Information Release Code Insurance Type Code Insured Employer First Address Line Insured Employer First Name Insured Employer Identifier Insured Group Name Insured Group Number Investigational Device Exemption Identifier Last Admission Date Last Visit Date Leads Left In Patient Indicator Legal Representative City Name Legal Representative Contact Name Legal Representative First Address Line Legal Representative First Name Legal Representative Last or Organization Name Legal Representative Middle Name Legal Representative Second Address Line Legal Representative State Code Legal Representative ZIP Code Lifetime Psychiatric Days Count Lifetime Reserve Days Count Line Charge Amount Line Item Denied Charge or Non-Covered Charge Amount Manufacturer Identifier Medicare Coverage Indicator Medicare Paid at 100% Amount [[Page 25314]] Medicare Paid at 80% Amount Mental Status Code Model Number Non-Covered Charge Amount Non-Insured Employer City Name Non-Insured Employer First Address Line Non-Insured Employer First Name Non-Insured Employer Identifier Non-Insured Employer Last or Organization Name Non-Insured Employer Middle Name Non-Insured Employer Second Address Line Non-Insured Employer State Code Non-Insured Employer ZIP Code Note Reference Code Old Capital Amount Operating Physician First Name Operating Physician Last Name Operating Physician Middle Name Operating Physician Primary Identifier Ordering Provider Identifier Ordering Provider Last Name Originator Application Transaction Identifier Other Employer City Name Other Employer First Address Line Other Employer First Name Other Employer Last or Organization Name Other Employer Second Address Line Other Employer Secondary Identifier Other Employer State Code Other Employer ZIP Code Other Insured Additional Identifier Other Insured Birth Date Other Insured City Name Other Insured First Address Line Other Insured First Name Other Insured Gender Code Other Insured Identifier Other Insured Last Name Other Insured Middle Name Other Insured Plan Name or Program Name Other Insured Second Address Line Other Insured State Code Other Insured ZIP Code Other Payer City Name Other Payer First Address Line Other Payer Last or Organization Name Other Payer Patient Paid Amount Other Payer Primary Identifier Other Payer Second Address Line Other Payer Secondary Identifier Other Payer State Code Other Payer ZIP Code Other Physician First Name Other Physician Identifier Other Physician Last Name Other Physician Middle Name Paid From Part A Medicare Trust Fund Amount Paid From Part B Medicare Trust Fund Amount Patient Account Number Patient Amount Paid Patient Birth Date Patient City Name Patient Discharge Facility Type Code Patient First Address Line Patient First Name Patient Gender Code Patient Last Name Patient Liability Amount Patient Marital Status Code Patient Middle Name Patient Name Suffix Patient Primary Identifier Patient Second Address Line Patient Secondary Identifier Patient State Code Patient Status Code Patient ZIP Code Payer Additional Identifier Payer City Name Payer First Address Line Payer Identifier Payer Name Payer Paid Amount Payer Responsibility Sequence Number Code Payer Second Address Line Payer State Code Payer ZIP Code Period Count Physician Contact Date Physician Order Date Policy Compliance Code Pricing Methodology Prior Authorization Number Procedure Modifier Product/Service ID Qualifier Product/Service Procedure Code Professional Component Amount Prognosis Code PPS-Capital DSH DRG Amount PPS-Capital Exception Amount PPS-Capital FSP DRG Amount PPS-Capital HSP DRG Amount PPS-Capital IME amount PPS-Operating Federal Specific DRG Amount PPS-Operating Hospital Specific DRG Amount Quantity Qualifier Reference Identification Qualifier Reimbursement Rate Reject Reason Code Related-Causes Code Repriced Claim Reference Number Repricing Organization Identifier Repricing Per Diem or Flat Rate Amount Returned to Manufacturer Indicator Saving Amount School City Name School First Address Line School Name School Primary Identifier School Second Address Line School State Code School ZIP Code Serial Number Service Date Service From Date Service Line Paid Amount Service Line Rate Service Line Revenue Code Service Unit Count Statement From or To Date Submission or Resubmission Number Submitted Charge Amount Submitter or Receiver Contact Name Submitter or Receiver Identifier Submitter or Receiver Last or Organization Name Subscriber Additional Identifier Subscriber Birth Date Subscriber First Address Line Subscriber First Name Subscriber Gender Code Subscriber Last Name Subscriber Marital Status Code Subscriber Middle Name Subscriber Second Address Line Subscriber State Surgery Date Surgical Procedure Code Terms Discount Percentage Time Period Qualifier Total Claim Charge Amount Total Medicare Paid Amount Total Visits Projected This Certification Count Transaction Segment Count Transaction Set Control Number Transaction Set Identifier Code Transaction Set Purpose Code Unit or Basis for Measurement Code Value Added Network Trace Number Version Identification Code Visits Prior to Recertification Date Count Warranty Expiration Date 1861J1 Facility Indicator D. Dental Claim or Equivalent Encounter The transaction selected for the dental health care claim or equivalent encounter is: ASC X12N 837--Health Care Claim: Dental (004010X097). 1. Implementation Guide and Source The source of the implementation guide for the dental health care claim or equivalent encounter is: Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, Telephone 301-590-9337, FAX: 301-869-9460. The web site address is http://www.wpc-edi.com/hipaa/ 2. Data Elements Accident Date Adjudication or Payment Date Adjustment Amount Adjustment Quantity Adjustment Reason Code Admission Date or Start of Care Date Amount Qualifier Code Anesthesia Unit Count Appliance Placement Date Assigned Number Assistant Surgeon City Name Assistant Surgeon First Address Line Assistant Surgeon First Name Assistant Surgeon Last Name Assistant Surgeon Middle Name Assistant Surgeon Primary Identification Number Assistant Surgeon Second Address Line Assistant Surgeon State Code Assistant Surgeon Suffix Name Assistant Surgeon ZIP Code Attachment Control Number Attachment Report Type Code Attachment Transmission Code Auto Accident State or Province Code Benefits Assignment Certification Indicator Billing Provider City Name Billing Provider Credit Card Identifier Billing Provider First Address Line Billing Provider First Name Billing Provider Identifier Billing Provider Last or Organizational Name Billing Provider Middle Name Billing Provider Name Suffix Billing Provider Postal Zone or ZIP Code Billing Provider Second Address Line Billing Provider State or Province Code Claim Adjustment Group Code Claim Encounter Identifier Claim Filing Indicator Code Claim Submission Reason Code Clinical Laboratory Improvement Amendment Number [[Page 25315]] Code List Qualifier Code Contact Function Code Coordination of Benefits Code Country Code Creation Date Credit or Debit Card Authorization Number Credit or Debit Card Holder First Name Credit or Debit Card Holder Last or Organizational Name Credit or Debit Card Holder Middle Name Credit or Debit Card Holder Name Suffix Credit or Debit Card Maximum Amount Credit or Debit Card Number Credit/Debit Flag Code Currency Code Date Time Period Format Qualifier Date/Time Qualifier Destination Payer Code Diagnosis Code Diagnosis Date Diagnosis Type Code Discharge Date/End Of Care Date Entity Identifier Code Entity Type Qualifier Facility Code Qualifier Facility Type Code File Creation Time Group or Policy Number Hierarchical Child Code Hierarchical ID Number Hierarchical Level Code Hierarchical Parent ID Number Hierarchical Structure Code Identification Code Qualifier Individual Relationship Code Information Release Code Information Release Date Initial Placement Date Insured Employer First Address Line Insured Employer First Name Insured Employer Identifier Insured Employer Middle Name Insured Employer Name Suffix Insured Group Name Insured Group Number Laboratory or Facility City Name Laboratory or Facility First Address Line Laboratory or Facility Name Laboratory or Facility Postal ZIP or Zonal Code Laboratory or Facility Primary Identifier Laboratory or Facility Second Address Line Laboratory or Facility State or Province Code Legal Representative or Responsible Party Identifier Legal Representative City Name Legal Representative First Address Line Legal Representative First Name Legal Representative Last or Organization Name Legal Representative Middle Name Legal Representative Second Address Line Legal Representative State Code Legal Representative Suffix Name Legal Representative ZIP Code Line Charge Amount Medicare Assignment Code Oral Cavity Designation Code Originator Application Transaction Identifier Orthodontic Treatment Months Count Orthodontic Treatment Months Remaining Count Other Insured Birth Date Other Insured City Name Other Insured First Address Line Other Insured First Name Other Insured Gender Code Other Insured Identifier Other Insured Last Name Other Insured Middle Name Other Insured Name Suffix Other Insured Second Address Line Other Insured State Code Other Insured ZIP Code Other Payer Covered Amount Other Payer Discount Amount Other Payer Last or Organization Name Other Payer Patient Paid Amount Other Payer Patient Responsibility Amount Other Payer Primary Identifier Patient Account Number Patient Amount Paid Patient Birth Date Patient City Name Patient First Address Line Patient First Name Patient Gender Code Patient Last Name Patient Marital Status Code Patient Middle Name Patient Name Suffix Patient Primary Identifier Patient Second Address Line Patient Signature Source Code Patient State Code Patient ZIP Code Pay-to-Provider City Name Pay-to-Provider First Address Line Pay-to-Provider First Name Pay-to-Provider Identifier Pay-to-Provider Last or Organizational Name Pay-to-Provider Middle Name Pay-to-Provider Name Suffix Pay-to-Provider Second Address Line Pay-to-Provider State Code Pay-to-Provider ZIP Code Payer Additional Identifier Payer City Name Payer First Address Line Payer Identifier Payer Name Payer Paid Amount Payer Responsibility Sequence Number Code Payer Second Address Line Payer State Code Payer ZIP Code Periodontal Charting Measurement Policy Name Predetermination of Benefits Identifier Predetermination of Benefits Indicator Prior Authorization Number Prior Placement Date Procedure Count Procedure Modifier Product/Service ID Qualifier Product/Service Procedure Code Prothesis, Crown or Inlay Code Provider or Supplier Signature Indicator Provider Signature Date Quantity Qualifier Reference Identification Qualifier Referring Provider City Name Referring Provider First Address Line Referring Provider First Name Referring Provider Identification Number Referring Provider Last Name Referring Provider Middle Name Referring Provider Name Suffix Referring Provider Second Address Line Referring Provider State Code Referring Provider ZIP Code Related-Causes Code Rendering Provider City Name Rendering Provider First Address Line Rendering Provider First Name Rendering Provider Identifier Rendering Provider Last Name Rendering Provider Middle Name Rendering Provider Name Suffix Rendering Provider Second Address Line Rendering Provider State Code Rendering Provider ZIP Code Replacement Date Retirement or Insurance Card Date School City Name School First Address Line School Name School Primary Identifier School Second Address Line School State Code School ZIP Code Service Date Service Line Paid Amount Student Status Code Submitter or Receiver Address Line Submitter or Receiver City Name Submitter or Receiver Contact Name Submitter or Receiver First Name Submitter or Receiver Identifier Submitter or Receiver Last or Organization Name Submitter or Receiver Middle Name Submitter or Receiver State Code Submitter or Receiver ZIP Code Subscriber Birth Date Subscriber First Address Line Subscriber First Name Subscriber Gender Code Subscriber Identifier Subscriber Last Name Subscriber Marital Status Code Subscriber Middle Name Subscriber Name Suffix Subscriber Postal ZIP Code Subscriber Second Address Line Subscriber State Title XIX Identification Number Tooth Code Tooth Number Tooth Status Code Tooth Surface Total Claim Charge Amount Transaction Segment Count Transaction Set Control Number Transaction Set Identifier Code Transaction Set Purpose Code Unit or Basis for Measurement Code Addendum 2--Health Care Payment and Remittance Advice The transaction selected for the health care payment and remittance advice is ASC X12N 835--Health Care Claim Payment/Advice (004010X091). A. Implementation Guide and Source The source of the implementation guide for the ASC X12N 835-- Health Care Claim Payment/Advice (004010X091) is: Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, Telephone 301-590-9337, FAX: 301-869-9460. The website address is http://www.wpc-edi.com/hipaa/ B. Data Elements Account Number Qualifier Additional Payee Identifier [[Page 25316]] Adjustment Amount Adjustment Quantity Adjustment Reason Code Amount Paid to Patient Amount Qualifier Code Assigned Number Average DRG length of stay Average DRG weight Century Check or EFT Trace Number Check/EFT Issue Date Claim Adjustment Group Code Claim Contact Communications Number Claim Contact Name Claim Date Claim Disproportionate Share Amount Claim ESRD Payment Amount Claim Filing Indicator Code Claim Frequency Code Claim HCPCS payable amount Claim Indirect Teaching Amount Claim MSP Pass-through amount Claim Payment Remark Code Claim PPS capital amount Claim PPS capital outlier amount Claim Status Code Claim Supplemental Information Amount Claim Supplemental Information Quantity Code List Qualifier Code Communication Number Extension Communication Number Qualifier Contact Function Code Corrected Insured Identification Indicator Corrected Patient or Insured First Name Corrected Patient or Insured Last Name Corrected Patient or Insured Middle Name Corrected Patient or Insured Name Prefix Corrected Patient or Insured Name Suffix Corrected Priority Payer Identification Number Corrected Priority Payer Name Cost Report Day Count Covered Days or Visits Count Credit/Debit Flag Code Crossover Carrier Identifier Crossover Carrier Name Currency Code Date/Time Qualifier Depository Financial Institution (DFI) Identifier Depository Financial Institution (DFI) ID Number Qualifier Description Text Diagnosis Related Group (DRG) Weight Diagnosis Related Group (DRG) Discharge Fraction Entity Identifier Code Entity Type Qualifier Exchange Rate Facility Type Code Fiscal Period Date Identification Code Qualifier Lifetime Psychiatric Days Count Line Item Provider Payment Amount Location Identification Code Location Qualifier National Uniform Billing Committee Revenue Code Old Capital Amount Original Service Unit Count Originating Company Supplemental Code Other Claim Related Identifier Patient Control Number Patient First Name Patient Last Name Patient Liability Amount Patient Middle Name Patient Name Prefix Patient Name Suffix Patient Status Code Payee City Name Payee First Line Address Payee Identification Code Payee Name Payee Postal Zip Code Payee Second Line Address Payee State Code Payer City Name Payer Claim Control Number Payer Contact Communication Number Payer Contact Name Payer First Address Line Payer Identifier Payer Name Payer Process Date Payer Second Address Line Payer State Code Payer ZIP Code Payment Format Code Payment Method Code Procedure Modifier Product/Service ID Qualifier Product/Service Procedure Code Text Product/Service Procedure Code Production Date Professional Component Amount Provider Adjustment Amount Provider Adjustment Identifier Provider First Name Provider Identifier Provider Last or Organization Name Provider Middle Name Provider Name Prefix Provider Name Suffix PPS-Capital DSH DRG Amount PPS-Capital Exception Amount PPS-Capital FSP DRG Amount PPS-Capital HSP DRG Amount PPS-Capital IME amount PPS-Operating Federal Specific DRG Amount PPS-Operating Hospital Specific DRG Amount Quantity Qualifier Receiver or Provider Account Number Receiver Identifier Receiver/Provider Bank ID Number Reference Identification Qualifier Reimbursement Rate Remark Code Sender Account Number Sender DFI Identifier Service Date Service Supplemental Amount Service Supplemental Quantity Count Submitted Charge Amount Submitted Line Charges Paid Subscriber First Name Subscriber Identifier Subscriber Last Name Subscriber Middle Name Subscriber Name Prefix Subscriber Name Suffix Total Actual Provider Payment Amount Total Blood Deductible Total Capital Amount Total Claim Charge Amount Total Claim Count Total Coinsurance Amount Total Contractual Adjustment Amount Total Cost Outlier Amount Total Cost Report Day Count Total Covered Charge Amount Total Covered Day Count Total Day Outlier Amount Total Deductible Amount Total Denied Charge Amount Total Discharge Count Total Disp. Share Amount Total DRG Amount Total Federal-Specific Amount Total Gramm-Rudman Reduction Amount Total Hospital-Specific Amount Total HCPCS Payable Amount Total HCPCS Reported Charge Amount Total Indirect Medical Education Amount Total Interest Amount Total MSP Pass-Through Amount Total MSP Patient Liability Met Amount Total MSP Payer Amount Total Non-Covered Charge Amount Total Non-Lab Charge Amount Total Noncovered Charge Amount Total Noncovered Day Count Total Outlier Day Count Total Patient Reimbursement Amount Total Professional Component Amount Total Provider Payment Amount Total PIP Adjustment Amount Total PIP Claim Count Total PPS Capital FSP DRG Amount Total PPS Capital HSP DRG Amount Total PPS DSH DRG Amount Trace Type Code Transaction Handling Code Transaction Segment Count Transaction Set Control Number Transaction Set Identifier Code Units of Service Paid Count Version Identifier Addendum 3--Coordination of Benefits A. Professional Claim Coordination of Benefits The transaction selected for the professional claim coordination of benefits is ASC X12N 837--Health Care Claim: Professional (004010X098). 1. Implementation Guide and Source The source of the implementation guide for the professional claim coordination of benefits transaction set is: Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, Telephone 301-590-9337, FAX: 301-869-9460. The web site address is http://www.wpc-edi.com/hipaa/ 2. Data Elements Data elements are found in addendum 1, B.2. B. Institutional Claim Coordination of Benefits The transaction selected for the institutional claim coordination of benefits is ASC X12N 837--Health Care Claim: Institutional (004010X096). 1. Implementation Guide and Source The source of the implementation guide for the institutional claim coordination of benefits transaction set is: Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, Telephone 301-590-9337, FAX: 301-869-9460. The web site address is http://www.wpc-edi.com/hipaa/ [[Page 25317]] 2. Data Elements Data elements are found in Addendum 1, C.2. C. Dental Claim Coordination of Benefits The transaction selected for the dental claim coordination of benefits is ASC X12N 837--Health Care Claim: Dental (004010X097). 1. Implementation Guide and Source The source of implementation guide for the dental claim coordination of benefits transaction set is: Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, Telephone 301-590-9337, FAX: 301-869-9460. The web site address is http://www.wpc-edi.com/hipaa/ 2. Data Elements See Addendum 1, D.2. D. Retail Drug Claim Coordination of Benefits The transactions selected for retail drug coordination of benefits is NCPDP Telecommunications Standard Format version 3.2 and the equivalent NCPDP Batch Standard Version 1.0. 1. Implementation Guide and Source The source of implementation guide for the retail drug claim coordination of benefits transaction set is: National Council for Prescription Drug Programs, 4201 North 24th Street, Suite 365, Phoenix, AZ, 85016, Telephone 602-957-9105, FAX 602-955-0749. The web site address is http://www.ncpdp.org 2. Data Elements See Addendum 1, A.2. Addendum 4--Health Claim Status The transaction selected for the health claim status is ASC X12N 276/277--Health Care Claim Status Request and Response (004010X093). A. Implementation Guide and Source The source of the implementation guide for the health claim status transaction set is: Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, Telephone 301-590- 9337, FAX: 301-869-9460. The website address is http://www.wpc- edi.com/hipaa/ B. Data Elements Adjudication or Payment Date Amount Qualifier Code Bill Type Identifier Check or EFT Trace Number Check/EFT Issue Date Claim Payment Amount Claim Service Period Creation Date Date Time Period Format Qualifier Date/Time Qualifier Entity Identifier Code Entity Type Qualifier Extra Narrative Data Health Care Claim Status Category Code Health Care Claim Status Code Hierarchical Child Code Hierarchical ID Number Hierarchical Level Code Hierarchical Parent ID Number Hierarchical Structure Code Identification Code Qualifier Information Receiver Additional Address Information Receiver Address Information Receiver City Information Receiver First Name Information Receiver Identification Number Information Receiver Last or Organization Name Information Receiver Middle Name Information Receiver Name Prefix Information Receiver Name Suffix Information Receiver Specific Location Information Receiver State Information Receiver ZIP Code Line Charge Amount Line Item Control Number Line Item Service Date Location Qualifier Original Service Unit Count Originator Application Transaction Identifier Patient Control Number Patient First Name Patient Last Name Patient Middle Name Patient Name Prefix Patient Name Suffix Payer City Name Payer Claim Control Number Payer First Address Line Payer Identifier Payer Name Payer Second Address Line Payer State Code Payer ZIP Code Payment Method Code Procedure Modifier Product/Service ID Qualifier Provider First Name Provider Identifier Provider Last or Organization Name Provider Middle Name Provider Name Prefix Provider Name Suffix Reference Identification Qualifier Revenue Code Service Identification Code Service Line Date Service Unit Count Status Information Effective Date Subscriber Birth Date Subscriber City Subscriber First Address Line Subscriber First Name Subscriber Gender Code Subscriber Identifier Subscriber Last Name Subscriber Middle Name Subscriber Name Prefix Subscriber Name Suffix Subscriber Postal ZIP Code Subscriber Second Address Line Subscriber State Total Claim Charge Amount Trace Type Code Transaction Segment Count Transaction Set Control Number Transaction Set Identifier Code Transaction Set Purpose Code Transaction Type Code [Direct Comments to Judy Ball, Enrollment and Eligibility IT] Addendum 5--Benefit Enrollment and Maintenance The transaction selected for benefit enrollment and maintenance is ASC X12N 834--Benefit Enrollment and Maintenance Transaction Set (004010X095). A. Implementation Guide and Source The source of the implementation guide for the benefit enrollment and maintenance transaction set is: Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, Telephone 301-590-9337, FAX: 301-869-9460. The web site address is http://www.wpc-edi.com/hipaa/ B. Data Elements Label--name of elements Account Address Information Account City Name Account Communication Number Account Contact Inquiry Reference Number Account Contact Name Account Country Code Account Effective Date Account Identification Code Account Monetary Amount Account Number Qualifier Account Postal ZIP Code Account State Code Action Code Additional Account Identifier Additional Other Coverage Identifier Adjustment Amount Adjustment Reason Code Characteristic Adjustment Reason Code Amount Qualifier Code Assigned Number Benefit Account Number Benefit Status Code Birth Sequence Number Card Count Citizenship Status Code Code List Qualifier Code Communication Number Qualifier Communication Number Consolidated Omnibus Budget Reconciliation Act (COBRA) Qualifying Event Code Contact Function Code Contact Inquiry Reference Coordination of Benefits Code Coordination of Benefits Date Country Code Coverage Level Code Creation Date Credit/Debit Flag Code Current Health Condition Code Date Time Period Format Qualifier Date/Time Qualifier Dependent Employer Identification Code Dependent Employer Name Dependent Employment Date Dependent School Date Dependent School Identification Code Dependent School Name Description Text Diagnosis Code Disability Eligibility Date Disability Maximum Entitlement Amount Disability Type Code Employment Status Code Enrollment Control Total Entity Identifier Code Entity Relationship Code Entity Type Qualifier File Creation Time First Diagnosed Date Frequency Code Gender Code Group or Policy Number [[Page 25318]] Health Coverage Eligibility Date Health-Related Code Identification Card Type Code Identification Code Qualifier Individual Relationship Code Industry Code Insurance Eligibility Date Insurance Group Number Insurance Line Code Insurer Contact Inquiry Reference Insurer Contact Name Insurer Contact Number Insurer Entity Relationship Code Insurer Identification Code Insurer Name Issuing State Last Visit Reason Text Late Reason Code Location Qualifier Maintenance Reason Code Maintenance Type Code Marital Status Code Master Policy Number Medicare Plan Code Member Additional Address Member City Name Member Contact Name Member Postal Code Member State or Province Code Monetary Amount Occupation Code Other Insurance Company Identification Code Other Insurance Company Name Payer Responsibility Sequence Number Code Plan Coverage Description Text Policy Name Pre-disability Work Days Count Premium Contribution Amount Previous Transaction Identifier Primary Insured Collateral Dependent Count Primary Insured Sponsored Dependent Count Product Option Code Product/Service ID Qualifier Provider Code Provider Communications Number Provider Contact Inquiry Reference Provider Contact Name Provider Eligibility Date Provider First Name Provider Identifier Provider Last or Organization Name Provider Middle Name Provider Name Prefix Provider Name Suffix Quantity Count Quantity Qualifier Race or Ethnicity Code Reference Identification Qualifier Sponsor Additional Name Sponsor City Name Sponsor Contact Name Sponsor Country Code Sponsor Identifier Sponsor Name Sponsor State Code Sponsor Street Address Sponsor Zip Code Student Status Code Subscriber or Dependent Death Date Subscriber Additional Identifier Subscriber Birth Date Subscriber City Subscriber County Code Subscriber Current Weight Subscriber First Address Line Subscriber First Name Subscriber Height Subscriber Identifier Subscriber Last Name Subscriber Middle Name Subscriber Name Prefix Subscriber Name Suffix Subscriber Postal ZIP Code Subscriber Previous Weight Subscriber Second Address Line Subscriber State Time Zone Code Transaction Segment Count Transaction Set Control Number Transaction Set Identifier Code Transaction Set Purpose Code TPA or Broker Account Address TPA or Broker Account Amount TPA or Broker Account City Name TPA or Broker Account Contact Communication Number TPA or Broker Account Contact Inquiry Reference TPA or Broker Account Contact Name TPA or Broker Account Number TPA or Broker Account Postal Code TPA or Broker Account State or Province Code TPA or Broker Additional Account Reference Identification Number TPA or Broker Additional Name TPA or Broker Communication Number TPA or Broker Contact Inquiry Reference Number TPA or Broker Country Code TPA or Broker Identification Code TPA or Broker Name TPA or Broker State Code Underwriting Decision Code Version Identification Code Weight Change Text Work Intensity Code Yes/No Condition or Response Code Addendum 6--Eligibility for a Health Plan The transaction selected for the eligibility for a health plan is ASC X12N 270/271--Health Care Eligibility Inquiry and Response (004010X092). A. Implementation Guide and Source The source of the implementation guide for eligibility for a health plan transaction set is: Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, Telephone 301- 590-9337, FAX: 301-869-9460. The website address is http://www.wpc- edi.com/hipaa/ B. Data Elements Labels Agency Qualifier Code Amount Qualifier Code Authorization Indicator Code Benefit Coverage Level Code Benefit Used or Available Amount Birth Sequence Number Communication Number Qualifier Communication Number Contact Function Code Country Code Coverage Level Code Creation Date Date Time Period Format Qualifier Date/Time Qualifier Dependent Additional Identification Text Dependent Additional Identifier Dependent Benefit Date Dependent Birth Date Dependent City Name Dependent Communications Number Dependent Contact Name Dependent First Line Address Dependent First Name Dependent Gender Code Dependent Identification Code Dependent Last Name Dependent Middle Name Dependent Name Suffix Dependent Postal Zip Code Dependent Second Line Address Dependent State Code Dependent Trace Number Description Text Eligibility or Benefit Amount Eligibility or Benefit Information Eligibility or Benefit Percent Entity Identifier Code Entity Type Qualifier File Creation Time Follow-up Action Code Free-Form Message Text Handicap Indicator Code Hierarchical Child Code Hierarchical ID Number Hierarchical Level Code Hierarchical Parent ID Number Hierarchical Structure Code Identification Code Qualifier Individual Relationship Code Information Receiver Additional Address Information Receiver Additional Identifier Information Receiver Address Information Receiver City Information Receiver Contact Name Information Receiver First Name Information Receiver Identification Number Information Receiver Last or Organization Name Information Receiver Middle Name Information Receiver Name Suffix Information Receiver State Information Receiver Trace Number Information Receiver ZIP Code Information Source Contact Name Information Source Process Date Insurance Eligibility Date Insurance Type Code Insured Indicator Location Identification Code Location Qualifier Loop Identifier Code Maintenance Reason Code Maintenance Type Code Network Services Code Originating Company Identifier Originating Company Secondary Identifier Period Count Plan Coverage Description Text Plan Sponsor Name Printer Carriage Control Code Prior Authorization Number Prior Authorization Text Procedure Coding Method Procedure Modifier Product/Service ID Qualifier Provider Address 1 Provider Address 2 Provider City Provider Code Provider Contact Name Provider Contact Number Provider First Name [[Page 25319]] Provider Identifier Provider Last or Organization Name Provider Middle Name Provider Name Suffix Provider Specialty Certification Code Provider Specialty Code Provider State Provider Zip Quantity Qualifier Receiver Additional Identifier Description Text Receiver Additional Identifier Receiver Provider Additional Identifier Type Code Receiver Provider Additional Identifier Receiver Trace Number Reference Identification Qualifier Reject Reason Code Relationship To Insured Code Sample Selection Modulus Service Type Code Service Unit Count Ship/Delivery or Calendar Pattern Code Ship/Delivery Pattern Time Code Source Additional Reference Identifier Source City Name Source Organization Name Source Postal Zip Code Source Primary Identification Number Source State Code Source Street Address Spend Down Amount Student Status Code Subscriber Additional Identifier Subscriber Additional Information Text Subscriber Benefit Date Subscriber Birth Date Subscriber Card Issue Date Subscriber City Subscriber Contact Name Subscriber Contact Phone Number Subscriber First Address Line Subscriber First Name Subscriber Gender Code Subscriber Identifier Subscriber Last Name Subscriber Middle Name Subscriber Name Suffix Subscriber Postal ZIP Code Subscriber Second Address Line Subscriber State Time Period Qualifier Trace Assigning Entity Additional Number Trace Assigning Entity Number Trace Number Trace Type Code Transaction Segment Count Transaction Set Control Number Transaction Set Identifier Code Transaction Set Purpose Code Transaction Type Code Unit or Basis for Measurement Code Valid Request Indicator Code Value Added Network Trace Number Addendum 7--Health Plan Premium Payment The transaction selected for the health plan premium payment is ASC X12N 820--Payment Order/Remittance Advice Transaction Set (004010X061). A. Implementation Guide and Source The source of the implementation guide for the health plan premium payment transaction set is: Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, Telephone 301-590-9337, FAX: 301-869-9460. The website address is http:// www.wpc-edi.com/hipaa/ B. Data Elements Account Number Qualifier Adjustment Reason Code Assigned Number Billed Premium Amount Contact Function Code Contract or Invoice or Account Number Country Code Coverage Period Date Credit/Debit Flag Code Currency Code Date Time Period Format Qualifier Date/Time Qualifier Depository Financial Institution (DFI) Identifier Depository Financial Institution (DFI) ID Number Qualifier Employee Identification Number Entity Identifier Code Exchange Rate Funds Issued Date Head Count Identification Code Qualifier Individual Identifier Information Only Indicator Code Information Receiver City Information Receiver Last or Organization Name Information Receiver State Information Receiver ZIP Code Insurance Policy or Plan Identifier Line Item Control Number Organization Premium Identification Code Originating Company Identifier Originating Company Supplemental Code Payer Additional Name Payer City Name Payer Contact Name Payer Identifier Payer Name Payer Process Date Payer Second Address Line Payer State Code Payer ZIP Code Payment Action Code Payment Format Code Payment Method Code Payroll Processor Additional Name Payroll Processor City Name Payroll Processor Contact Name Payroll Processor First Address Line Payroll Processor Identifier Payroll Processor Name Payroll Processor Second Address Line Payroll Processor State Code Payroll Processor ZIP Code Policy Level Individual Name Premium Delivery Date Premium Payment Amount Premium Receiver First Address Line Premium Receiver Reference Identifier Premium Receiver Second Address Line Receiver Account Number Receiver Additional Name Receiver Identifier Reference Identification Qualifier Sender Account Number Trace Number Trace Type Code Transaction Handling Code Transaction Segment Count Transaction Set Control Number Transaction Set Identifier Code Unit or Basis for Measurement Code Addendum 8--Referral Certification and Authority The transaction selected for the referral certification and authority is ASC X12N 278--Health Care Services Review Information (004010X094). A. Implementation Guide and Source The source of the implementation guide for the referral certification and authority is: Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, Telephone 301- 590-9337, FAX: 301-869-9460. The website address is http://www.wpc- edi.com/hipaa/ B. Data Elements Action Code Admission Source Code Admission Type Code Agency Qualifier Code Ambulance Transport Code Ambulance Transport Reason Code Ambulance Trip Destination Address Ambulance Trip Origin Address Arterial Blood Gas Quantity Certification Condition Indicator Certification Expiration Date Certification Number Certification Type Code Chiropractic Series Treatment Number Citizenship Status Code Code Category Code List Qualifier Code Communication Number Qualifier Complication Indicator Condition Codes Contact Function Code Country Code Creation Date Current Health Condition Code Daily Oxygen Use Count Date Time Period Format Qualifier Date/Time Qualifier Delay Reason Code Dependent Additional Identification Text Dependent Additional Identifier Dependent Birth Date Dependent Citizenship Country Code Dependent First Name Dependent Gender Code Dependent Identification Code Dependent Last Name Dependent Marital Status Code Dependent Middle Name Dependent Name Prefix Dependent Name Suffix Dependent Trace Number Diagnosis Code Diagnosis Date Diagnosis Type Code Entity Identifier Code Entity Type Qualifier Equipment Reason Description Facility Code Qualifier Facility Type Code File Creation Time Follow-up Action Code Free-Form Message Text Full Destination Address Full Origin Address Hierarchical Child Code Hierarchical ID Number [[Page 25320]] Hierarchical Level Code Hierarchical Parent ID Number Hierarchical Structure Code Home Health Certification Period Identification Code Qualifier Information Release Code Insured Indicator Last Admission Date Last Visit Date Level of Service Code Medicare Coverage Indicator Monthly Treatment Count Nature of Condition Code Nursing Home Residential Status Code Originator Application Transaction Identifier Oxygen Delivery System Code Oxygen Equipment Type Code Oxygen Flow Rate Oxygen Saturation Quantity Oxygen Test Condition Code Oxygen Test Findings Code Oxygen Use Period Hour Count Patient Condition Description Text Patient Discharge Facility Type Code Patient Status Code Patient Weight Period Count Physician Contact Date Physician Order Date Portable Oxygen System Flow Rate Previous Certification Identifier Procedure Date Procedure Monetary Amount Procedure Quantity Product/Service ID Qualifier Product/Service Procedure Code Text Product/Service Procedure Code Prognosis Code Proposed Admission Date Proposed Discharge Date Proposed Surgery Date Provider Code Provider Contact Name Provider Identifier Provider Service State Code Provider Specialty Certification Code Provider Specialty Code Quantity Qualifier Race or Ethnicity Code Reference Identification Qualifier Reject Reason Code Related-Causes Code Relationship To Insured Code Request Category Code Requester Address First Address Line Requester Address Second Address Line Requester City Name Requester Contact Communication Number Requester Contact Name Requester Country Code Requester First Name Requester Identifier Requester Last or Organization Name Requester Middle Name Requester Name Prefix Requester Name Suffix Requester Postal Code Requester State or Province Code Requester Supplemental Identifier Respiratory Therapist Order Text Round Trip Purpose Description Text Sample Selection Modulus Second Surgical Opinion Indicator Service Authorization Date Service From Date Service Provider City Name Service Provider Contact Communication Number Service Provider Country Code Service Provider First Address Line Service Provider First Name Service Provider Identifier Service Provider Last or Organization Name Service Provider Middle Name Service Provider Name Prefix Service Provider Name Suffix Service Provider Postal Code Service Provider Second Address Line Service Provider State or Province Code Service Provider Supplemental Identifier Service Trace Number Service Type Code Service Unit Count Ship/Delivery or Calendar Pattern Code State Code Stretcher Purpose Description Text Subluxation Level Code Subscriber Additional Identifier Subscriber Additional Information Text Subscriber Birth Date Subscriber Citizenship Country Code Subscriber First Name Subscriber Gender Code Subscriber Identifier Subscriber Last Name Subscriber Marital Status Code Subscriber Middle Name Subscriber Name Prefix Subscriber Name Suffix Subscriber Trace Number Surgery Date Surgical Procedure Code Time Period Qualifier Trace Type Code Transaction Segment Count Transaction Set Control Number Transaction Set Identifier Code Transaction Set Purpose Code Transaction Type Code Transport Distance Treatment Count Treatment Period Count Treatment Series Number Unit or Basis for Measurement Code Utilization Management Organization (UMO) or Last Name Utilization Management Organization (UMO) First Address Line Utilization Management Organization (UMO) First Name Utilization Management Organization (UMO) Middle Name Utilization Management Organization (UMO) Name Prefix Utilization Management Organization (UMO) Name Suffix Utilization Management Organization (UMO) Second Address Line Utilization Managment Organization (UMO) City Name Utilization Managment Organization (UMO) Contact Communication Number Utilization Managment Organization (UMO) Contact Name Utilization Managment Organization (UMO) Country Code Utilization Managment Organization (UMO) Identifier Utilization Managment Organization (UMO) Postal Code Utilization Managment Organization (UMO) State or Province Code Valid Request Indicator Code Version/Release/Industry Identifier X-Ray Availability Indicator Code 1861J1 Facility Indicator [FR Doc. 98-11691 Filed 5-1-98; 9:04 am] BILLING CODE 4120-01-P