department of health and human services - aspe · 50312 federal register/vol. 65, no. 160/thursday,...

Thursday,

August 17, 2000

Part III

Department ofHealth and HumanServicesOffice of the SecretaryHealth Care Financing Administration

45 CFR Parts 160 and 162Health Insurance Reform: Standards forElectronic Transactions; Announcement ofDesignated Standard MaintenanceOrganizations; Final Rule and Notice

VerDate 11<MAY>2000 18:28 Aug 16, 2000 Jkt 190000 PO 00000 Frm 00001 Fmt 4717 Sfmt 4717 E:\FR\FM\17AUR2.SGM pfrm03 PsN: 17AUR2

50312 Federal Register / Vol. 65, No. 160 / Thursday, August 17, 2000 / Rules and Regulations

DEPARTMENT OF HEALTH ANDHUMAN SERVICES

Office of the Secretary

45 CFR Parts 160 and 162

[HCFA–0149–F]

RIN 0938–AI58

Health Insurance Reform: Standardsfor Electronic Transactions

AGENCY: Office of the Secretary, HHS.ACTION: Final rule.

SUMMARY: This rule adopts standards foreight electronic transactions and forcode sets to be used in thosetransactions. It also containsrequirements concerning the use ofthese standards by health plans, healthcare clearinghouses, and certain healthcare providers.

The use of these standard transactionsand code sets will improve the Medicareand Medicaid programs and otherFederal health programs and privatehealth programs, and the effectivenessand efficiency of the health careindustry in general, by simplifying theadministration of the system andenabling the efficient electronictransmission of certain healthinformation. It implements some of therequirements of the AdministrativeSimplification subtitle of the HealthInsurance Portability andAccountability Act of 1996.DATES: The effective date of this rule isOctober 16, 2000. The incorporation byreference of certain publications listedin this rule is approved by the Directorof the Federal Register as of October 16,2000.FOR FURTHER INFORMATION CONTACT: PatBrooks, (410) 786–5318, for medicaldiagnosis, procedure, and clinical codesets.

Joy Glass, (410) 786–6125, for thefollowing transactions: health claims orequivalent encounter information;health care payment and remittanceadvice; coordination of benefits; andhealth claim status.

Marilyn Abramovitz, (410) 786–5939,for the following transactions:enrollment and disenrollment in ahealth plan; eligibility for a health plan;health plan premium payments; andreferral certification and authorization.SUPPLEMENTARY INFORMATION:

Availability of Copies

To order copies of the FederalRegister containing this document, sendyour request to: New Orders,Superintendent of Documents, P.O. Box371954, Pittsburgh, PA 15250–7954.

Specify the date of the issue requestedand enclose a check or money orderpayable to the Superintendent ofDocuments, or enclose your Visa orMaster Card number and expirationdate. Credit card orders can also beplaced by calling the order desk at (202)512–1800 or by faxing to (202) 512–2250. The cost for each copy is $8. Asan alternative, you can view andphotocopy the Federal Registerdocument at most libraries designatedas Federal Depository Libraries and atmany other public and academiclibraries throughout the country thatreceive the Federal Register. You mayalso obtain a copy from the followingweb sites: http://www.access.gpo.gov/su—docs/aces/aces140.html; http://aspe.hhs.gov/admnsimp/.

I. Background

A. Electronic Data Interchange

Electronic data interchange (EDI) isthe electronic transfer of information,such as electronic media health claims,in a standard format between tradingpartners. EDI allows entities within thehealth care system to exchange medical,billing, and other information and toprocess transactions in a manner whichis fast and cost effective. With EDI thereis a substantial reduction in handlingand processing time compared to paper,and the risk of lost paper documents iseliminated. EDI can eliminate theinefficiencies of handling paperdocuments, which will significantlyreduce administrative burden, loweroperating costs, and improve overalldata quality.

The health care industry recognizesthe benefits of EDI and many entities inthat industry have developedproprietary EDI formats. Currently, thereare about 400 formats for electronichealth claims being used in the UnitedStates. The lack of standardizationmakes it difficult and expensive todevelop and maintain software.Moreover, the lack of standardizationminimizes the ability of health careproviders and health plans to achieveefficiency and savings.

B. Statutory Background

The Congress included provisions toaddress the need for standards forelectronic transactions and otheradministrative simplification issues inthe Health Insurance Portability andAccountability Act of 1996 (HIPAA),Public Law 104–191, which was enactedon August 21, 1996. Through subtitle Fof title II of that law, the Congress addedto title XI of the Social Security Act anew part C, entitled ‘‘AdministrativeSimplification.’’ (Public Law 104–191

affects several titles in the United StatesCode. Hereafter, we refer to the SocialSecurity Act as the Act; we refer to theother laws cited in this document bytheir names.) The purpose of this part isto improve the Medicare program undertitle XVIII of the Social Security Act andthe Medicaid program under title XIX ofthe Act, and the efficiency andeffectiveness of the health care system,by encouraging the development of ahealth information system through theestablishment of standards andrequirements to enable the electronicexchange of certain health information.

Part C of title XI consists of sections1171 through 1179 of the Act. Thesesections define various terms andimpose several requirements on HHS,health plans, health care clearinghouses,and certain health care providers.

The first section, section 1171 of theAct, establishes definitions for purposesof part C of title XI for the followingterms: code set, health careclearinghouse, health care provider,health information, health plan,indiyvidually identifiable healthinformation, standard, and standardsetting organization (SSO).

Section 1172 of the Act makes anystandard adopted under part Capplicable to (1) all health plans, (2) allhealth care clearinghouses, and (3) anyhealth care provider who transmits anyhealth information in electronic form inconnection with transactions referred toin section 1173(a)(1) of the Act.

This section also containsrequirements concerning standardsetting.

• The Secretary may adopt a standarddeveloped, adopted, or modified by astandard setting organization (that is, anorganization accredited by the AmericanNational Standards Institute (ANSI))that has consulted with the NationalUniform Billing Committee (NUBC), theNational Uniform Claim Committee(NUCC), the Workgroup for ElectronicData Interchange (WEDI), and theAmerican Dental Association (ADA).

• The Secretary may also adopt astandard other than one established bya standard setting organization, if thedifferent standard will reduce costs forhealth care providers and health plans,the different standard is promulgatedthrough negotiated rulemakingprocedures, and the Secretary consultswith each of the above-named groups.

• If no standard has been adopted byany standard setting organization, theSecretary is to rely on therecommendations of the NationalCommittee on Vital and HealthStatistics (NCVHS) and consult with theabove-named groups before adopting astandard.


50313Federal Register / Vol. 65, No. 160 / Thursday, August 17, 2000 / Rules and Regulations

• In complying with the requirementsof part C of title XI, the Secretary mustrely on the recommendations of theNCVHS, consult with appropriate Stateand Federal agencies and privateorganizations, and publish therecommendations of the NCVHSregarding the adoption of a standardunder this part in the Federal Register.

Paragraph (a) of section 1173 of theAct requires that the Secretary adoptstandards for financial andadministrative transactions, and dataelements for those transactions, toenable health information to beexchanged electronically. Standards arerequired for the following transactions:health care claims or equivalentencounter information, health claimsattachments, health plan enrollmentsand disenrollments, health planeligibility, health care payment andremittance advice, health plan premiumpayments, first report of injury, healthcare claim status, and referralcertification and authorization. Section1173(a)(1)(B) authorizes the Secretary toadopt standards for any other financialand administrative transactions as shedetermines appropriate.

Paragraph (b) of section 1173 of theAct requires the Secretary to adoptstandards for unique health identifiersfor each individual, employer, healthplan, and health care provider. It alsorequires that the adopted standardsspecify for what purposes unique healthidentifiers may be used.

Paragraphs (c) through (f) of section1173 of the Act require the Secretary toadopt standards for code sets for eachdata element for each health caretransaction listed above, securitystandards to protect health careinformation, standards for electronicsignatures (established together with theSecretary of Commerce), and standardsfor the transmission of data elementsneeded for the coordination of benefitsand sequential processing of claims.Compliance with electronic signaturestandards will be deemed to satisfy bothState and Federal statutory requirementsfor written signatures with respect to thetransactions listed in paragraph (a) ofsection 1173 of the Act.

In section 1174 of the Act, theSecretary is required to adopt standardsfor all of the above transactions, exceptclaims attachments, within 18 monthsafter enactment. The standards forclaims attachments must be adoptedwithin 30 months after enactment.Modifications to any establishedstandard may be made after the firstyear, but not more frequently than onceevery 12 months. The Secretary may,however, modify an initial standard atany time during the first year of

adoption, if she determines that themodification is necessary to permitcompliance with the standard. TheSecretary must also ensure thatprocedures exist for the routinemaintenance, testing, enhancement, andexpansion of code sets and that there arecrosswalks from prior versions. Anymodification to a code set must beimplemented in a manner thatminimizes the disruption and the cost ofcompliance.

Section 1175 of the Act prohibitshealth plans from refusing to conduct atransaction as a standard transaction. Italso prohibits health plans fromdelaying the processing of, or adverselyaffecting or attempting to adverselyaffect, a person submitting a standardtransaction or the transaction itself onthe grounds that the transaction is instandard format. It establishes atimetable for compliance: each person towhom a standard or implementationspecification applies is required tocomply with the standard no later than24 months (or 36 months for smallhealth plans) following its adoption.With respect to modifications tostandards or implementationspecifications made after initialadoption, compliance must beaccomplished by a date designated bythe Secretary. This date may not beearlier than 180 days after themodification is adopted by theSecretary.

Section 1176 of the Act establishescivil monetary penalties for violation ofthe provisions in part C of title XI of theAct, subject to several limitations.Penalties may not be more than $100per person per violation of a provision,and not more than $25,000 per personper violation of an identical requirementor prohibition for a calendar year. Withcertain exceptions, the proceduralprovisions in section 1128A of the Act,‘‘Civil Monetary Penalties,’’ areapplicable to imposition of thesepenalties.

Section 1177 of the Act establishedpenalties for any person that knowinglymisuses a unique health identifier, orobtains or discloses individuallyidentifiable health information inviolation of this part. The penaltiesinclude: (1) A fine of not more than$50,000 and/or imprisonment of notmore than 1 year; (2) if the offense is‘‘under false pretenses,’’ a fine of notmore than $100,000 and/orimprisonment of not more than 5 years;and (3) if the offense is with intent tosell, transfer, or use individuallyidentifiable health information forcommercial advantage, personal gain, ormalicious harm, a fine of not more than$250,000 and/or imprisonment of not

more than 10 years. We note that thesepenalties do not affect any otherpenalties that may be imposed by otherfederal programs.

Under section 1178 of the Act, theprovisions of part C of title XI of theAct, as well as any standards orimplementation specifications adoptedunder them, generally supersedecontrary provisions of State law.However, the Secretary may makeexceptions to this general rule if shedetermines that the provision of Statelaw is necessary to prevent fraud andabuse, ensure appropriate Stateregulation of insurance and healthplans, or for State reporting on healthcare delivery or costs, among otherthings. In addition, contrary State lawsrelating to the privacy of individuallyidentifiable health information are notpreempted if more stringent than therelated federal requirements. Finally,contrary State laws relating to certainactivities with respect to public healthand regulation of health plans are notpreempted by the standards adoptedunder Part C or section 264 of PublicLaw 104–191.

Finally, section 1179 of the Act makesthe above provisions inapplicable tofinancial institutions or anyone actingon behalf of a financial institution when‘‘authorizing, processing, clearing,settling, billing, transferring,reconciling, or collecting payments for afinancial institution.’’

II. General Overview of the Provisionsof the Proposed Rule

On May 7, 1998, we proposedstandards for eight transactions (we didnot propose a standard for either healthclaims attachments or first report ofinjury) and for code sets to be used inthe transactions (63 FR 25272). Inaddition, we proposed requirementsconcerning the implementation of thesestandards. This proposed rule set forthrequirements that health plans, healthcare clearinghouses, and certain healthcare providers would have to meetconcerning the use of these standards.

We proposed to add a new part 142to title 45 of the Code of FederalRegulations to include requirements forhealth plans, certain health careproviders, and health careclearinghouses to implement HIPAAadministrative simplificationprovisions. This material has beenrestructured to accommodate HIPAAprivacy and security provisions, and isnow contained in parts 160 and 162 oftitle 45. Subpart A of part 160 containsthe general provisions for all parts.Subpart I of part 162 contains thegeneral provisions for the standardsproposed in the Standards for Electronic



Transactions proposed rule. Subparts Jthrough R contain the provisionsspecific to each of the standardsproposed in the Standards for ElectronicTransactions proposed rule.

III. Analysis of, and Responses to,Public Comments on the Proposed Rule

In response to the publication in theFederal Register of the proposed rule onMay 7, 1998, we received approximately17,000 timely public comments. Thecomments came from a wide variety ofcorrespondents including professionalassociations and societies, health careworkers, law firms, third party healthinsurers, hospitals, and privateindividuals. We reviewed eachcommenter’s letter and grouped like orrelated comments. Some commentswere identical, indicating that thecommenters had submitted form letters.After associating like comments, weplaced them in categories based onsubject matter or based on the section(s)of the regulations affected and thenreviewed the comments. All commentsrelating to general subjects, such as theformat of the regulations were similarlyreviewed.

This process identified areas of theproposed regulation that requiredreview in terms of their effect on policy,consistency, or clarity of the rules.

We present comments and responsesgenerally in the order in which theissues appeared in the May 1998proposed rule.

General—Comment Period

Comment: We received severalcomments that stated the 60-daycomment period was too short. It wasstated that the period did not take intoaccount the highly detailed, technicalreview of the thousands of pages in theimplementation specifications that wasrequired in order to comment in ameaningful way.

Response: We disagree. Weunderstand the difficulty in reviewing arule of this complexity. However, wemet our notice requirements for thelength of the comment period and madeevery effort to ensure that the proposedrule was readily accessible to the public(for example, the proposed rule waspublished in the Federal Register andavailable over the Internet). In addition,we received many comments requestingchanges to the implementationspecifications, which indicates that themajority of interested parties were ableto review all implementationspecifications in the 60-day period. Ifadditional changes are necessary,revisions may be made to the standardson an annual basis.

A. ApplicabilityIn subpart A § 142.102 we listed the

entities that would be subject to theprovisions and we discussed underwhat circumstances they would apply.

Below we discuss the commentsconcerning applicability.

Comments and Responses on theApplicability of the Regulations

1. Electronically TransmittingTransactions

Proposal Summary: Our proposedrules apply to health plans and healthcare clearinghouses, as well as anyhealth care provider when transmittingan electronic transaction defined inSubpart A of 45 CFR Part 142.

Comment: Several commentersrequested clarification on theapplicability provisions. For example,several commenters questioned whethera health plan would be required toaccept or send a standard that it doesnot currently support electronically.Some commenters believe the languageallows any entity to submit a standardtransaction and expect it to be processedby the receiver even though they do nothave a business relationship with eachother.

Response: Under the terms of section1172(a) of the Act, these regulationsapply to health plans, health careclearinghouses, and health careproviders who transmit any healthinformation in electronic form inconnection with a transaction referredto in section 1173(a) of the Act (in otherwords, ‘‘covered entities’’). We interpretthis provision to mean that by theapplicable compliance dates of theregulation, all covered entities mustcomply with the standards adopted bythis regulation. (Covered entities, ofcourse, may comply before theapplicable compliance dates.) We do nothave the authority to apply thesestandards to any entity that is not acovered entity. However, we requirecovered entities to apply many of theprovisions of the rule to the entitieswith whom they contract foradministrative and other servicesrelated to the transactions, as it wouldbe inconsistent with the underlyingstatutory purpose to permit coveredentities to avoid the Act’s requirementsby the simple act of contracting outcertain otherwise covered functions.

With respect to health plans, a healthplan is required to have the capacity toaccept and/or send (either itself, or byhiring a health care clearinghouse toaccept and/or send on its behalf) astandard transaction that it otherwiseconducts but does not currently supportelectronically. For example, if a health

plan pays claims electronically buthistorically performed enrollment anddisenrollment functions in paper, thehealth plan must have the capacity toelectronically perform enrollment anddisenrollment as well as claimspayment as standard transactions by theapplicable compliance date of theregulation.

Also, in response to the public’s needfor clarification of the applicability ofthe HIPAA administrative simplificationprovisions (45 CFR subtitle A,subchapter C) to covered entities, werevisited the applicability provisionwith respect to health care providers. Inthe proposed rule, we proposed that theadministrative simplification provisionswould apply to a health care providerwhen transmitting an electronictransaction (63 FR 25305). (We note thatthis language differed somewhat fromthe statute, which states that the HIPAAadministrative simplification provisionsapply to ‘‘a health care provider whotransmits any health information inelectronic form in connection with atransaction’’ referred to in subchapterC.)

We phrased the applicability sectionin the proposed rule as we did in aneffort to convey the message that theseregulations do not require a health careprovider to transmit transactionselectronically; thus, a health careprovider remains free to use papermedia. These regulations do require,however, that a health care providerwho uses electronic media to transmitany health information in connectionwith a transaction referred to in 45 CFRsubtitle A, subchapter C, must do so incompliance with the regulations. We donot believe that the proposedapplicability language as it applied tohealth care providers adequatelycommunicated this message. Thus, afterreevaluating the proposed approach, webelieve that the best approach is to havethe applicability text mirror the statuteand use § 162.923 (Requirements forCovered Entities) as the vehicle to detailthe specific requirements for coveredhealth care providers.

In addition, we provide the followingas examples of types of health careprovider behavior that are permissibleunder the regulations. For instance, ahealth care provider may send anelectronic health care claim orequivalent encounter informationstandard transaction for Patient A tohealth plan Z, and may send a paperclaim for Patient B to health plan Z. Ahealth care provider may also send anelectronic health care claim orequivalent encounter informationstandard transaction to health plan S



and then send paper claims to healthplan T.

In regard to the second comment,while we interpret HIPAA to mean thata health plan cannot refuse to conducta transaction because it is a standardtransaction, we do not believe that useof standard transactions can create arelationship or liability that does notexist. For example, a health plan cannotrefuse to accept a claim from a healthcare provider because the health careprovider electronically submits thestandard transaction. However, thehealth plan is not required to pay theclaim merely because the health careprovider submitted it in standardformat, if other business reasons existfor denying the claim (for example, theservice for which the claim is beingsubmitted is not covered). This ruledoes not require a health care providerto send or accept an electronictransaction.

2. Various TechnologiesProposal Summary: Entities that offer

on-line interactive transmission of thetransactions described in section1173(a)(2) of the Act, would have tocomply with the standards (63 FR25276). For example, the HypertextMarkup Language (HTML) interactionbetween a server and a browser bywhich the data elements of a transactionare solicited from a user would not haveto use the standards, although the datacontent must be equal to that requiredfor the standard. Once the data elementsare assembled into a transaction by theserver, the transmitted transactionwould have to comply with thestandards.

a. Comment: Several commentsrecommended that electronictransmissions should be classified as‘‘computer to computer without humaninteraction’’ (i.e., batch and fast batchtransmissions) and be subject to thenational standards. They alsorecommended that transmissionsinvolving browser to server (Internet,Extranet, HTML, Java, ActiveX, etc.),direct data entry terminals (dumbterminals), PC terminal emulators, pointof service terminals (devices similar infunction to credit card terminals),telephone voice response systems,‘‘faxback’’ systems, and any real-timetransactions where data elements aredirectly solicited from a human user, beclassified as ‘‘person to computer’’transmissions. Moreover, ‘‘person tocomputer’’ transmissions should besupplemental to the national standards,but the data content of thesetransmissions should comply with theHIPAA electronic standards as theyapply to data content.

Several commenters questionedwhether HIPAA requires a health planto support ‘‘person to computer’’methods. Several commenters suggestedthat we should only except HTML websites from the transaction standards ifthe web browser is used in HTMLpassive mode without plug-ins orprogrammable extensions and that theresponse times must be the same orfaster than that of the HIPAA electronicstandards.

Commenters also recommended thatwe permit the use of a proprietaryformat for web-based transactions if thetransactions are sent to an entity’s in-house system for processing, and theentity’s web browser is under thecontrol of a back-end processor, as wellas part of the same corporate entity, anddoes not serve other back-endprocessors. They recommended that theHIPAA standards be used if thetransactions are sent externally (outsideof that entity’s system) for processing,and the entity’s web browser is under acontract with a back-end processor thatis not under the same corporate control,and that serves more than one back-endprocessor.

Response: We are pleased thatcommenters support the use of thenational standards for electronictransactions since this outcome isrequired by section 1173 of the Act. Foreach designated transaction, thesestandards specify the format, the dataelements required or permitted tostructure the format, and the datacontent permitted for each of the dataelements, including designated codesets where applicable.

Certain technologies present a specialcase for the use of standard transactions.We proposed that telephone voiceresponse, ‘‘faxback’’, and Hyper TextMarkup Language (HTML) interactionswould not be required to follow thestandard. We have since reevaluatedthis position in light of the manycomments on this position and ondevelopments in the EDI industry whichcontinue to expand the options in thisarea. We have decided that, instead ofcreating an exception for thesetransmissions, we will recognize thatthere are certain transmission modes inwhich use of the format portion of thestandard is inappropriate. However, thetransaction must conform to the datacontent portion of the standard. The‘‘direct data entry’’ process, using dumbterminals or computer browser screens,where the data is directly keyed by ahealth care provider into a health plan’scomputer, would not have to use theformat portion of the standard, but thedata content must conform. If the datais directly entered into a system that is

outside of the health plan’s system, tobe transmitted later to the health plan,the transaction must be sent using thefull standard (format and content). Wehave included this clarification in§ 162.923 (Requirements for CoveredEntities).

3. Atypical ServicesProposal Summary: Transactions for

certain services that are not normallyconsidered health care services, butwhich may be covered by some healthplans, would not be subject to thestandards (63 FR 25276). These serviceswould include, but not be limited to:nonemergency transportation, physicalalterations to living quarters for thepurpose of accommodating disabilities,and case management. Other servicesmay be added to this list at thediscretion of the Secretary.

Comment: We received commentsboth for and against subjectingtransactions for certain services to thetransaction standards. Somecommenters recommended that anyservice that could be billed to a healthplan be required to comply with thestandards in order to avoid the need tomaintain alternate systems. However,other commenters argued that certainMedicaid services are not insured byany other program, thus, use of thestandard is unnecessary.

Several commenters supported notsubjecting these services to thestandard, except for case management,arguing that a more precise definition ofcase management needs to bedeveloped. Other commenters statedthat case management is considered ahealth care service by many healthplans and health care providers, andreported using standard codes.

We received suggestions foradditional services that should not besubject to the standards. Suggestionsincluded home and community basedwaiver services provided under theMedicaid program and abbreviatedtransactions between State agencies, forexample, claims between a State healthservice and a State Medicaid agency.

Response: We agree with commentersthat case management is a health careservice since it is directly related to thehealth of an individual and is furnishedby health care providers. Casemanagement will, therefore, be subjectto the standards.

We recognize that the health careclaim and equivalent encounterinformation standard, with itssupporting implementationspecification, is capable of supportingclaims for atypical services. However,requiring all services potentially paidfor by health plans to be billed using the



standards would lead to taxi drivers,auto mechanics and carpenters to beregulated as health care providers.Instead, we will use our definition of‘‘health care’’ found at 160.103 todetermine whether a particular serviceis a ‘‘health care’’ service or not.Services that are not health care servicesor supplies under this definition are notrequired to be claimed using thestandard transactions. Thus, claims fornon-emergency transportation orcarpentry services for housingmodifications, if submittedelectronically, would not be required tobe conducted as standard transactions.As noted above, the standards dosupport such claims and a health planmay choose to require its atypicalservice providers to use the standardsfor its own business purposes.

Those atypical services that meet thedefinition of health care, however, mustbe billed using the standard if they aresubmitted electronically. If there are nospecific codes for billing a particularservice (for example, there is not yet anapproved code set for billing foralternative therapies), or if the standardtransactions do not readily support aparticular method of presenting anatypical service (for example, rosterbilling for providing immunizations foran entire school or nursing facility), thehealth care service providers are urgedto work with the appropriate DesignatedStandard Maintenance Organizations(DSMOs) to develop modifications tothe standard and implementationspecifications. (See ‘‘I. New and RevisedStandards’’ in this section of thepreamble for a discussion of theDSMOs.)

We disagree with the proposal thathome and community based waiverservices should have a blanketexemption from the administrativesimplification standards. First, Congressexplicitly included the Medicaidprograms as health plans that are subjectto the administrative simplificationstandards. Second, these waiverprograms commonly pay for a mix ofhealth care and non-health careservices. State Medicaid agencies withhome and community based waivers arenot exempt from these standards fortransactions relating to health careservices or supplies.

4. Conducting the TransactionsProposal Summary: If a person

conducts a transaction (as defined in§ 160.103) with a health plan as astandard transaction, the followingapply:

(1) The health plan may not refuse toconduct the transaction as a standardtransaction.

(2) The health plan may not delay thetransaction or otherwise adverselyaffect, or attempt to adversely affect, theperson or the transaction on the groundthat the transaction is a standardtransaction.

Comment: Some commentersquestioned what was meant by ‘‘delay’’of a standard transaction. Theyquestioned what methods (i.e., batch,online, etc.) a health plan must provideto support receipt and submission ofstandard transactions. The proposedrule did not define the term ‘‘delay’’ norspecify the time frame within which ahealth plan is required to act when itreceives a standard transaction.

Several commenters recommendedthe rule encompass all entities thatmight be conducting an electronictransaction with a health plan and thatthere be further clarification of what anunreasonable delay would be. It wasalso recommended that the regulationshould apply to a health care provider,not a person that conducts an‘‘electronic’’ transaction.

Response: Section 1175 of the Actprohibits a health plan from delaying astandard transaction, or otherwiseadversely affecting, or attempting toadversely affect any person desiring toconduct a transaction referred to in§ 1173 (a)(1) of the Social Security Actor the transaction on the ground that thetransaction is a standard transaction. Weinterpret this provision to mean thatthere should be no degradation in thetransmission of, receipt of, processingof, and response to a standardtransaction solely because thetransaction is a standard transaction.Thus, health plans must processstandard transactions from any person,including, but not limited to, coveredentities, in the same time frame inwhich they processed transactions priorto implementation of HIPAA. They alsomay not provide incentives that willdiscourage (i.e., adversely affect) the useof standard transactions.

In § 162.923 we have includedrequirements for all covered entities andin § 162.925 we have providedadditional requirements for healthplans.

5. Role of Health Care ClearinghousesProposal Summary: Health care

clearinghouses would be able to acceptnonstandard transactions for the solepurpose of translating them intostandard transactions for sendingcustomers and would be able to acceptstandard transactions and translate theminto nonstandard formats for receivingcustomers (63 FR 25276).

Comment: Several commentersbelieve health care clearinghouses are

excepted from accepting the standards.Other commenters believe that allowinghealth care providers to use a healthcare clearinghouse will negateadministrative simplification. There wasalso concern that entities may designatethemselves as a health careclearinghouse to avoid compliance.

Several commenters also requestedthat we clarify who is responsible forhealth care clearinghouse costs and statethat contracts cannot require health careproviders to use nonstandard formats.

Response: First, we clarify that ahealth care clearinghouse is a coveredentity and must comply with theserules. Accordingly, all transactionscovered by this part between health careclearinghouses must be conducted asstandard transactions. However, thestatute permits a covered entity tosubmit nonstandard communications toa health care clearinghouse forprocessing into standard transactionsand transmission by the health careclearinghouse as well as receivestandard transactions through the healthcare clearinghouse.

If a covered entity (for example, ahealth care provider) uses a health careclearinghouse to submit and receivenonstandard/standard transactions, thehealth care clearinghouse is the coveredentity’s business associate. If a healthplan operates as a health careclearinghouse, or requires the use of ahealth care clearinghouse, a health careprovider may submit standardtransactions to that health plan throughthe health care clearinghouse. However,the health care provider must not beadversely affected, financially orotherwise, by doing so. (For example,the costs of submitting a standardtransaction to a health plan’s health careclearinghouse must not be in excess ofthe costs of submitting a standardtransaction directly to the health plan.)

In § 162.915, we clarify what a tradingpartner agreement that a covered entityenters into may not do. Section 162.923specifies that a covered entityconducting a transaction covered underthis rule with another covered entity (orwithin the same covered entity) usingelectronic media must conduct thetransaction as standard transaction, withan exception for direct data entry.Section 162.925 makes it clear that ahealth plan may not offer an incentivefor a health care provider to conduct atransaction covered by this part underthe direct data entry exception.

6. Exception for Transmissions withinCorporate Entities

Proposal Summary: Transmissionswithin a corporate entity would not be



required to comply with the standards(63 FR 25276).

Comment: We received manycomments regarding exceptingtransmissions within corporateboundaries and the examples weprovided. The comments can besummarized by three questions: (1)What constitutes a ‘‘corporate entity’’and ‘‘internal’’ communications; (2) canthe ‘‘internal umbrella’’ cover thetransactions among ‘‘corporate’’ entities;and (3) why should Governmentagencies be excepted from meeting thestandards?

Some commenters attempted todetermine the circumstances underwhich compliance with the standardscan be avoided. Generally, thesecommenters indicated a desire for a verybroad definition of ‘‘corporate entity.’’Some commenters reflected a desire toseverely restrict the boundaries oreliminate them altogether. Othercommenters asked if particular kinds ofdata or transactions are required inparticular situations.

Response: We proposed to create anexception for transactions within acorporate entity to minimize burden.However, after considering publiccomment, and further analyzing theimplications of the proposed exception,we have decided not to create anexception for standard transactionswithin a ‘‘corporate entity.’’ First, wehave not been able to define ‘‘corporateentity’’ so that the exception would notdefeat the rule. The rapid pace ofmergers, acquisitions, and dissolutionsin the corporate health care worldwould make such an exceptionextremely difficult to implement.Equally important, the proposedexception would not have promoted theuse of the standard transactions at thehealth care provider and health planlevel. Each health care provider that isowned by or under contract to one ormore health plans could be required touse the ‘‘in-house’’ or ‘‘non-standard’’transactions favored by each healthplan, thus negating the benefits of theuse of the standards. Finally, ourdecision to not adopt a corporate entityexception does not impose an additionalburden on health plans, because healthplans already are required to have thecapacity to accept standard transactionsfrom any person. Thus, the fundamentalpolicy is that covered entities must usea standard transaction whentransmitting a transaction covered bythis part with another covered entity (orwithin the same covered entity)electronically, regardless of whether thetransmission is inside or outside theentity.

We have decided to clarify thedescription of each transaction to helpcovered entities determine when thestandards must be used. A transaction isnow defined in § 160.103 as theexchange of data for one of theenumerated specific purposes. Insubparts K through R of part 162, wedescribe each transaction in specific,functional terms. For example, one typeof health care claims or equivalentencounter information transaction is theexchange of information between ahealth care provider and a health planabout services provided to a patient toobtain payment; one type of eligibilityfor a health plan transaction is theexchange of information between ahealth provider and a health plan todetermine whether a patient is eligiblefor services under that health plan. Datasubmissions or exchanges for purposesother than those designated in thisregulation are not transactions andtherefore do not require use of thestandards.

Transactions may be used by bothcovered entities and other entities. Forexample, the enrollment anddisenrollment in a health plantransaction is most commonly sent byemployers or unions, which are notcovered entities, to health plans, whichare covered entities. The employer maychoose to send the transactionelectronically in either standard or non-standard format. The health plan,however, must conduct the transactionas a standard transaction whenconducting the transactionelectronically with another coveredentity, with another part of itself, orwhen requested to do so by any otherentity. Moreover, if an employer orother non-covered entity desires to senda transaction as a standard transaction,the health plan may not delay oradversely affect either the sender or thetransaction. It is expected that thisprovision will encourage non-coveredentities that conduct the designatedtransactions with more than one healthplan to conduct these transactions asstandard transactions.

In general, if a covered entityconducts, using electronic media, atransaction adopted under this part withanother covered entity (or within thesame covered entity), it must conductthe transaction as a standardtransaction. If any entity (covered or notcovered) requests a health plan toconduct a transaction as a standardtransaction, the health plan mustcomply. We have provided examplesbelow to assist in determining when atransaction must be conducted as astandard transaction.

Example 1: Corporation K operates ahealth plan that is a covered entity underthese rules. Corporation K owns a hospitalwhich provides care to patients withcoverage under Corporation K’s health planand also provides care to patients withcoverage under other health plans. Corporaterules require the hospital to send encounterinformation electronically to Corporation Kidentifying the patients covered by thecorporate plan and served by the hospital.

(A) Must the transmission of encounterdata comply with the standards? Both thehealth plan and the hospital are coveredentities. The hospital is a covered entitybecause it is conducting covered transactionselectronically in compliance with itscorporate rules. The electronic submission ofencounter data satisfies the definition of thehealth care claims or equivalent encounterinformation transaction designated as astandard transaction (see § 162.1101(b)).Therefore, the submission of this encounterdata therefore must be a standard transaction.

(B) Must the payments and remittanceadvices sent from Corporation K’s healthplan to the hospital be conducted as standardtransactions? Corporation K’s health plan iscovered by the definition of ‘‘health plan,’’the hospital is a covered entity, and thetransmission of health care payments andremittance advices is within the scope of thedesignated transactions (see § 162.1601). Thehealth care payments and remittance advicesmust be sent as standard transactions.

Example 2: A large multi-state employerprovides health benefits on a self-insuredbasis, thereby establishing a health plan. Thehealth plan contracts with insurancecompanies in seven states to function as thirdparty administrators to process itsemployees’ health claims in each of thosestates. The employer’s health plan contractswith a data service company to hold thehealth eligibility information on all itsemployees. Each of the insurance companiessends eligibility inquiries to the data servicecompany to verify the eligibility of specificemployees upon receipt of claims for servicesprovided to those employees or theirdependents.

(A) Are these eligibility inquiries activitiesthat must be conducted as standardtransactions? In this case, each insurancecompany is not a covered entity in its ownright because it is functioning as a third partyadministrator, which is not a covered entity.However, as a third party administrator(TPA), it is the business associate of acovered entity (the health plan) performing afunction for that entity; therefore, assumingthat the covered entity is in compliance, theTPA would be required to follow the samerules that are applicable to the covered entityif the covered entity performed the functionsitself. The definition for the eligibility for ahealth plan transaction is an inquiry from ahealth care provider to a health plan, or fromone health plan to another health plan, todetermine the eligibility, coverage, orbenefits associated with a health plan for asubscriber. In this case, the inquiry is fromone business associate of that health plan toanother business associate of that samehealth plan. Therefore, the inquiry does notmeet the definition of an eligibility for a



health plan transaction, and is not requiredto be conducted as a standard transaction.

(B) Is an electronic eligibility inquiry froma health care provider to the data servicecompany, to determine whether anemployee-patient may receive a particularservice, required to be a standardtransaction? The health care provider is acovered entity, because it conducts coveredelectronic transactions. The data servicecompany is the business associate of theemployer health plan performing a planfunction. Therefore, the activity meets thedefinition of the eligibility for a health plantransaction, and both the inquiry and theresponse must be standard transactions.

Example 3: A pharmacy (a health careprovider) contracts with a pharmacy benefitsmanager (PBM) to forward its claimselectronically to health plan Z. Under thecontract, the PBM also receives health carepayment and remittance advice from healthplan Z and forwards them to the pharmacy.

(A) Must the submission of claims bestandard transactions? The pharmacy is acovered entity electronically submitting, tocovered entity health plan Z, health careclaims or equivalent encounter information,which are designated transactions (see§ 162.1101), through a business associate, thePBM. The claims must be submitted asstandard transactions.

(B) Must the explanation of benefits andremittance advice information be sent as astandard transaction? Health plan Z and thehealth care provider are covered entitiesconducting one of the designatedtransactions (see § 162.1601). Thistransaction, therefore, must be conducted asa standard transaction.

Example 4: A State Medicaid plan entersinto a contract with a managed careorganization (MCO) to provide services toMedicaid recipients. That organization inturn contracts with different health careproviders to render the services.

(A) When a health care provider submits aclaim or encounter information electronicallyto the MCO, is this activity required to be astandard transaction? The entity submittingthe information is a health care provider,covered by this rule, and the MCO meets ourdefinition of health plan. The activity is ahealth care claims or equivalent encounterinformation transaction designated in thisregulation. The transaction must be astandard transaction.

(B) The managed care organization thensubmits a bill to the State Medicaid agencyfor payment for all the care given to all thepersons covered by that MCO for that monthunder a capitation agreement. Is this astandard transaction? The MCO is a healthplan under the definition of ‘‘health plan’’ in§ 160.103. The State Medicaid agency is alsoa covered entity as a health plan. Theactivity, however, does not meet thedefinition of a health care claims orequivalent encounter informationtransaction. It does not need to be a standardtransaction.

However, note that the health planpremium payment transaction from the StateMedicaid agency to the health plan wouldhave to be conducted as a standardtransaction because the State Medicaid

agency is a covered entity sending thetransaction to another covered entity (thehealth plan), and the transaction meets thedefinition of health plan premium payment.

7. Applicability to Paper Transactionsand Other Entities

Proposal Summary: Although thereare situations in which the use of thestandards is not required (for example,health care providers may continue tosubmit paper claims and employers andother noncovered entities are notrequired to use any of the standardtransactions), we stressed that astandard may be used voluntarily in anysituation in which it is not required (63FR 25276).

a. Comment: The majority ofcommenters suggested that thetransaction standards and their codessets, in some manner, apply to papertransactions. They suggested that therequired data elements in the standardtransactions also be required for papertransactions and that any requiredidentifiers also be required for use onpaper transactions.

The commenters stated that therecould be two consequences if the samedata were not required on paper andelectronic transactions. First, healthplans would have to maintain twosystems: one for the processing ofelectronic claims; and one for theprocessing of paper claims. The sameargument was also applied toidentifiers—it was argued that healthplans would need to maintain two setsof identifiers: one for paper claims; andone for electronic claims. Second, manyhealth care providers would revert topaper claims if the data requirementswere less restrictive than those forelectronic claims.

Response: These are powerfularguments from a cost benefitstandpoint. While the HIPAA statuteprovides the Secretary with theauthority to declare these standardsapplicable to all transactions, includingthose on paper, we chose at this pointto focus on standards for electronictransactions. Most of the paper formscurrently in use today cannotaccommodate all of the data contentincluded in the standard transactions.This does not prevent health plans fromrequiring the same data, includingidentifiers for paper transactions as isrequired by the HIPAA regulations withrespect to electronic transactions.

b. Comment: Several commentersrecommended that employers/sponsorswho perform EDI should be required touse the standards because they play acritical role in the overalladministration of health care. Theseentities are the major users of the

enrollment and disenrollment in ahealth plan transactions, and are oftenmajor payers of health premiums.

Response: The administrativesimplification provisions of HIPAA donot require noncovered entities to usethe standards, but noncovered entitiesare encouraged to do so in order toachieve the benefits available from suchuse. For example, employers andsponsors play a key role in theadministrative functions of health care,e.g. the enrollment and disenrollment ofindividuals in health plans. But becausethe legislation does not specificallyrequire employers /sponsors to use thetransaction standards, we are notextending the requirement to them inthe regulation. Health plans are,however, free to negotiate tradingpartner agreements with employers andsponsors that require the use of standardtransactions.

8. Exceptions for State Law (Section1178)

Proposal Summary: The proposedrule did not propose preemptionrequirements in the regulation text anddid not directly request comments onthe preemption issue. However, it didset forth a summary of the preemptionprovision of the Act, section 1178, and,therefore, raised the issue for publiccomment (63 FR 25274). In response, wereceived a number of commentsregarding the preemption issue, andrequesting guidance on how preemptionquestions will be resolved.

Comment: Many commentersrecommended the exception for Statelaw process be delineated or clarified inthe final rule. Many commenters statedthat exceptions in general should not begranted, saying that this is contrary tothe idea of national standards. Othercommenters stated exceptions should bediscouraged.

Response: The statute clearly statesthat the Secretary may grant exceptionsin certain circumstances. The proposedrule regarding Standards for Privacy forIndividually Identifiable HealthInformation, published in the FederalRegister on November 3, 1999 (64 FR59967), specifically raised thepreemption issue. Comments receivedin response to that proposed rule arebeing analyzed. We will issueconforming amendments to Part 160Subpart B when the preemption issueshave been resolved in the context of theStandards for Privacy for IndividuallyIdentifiable Health Information finalrule.



B. Definitions

Comments and Responses Concerningthe Definitions

Several definitions in this rule havealso been proposed in other HIPAAproposed rules. They may be revised asthese other rules are published in final.

1. Code set

Comment: One commenter stated thatthe definition of code set should beexpanded to include factors such asfunctional status, in order to clarify thata code set is not limited to ‘‘medical’’terms.

Response: We have defined ‘‘codeset’’ very broadly to encompass any setof codes used to encode data elements.Many code sets (such as revenue codes)are nonmedical in nature and aredesignated within the transactionstandards. We are separately designatingstandards for medical data code setsused in the transaction.

2. Health Care Clearinghouse

Comment: Several commentersrequested that the definition of a healthcare clearinghouse be reworded. Ofparticular concern was the reference toother entities, such as billing services,repricing companies, etc. Commentersstated the definition would precludethese other entities from using a healthcare clearinghouse for format translationand data conversion. Severalcommenters stated health careclearinghouses play roles other thandata and format conversion as describedin the proposed rule.

Response: If an entity does notperform the functions of formattranslation and data conversion, it is notconsidered a health care clearinghouseunder our definition. Billing services,for example, are often extensions of ahealth care provider’s office, primarilyperforming data entry of health careclaims and reconciling the paymentsreceived from a health plan. Health careproviders may use health careclearinghouses for format translationand other services a health careclearinghouse provides. We agree thedefinition should be reworded and haverevised the definition in § 160.103.

3. Health care provider

Comment: We received severalcomments requesting clarification onthe distinction between billing healthcare providers and a billing service, aswell as clarification on the differencebetween housekeeping staff and homehealth aides. Several commentersrecommended removal of the word‘‘bills’’ in the definition. They want thedefinition to be based on the direct

provision of health care and notfinancial arrangements.

Response: The proposed ruleregarding Standard Health Care ProviderIdentifiers, published in the FederalRegister on May 7, 1998 (63 FR 25320)also included the definition of healthcare provider. Comments received inresponse to that proposed rule regardingthe definition of a health care providerincluded the comments above, as wellas additional comments, and are beinganalyzed. We believe it is appropriate toaddress all comments regarding thedefinition of a health care provider inthe final rule for Standard Health CareProvider Identifiers.

4. Health planWe interpret section 1171(5)(G) of the

Act to mean that issuers of long-termcare policies are considered healthplans for purposes of administrativesimplification. We also believe that thisprovision of the statute gives theSecretary the discretionary authority toinclude or exclude nursing home fixed-indemnity policies from the definitionof a health plan. We specificallyrequested comments on the impact ofHIPAA on the long-term care segment ofthe health care industry.

a. Comment: The majority whocommented on long-term care policiesrecommended we exclude these policiesfrom the definition of a health plan.Several commenters stated the standardtransaction implementationspecifications do not meet long termcare administrative requirements. Thecommenters noted that there arefundamental differences between thenature and type of transactions andinformation required by health plansthat pay for long-term care services andthose that pay for hospital or physiciancare. The commenters pointed out thatnot all long-term care insurance policiespay directly for specific long-term careservices. They also stated that the codesets included in the proposed regulationdo not adequately meet the needs oflong-term care insurance because mostdocuments sent to these companies arenarrative ‘‘activities of daily living’’(ADLs) evaluations, adult ‘‘day care’’invoices and physician notes.

Moreover, including long-term careonly policies within the definition of ahealth plan would be contrary to thepurposes of section 1171 of the Act. Itwas also stated that for the most part,the long-term care industry is notautomated and the costs of developingsystems to implement theserequirements will be dramatic withlittle, if any, return. It would increaseconsumer premiums. Most long-termcare claim submissions and payment

transactions are between the insured (ora family member) and their insurancecompanies, without health careproviders submitting claims.

One commenter that supportedincluding long-term care policies in thedefinition of a health plan stated thatthere have been great strides in theautomation of health information in thelong-term care industry and it shouldnot be excepted from the standards.Another commenter stated the proposedstandards offer the opportunity for allsegments of the health care industry toadopt automation and to benefit fromsuch adoption. The standards providelong-term care health care providerswith a single method that can beexchanged with all health plans. Thecommenter stated it would be anunfortunate precedent to exceptsegments of the health care industryfrom these rules.

Response: The arguments both for andagainst inclusion of long-term carepolicies have merit. Since some longterm care health care providers billMedicaid using the UB92, it appearsthat standard transactions and code setscould be used by long-term care healthcare providers to bill health plans. Inaddition, we agree that movement bythe industry to these electronicstandards would create long termbenefits including decreasedadministrative costs.

We interpret the statute as authorizingthe Secretary to exclude nursing homefixed-indemnity policies, not all long-term care policies, from the definition of‘‘health plan,’’ if she determines thatthese policies do not provide‘‘sufficiently comprehensive coverage ofa benefit’’ to be treated as a health plan(see section 1171 of the Act). Weinterpret the term ‘‘comprehensive’’ torefer to the breadth or scope of coverageof a policy. ‘‘Comprehensive’’ policieswould be those that cover a range ofpossible service options. Since nursinghome fixed indemnity policies are, bytheir own terms, limited to paymentsmade solely for nursing facility care, wehave determined that they should not beincluded as health plans for thepurposes of this regulation. TheSecretary has, therefore, determined thatonly nursing home fixed-indemnitypolicies should be excluded from thedefinition of ‘‘health plan.’’ Issuers of allother long-term care policies areconsidered to be health plans under thisrule.

b. Comment: Several commentersrecommended that property andcasualty insurance health plans andworkers’ compensation health plans beincluded in the definition of a healthplan. It was stated that we should not



arbitrarily exclude certain health plans.It was also stated that exclusion willcause undue hardship on health careproviders of those specialities that mostfrequently deal with these health plans,such as orthopedic specialists. It wasquestioned whether the Bureau ofPrisons or state correctional facilities areincluded in this definition, since theyprovide or pay for the cost of medicalcare.

Another commenter stated that ifState Workers’ Compensation Programsare allowed to operate with differentrules (as they do now) health careproviders will be required to maintainmultiple systems to accommodate themany variations. Consequently,administrative simplification will notachieve the desired cost savings.

Response: We recognize that non-HIPAA entities such as workers’compensation programs and propertycasualty insurance accept electronictransactions from health care providers,however, the Congress did not includethese programs in the definition of ahealth plan under section 1171 of theAct.

The statutory definition of a healthplan does not specifically includeworkers’ compensation programs,property and casualty programs, ordisability insurance programs, and,consequently, we are not requiring themto comply with the standards. However,to the extent that these programsperform health care claims processingactivities using an electronic standard, itwould benefit these programs and theirhealth care providers to use thestandard we adopt.

We believe that prisons do not fallwithin this definition of health plan, asprisons are not ‘‘individual or groupplans’’ established for the purpose ofpaying the cost of health care.

c. Comment: We received tworequests to clarify that limited scopedental and vision health plans are notsubject to the rule. It was stated that theproposed rule did not specificallyindicate that the standards areapplicable to these health plans. Thelimited scope dental health plansprovide for annual maximum benefitsgenerally in the $1000–$2000 range andannual benefit payments under limitedscope vision health plans rarely exceeda few hundred dollars. The commentersnoted that consumers can affordpresently to pay for the cost of theannual benefit payments, but if healthplans must implement these standards,they will most likely pass on the costsassociated with this burden to theirenrollees, causing many consumers todrop their coverage.

Response: We believe limited scopedental health plans and limited scopevision health plans meet the definitionof health plan and, thus, they are subjectto the requirements of this rule. TheCongress did not give the Secretary thediscretion to treat these health plansdifferently than other health plans. If ahealth plan believes it would be costprohibitive to implement the standards,it has the option of using a health careclearinghouse to transmit and receivethe standard transactions.

5. Small Health PlanComment: One commenter requested

we clarify how the figure for the numberof participants for a small health planwas determined. For instance, is anindividual insured in a health plan forone month considered a participant forthat year? Would twelve differentpeople insured for one month each in asingle year be considered a participant?Another commenter questioned whysmall health plans are being given anextra 12 months to implement thestandards.

Response: In the proposed rule, westated that a small health plan means agroup health plan or individual healthplan with fewer than 50 participants. Ithas come to our attention that the SmallBusiness Administration (SBA)promulgates size standards thatindicates the maximum number ofemployees or annual receipts allowedfor a concern (13 CFR 121.105) and itsaffiliates to be considered ‘‘small.’’ Thesize standards themselves are expressedeither in number of employees orannual receipts (13 CFR 121.201). Thesize standards for compliance withprograms of other agencies are those forSBA programs which are mostcomparable to the programs of suchother agencies, unless otherwise agreedby the agency and the SBA (13 CFR121.902). With respect to the insuranceindustry, the SBA has specified thatannual receipts of $5 million is themaximum allowed for a concern and itsaffiliates to be considered small (13 CFR121.201). Consequently, the definitionof small health plan has been amendedto be consistent with SBA requirements.As such, we need not address thedefinition of participants for purposes ofsmall health plans.

Small health plans must implementthe standards no later than 36 monthsafter adoption under section 1175 of theAct.

6. StandardComment: One commenter stated the

proposed rule dramatically changed thedefinition of standard. The commenterstated the new definition implies that

any and all standards promulgated byan ANSI SSO or HHS automaticallybecome a standard, whereas under theAct, only the Secretary can specify,establish, or adopt standards. Thecommenter recommended the definitionunder the Act stay the same.

Response: We agree that only theSecretary may adopt a standard underthe Act. Because the statutory definitionof the term ‘‘standard’’ is ambiguous, weare adopting a broader definition toaccommodate the varying functions ofthe specific standards proposed in theother HIPAA regulations. We haverevised the definition in § 160.103 toclarify this, and have also added adefinition for standard transaction in§ 162.103 for further clarification.

7. TransactionComment: Several commenters

recommended we amend the transactiondefinition to clarify each transaction.

Response: We have providedclarification in the definitions of eachtransaction in subparts K through R.

Additional DefinitionsComment: We received comments

requesting that we define the terms‘‘sponsor,’’ ‘‘third party administrator,’’‘‘trading partner agreement,’’ and‘‘health claims attachments.’’

Response: We have included adefinition for trading partner agreementin § 160.103. In this final rule, we aredefining only terms used in theregulations text, therefore, we are notproviding definitions for ‘‘sponsor’’ or‘‘third party administrator.’’ In thefuture, we intend to publish a proposedrule that defines health claimsattachment.

We have added definitions to parts160 and 162 that were not part of theproposed rule. In order to clarify theapplicability and scope of this rule, wehave added definitions for ‘‘coveredentity,’’ ‘‘trading partner agreement,’’and ‘‘workforce’’ to part 160, anddefinitions for ‘‘direct data entry’’ and‘‘electronic media’’ to part 162.

We have added a definition for‘‘business associate’’ to part 160 in orderto distinguish those functions a coveredentity chooses other entities to performon its behalf (making the other entity abusiness associate of the covered entity)from the functions of other types ofagents. These other types may havediffering meanings in differentsituations (for example, insuranceagent).

To aid in the articulation of theprocess by which standards are adoptedand changed, we have added definitionsfor ‘‘compliance date,’’ ‘‘implementationspecification,’’ ‘‘modify’’ and ‘‘standard



setting organization’’ to part 160, anddefinitions for ‘‘code set maintainingorganization,’’ ‘‘designated standardmaintenance organization (DSMO),’’and ‘‘maintenance’’ to part 162.

We added a definition for ‘‘standardtransaction’’ to part 162 to complementthe definitions of ‘‘standard’’ and‘‘transaction,’’ which were proposedand, in the case of standard, revised asdiscussed earlier in this preamble. And,in order to enumerate as many facets ofa standard transaction as possible, wehave added definitions for ‘‘datacondition,’’ ‘‘data content,’’ ‘‘dataelement,’’ ‘‘data set,’’ ‘‘descriptor,’’‘‘format,’’ ‘‘maximum defined data set,’’and ‘‘segment’’ to part 162. Thesedefinitions should help to make clearthe components of a standardtransaction.

We also made several clarificationswith respect to the definition of ‘‘healthplan’’ (§ 160.103). For purposes ofdefining the various health plans thatare considered health plans for purposesof the regulation, we added the word‘‘issuer’’ to Medicare supplementalpolicy, and long-term care policy. Weincluded the word ‘‘issuer’’ whenreferring to long-term care policies,because policies themselves are notentities subject to the statute. Rather, itis the issuers of long-term care policiesthat are subject to the statute. We alsoadded the SCHIP program, because it isa health plan under section 4901 of theBalanced Budget Act of 1997 (Pub. L.105–33) and meets the statutory criteriafor a health plan.

We are adding a definition of ‘‘state’’to § 160.103 to clarify its meaning withregard to the Federal programs includedin the definition of ‘‘health plan,’’which contain this term.

Several terms were in the proposedrule but are not included in the finalrule. We have reconsidered theinclusion of the definition of ‘‘medicalcare.’’ It has come to our attention thatthe term ‘‘medical care’’ is easilyconfused with the term ‘‘health care.’’Since the term medical care is used inthe regulation only in the context of thedefinition of health plan and itsinclusion in the regulation text maycause confusion, we have decided toremove the definition of ‘‘medical care’’from the final regulation. We note,however, that ‘‘medical care’’ is astatutorily defined term and its use iscritical in making a determination as towhether a health plan is considered a‘‘health plan’’ for purposes ofAdministrative Simplification. Thus, wedo include the statutory cite for‘‘medical care’’ in the definitions of‘‘group health plan’’ and ‘‘health plan.’’

Similarly, we removed the definitionof ‘‘participant’’ because it appears onlyin the context of the definitions of thevarious types of health plans. As in thecase of ‘‘medical care,’’ we embed thestatutory cite for the definition of‘‘participant’’ in the definition of ‘‘grouphealth plan.’’

Also, the definitions for ‘‘ASC X12,’’‘‘ASC X12N’’ were removed because wedecided their presence in the regulationdid not add to the functionality of thetext. We did not receive any commentson the definitions that were removed.

C. Effective Dates and Compliance Dates

1. Effective Dates and Compliance Datesfor Specified Standards

The effective date for this final rule isthe date that it amends the Code ofFederal Regulations (CFR). The currentCFR consists of the rules published inthe latest CFR volume and any effectiveamendments published in the FederalRegister since the revision of the latestCFR volume. Since the impact isexpected to be in excess of $100 millionper year, Congress will have 60 daysafter the date of publication in theFederal Register to revise the rulebefore it becomes effective. Standardsare adopted and implementationspecifications are established as of theeffective date of this rule.

The compliance dates of this finalrule are the dates that covered entitiesmust be in compliance with the rule.The compliance date of this final rulefor most covered entities is no later than24 months after the effective date of thisfinal rule. The compliance date of thisfinal rule for small health plans,however, is no later than 36 monthsafter the effective date of this final rule.

In our proposed rule, we stated thatwe would include the specificcompliance dates in the subpart for eachstandard (63 FR 25279). The compliancedates in this final rule have beenconsolidated in § 162.900.

Comments and Responses on EffectiveDates and Compliance Dates forSpecific Standards

Comment: The majority ofcommenters cited that Y2K initiativeswill clash with implementing theHIPAA standards. It was recommendedthat the implementation date should bedelayed until after the year 2000.

Several commenters stated that a 2-year implementation time frame may beinadequate to coordinate new systemdesigns with other health plans and tomodify existing systems and contracts.There was concern that the industrycannot convert to the new standardswithin 2 years.

Several commenters recommendedthat all health plans have the same timeframe with which to comply with thestandards of this rule. They noted thata health care provider has no knowledgeof whether a health plan is a small orlarge health plan. It would be veryinefficient for a health care provider tomaintain two systems for an additionalyear.

The majority of those whocommented on the publication of thefinal rule recommended that the rulesbe published in a staggered fashion,specifically the identifiers first, then thetransactions. Some also wanted theattachment and security regulationspublished at the same time thetransaction regulation is published.Some commenters also wanted theeffective dates for each standardtransaction to be staggered. Severalcommenters recommended publishingan interim final rule allowing foradditional comments.

Several commenters generallysupported the WEDI recommendationthat health care providers not berequired by health plans to use any ofthe standards during the first year afteradoption of the standards, and thatwilling trading partners couldimplement any or all of the standards bymutual agreement at any time duringthe 2 year implementation phase (3years for small health plans). WEDI alsorecommended that health care providersbe given at least 6 months’ notice by ahealth plan before requiring health careproviders to implement the standards.

Response: Section 1175 of the Actdictates that the standards are to beimplemented no later than 24 monthsafter adoption (36 months for smallhealth plans).

In the interest of a smooth transition,we encourage health plans not torequire health care providers to use thestandards specified in subparts Kthrough R during the first year after theeffective date of the transactions finalrule, although willing trading partnerscould do so by mutual agreement duringthat time. We also encourage healthplans to give health care providers atleast 6 months notice before requiringhealth care providers to implement astandard transaction. For example, if theeffective date of the rule is 8/1/2000 andtrading partners have agreed not toimplement during the first year, the firstimplementation date could be 8/1/2001and health care providers should benotified by 2/1/2001.

2. Effective Dates and Compliance Datesof Modifications

Proposal Summary: In § 142.106 (now§ 160.104), we proposed that if the



Secretary adopts a modification to animplementation specification or astandard, the implementation date ofthe modification (the date by whichcovered entities must comply with themodification) would be no earlier thanthe 180th day following the adoption ofthe modification (the effective date ofthe final rule in the Federal Registerwhich adopts the modification). TheSecretary would determine the actualdate, taking into account the timeneeded to comply due to the nature andextent of the modification. TheSecretary would be able to extend thetime for compliance for small healthplans.

Comments and Responses on EffectiveDates and Compliance Dates ofModifications

Comment: Some commenters believed180 days may not always be enoughtime to implement a revised standard.

Response: The statute states that theSecretary must permit no ‘‘fewer’’ than180 days for implementation afteradopting a revised standard (i.e., amodification). Depending on the natureof the revision, the minimum time frameof 180 days could be longer. This timeframe does not apply to themaintenance of medical code sets andexternal code sets. The compliance datewill be specified by the code setmaintaining organization responsible formaintenance changes to that code set.

We will clarify the terms modificationand maintenance. In the transactionscontext, when a change is substantialenough to justify publication of a newversion of an implementationspecification, this change will beconsidered to be a modification. Such achange must be adopted by theSecretary through regulation.Maintenance is the activities necessaryto support the use of a standard,including technical corrections to animplementation specification, andenhancements, additions, or deletions toa data code set. These changes could benon-substantive or error correction.Public comment and notification isrequired as part of the normal, ANSI-accredited standards developmentprocess, but regulatory action would notbe required for maintenance as we havedefined it. For example, this final ruleadopts the ASC X12N 278—Health CareServices Review—Request for Reviewand Response, Version 4010, May 2000as the standard for the referralcertification and authorizationtransaction. Error corrections oraddendums to Version 4010, May 2000,would constitute maintenance to thisstandard and there would be noregulatory action. Changes requiring a

new version, or an updated edition ofVersion 4010 (for example, moving fromVersion 4010, May 2000 to Version4010, October 2001) would constitute amodification to this standard and wouldbe adopted through regulatory action.

D. Data ContentProposal Summary: We proposed

standard data content for each adoptedstandard. Information that wouldfacilitate data content standardization,while also facilitating identicalimplementations, would consist ofimplementation specifications, dataconditions, data dictionaries, and thestandard code sets for medical data thatare part of this rule. Data conditions arerules that define the situations when aparticular data element or segment canor must be used.

It is important to note that all dataelements would be governed by theprinciple of a maximum defined dataset. No one would be able to exceed themaximum defined data set in this rule.This principle applies to the dataelements of all transactions.

Comments and Responses on DataContent

Comment: The majority ofcommenters supported the concept of amaximum defined data set; however,there was some confusion on what wewere proposing.

Several commenters believed we wererequiring health care providers toalways send the transaction with themaximum data possible. They statedthat health care providers and healthplans will pay excessively for unuseddata that is transmitted. Concern wasalso expressed that health plans wouldhave to store coordination of benefits(COB) information if it is submitted,even though they do not perform COB.Several commenters suggested thathealth plans be allowed to reject atransaction because it containsinformation they do not want.

One commenter recommended thatthe maximum defined data set be thefull set of data available in theimplementation specifications, not theaddendum in the proposed rule.

A few commenters wanted to expandthe concept of a maximum defined dataset to include code sets, modifiers,narrative descriptions, guidelines andinstructions applicable to codes sets, aswell as an additional category for‘‘usage’’ in the implementationspecifications, ‘‘not required unlessspecified by a contractual agreement.’’Several commenters wanted tradingpartners to be able to agree on whichnon-required data will be used betweenthem.

One commenter suggested a‘‘minimum’’ data set principle beapplied. If a submitter sends a minimumdata set, the receiver cannot reject it asincomplete. Again, the commenterbelieved we were implying that asubmitter must send the maximumevery time, in order to assureacceptance of the transaction.

Response: We wish to clarify themaximum defined data set concept. Amaximum defined data set contains allof the required and situational dataelements possible in a standardtransaction. For each standardtransaction there are situational dataelements that are both relevant to theparticular transaction and necessary toprocess it; there are also situational dataelements that an entity may include ina transaction, but does not need toinclude, in order for the transaction tobe processed. A required data element isalways required in a transaction. Asituational data element is dependenton the written condition in theimplementation specification thatdescribes under which circumstances itis to be provided. The maximumdefined data set is based on theimplementation guides and not theaddendum in the proposed rule. Themaximum defined data set also includesthe applicable medical and nonmedicalcode sets for that transaction. Somecode sets, e.g., HCPCS and CPT–4,include special codes referred to as‘‘modifiers.’’ Modifiers are included inthe concept of maximum defined dataset. The maximum defined data set doesnot include operational guidelines orinstructions for every code set.

We note that if an entity follows theimplementation specification and theconditions in the implementationspecification for each transaction, theentity will only be supplying theminimum amount of data elementsnecessary to process a transaction(required data elements and relevantsituational data elements); the entitywill not be supplying possible butunnecessary situational data elements.

In addition, we note that the intentbehind the maximum defined data setwas to set a ceiling on the nature andnumber of data elements inherent toeach standard transaction and to ensurethat health plans did not reject atransaction because it containedinformation they did not want. Forexample, if an implementationspecification defines a health care claimor equivalent encounter informationtransaction as having at most 50 specificdata elements, a health plan could notrequire a health care provider to submita health care claim or encountertransaction containing more than the 50



specific data elements as stipulated inthe implementation guide. (A healthplan may, however, request additionalinformation through attachments.)

While operational guidelines orinstructions are not included in theconcept of a maximum defined data set,we agree that standardization of thesecode set guidelines is highly desirableand beneficial. We reviewed theavailable guidelines to determine whichshould be adopted as implementationspecifications and have found that thereare also many current practical barriersto achieving such standardization. Forexample, we recognize that theoperational guidelines for some codesets required for use in the designatedtransactions are more complete thanothers. Also, objective, operationaldefinitions for most codes are notavailable and the level of detail varieswidely from code to code. In addition,the processes for developing guidelinesand instructions are typically not openand include limited participationcompared to the code developmentprocesses. However, where suchguidelines exist and are universallyaccepted, we name them as part of thestandard. Therefore, we adopt theOfficial ICD–9–CM Guidelines forCoding and Reporting as maintainedand distributed by the Department ofHealth and Human Services(§ 162.1002). Additionally, we receivedmany public comments in support ofthis action. We do not name guidelinesfor other code sets.

With respect to COB, if a health planelectronically performs COB exchangewith another health plan or other payer,then it must store the COB datanecessary to forward the transaction tothat health plan or other payer.

In addition, we disagree withcommenters that we should add a new‘‘usage’’ statement, ‘‘not required unlessspecified by a contractual agreement,’’in the implementation guide. Webelieve that the usage statement wouldhave the same effect as allowing tradingpartners to negotiate which conditionaldata elements will be used in a standardtransaction. Each health plan could theninclude different data requirements intheir contracts with their health careproviders. Health care providers wouldthen be required to use a variety ofguidelines to submit transactions todifferent health plans. This woulddefeat the purpose of standardization.

E. Availability of ImplementationSpecifications

Proposal Summary: We provided theaddresses and telephone numbers for aperson to obtain the implementation

specifications for the proposedstandards.

Comments and Responses onImplementation Specifications andTheir Availability

1. Comment: One commentersuggested that the X12N (the ASC X12subcommittee chartered to developelectronic standards specific to theinsurance industry) implementationspecifications under HIPAA must beflexible to permit businesses tocustomize their EDI process. It wasstated the implementation specificationsdo not allow flexibility between tradingpartners.

Response: We disagree. Allowingflexibility would result in non-standardimplementation of the transactions. TheX12N implementation specificationsunder HIPAA, adopted in this final rule,are all version 4010. If businessescustomize implementations of 4010, thehealth care industry would havehundreds of different implementationsof the same transaction.

2. Comment: One commenterrecommended we include the followinglanguage: ‘‘In addition, a set of NCPDPstandards contains all of the approvedstandards and implementationspecifications. For an additional fee, thedata dictionaries are available.’’

Response: We are aware that datadictionaries are available and that thereis a charge separate from themembership fee for them. We do notbelieve this needs to be included in thefinal rule, since this information isavailable through the NCPDP web site.

F. Proposed Requirements Stated inEach Subpart

In each subpart setting forth astandard or standards, we stated whichentities had to use the standard(s), theeffective dates for implementation, andthat we are incorporatingimplementation specifications (whereapplicable) by reference.

Comments and Responses on ProvisionsAppearing in Each Subpart

1. Code Set Standards

Proposal Summary: We proposed insubpart J the following: In § 142.1002(now § 162.1000), we stated that healthplans, health care clearinghouses, andcertain health care providers wouldhave to use the diagnosis and procedurecode sets as prescribed by the Secretaryfor electronic transactions. Theproposed standard medical code sets ofthese diagnosis and procedure code setswere identified in the preamble, and theimplementation specifications for thetransaction standards in part 142 (now

part 162), Subparts K through R,specified which of the standard medicaldata code sets should be used inindividual data elements within thosetransaction standards.

In § 142.1004, we specified that thecode sets in the implementationspecification for each transactionstandard in part 142, subparts K throughR, would be the standard for the codednonmedical data elements present inthat transaction standard.

In § 142.1010, the requirementssections of part 142, subparts K throughR, specified that those who transmitelectronic transactions covered by thetransaction standards must use theappropriate transaction standard,including the code sets that are requiredby that standard. These sections wouldfurther specify that those who receiveelectronic transactions covered by thetransaction standards must be able toreceive and process all standard codes.

We proposed code sets for varioustypes of services and diagnoses.

Comments and Responses on ProposedStandards for Code Sets andRequirements for Their Use

Proposed Code Sets

a. Version Control. Comment: Themajority of commenters stated that weshould have a clearer requirement forversion control, that is, we shouldrequire an electronic transaction to usethe version of each applicable code setthat is valid at the time the transactionis initiated. A common schedule shouldbe established (for example, calendaryear) for conversion to new versions ofall standard code sets. A fewcommenters indicated that there shouldbe an overlap period in which both lastyear’s and this year’s codes are acceptedto accommodate resubmission orsubsequent transfer of claims initiatedin the prior year.

Many commenters said that HHSshould maintain a consolidated list ofthe current accepted versions ofstandard code sets and make this listavailable to the public, e.g., on the Web.Several commenters indicated that all ofthe code sets themselves should beavailable from a single HHS website.

Response: We have included in§ 162.1000 a clearer statement that theversion of the medical data code setsspecified in the implementationspecifications must be the version thatis valid at the time the health care isfurnished. Since transactions may haveto be resubmitted long after the timehealth care was provided, health plansmust be able to process earlier versionsof code sets. The version of thenonmedical data code sets specified in



the implementation specifications mustbe the version that is valid at the timethe transaction is initiated.

At this time we are not establishing acommon schedule for implementingnew versions of all HIPAA medical datacode sets, since some of the code setsare updated annually (for example, ICD–9–CM, CPT) and some are updated morefrequently. The organizations thatmaintain medical data code sets willcontinue to specify their updateschedule. Different Federal lawsmandate the implementation of annualupdates to ICD–9–CM on October 1 andannual updates to the CPT on January1 of the following year for their use inthe Medicare program. Changing eitherof these dates would require legislativeaction and would also represent a majorchange in current practice for manyelements of the health care industry.

We agree that a common web site isa viable solution, but it is unclear whatthe Federal role would be in thedevelopment of one. We expect to workwith the medical data code setmaintainers to explore this option.

6. Proprietary coding systems. Two ofthe code sets proposed as HIPAAstandards, CPT and The Code on DentalProcedures and Nomenclature (referredto as ‘‘The Code’’ and published asCDT), are proprietary products.

Comment: Many commenters statedthat the Secretary should notrecommend proprietary systems asnational standards. They believed thatthe proposed rule lacked a definitivemethod to guarantee public access to theproposed standards at low cost, andrecommended that the governmentshould develop or maintain the nationalstandards or acquire the rights to thestandards of choice. Without ownershipand control, the government placesitself and the remainder of the healthindustry at noteworthy risk. Onecommenter indicated thatimplementation of the standards shouldbe delayed until proprietary code setshave been moved into the publicdomain. One commenter said it wasillegal for the Secretary to establish theCPT as a national standard. Anotherargued that the ‘‘The Code’’ should notbe named a national standard.

Response: Under HIPAA, theSecretary has the authority to selectexisting code sets developed by eitherprivate or public entities and is notprecluded from selecting proprietarycode sets. The Secretary is required toensure that all standard code sets areupdated as needed and that there areefficient, low cost mechanisms fordistribution (including electronicdistribution) of the code sets and their

updates. Free distribution of standardcode sets is not required by the statute.

The comments we received regardingcode sets were overwhelmingly in favorof the selection of currently used codesets as the initial standards. Some of thecode sets that are currently used inadministrative transactions areproprietary code sets. We have obtainedsome clarification from the developersof these code sets about the pricingstructure and mechanisms forpublishing the pricing structure thatwill be in place when the initialstandards are implemented. Theexistence of efficient, low-costdistribution mechanisms will affectfuture decisions regarding changes oradditions to the code sets designated asstandards.

A health care provider who submitsX12N transactions can download theimplementation specifications free ofcharge from the Washington PublishingCompany website. However, two of themedical codes sets, CPT and the DentalCode require a fee. Royalties forelectronic use of the CPT are based ona $10.00 per user standard. Royalties forelectronic use of the Dental Code inpractice management systems are basedon $10.00 per user site. These royaltyfees are normally included in thepurchase and maintenance costs of theelectronic systems that such providersuse. The other medical codes sets,HCPCS and ICD–9 CM, may bedownloaded free of charge.

For paper manuals, to which mostproviders that use these code setsalready subscribe, the CPT manual is$49.95 and the Dental Code manual is$39.95. In fact, the need for such papermanuals may decrease as moreelectronic systems are implemented.

A health care provider who submitsretail pharmacy transactions who wantsa copy of the NCPDP standards can payan annual fee of $550 for membershipin the NCPDP organization, whichincludes copies of the implementationspecifications for the retail pharmacystandard and the data dictionary as wellas technical assistance inimplementation. As a non-member, theimplementations specifications and datadictionary may be purchased separatelyfor $250 each.

Although nothing in this final rule,including the Secretary’s designation ofstandards, implementationspecifications, or code sets is intendedto divest any copyright holders of theircopyrights in any work referenced inthis final rule, future decisionsregarding changes or additions to thecode sets designated as standards maybe affected by the existence of efficient,low-cost distribution mechanisms.

c. Code Sets Proposed. The followingcode sets were proposed as initialstandards:

(a) Diseases, injuries, impairments,other health related problems, theirmanifestations, and causes of injury,disease, impairment, or other health-related problems.

The standard code set for theseconditions is the InternationalClassification of Diseases, 9th edition,Clinical Modification, (ICD–9–CM),Volumes 1 and 2, as maintained anddistributed by the U.S. Department ofHealth and Human Services. Thespecific data elements for which theICD–9–CM is the required code set areenumerated in the implementationspecifications for the transactionstandards that require its use.

(b) Procedures or other actions takento prevent, diagnose, treat, or managediseases, injuries and impairments.

(1) Physician Services. The standardcode set for these services is the CurrentProcedural Terminology (CPT–4)maintained and distributed by theAMA. The specific data elements forwhich the CPT–4 (including codes andmodifiers) is a required code set areenumerated in the implementationspecifications for the transactionstandards that require its use.

(2) Dental Services. The standard codeset for these services is The Code onDental Procedures and Nomenclature,printed as ‘‘The Code’’ and published asCDT, maintained and distributed by theADA for a charge. The specific dataelements for which the Dental Code isa required code set are enumerated inthe implementation specifications forthe transaction standards that require itsuse.

(3) Inpatient Hospital Services. Thestandard code set for these services isthe International Classification ofDiseases, 9th edition, ClinicalModification (ICD–9–CM), Volume 3procedures, maintained and distributedby the U.S. Department of Health andHuman Services. The specific dataelements for which ICD–9–CM, Volume3 procedures, is a required code set areenumerated in the implementationspecifications for the transactionstandards that require its use.

(c) Other Health-Related Services. Thestandard code set for other health-related services is the Health CareFinancing Administration CommonProcedure Coding System (Level II ofHCPCS) maintained and distributed bythe U.S. Department of Health andHuman Services.

(d) Drugs. The proposed standardcode set for these entities is the NationalDrug Codes maintained and distributedby the U.S. Department of Health and



Human Services, in collaboration withdrug manufacturers. The specific dataelements for which the NDC is arequired code set are enumerated in theimplementation specifications for thetransaction standards that require itsuse.

(e) Other Substances, Equipment,Supplies, or Other Items Used in HealthCare Services. The proposed standardcode set for these entities is the HealthCare Financing AdministrationCommon Procedure Coding System(Level II of HCPCS) as maintained anddistributed by the U.S. Department ofHealth and Human Services.

a. Comment: The great majority ofcommenters supported the selection ofthe code sets proposed on the basis thatthese code sets were already in wide useamong hospitals, physician offices,other ambulatory facilities, pharmacies,and similar health care locations.Commenters mentioned thatreplacement systems could havedifferent formats and number of digits.This could complicate the initialconversion. They also pointed out thatreplacement systems for the ICD–9–CMare still under development and testing.Many commenters stated that it wouldbe premature to make a decision onreplacements for the ICD–9–CM prior totheir completion and testing.

Response: We agree that thecontinued use of the proposed codingsystems will be the least disruptive formany entities required to implementHIPAA standards. The fact thatreplacement systems are still underdevelopment and testing furthersupports this decision.

b. Comment: Two commenters statedthat the proposal did not reflect currentuses of some code sets. One commenterstated that in addition to being used forinpatient procedural coding, the ICD–9–CM procedure codes are also requiredby many health plans for the reportingof facility-based outpatient procedures.The second commenter pointed out thatin addition to being used by physiciansand other health care professionals, thecombination of HCPCS level I and CPT–4 is required for reporting ancillaryservices such as radiology andlaboratory services and by some healthplans for reporting facility-basedprocedures. Further, Medicare currentlyrequires HCPCS level II codes forreporting services in skilled nursingfacilities.

Response: Health plans must conformto the requirements for code set use setout in this final rule. Therefore, if ahealth plan currently requires healthcare providers to use CPT–4 to reportinpatient facility-based procedures, they

both would be required to convert toICD–9.

We agree that the proposal did notreflect all current uses of some codesets. For example, we agree that CPT–4 is commonly used to code laboratorytests, yet laboratory tests are notnecessarily considered to be physicianservices. Moreover, the proposed ruleimplied that laboratory tests are a typeof other health care service which areencoded using HCPCS. We believe thatthe architecture of both coding sets,HCPCS and CPT–4, is such that they areboth frequently used for codingphysician and other health careservices. Both of these medical datacode sets are standard medical datacode sets and may be used in standardtransactions (see § 162.1002(e)).Therefore, a health plan using CPT–4 toreport outpatient facility-basedprocedures would not be required tochange that practice.

In addition, the proposed rule did notitemize the types of services included inother health care services. These otherhealth care services include theancillary services, radiology andlaboratory which are mentioned in thecomment, as well as other medicaldiagnostic procedures, physical andoccupational therapy, hearing andvision services, and transportationservices including ambulance.Similarly, other substances, equipment,supplies, or other items used in healthcare services includes medical supplies,orthotic and prosthetic devices, anddurable medical equipment.

In the final rule, we clarify thedescription of physician and otherhealth care services and we recognizethat two code sets (CPT–4 and HCPCS)are used to specify these services. In theproposed rule, we used the term‘‘health-related services’’ to helpdescribe these services. We believe thatuse of the term ‘‘health-related services’’might suggest that these services are nothealth care. In an effort to prevent thisconfusion, and because the codes in thiscategory are used to enumerate servicesmeeting the definition of health care, weare using what we believe is the moreappropriate term (‘‘health careservices’’) to describe these services. Wenote that the substance of the categoryremains the same. The final rule hasbeen revised to indicate that thecombination of HCPCS and CPT–4 willbe used for physician services and otherhealth care services. The use of ICD–9–CM procedure codes is restricted to thereporting of inpatient procedures byhospitals.

In § 162.1002 we clarify the use ofmedical code sets. The standard codesets are the following:

(a) ICD–9–CM, Volumes 1 and 2(including The Official ICD–9–CMGuidelines for Coding and Reporting), isthe required code set for diseases,injuries, impairments, other healthproblems and their manifestations, andcauses of injury, disease, impairment, orother health problems.

(b) ICD–9–CM Volume 3 Procedures(including The Official ICD–9–CMGuidelines for Coding and Reporting) isthe required code set for the followingprocedures or other actions taken fordiseases, injuries, and impairments onhospital inpatients reported byhospitals: prevention, diagnosis,treatment, and management.

(c) NDC is the required code set fordrugs and biologics.

(d) Code on Dental Procedures andNomenclature is the code set for dentalservices.

(e) The combination of HCPCS andCPT–4 is the required code set forphysician services and other health careservices.

(f) HCPCS is the required code set forother substances, equipment, supplies,and other items used in health careservices.

c. Comment: Although there was widesupport for the code sets that wereproposed, a number of commenterspointed out that additional code setswere needed to cover some healthservices recorded in administrativehealth transactions. One commentermentioned that the code sets proposedas standards lacked coverage ofalternative health care procedures andrecommended that the Alternative Linkcoding system also be designated as astandard code set. Commenters alsoindicated that none of the proposedstandard code sets covered homeinfusion procedures; they recommendedthat the Home Infusion EDI CoalitionCoding System (HIEC) be selected as aHIPAA standard. HIEC is currently usedby some non-governmental health plans.One commenter recommended thatdental diagnostic codes (SNODENT)developed by the ADA be used as anational standard. This commenterstated that the ICD–9–CM codes wereinadequate for dentistry.

Response: No single code set in usetoday meets all of the businessrequirements related to the full range ofhealth care services and conditions.Adopting multiple standards is a way toaddress code set inadequacies, but canalso introduce complexities due to codeset overlaps. We acknowledge that thecoding systems proposed as initialstandards may not address all businessneeds, especially in the areas ofalternative health care procedures,home infusion procedures, and dental



diagnoses. Specific shortcomings shouldbe brought to the attention of the codeset maintainers. The adoption ofadditional standards may be anappropriate way to fill gaps in codingcoverage in these areas. Additional codesets must be analyzed by the DSMOsthat will make recommendations to theNational Committee on Vital and HealthStatistics. In order to request changes,we recommend working through theprocesses described in §§ 162.910 and162.940. In the interim, segments existin the standard transactions whichallow for manual processing of servicesfor which codes have not been adopted.

d. Comment: While agreeing ingeneral with the code sets proposed asstandards, some commenters indicatedthat they lacked sufficient specificity tocode data elements in several areas:functional status and other dataelements necessary for studying personswith mental illness; behavioral health;chronic conditions and functionalassessments covered by long term careinsurance; and mental health services.

Response: We agree the code setsproposed as HIPAA standards may notcover functional status, mental andbehavioral health, chronic conditions,and mental health services to the extentrequired by the legitimate businessneeds of some health care providers andhealth plans. We are unaware of anyviable alternative code sets which coverthese areas more completely.Maintainers of code sets seeking to benamed as standards must pursuerecognition through the processes setout at §§ 162.910 and 162.940.

e. Comment: One commenter, whosupported the proposed code sets fortheir intended purposes, felt that theylacked the detail necessary to documenta complete clinical encounter. Thecommenter stated that a comprehensivehealth information system requires theuse of a controlled referenceterminology to document care, retrievedata to perform studies, and assesspatient outcomes. The commenter statedthat as the implementation of HIPAAprogresses towards the adoption ofstandards for a complete computerbased patient record, the current codingsystems will be inadequate. Thecommenter stated that the systemdeveloped by SystematizedNomenclature of Human and VeterinaryMedicine International (SNOMED)could be used as a future standard.

Response: We agree that moredetailed clinical terminologies are likelyto be needed in complete computer-based patient records. SNOMED is oneof the clinical terminologies beingexamined by the Work Group onComputer-Based Patient Records of the

National Committee on Vital and HealthStatistics’ Subcommittee on Standardsand Security. The Work Group isresponsible for studying the issuesrelated to the adoption of uniform datastandards for patient medical recordinformation and the electronic exchangeof such information.

f. Comment: One commenterexpressed problems with the use of theICD–9–CM and the ICD–10–CM for thecollection of both reimbursement andresearch related data. It was stated thatthe data collected in claims’transactions clog up the reimbursementdata system with a large amount ofextraneous material. The commenteralso felt that the data were of dubiousquality. The commenter estimated thatas much as 50% of the informationgathered within the transactions’systems was for research purposes only.The commenter felt it was unfair toforce the private sector to subsidizeresearch costs through subterfuge. Thecommenter suggested that the issue beresolved by limiting the initial scope ofthe ICD–10–CM to collecting onlyinformation used or needed forreimbursement.

Response: The adopted codingsystems support the collection of a widevariety of data that can be used for manypurposes. However, we disagree withthe commenter that standard health careclaims or equivalent encounterinformation transactions collect dataprimarily for research purposes. Thecontent of the health care claims orequivalent encounter informationtransaction was developed on aconsensus basis by health careproviders, health plans, and otherindustry representatives as necessary forthe conduct of administrativetransactions.

d. Coordination among Code Sets.Comment: Several commentersrecommend that a very tight process beput in place to control overlap ofHCPCS Level II ‘‘D’’ codes (The Code onDental Procedures and Nomenclature,printed as ‘‘The Code’’ and published asCDT) and the CPT–4 codes. It wasquestioned whether there will be areview process in place for dental codes.Since there is some duplication ofdental codes and the CPT–4 codespresently, a review process is needed toavoid duplication. One commenterstated that to attain and maintain codingconsistency and avoid duplicate codes,the American Dental Association shouldbe a member of a federal HCPCScommittee.

Response: We agree that a mutualexchange of information is necessary toattain and maintain coding consistency.Panel member(s) from HCPCS Level II

‘‘D’’ Codes (The Code on DentalProcedures and Nomenclature), CPT–4,and Alpha-Numeric HCPCS willparticipate or act as consultants on theother coding panels in order to attainand maintain coding consistency andavoid duplicate codes.

e. Proposed changes to Dental Codes.Proposal: In HCPCS, the first digit ‘‘0’’in the American Dental Association’sThe Code on Dental Procedures andNomenclature is replaced by a ‘‘D’’ toeliminate confusion and overlap withcertain CPT–4 codes. The ADA hasagreed to make this change an officialpart of the dental codes they distributeand to replace their first digit ‘‘0’’ witha ‘‘D.’’ Consequently, dental codes willno longer be issued within HCPCS as ofthe year 2000. The ADA will be the solesource of the authoritative version of‘‘The Code.’’

Comment: There were several specificcomments about the proposal to changethe initial digit in the ADA’s version ofThe Code on Dental Procedures andNomenclature from ‘‘0’’ to ‘‘D.’’Comments in favor of the change agreedthat it would avoid potential overlapand confusion. One commenterindicated that this was particularly truefor those claims that would continue tobe submitted manually since the ASCX12N 837 and 835 transactions containa code qualifier that clearly indicateswhich procedure code is being used.One commenter stated that as the ADAreplaces the leading ‘‘0’’ with the letter‘‘D,’’ some of the resulting codes willcoincide with existing HCPCS Level II‘‘D’’ codes, but will have totallydifferent meanings. This could creategreat confusion at adjudication time.Dealing with a coding system thatcontains an alphabetic character wouldalso cause problems for many systems.One commenter believed that it is theresponsibility of both the ADA and theDepartment to specify clear andunambiguous rules that will affect thistransition between coding systems, sothe resulting confusion is minimized.The commenter suggested the followingoptions: (1) Replace the codesnationwide on a certain date; (2) choosea letter other than ‘‘D’’ for ‘‘The Code,’’so there is no overlap; or (3) retain theleading zero in ‘‘The Code’’ and assurethat there continues to be no conflict oroverlap with the CPT–4 anesthesiacodes, as currently they do not overlap.

There were no comments about theproposal that ‘‘The Code’’ be removedfrom HCPCS and that the ADA becomethe sole source of the definitive versionof these codes.

Response: The ADA will change theleading ‘‘0’’ to a ‘‘D’’ as proposed. Manyorganizations are already using the ‘‘D’’



Codes, which contains the leading ‘‘D,’’without difficulty, and we expect othersto make this transition withoutdifficulty. Although we did not receivecomments that specifically addressedthe removal of the dental codes from theHCPCS, general comments about thedesirability of more consolidated accessto all HIPAA code sets have led us torevise our position on the inclusion of‘‘The Code’’ in the HCPCS. Thus, thedental codes will be available from twosources: the ADA, and through alicensing agreement between HCFA andthe ADA.

f. Other Dental Code Issues. a.Comment: One commenter (a majorhealth plan) emphasized the criticalimportance of federal oversight andmonitoring of dental codingmaintenance and revision to ensure thatdental data sets do not incorporatefragmented or unbundled proceduresthat are integral parts of a single dentalservice. For example, in ‘‘The Code-1,’’the procedure code 04910, periodontalprophylaxis/periodontal recall,included the examination as part of thissingle dental service; in ‘‘The Code-2,’’the examination is unbundled and islisted as a separate procedure. Theimport of this unbundling is thepotential for increasing cost of care,without otherwise increasing theservices provided. At the very least, tocontrol the impact that unbundlingmight potentially have on the cost ofcare, it was recommended that once aparticular standard code is established,it may not be deleted and any changesor modifications to the code ordescriptor be included as a new code.

Response: The American DentalAssociation (ADA) will be responsiblefor maintaining an appropriate openprocess for updating ‘‘The Code.’’Interested public and private sectororganizations and groups will have theopportunity for substantive input, asthey will for all HIPAA standards. TheDepartment will continue to review theprocess of code modification to ensurethat the code sets continue to meet thebusiness needs of the industry.

b. Comment: One commenterquestioned whether the addition of aspecific procedure to the dental codesadopted as a HIPAA standard meantthat a health plan had to cover theprocedure or whether it meant thehealth plan only had to be able toreceive and process the standard codefor the procedure.

Response: The establishment of acode in any of the code sets adopted asHIPAA standards does not require thata health plan cover the codedprocedure. However, health plans mustbe able to receive and process all codes

in HIPAA standard code sets. In otherwords, transactions containing standardcodes may be returned with a messagethat the procedure is not covered by thehealth plan to whom they have beensubmitted. Transactions may not berejected because the health plan’ssystem does not recognize validstandard codes.

g. Future Consideration of ICD–10Code Sets. Proposal Summary:Although the exact timing and precisenature of changes in the code setsdesignated as standards for medical dataare not yet known, it is inevitable thatthere will be changes to coding andclassification standards after the year2000. For example, the ICD–10–CM fordiagnosis may replace the ICD–9–CM asthe standard for diagnosis data. Whenany of the standard code sets proposedin this rule are replaced by wholly newor substantially revised systems, thenew standards may have different codelengths and formats.

a. Comment: Several commenters feltthat the ICD–10–CM should beconsidered as a future national standardafter the year 2000. The commentersstated that the proposed initial standard,ICD–9–CM, should be selected since itwas currently in use. They pointed outthat the ICD–10–CM was still underdevelopment. Several commenterssuggested that the system be tested andevaluated as a future national standardwhen the final draft is completed. Onecommenter was supportive of thesystem and suggested that factors suchas code length be considered as part ofthe testing and evaluation of the ICD–10–CM system. Several commenters feltthat the current draft of the ICD–10–CMshowed significant improvements overthe ICD–9–CM. Another commenterstated that the system would allow formore accurate reporting by health careproviders. One commenter stated thatthe use of the ICD–10–CM will requireconsiderable training.

Response: We agree with thecommenters that the ICD–10–CM hasgreat potential as a replacement for theICD–9–CM. We also agree that a finalevaluation of the system should awaitthe completion of the final draft andtesting.

b. Comment: Several commentersstated the ICD–10–PCS (which is underdevelopment for use in the UnitedStates as a replacement for theprocedure coding section of ICD–9–CM)should be considered as a futurenational standard. Most commentersrecommended that the decision to useor not use the ICD–10–PCS should awaitfinal development and testing. Themajority of commenters stated thatfuture systems, such as the ICD–10–

PCS, should not be implemented untilafter the year 2000. However, severalcommenters supported the futuremigration to the ICD–10–PCS because itwas felt to offer significantimprovements over the ICD–9–CM. Onecommenter stated that the ICD–10–PCSdevelopment project has made valuablecontributions to many issues relating tocoding and terminology. Anothercommenter expressed concern about thelevel of detail in the ICD–10–PCS andrecommended that further studies andtrials should be performed in order toestablish the relative costs and benefitsof the system. This commenter wasparticularly concerned about thepathology section and felt it neededmore work. Others praised the increasedlevel of detail in the system and felt theadded clinical information would beuseful.

Response: We believe the ICD–10–PCS has great promise as a futurereplacement of the ICD–9–CM, volume3. However, we also believe the systemneeds additional testing and revisionprior to making a decision about its useas a national standard. The system isdramatically different from the ICD–9–CM containing more digits, greaterdetail, and a more organized approach.With any new system, many factorsmust be weighed prior to making arecommendation about national use.Changing a coding system will have agreat impact on national data and wouldbe evaluated carefully by the DesignatedStandard Maintenance Organizationsand the NCVHS, with opportunity forpublic input.

h. Universal Product Number (UPN).Proposal: The Universal ProductNumber (UPN) identifies medicalequipment and supplies. It was notrecommended as an initial standard forthe following reasons: the existence oftwo different sets of UPN codes;incomplete coverage—approximately 30percent of the health care products donot have a UPN assigned to them; andlack of experience with UPNs forreimbursement. However, the proposalasked for comments regarding UPNs andwhen it might be appropriate todesignate one or more UPN systems asHIPAA standards.

a. Comment: Several commentersstated that the HCPCS level II codes thatwe recommended to identify medicalequipment and supplies are currentlynot specific enough for accurate claimsprocessing, proper financial controls, orproper tracking of utilization. Healthcare providers use many different kindsof supplies and equipment not found inthe HCPCS level II codes. It was arguedthat establishing UPNs as a nationalcoding system for identifying health



care supplies and equipment willprovide the following advantages overthe HCPCS level II codes:

• The UPN system would allow formore accurate billing and better fraudand abuse detection than the use of anon-specific coding system such as theHCPCS level II.

• UPNs would improveadministrative efficiency andeffectiveness.

• The product specificity that UPNsprovide in identifying the actualspecifications of manufacturer’sproducts and packaging sizes isessential to managing health industrytransactions and determining accuratepayment amounts.

• The UPN mechanism is already inplace and has been proven in use.

Several commenters agreed that weshould not include the UPNs in theinitial list of standards. A cautiousapproach and considerable further studyis necessary to determine if theobjectives of administrativesimplification and reduced costs withinthe health care system will be achievedby using the UPNs as a national codingsystem for health care products.

Response: We agree that additionalinformation regarding the utility of theUPNs for claims processing needs to beobtained before a decision is made torequire their use. Specifically, moreinformation is needed concerning thecosts and benefits that can be expectedfrom using the UPNs and the extent towhich their use would promoteadministrative simplification. Also,information is needed regarding thestandards that would have to beestablished to ensure that the UPNscould be used effectively by third partypayers. Another issue that needs to bestudied is the amount and type ofinformation that an insurer would haveto obtain from manufacturers in order toadequately identify the productsrepresented by approximately three tofive million UPNs. Only detailedinformation concerning the productsthat are represented by the UPNs,provided in a consistent manner, willallow comparisons to determine ifproducts from different manufacturersare functionally equivalent.

b. Comment: Several commentersexpressed concern that the health careindustry may continue to use twodifferent types of UPN systems ratherthan a single system. They asserted thatthis is the best time to choose betweenthe two coding councils, the Health CareUniform Code Council (UCC) and theHealth Industry BusinessCommunications Council (HIBCC),because there has not been a substantialinvestment in either system.

Response: We believe that neitherUPN system should be selected at thistime, based on the reasons outlinedabove. We look to the industry toresolve the issue of whether the twosystems should continue.

Before requiring the use of UPNs, weneed to obtain more informationregarding the costs and benefits ofimplementing the UPN, the adaptabilityof the UPN system for making coverageand payment determinations, and forcombating fraud and abuse. We will bemonitoring demonstrations beingconducted by California Medicaid todetermine the cost and feasibility ofusing UPNs in the health care industry.The entity proposing such ademonstration must request anexception from the standards followingthe procedures in § 162.940.

i. NDC. a. Comment: Commentersgenerally agreed with ourrecommendation to eliminate Level IIHCPCS codes for drugs by the year 2000and to use NDC for all drugs. However,some commenters disagreed withapplying this requirement to non-pharmacy claims and recommendedthat the NDC be used only for retailpharmacy claims until sufficientbenefits and overhead costs ofexclusively implementing the NDCcodes can be further researched. It wasmentioned that the NDC numbers notatea vial size and physician injectionsoften results in a single vial being usedfor multiple patients. They alleged thatcurrent Level II HCPCS codes allow forthis identification. Several commentersalso recommended that those durablemedical equipment (DME) that do nothave Level II HCPCS codes should useNDC codes.

It was noted that Medicaid agenciesmust reimburse health care providersfor supplying the drug products of anycompany in the Federal Rebate Programas long as the drug reimbursement ratesare within the Federal Upper PaymentLimit. Because many companiesproduce the same drug, there are oftenmany NDCs that correspond to the samedrug with the same Level II HCPCScode. It was stated that Medicaid usesthe Level II HCPCS codes to indicatewhich of these many products isreimbursable for health care providersubmitted drug transactions.

One commenter suggested moving theNDC codes to the HCPCS codes. Thecommenter stated using two differentcoding systems (NDC and HCPCS) iscounter to the overall goal ofadministrative simplification.

Response: We continue to believe thatuse of NDC to identify drugs is the mostappropriate and efficient coding systemavailable. While commenters gave

various reasons in support of theirobjection to requiring use of NDC fornon-pharmacy claims, most of thesereasons were based upon amisunderstanding of the proposal. Forexample, contrary to one comment, theMedicaid drug rebate program requiresthe NDC, not the generalized Level IIHCPCS code for the rebate program.

In response to the commenter whostated that the NDC does not alwaysallow identification of partial vials (thatis, when a single vial is used amongmultiple patients), we note thatalthough this may be true with certainNDC codes, the transaction standardsallow the reporting of dosage units forthe NDC. In addition, although certaincommenters requested a crossoverperiod during which both nonstandardand standard codes may be used forprocessing, we believe that it is morereasonable to require all of the systems’changes that we can at one time, ratherthan addressing the changes in apiecemeal fashion. The two years afterthe effective date allowed beforecompliance is required will allow for asmooth transition period. Both non-standard electronic formats and the newstandard transactions may be usedduring this transition period.

With respect to DME claims, HCPCSLevel II is the proposed standard forDME. DME do not receive NDC as NDCare national drug codes. We are notmoving the NDC codes to the HCPCSsince each are separate coding systemsfor different purposes. Commentersgenerally supported thisrecommendation.

b. Comment: One commenterrecommended to either revise theexisting NDC or create a new codingsystem so the codes are distinctive intheir format. The commenter stated thatthe coding system should serve theinventory and distribution industries aswell as assist with the billing andinventory management of outpatientand hospital settings. Moreover, thecommenter wanted the system to havethe capacity to last 50 to 100 years orlonger.

One commenter stated the NDCsystem was designed for health careproviders who manufacture drugproducts or pay for drug therapy. Thecommenter said the design iscompletely inappropriate for the needsof most health care providers whoprescribe drug therapies, dispense drugproducts, or administer medications topatients. The NDC identifies drugproducts at a level of detail (thepackage) that is much too granular to beof any practical use for most health careproviders. The commenterrecommended to select either



MediSource Lexicon or the HL7Vocabulary Special Interest Group DrugModel and Listing as the standard codeset for drugs.

Response: In general, the Act requiresthe Secretary to adopt existing code setsdeveloped by private or public entities,unless code sets for the data elementshave not been developed by suchentities. When new code sets aredeveloped or existing ones revised, theyneed to be evaluated. Demonstrationsneed to be performed in order todetermine the cost and feasibility ofsuch codes sets in the health careindustry. MediSource and HL7 are notcurrently used within the transactionsystem for administrative andreimbursement purposes for retailpharmacy claims. The majority ofcommenters supported the adoption ofthe NDC coding system for pharmacyclaims and did not support onecommenter’s opinion regardingdifficulties perceived. The NDC wasoriginally developed as a 10-digitidentifier made up of three subcodes:the manufacturer code, the productcode, and the package size code. Eachsubcode is variable in length. Somesubcodes are reported with leadingzeroes and some truncate the leadingzero. This leads to variable sizes, suchas: 5–4–1, 5–3–2, and 4–4–2. Originally,the subcodes were separated byhyphens. However, when used incomputer systems, it is customary todisplay each subcode using its largestvalid size, yielding an 11-digit number:5–4–2. We are adopting the 11-digitNDC in order that the format isdistinctive and will be in place until theSecretary decides to adopt a new codesystem. Since it will be in a standardformat, inventory systems, as well asother systems, should realize benefits.As the nation moves beyond theadoption of initial standards, there maybe a need to evaluate other codingsystems that have the potential of beingadopted as a standard in the future.

c. Comment: Several commenters saidthe FDA needs to improve its oversightof NDC before adoption. It was statedthat the FDA shifted responsibilities forthe maintenance of the system tomanufacturers and drug packagers whoassigned their own codes. As a result,the FDA does not possess a current,accurate, or complete NDC list. It wasstated that the 11-digit NDC codeidentifies drugs, and these codes areassigned on a continuous basisthroughout the year as new drugproducts are issued.

Response: The Food and DrugAdministration’s Center for DrugEvaluation and Research provides dailyupdates to the New and Generic

Prescription Drug Approval List. Theyprovide weekly updates to the FDADrug Approval List. This list includesadditions and deletions to prescriptionand over the counter (OTC) drugproducts. This list must be used inconjunction with the most currentpublication of the Approved DrugProducts with Therapeutic EquivalenceEvaluations (a.k.a. Orange Book) whichis updated on a monthly basis. The NDCDirectory is updated on a quarterlybasis. These lists are available via theInternet at: http://www.fda.gov/cder.

j. Training Requirements. Comment:A medical association stated that therewill be a significant increase in theworkload required in order toadequately comply with thestandardized transaction code sets.There is a tremendous need for trainingfor health care providers as well asinformation systems modifications. Forexample, the code sets for anesthesia,dental, and procedure codes will requirea large amount of time and effort forState Medicaid ManagementInformation Systems (MMIS) to complywith using the standardized code sets.

Response: We agree that educationalactivities must occur. Health plansshould inform their health careproviders of the impending changes assoon as possible and arrange forappropriate educational opportunitiesin 2000. It is also anticipated that healthcare clearinghouses and othercommercial entities will offer training.

k. Local Codes. Proposal Summary:The Health Care FinancingAdministration Procedural CodingSystem (HCPCS) contains three levels.Level I (CPT–4), is developed andmaintained by the AMA and capturesphysician services. Level II of HCPCScontains codes for products, supplies,and services not included in CPT–4.Level III, local codes, include codesestablished by insurers and agencies tofulfill local claim processing needs. Oneof the intentions of this rule is toeliminate local codes.

Comment: We received commentsfrom a diverse group of organizations,ranging from data managementcorporations, health insuranceorganizations, State agencies, etc. Alittle less than half of the commentersdid not favor the elimination of localcodes. There was a general concernexpressed by both public and privateinsurers that very specific and uniquecodes are necessary for processing andpaying claims efficiently. Manycommenters, particularly ones fromState Medicaid agencies and from otherinsurance health plans, commented onthe need for local codes to describe awide variety of health care services. For

example, several commenters describedspecific needs for local codes forphysician services, such as digital rectalexam, that are not delineated in CPT–4or HCPCS. Other commenters opposedthe elimination of local codes becausethey argued that it would be difficult toget a national code approved in a timelyfashion to process claims for newtechnologies that come onto the marketand are coverable. The main concern ofthese commenters was that the needs ofsome health plans’ programs are sospecific that a more general code wouldnot meet their needs. Furthermore,eliminating both local codes and theprocess to standardize codes would takeaway some of a State’s authority toadminister its programs. There was greatconcern that if the translation of localcodes to national codes is not doneexpeditiously it would create a highnumber of ‘‘not otherwise classifiedcodes,’’ which in turn create processingdelays. There was a great deal ofconcern expressed by health plans thateliminating local codes would disruptdata reporting, claims payment, anddata systems design for a considerableamount of time and would be veryexpensive.

Many commenters said that theproposed process was not well definedin the proposed rule. They felt thatgiven the timetable specified in theproposed rule there would not beenough time to develop and implementan effective standardization process.

Commenters made a number ofrecommendations regarding thestandardization process. Includedamong them were the following:conduct monthly meetings of theHCPCS panel; have each State establishits own HCPCS committee with healthplan and health care providerrepresentatives deciding which localcodes to eliminate and which to submitto the national panel forstandardization; open the HCPCS panelmeetings to the public and includeparticipation of stakeholders such asstate beneficiary representatives anddata maintenance organizations; add theAMA, ADA and BC/BS Association asvoting members; and establish both stateand regional level committees to makedecisions on standardization of codes.

The main concern was that theproposed elimination of local codeswould create an enormous backlog ofcodes for the HCPCS panel to reviewand this would result in the delay of theimplementation of national codes. Therewas a general recommendation that anyprocess that is established tostandardize local codes should alsohave a mechanism in place to assign



national codes for use within a veryshort time frame.

Several commenters stated they wereunclear about whether all local codescould be translated into equivalentnational codes within the next twoyears. They considered the timetablepresented as difficult to achieve, andsuggested that all codes developed andapproved by HCFA should have astandard publication timetable. Theysaid that any process for standardizinglocal codes must have the ability toassign codes within a very short timeframe to assure that claims can beprocessed timely. Some commentersproposed that local codes should beeliminated when the ICD–10 codes setsand transactions are implemented.Others suggested delaying theelimination of local codes to allow foran orderly transition.

Response: We understandcommenters’ concern about eliminatinglocal codes and moving to a nationalprocess for reviewing and approvingcodes that are needed by public andprivate insurers. We remain committedin our effort to work with the industryto facilitate the standardization process.We will be monitoring the process ofcode revision to ensure that the codesets continue to meet the needs of theindustry. Moreover, although thestandardization of local codes will bechallenging, we believe it is anachievable undertaking as health plansand health care providers have twoyears to eliminate local codes andtransition to national codes (smallhealth plans have three years beforethey are required by statute to becompliant with the HIPAA standards).

We would like to clarify that coveredentities may not use local codes instandard transactions after compliancewith this regulation is required. Normay a covered entity require the use oflocal codes in standard transactionsafter compliance with this regulation isrequired.

We believe that the prohibition on theuse of local codes in standardtransactions will likely require healthinsurers to review their local codes andeliminate those codes that duplicateelements in the national codes. Duringthis review process, we expect thatcovered entities will find that there areinstances when they use a particularlocal code in fewer than 50 claimssubmissions per year. In those instanceswhen a covered entity discovers that ituses a local code in fewer than 50claims submissions per year, thecovered entity should not make amodification request to the maintainerof the relevant medical code set for aunique national code for the item or

service. Rather than having themaintainer of the relevant code set issuea unique national code for a service oritem for which there are fewer than 50claim submissions per year, a coveredentity should use the national NotOtherwise Specified (NOS) code (use ofthe NOS code is voluntary before thecompliance date of this regulation, butuse of the NOS code becomesmandatory after the compliance date ofthe regulation). We believe that not onlywill NOS codes continue to serve as thenational code for claim submissions foran item or service that are submittedfewer than 50 times per year, they willcontinue to serve as the national codefor new services or items that have notyet been assigned a unique nationalcode by the maintainer of the relevantmedical code set.

Also, we anticipate that insurers willneed to work with other similarlysituated health plans to review localcodes used for professional services,procedures, health care products andsupplies which are not described by thecurrent code sets. Finally, in situationswhere, after careful review, no nationalcode currently exists to replace a localcode, health plans may request theestablishment of a national code. Healthplans should bear in mind the criteriafor the establishment of a national code.Specifically, national codes are onlydesigned to identify an item or service;additional codes are not established tocarry health plan specific informationsuch as units or health care provideridentification for products orprocedures which have been given anational code. Such information mustbe used elsewhere and cannot beimbedded in the national codes.

Health plans should submitindividual code requests for theestablishment of national codes, alongwith supporting documentation, to theappropriate standard code setmaintenance group. For example, inorder to provide a better understandingof the HCPCS process, a Web site hasbeen set up to provide public access tothe list of items submitted for theHCPCS National Panel for review. An e-mail link is available for questions andcomments related to the HCPCS process.The Internet site is http://www.hcfa.gov/medicare/hcpcs.htm.

For information on changes andupdates to the procedure part of ICD–9–CM (Volume 3) see the followingInternet site: http://www.hcfa.gov/medicare/icd9cm.htm.

For information on changes andupdates to the diagnosis part of ICD–9–CM (Volumes 1 & 2) see the followingInternet site: http://www.cdc.gov/

nchswww/about/otheract/icd9/maint/maint.htm.

The Internet site for requesting achange or an addition to the code(s) inthe Code on Dental Procedures andNomenclature is: http://www.ada.org/P&S/benefits/cdtguide.html.

To request a change or an addition tothe code(s) in the Current ProceduralTerminology, Fourth Edition (CPT–4)you can write: American MedicalAssociation, Department of Coding andNomenclature, 515 North State Street,Chicago, Illinois, 60610. The Internetsite for the American MedicalAssociation is http://www.ama-assn.org.

For the list of codes found in theNational Drug Codes, see the followingInternet site: http://www.fda.gov/cder/ndc/index.htm.

For information about submitting arequest to modify the National DrugCodes, see the following Internet site:http://www.fda.gov/cder.

In addition, some commenters havestated that they use codes within theiroperating systems that are internallygenerated. These internal operatingcodes are used solely within theorganization for administrativepurposes. We understand that thesecodes are sometimes called local codes.Furthermore, commenters are concernedthat this regulation will require theelimination of those internal operatingcodes. We clarify that this regulationwill not require the elimination of theuse of these internal operating codeswhen not part of a transaction for whicha standard has been adopted under thispart.

2. Transaction StandardsWe received numerous comments on

the specific transaction standards andimplementation specifications whichwe proposed to adopt. Some of theseconcerned the choice of the particularstandard itself, a matter clearly withinthe Secretary’s purview. Many of theother comments, however, concernedspecific issues raised by the electronicformats, data conditions, and/or datacontent of the proposed standards and/or implementation specificationsthemselves. As these are all standardsthat are developed and maintained byexternal organizations (SSOs), theconcerns raised by this latter group ofcomments could not be directlyaddressed by the Secretary.

Thus, we initially analyzed the publiccomments received to determine whichcomments fell into this latter group. Thecomments directed at theimplementation specification for theX12N standards were turned over to theASC X12N Subcommittee for reviewand action by the appropriate work



group(s). They classified the commentsinto two categories: business needs, andtechnical or editorial errors. A listing ofissues reviewed by X12N and the X12Nresponse to those issues can be viewedon the Internet at http://www.wpc-edi.com/hipaa/nprm_issues. Thoseworkgroups in turn reviewed thevarious comments and concluded thatthe existing standard and/orimplementation specification: (1)Needed to be changed and made theappropriate changes, (2) alreadyaddressed the concerns raised, so thatno change was needed, (3) were correct,so that no change was needed, or (4)needed to be changed, but that thechanges needed could not be made inthe time available.

Thus, the discussion of the particularX12N standards in the preamble belowgenerally reflects this approach. Thefirst four paragraphs of the discussion ofthe agency’s response to each standardfollows the following general format:

Of those comments we referred to ASCX12N, the work groups determined that [#]comments identified areas where theimplementation specification could beimproved, and the appropriate changes weremade. [#] comments identified businessneeds that ASC X12N judged could alreadybe met within the current standardimplementation specification. Detailedinformation on how the currentimplementation specifications can be used tomeet these business needs has been providedby ASC X12N at the Internet site in§ 162.920. [#] comments alleged technical oreditorial errors in the standardimplementation specification. A technicalreview of these issues was conducted bywork groups within ASC X12N. The workgroups determined that [#] commentsidentified areas where the implementationspecifications were in fact correct and that nochanges were needed. Changes to theimplementation specification were notrequired. There were another [#] commentswhich identified business needs that ASCX12N judged could not be met directlywithin the current standard implementationspecification. The implementationspecifications could not be changed prior tothe issuance of the final regulation becausethe X12 standards development process formodifying standards could not be completedin time. However, a review of the issues bythe ASC X12N work groups has identified ameans of meeting the business needs withinthe existing implementation specification asan interim measure. Organizations andindividuals who submitted such commentsare encouraged to work with the DSMOs tosubmit a request to modify the nationalstandard.

We set out below the number ofcomments that fell into each categorywith respect to each of the standards.The particular groupings above appear,where applicable, as paragraphs (i), (ii),(iii), and (iv), respectively, of the

responses to the comments on eachX12N standard.

a. Transaction Standard for HealthCare Claims or Equivalent EncounterInformation. We proposed in subpart Kthat:

For pharmacy claims, the NCPDPTelecommunications Standard FormatVersion 3.2 and equivalent StandardClaims Billing Tape Format batchimplementation, version 2.0, would bethe standard.

For dental claims, the ASC X12N837—Health Care Claim: Dental,Version 4010, Washington PublishingCompany, 004010X097, would be thestandard.

For professional claims, the ASCX12N 837—Health Care Claim:Professional, Version 4010, WashingtonPublishing Company, 004010X098,would be the standard.

For institutional claims, the ASCX12N 837—Health Care Claim:Institutional, Version 4010, WashingtonPublishing Company, 004010X096,would be the standard.

Comments and Responses on theTransaction Standard for Health CareClaims and Equivalent EncounterInformation: Pharmacy

i. Comment: One commentersuggested that the final rule contain thecorrect version of the NCPDP BatchStandard Version. The correct version is1.0, not version 2.0 as originallyproposed.

Response: We agree to make therecommended change. The correct nameof the standard may be found in§ 162.1102.

ii. Comment: Several commentersrecommended that we reword thissection to state ‘‘version 3.2 or higher.’’This change would allow any approvedversion of the standard to be used.Currently, there are health plans andhealth care providers who haveimplemented a higher version of thestandard.

Response: This final rule adoptsNCPDP Telecommunications StandardFormat, Version 5.1 in place of version3.2. We do not believe that the term ‘‘orhigher’’ is appropriate in that it willallow for variations in the standard usedfor pharmacy transactions. This is themost recently approved version of theNCPDP standard. This version containsrevisions that address comments madeto the proposed rule. There arenumerous other benefits and advantagesto naming Version 5.1. Some of thesebenefits and advantages are thefollowing:

• Expanded dollar fields.• HIPAA supported fields including

Employer ID, Plan ID, and Prescriber(Provider) ID.

• New clinical fields including expandedDiagnosis Code, Patient Height, and PatientBody Surface Area.

• Service transactions for expandedprofessional pharmacy service support.

• Expanded coordination of benefits (COB)support.

• Support of intermediary processing.• Coupon fields.• Expanded response messaging including

preferred product support and approvedmessage codes.

• Flexibility with qualifiers that allows foraddition of qualifier type codes instead ofadding new fields.

• Pricing uniformity.• Controlled Substance reporting support

including Alternate ID and Scheduled Rx ID.• Consistency within the NCPDP

telecommunication standard.• Correction of issues from previous

versions.• Variable length transactions that allow

for trading partners to transmit only the datarequired for doing business (i.e. A v5.1 claimcan be very small when necessary. Refer tothe v5.1 implementation specifications forexamples).

• Supports partial fill indicators.• Additional code values for Drug

Utilization Review (DUR).iii. Comment: One commenter

recommended that the word ‘‘retail’’ beremoved when mentioning the NCPDPstandard since the NCPDPTelecommunications Standard FormatVersion 3.2 and equivalent NCPDPBatch Standards Version 1.0 may beused to bill professional pharmacyservices as well as retail pharmacyservices.

Response: We are adopting theNCPDP standard for retail pharmacyonly. We are adopting the ASC X12N837 for professional pharmacy claims.Professional pharmacy claims use boththe National Drug Code (NDC) andHCPCS j-codes to identify the pharmacyprocedure or service. The NCPDPstandard is designed to accommodatethe NDC only and does not allow forbilling of professional pharmacy claimsusing HCPCS. The NCPDP standardwould require major modifications inorder to accommodate the HCPCScodes.

Comments and Responses on theTransaction Standard for Health CareClaims or Equivalent EncounterInformation: Dental

The majority of commentersexpressed support of the selectedstandard.

i. Of those comments we referred toASC X12N, the work groups determinedthat 246 comments identified areaswhere the implementation specificationcould be improved, and the appropriatechanges were made.

ii. One individual comment identifieda business need that ASC X12N judged



could already be met within the currentstandard implementation specification.Detailed information on how the currentimplementation specifications can beused to meet these business needs hasbeen provided by ASC X12N at theInternet site in § 162.920.

iii. Thirty-one individual commentsalleged technical or editorial errors inthe standard implementationspecification. A technical review ofthese issues was conducted by workgroups within ASC X12N. The workgroups determined that the 31comments identified areas where theimplementation specifications were infact correct and that no changes wereneeded. Changes to the implementationspecification were not required.

iv. There were another 4 individualcomments which identified businessneeds that ASC X12N judged could notbe met directly within the currentstandard implementation specification.The implementation specificationscould not be changed prior to theissuance of the final regulation becausethe X12 standards development processfor modifying standards could not becompleted in time. However, a review ofthe issues by the ASC X12N workgroups has identified a means ofmeeting the business needs within theexisting implementation specification asan interim measure. Organizations andindividuals who submitted suchcomments are encouraged to work withthe DSMOs to submit a request tomodify the national standard.

Comments and Responses on theTransaction Standard for Health CareClaims or Equivalent EncounterInformation: Professional


ii. Thirty-five comments identifiedbusiness needs that ASC X12N judgedcould already be met within the currentstandard implementation specification.Detailed information on how the currentimplementation specifications can beused to meet these business needs hasbeen provided by ASC X12N at theInternet site in § 162.920.

iii. 267 comments alleged technical oreditorial errors in the standardimplementation specification. Atechnical review of these issues wasconducted by work groups within ASCX12N. The work groups determined thatthe 276 comments identified areaswhere the implementationspecifications were in fact correct andthat no changes were needed. Changes

to the implementation specificationwere not required.

iv. There were another 9 commentswhich identified business needs thatASC X12N judged could not be metdirectly within the current standardimplementation specification. Theimplementation specifications could notbe changed prior to the issuance of thefinal regulation because the X12standards development process formodifying standards could not becompleted in time. However, a review ofthe issues by the ASC X12N workgroups has identified a means ofmeeting the business needs within theexisting implementation specification asan interim measure. Organizations andindividuals who submitted suchcomments are encouraged to work withthe DSMOs to submit a request tomodify the national standard.

v. Comment: The majority ofcommenters expressed support for theselected standard. However, there wasconcern that the X12N 837 neithermeets Medicaid’s needs nor supportsbehavioral health services. Onecommenter stated that representatives ofthe alcoholism and substance abusetreatment fields were not adequatelyrepresented in the development of thestandards.

Response: The X12N standards aredeveloped and maintained in an openatmosphere. We strongly encourage allindustry stakeholders to assist in thisprocess to ensure that their businessneeds are met. If Medicaid Agencies orother entities believe their businessneeds will not be met through theselected standard, we encourage them tosubmit any new data requests to theDSMOs. We will be monitoring theDSMOs’ process for the revision ofstandards to ensure that they are revisedappropriately.

vi. Comment: Several commentersstated that the adoption of the claimstandard without the attachmentstandard will create processingproblems. They stated there is apotential that certain claims that requirean attachment will need to beadjudicated manually.

Response: The health care claims orequivalent encounter informationstandard currently contains manyjustification requirements for certainservices, including oxygen, chiropractic,ambulance, and durable medicalequipment services. Therefore, theseclaims will not have to be adjudicatedmanually. Once the attachment standardis adopted, we expect that thejustification requirements for theservices listed above will be met by theattachment standards and, therefore,will be removed from the health care

claims or equivalent encounterinformation standard. All otherattachments that are not in thistransaction or are not met by theattachment standard will need to beadjudicated manually.

Comments and Responses on theTransaction Standard for Health CareClaims or Equivalent EncounterInformation: Institutional


ii. Three comments identifiedbusiness needs that ASC X12N judgedcould already be met within the currentstandard implementation specification.Detailed information on how the currentimplementation specifications can beused to meet these business needs hasbeen provided by ASC X12N at theInternet site in § 162.920.

iii. 54 comments alleged technical oreditorial errors in the standardimplementation specification. Atechnical review of these issues wasconducted by work groups within ASCX12N. The work groups determined thatthe 54 comments identified areas wherethe implementation specifications werein fact correct and that no changes wereneeded. Changes to the implementationspecification were not required.


v. Comment: The majority ofcommenters expressed support of theselected standard.

Several commenters stated that theywanted the UB92 to be selected as theinstitutional claim standard since it iswidely used. Several commentersdisagreed that the X12N 837 met all ofthe guiding principles. The guidingprinciples are:

(1) Improve the efficiency and effectivenessof the health care system by leading to cost



reductions for, or improvements in benefitsfrom, electronic health care transactions.

(2) Meet the needs of the health datastandards user community, particularlyhealth care providers, health plans, andhealth care clearinghouses.

(3) Be consistent and uniform with theother standards required under this part—their data element names, definitions, andcodes and the privacy and securityrequirements—and with other private andpublic sector health data standards, to theextent possible.

(4) Have low additional development andimplementation costs relative to the benefitsof using the standard.

(5) Be supported by an ANSI-accreditedstandard setting organization or other privateor public organization that will ensurecontinuity and efficient updating of thestandard over time.

(6) Have timely development, testing,implementation, and updating procedures toachieve administrative simplificationbenefits faster.

(7) Be technologically independent of thecomputer platforms and transmissionprotocols used in electronic healthtransactions, except when they are explicitlypart of the standard.

(8) Be precise and unambiguous, but assimple as possible.

(9) Keep data collection and paperworkburdens on users as low as is feasible.

(10) Incorporate flexibility to adapt moreeasily to changes in the health careinfrastructure (such as new services,organizations, and provider types) andinformation technology.

The principles in question were 1, 4,6, 8, 9 and 10.

There was also concern that the X12N837 does not meet the needs of manyState Medicaid agencies. Differentagencies require codes and dataelements that are not in the transactionstandard.

Response: While the UB92 issupported by many institutions, it is notused in a standard manner. To undergoa national UB92 standardization effort isnot practical since the X12N 837 meetsinstitutional needs and the majority ofcommenters support the selection of allX12N transactions.

We believe the X12N 837 meets all ofthe guiding principles in question.Implementation of the X12N 837 usingthe specifications defined in theimplementation specification forversion 4010 will lead to administrativesimplification and cost savings for bothhealth plans and health care providers.One nationally accepted standard willexist, rather than a variety of nationaland local formats (#1). We believe thatthe long-term savings that will accruefrom the adoption of the standard willoffset the short-term implementationcosts (#4) (see section VI. Final ImpactAnalysis). The DSMOs have a processfor the development and maintenance of

transactions and implementationspecifications that include many qualityand technical assurance checkpointsprior to the approval of X12 standardsand X12N industry implementationspecifications (#6). Uniformimplementation of the standards iscritical. The implementationspecifications provide for standard aswell as unambiguous data contentrequirements for all users of eachtransaction (#8). Exchange of the X12N837 standard transaction does notrequire increased data collection orpaperwork burden (#9). The X12N 837standard and syntax allow for the easyaddition of new business functions. Forexample, instead of listing all CPTcodes, the implementation specificationrefers to the code source. The standarduses qualifiers to aggregate general datacontent into unambiguous businesstransactions (#10). If an external codeset is updated, the standard transactionwould not have to be updated since thecodes are external to theimplementation specification. Qualifiersallow for the precise definition ofgeneric fields, such as dates.

As part of the proposed rule commentprocess, commenters were encouragedto review the implementationspecifications. Many commenterssubmitted requests for data needs orchanges to the implementationspecifications and, thus, we believethere has been ample time to review andsubmit these requests. If Medicaidagencies or other entities did notidentify all of their business needs, theywill need to submit new data requeststo the DSMOs.

We note that health plans and coveredhealth care providers that do businesswith Medicaid agencies will be requiredto use the standards within the 24month implementation period (36months for small health plans). Webelieve it would be inconsistent withthe statutory intent to require theseentities to support non-standardrequirements solely for individual StateMedicaid agencies, especially wherethose health plans and health careproviders operate in more than oneState. HCFA and the DSMOs standready to assist the State agencies withtheir transitions to the standards.

b. Transaction Standard for HealthCare Payment and Remittance Advice.In subpart L, redesignated as subpart P,we proposed ASC X12N 835—HealthCare Claim Payment/Advice, Version4010, Washington Publishing Company,004010X091 as the standard for healthcare payment and remittance advice.

Comments and Responses on theTransaction Standard for Health CarePayment and Remittance Advice

The majority of commentersexpressed support of the selectedstandard.


ii. Seven comments identifiedbusiness needs that ASC X12N judgedcould already be met within the currentstandard implementation specification.Detailed information on how the currentimplementation specifications can beused to meet these business needs hasbeen provided by ASC X12N at theInternet site in § 162.920.

iii. Fifteen comments allegedtechnical or editorial errors in thestandard implementation specification.A technical review of these issues wasconducted by work groups within ASCX12N. The work groups determined thatthe 15 comments identified areas wherethe implementation specifications werein fact correct and that no changes wereneeded. Changes to the implementationspecification were not required.

iv. Comment: A number ofcommenters asked that they be allowedto continue to use proprietary codes,narrative information, and their currentalternate uses of selected ASC X12N 835segments.

Response: We disagree. Permitting thecombined use of nonstandard datacontent would not comply with theintent of the statute. The ASC X12N 835format is intended to be fully machinereadable, so that there can be totallyautomated posting of transactions topatient and health care provideraccounts wherever used, regardless ofthe health plan.

We encourage health care providersand health plans who have a businessneed for additional information in theASC X12N 835 format to providebackground to the DSMOs on the needso the ASC X12N 835 implementationspecification can be modified for afuture version, or so that the DSMOs canadvise commenters how their businessneeds can be met within the currentimplementation specification. ASCX12N made a number of changes in the4010 implementation specification as aresult of such comments on theproposed rule. In most cases, however,commenters who indicated that currentcode sets were inadequate did notsubmit any specific suggestions orrequests with respect to the changesthey needed. The DSMOs cannot



consider an implementationspecification modification to meet aneed if the need has not been defined.We strongly encourage health plans andhealth care providers to participate inthis process so that their needs are met.

v. Comment: Some commentersquestioned why the ASC X12N 835 didnot explain the basis for the paymentissued.

Response: The ASC X12N 835 is notintended to explain how the amount ofpayment for a service is determined. Ahealth care payment and remittanceadvice, as embodied in the ASC X12N835 format, primarily exists to notify thehealth care provider of the amountbeing paid for a set of bills and, if thatpayment does not equal the amountbilled, to briefly explain everyadjustment applied to those bills by thehealth plan. A health care payment andremittance advice is not a vehicle forinstructing health care providers oncoverage policy, except to briefly referto that policy when it is the reason fordenial or reduction of a billed service.Information on policy type and coveragerules is more appropriately included ona health plan’s membership card andthe coverage information shared withthe subscriber and/or a health careprovider at enrollment or in subsequentnewsletters.

vi. Comment: A number of healthplans requested that the ASC X12N 835format be rearranged to more closelyparallel the internal flat file they use fortheir claims systems in order tominimize the programming changesthey would need to make in order tocomply with version 4010 of the ASCX12N 835. They argued that they didnot consider it administratively simplerif they had to make extensiveprogramming changes.

Response: We considered thesecomments. In some cases, theimplementation specification waschanged, but for the most part, suchrequests could not be accommodated.HIPAA requires that United Stateshealth plans and certain health careproviders, or their clearinghouses, usenational health care transactionstandards. Health care providers andhealth plans have flexibility in how theywill implement the standards. They maychoose to utilize a health careclearinghouse to process theirtransactions. By definition, a health careclearinghouse is used to translate non-standard format into a standard format,or vice-versa. When a health plan orhealth care provider uses a health careclearinghouse for those functions, theymay be able to minimize programmingchanges. There are also a wide varietyof software vendors from whom they

may choose to purchase translationsoftware.

vii. Comment: Some commentersasked for more generic codes in the ASCX12N 835 version 4010 implementationspecification so that a health plan cansimply report a service as denied orreduced, without the need to furnishmore explanation on the reason for thedenial or reduction.

Response: Health care providers needto have adequate details on the ASCX12N 835 transaction that they receivein order to enable them to not only postaccounts, but to decide whether anappeal should be filed, or further actiontaken in response to the health plan’sdecision on a claim. A failure to supplyadequate reasons for denial or reductionwould undermine the effectiveness ofan ASC X12N 835 transaction.

viii. Comment: A few commentersasked for a code to indicate that a healthplan was knowingly issuing an ASCX12N 835 transaction that did notbalance. It was reasoned that not allhealth plans might be able to issue anASC X12N 835 transaction that balanceswhen the transaction becomes effectiveas a national health care standard.

Response: This request can not beaccommodated. As explained in theimplementation specification, an ASCX12N 835 transaction must balance atthe line, claim and provider levels. Tobe in balance, the amount billed, lessthe amount of any adjustments, mustequal the amount paid. An out ofbalance ASC X12N 835 would not be incompliance with the version 4010implementation specification. Healthplans are responsible for making allchanges as needed to issue completeand compliant ASC X12N 835 version4010 transactions. An out of balanceASC X12N 835 is of little to no value toa health care provider, raises morequestions than it settles, and consumesthe resources of health care providersand health plans who must explain whyit does not balance.

ix. Comment: A health careclearinghouse asked if it would shareany liability for non-compliance if itforwarded out of balance remittancedata from a health plan to a health careprovider.

Response: Liability issues will bediscussed in a later enforcementregulation.

x. Comment: One commenter askedthat all new codes or changes to codesconsidered for inclusion in an ASCX12N 835 implementation specificationbe circulated to all health plans forreview and comment prior to inclusion.

Response: This is not practical at thistime. There is not yet a central registryof health plans and, even if there were,

the cost of such distribution andanalysis of responses would be asignificant financial burden on the codeset maintainers. Such a process wouldalso greatly extend the clearance timefor such changes, preventingmaintainers from meeting immediatebusiness needs. Affected health planscan comment on code additions andchanges included in or referred to in alater implementation specificationthrough the maintenance andmodification process set out at§ 162.910. Affected health plans are alsoencouraged to increase theirinvolvement with the organizationsresponsible for code set maintenance.Health plans are encouraged to submitany new data requests to the DSMOs.

xi. Comment: A few State Medicaidagencies requested that they bepermitted to use the ASC X12N 835format, rather than the ASC X12N 820,to pay premiums to managed carecompanies under contract to providecare to Medicaid beneficiaries.

Response: Although the ASC X12N835 can accommodate claims andcapitation payments to health careproviders, including managed carecompanies, the payments described inthese comments are considered healthplan premium payments, rather thanpayment for direct patient care. Asdiscussed below under ‘‘Comments andResponses on the Transaction Standardfor Health Plan Premium Payments,’’ allhealth plan premium payments must betransmitted with the ASC X12N 820standard for consistency. Also, the ASCX12N 820 Payroll Deducted and OtherGroup Premium Payment for InsuranceProducts implementation specificationincludes some data elements notcontained in the ASC X12N 835,because it was designed specifically forpremium payment, rather than claimpayment.

xii. Comment: A number ofcommenters questioned whether theywould be prohibited from use of theautomated clearinghouse (ACH)transaction for electronic funds transfer(EFT) of health care payments once theASC X12N 835 is effective as a HIPAAtransaction standard.

Response: The ACH is an acceptablemode of EFT under both the ASC X12N835 and 820 transactions. Theimplementation specifications for theASC X12N 835 and 820 transactionscontain two parts, a mechanism for thetransfer of dollars and one for thetransfer of information about thepayment, and allow these two parts tobe transmitted separately. Consistentwith the implementation specifications,actual payment may be sent in a numberof different, equally acceptable ways,



including check and several varieties ofelectronic funds transfer. When thetransfer of funds is part of paying ahealth care premium or a health careclaim, the ACH transaction maycontinue to be used as a valid part of anASC X12N 835 or 820 transaction wherethe other part of the transaction is sentto the health plan or health careprovider, directly or indirectly (througha clearinghouse or financial institution).Although these standard transactionsallow transmission of one or both partsthrough a financial institution, they donot require both parts to be sent to thefinancial institution and the financialinstitution is not required by thisregulation to accept or forward suchtransactions.

Health plans may continue to use theACH transaction alone to authorize thetransfer of funds (electronic fundstransfer) when such transfer is not partof paying a health care premium or ahealth care claim for an individual,because such a transaction would not bea transaction covered under this part.The Department of the Treasury hasconfirmed that this standard does notconflict with their requirements fordisbursements.

xiii. Comment: One commentercriticized the ASC X12N 835 format asinadequate to explain benefit paymentsto subscribers. The commenter wasunder the impression that ASC X12N835 transactions would be issuedelectronically to patients as well ashealth care providers or theirclearinghouses.

Response: We clarify that the ASCX12N 835 will be sent from a healthplan to health care providers and/orhealth care clearinghouses. We are notregulating the explanations of benefits(EOBs) that health plans send to theirsubscribers. We believe subscribers willstill receive an adequate explanation ofbenefits.

xiv. Comment: A health plan asked ifit would be prohibited from sendingpaper EOBs to a health care providerwho was sent an ASC X12N 835transaction for the same claims. Thehealth plan currently issues electronicremittance advice but includes appealinformation only on the correspondingpaper remittance advice. The healthplan was concerned about how it coulddistribute appeal information for deniedor reduced claims.

Response: A health plan can choose tocontinue to send paper remittanceadvice notices to health care providersthat are issued ASC X12N 835transactions. However, all informationin the paper notice that could have beenexpressed in the X12N 835 must beincluded in the X12N 835 transaction. If

a health plan has a need to send datathat is not on the X12N 835, it needs towork with the DSMOs to submit arequest to modify the standard. It isanticipated, however, that withexpanded acceptance of electronictransactions by health care providers,and increases in automatedcoordination of benefits among healthplans, there may be less of a need forpaper remittance advice notices. Atsome point, health plans may be able toreduce or eliminate most paperremittance notices to health careproviders capable of receiving of theelectronic notices.

Also, the ASC X12N 835 transactionmay be used to notify a health careprovider of appeal rights by using the‘‘remark codes’’ segment. Please see theremark code menu item at www.wpc-edi.com for a listing of currentlyapproved remark codes and instructionson how to request additional remarkcodes to meet your business needs.

xv. Comment: One commenter wasconfused as to whether the NCPDPstandard for real time remittanceinformation could continue to be usedonce version 4010 of the ASC X12N 835became the national Health CarePayment and Remittance Advicestandard.

Response: Yes, the NCPDPTelecommunications Standard Formatmay continue to be used for real timepharmacy transactions because it isdesigned to apply to such transactions.The ASC X12N 835 is the standardtransaction for dental, professional, andinstitutional health care payment andremittance advice. The NCPDP standardwas not originally proposed due to anoversight on our part regarding thefunctionality of the standard. TheNCPDP standard is used for both claimand health care payment and remittanceadvice and is being adopted as thestandard transaction for retailpharmacy.

xvi. Comment: A few commentersasked for guidance as to when version4010 of the ASC X12N 835 might sunsetin favor of a later version or areplacement format. They also askedwhether version 4010 and a replacementversion/format could be operatedconcurrently for 90 days or more toallow for an orderly conversion ofhealth plans and health care providersbetween versions/formats.

Response: These issues will beaddressed when the Secretaryannounces any successor version/formatto version 4010 of the ASC X12N 835.Under HIPAA, however, as a generalrule, new versions or formats cannot berequired more than once every 12months and health care providers must

be allowed a minimum of 180 daysadvance notice to enable them tocomply with the change. We doanticipate a need for a crossover periodof at least 90 days to convert betweenversions/formats during which both theold and new versions/formats will needto be supported.

xvii. Comment: It was suggested thatthe ASC X12N 997 format be expandedor new format developed andrecognized as a HIPAA standard toallow health care providers or healthcare clearinghouses to notify a healthplan of some problem with the formator content of an ASC X12N 835transaction.

Response: This issue has beenreferred to X12N. There is noimplementation specification for atransaction of this type at present, butsuch a transaction can be considered foraddition to the published HIPAAstandards if and when it is developed,and the implementation specification iswritten.

xviii. Comment: One commenter wasconcerned that patient privacy could beviolated if a full ASC X12N 835transaction is sent to a health careprovider’s bank. The commenter askedwhat will be done to secure that data.

Response: A separate enforcementrule will address the penalties forviolating the HIPAA rules. Separateprivacy and security regulations arebeing prepared that will address privacyand security restrictions for healthinformation.

xix. Comment: Several commentersrecommended that we include theNCPDP telecommunications Standard3.2 for the submission of remittanceadvice for the pharmacy service sector.Another commenter said that they usethe NCPDP telecommunicationsStandard 3.2 for the claim andremittance transactions. Severalcommenters said the NCPDP meets theirbusiness needs and there is no businessneed to move to the ASC X12N 835transaction for remittance adviceinquiries.

Response: We agree with thecommenter that remittance informationis integral to the NCPDPTelecommunications Standard namedin the proposed rule for retail pharmacyclaims. As discussed previously, we arenaming the NCPDPTelecommunications Standard 5.1 andNCPDP Batch Standard as the standardfor health care payment and remittanceadvice within the retail pharmacysector. We have added this requirementto § 162.1602.

c. Transaction Standard forCoordination of Benefits. In subpart M,redesignated in this rule as subpart R,



we proposed as the standards forcoordination of benefits the following:

For pharmacy claims, the NCPDPTelecommunications Standard FormatVersion 3.2 and equivalent StandardClaims Billing Tape Format batchimplementation, version 2.0.

For dental claims, the ASC X12N837—Health Care Claim: Dental,Version 4010, Washington PublishingCompany, 004010X097.

For professional claims, the ASCX12N 837—Health Care Claim:Professional, Version 4010, WashingtonPublishing Company, 004010X098.

For institutional claims, the ASCX12N 837—Health Care Claim:Institutional, Version 4010, WashingtonPublishing Company, 004010X096.

Comments and Responses on theTransaction Standard for Coordinationof Benefits: Pharmacy

Comment: One commenter suggestedthat the final rule contain the correctversion of the NCPDP Batch StandardVersion. The correct version is 1.0, notversion 2.0 as originally proposed.

Response: We agree to make therecommended change for the batchstandard. The proposed version 2.0 wasincorrect. The correct name of thestandard may be found in § 162.1802.We are also changing the version to theNCPDP Telecommunications StandardFormat Version for COB. The version is5.1 as previously discussed.

Comments and Responses on theTransaction Standard for Coordinationof Benefits: Dental, Professional,Institutional

i. Comment: One commenterrecommended that claim/encounter dataitems should be distinguished fromthose data items that are part of the COBtransaction process.

Response: One implementationspecification is used for claims andcoordination of benefits. Theimplementation specification clearlydistinguishes between coordination ofbenefits data and claim data. Forexample, each coordination of benefitsdata element contains notes specifyingwhen a particular data element is used.

ii. Comment: The majority ofcommenters supported the selection ofthe ASC X12N 837 for the coordinationof benefits exchange standard. Somecommenters believe that the decision toconduct COB in a certain manner is abusiness decision and not within thescope of HIPAA. Others would like allhealth plans to be required toparticipate in COB exchange using theplan to plan model in which the healthcare provider supplies the primaryinsurer with information needed for the

primary insurer to then submit theclaim directly to the secondary insurer.Several commenters stated that the planto plan model would be quite costly andshould be closely evaluated before beingadopted at a national level.

Concern was expressed that if thestandard COB transaction were sent toa health plan that does not conduct COBtransactions, the health plan wouldreject the standard COB transactionbecause it contained COB information.

Response: Coordination of Benefitscan be accomplished in two ways, eitherbetween health plans and other payers(for example, an auto insurancecompany), or from a health careprovider to a health plan or other payer.The choice of model is up to the healthplan.

Under this rule health plans are onlyrequired to accept COB transactionsfrom other entities, including those thatare not covered entities, with whichthey have trading partner agreements toconduct COB. Once such an agreementis in place, a health plan may not refuseto accept and process a COB transactionon the basis that it is a standardtransaction. For example, a health planreceives a standard ASC X12N 837transaction from a health care providerwith which it has a COB trading partneragreement. If the health plan is not theprimary payer, it must accept andprocess the COB information toadjudicate the claim. If the health planhas decided to conduct COBtransactions with another payer, it mustaccept and store the COB information touse in a COB transaction with the otherpayer. If the health plan is the primarypayer and does not have a tradingpartner agreement with the secondarypayer, then it may simply dispose of theCOB information and leave the COBactivity up to the health care provider.

If a health plan electronicallyconducts COB with another health planit must do so using the standardtransaction. A health care provider thatchooses to conduct COB electronicallywith a health plan must do so using thestandard transaction. A COBtransmission between a health careprovider and a payer that is not a healthplan would not be subject to therequirements of this rule; nor would thetransmission of a COB transaction froma health plan to another payer that is notanother health plan.

d. Transaction Standard for HealthCare Claim Status. In subpart N, weproposed the ASC X12N 276/277 HealthCare Claim Status Request andResponse, Version 4010, WashingtonPublishing Company, 004010X093 asthe standard for health care claim status.

Comments and Responses on theTransaction Standard for Health CareClaim Status

The majority of commentersexpressed support for the selectedstandard.

i. Of those comments we referred toASC X12N, the work groups determinedthat all 94 comments identified areaswhere the implementation specificationcould be improved, and the appropriatechanges were made.

ii. Comment: We received severalcomments questioning whether the ASCX12N 277 ‘‘Unsolicited Claims StatusRequest’’ transaction will be included asa HIPAA standard transaction.

Response: The HIPAA transactionrequirements do not include the ASCX12N 277 ‘‘Unsolicited Claims StatusRequest.’’ We expect to consider thistransaction for adoption in a futureregulation.

iii. Comment: Several commentersquestioned whether a health careprovider is mandated to use the ASCX12N 276 Health Care Claim StatusRequest transaction.

Response: A health care providermust use the ASC X12N 276 Health CareClaim Status Request transaction whentransmitting the transactionelectronically to a health plan. Thehealth care provider has the option tosubmit nonstandard transactions to ahealth care clearinghouse for processinginto the standard transaction and may ofcourse choose to submit transactions inpaper form.

iv. Comment: Several commentersquestioned whether a health plan willbe required to respond to an ASC X12N276 request from a health care providerwho did not have a businessarrangement with the health plan.

Response: A health plan may notrefuse to process a transaction simplybecause it is a standard transaction.Whether a health plan may refuse toprocess a transaction on other groundsmay depend upon the particularbusiness agreements the health plan haswith the sender. Health plans may havecontracts that require them to processout of service area transactions. Use ofa standard transaction does not create arelationship or liability that does nototherwise exist. A health plan wouldnot be required by these rules torespond to such a request from a healthcare provider with whom it does nothave a business arrangement.

v. Comment: We received severalcomments relating to whether a State orhealth plan will be required to supportthe ASC X12N 276/277 transactions ifthey are currently using anotherapplication to provide this information.



Response: All health plans, includingstate Medicaid plans, must have thecapability to accept, process, and sendthe ASC X12N 276/277 transactions.

e. Transaction Standard forEnrollment and Disenrollment in aHealth Plan. In subpart O, we proposedthe ASC X12N 834—Benefit Enrollmentand Maintenance, Version 4010,Washington Publishing Company,(004010X095) as the standard forenrollment and disenrollment in ahealth plan.

Comments and Responses on theTransaction Standard for Enrollmentand Disenrollment in a Health Plan



ii. Ten comments identified businessneeds that ASC X12N judged couldalready be met within the currentstandard implementation specification.Detailed information on how the currentimplementation specifications can beused to meet these business needs hasbeen provided by ASC X12N at theInternet site in § 162.920.

iii. Twenty comments allegedtechnical or editorial errors in thestandard implementation specification.A technical review of these issues wasconducted by work groups within ASCX12N. The work groups determined thatthe 20 comments identified areas wherethe implementation specifications werein fact correct and that no changes wereneeded. Changes to the implementationspecification were not required.

iv. There was one comment whichidentified a business need that ASCX12N judged could not be met directlywithin the current standardimplementation specification. Theimplementation specifications could notbe changed prior to the issuance of thefinal regulation because the X12standards development process formodifying standards could not becompleted in time. However, a review ofthe issue by the ASC X12N work groupshas identified a means of meeting thebusiness need within the existingimplementation specification as aninterim measure. Organizations andindividuals who submitted suchcomments are encouraged to work withthe DSMOs to submit a request tomodify the national standard.

v. Comment: Several commenters saidthat health plans must be free to acceptenrollment data in non-standard formats

if that option is chosen by a sponsor. Inthe proposed rule we stated, we wouldrequire health plans to use only thestandard specified in § 142.1502 (63 FR25293). Commenters suggested that wenot include the word ‘‘only’’ in the finalrule under health plan requirements.One commenter suggested the additionof the following language to the rule:‘‘However, health plans may requiretrading partners to use the standardtransaction to conduct business.’’

Response: We recognize that entitiesthat are not covered under HIPAA, suchas sponsors of health plans, includingemployee welfare benefit plans, are notrequired to use the HIPAA standards toperform EDI with health plans. Theproposed rule stated that health plansare required to use only the standardspecified in § 142.1502 for electronicenrollment and disenrollment in ahealth plan transactions. Sponsors, oneof the primary trading partners withwhom the health plans exchangeenrollment and disenrollment in ahealth plan transactions, were proposedto be excluded from the requirements.Our reference to the requirements forhealth plans to accept ‘‘only’’ thestandard specified was intended topreclude health plans from using data informats other than the standardtransaction when exchangingtransactions with entities named in thelaw. It was not intended to imposerequirements on sponsors. Thus,sponsors remain free to send enrollmentdata in nonstandard format if theychoose, and health plans are free toaccept the data.

We expect that sponsors mayvoluntarily accommodate a healthplan’s request to use the ASC X12N 834by directly submitting the transaction instandard format or by using a healthcare clearinghouse to translate non-standard data into the standardtransaction.

vi. Comment: Several commenterssaid that the ASC X12N 834 should notbe used to collect demographic data forpublic health and health data research.A number of other commenters said thatthe ASC X12N 834 should be used forthis purpose. These commenters alsorecognized that the demographic datacollected by the ASC X12N 834, such asaddress, could change frequently.Commenters noted that the datacollected in the ASC X12N 834 isneeded by the enrolling entity so that itcan perform certain functions, such asdetermining the eligibility of a personfor enrollment into their offered healthplan.

Response: The ASC X12N 834 is usedto enroll and disenroll subscribers in aparticular health plan, and demographic

data are included in the data content.The decision to include demographicdata as required data content was madethrough the ASC X12N 834 work groupfollowing the usual standardsdevelopment process. We support theinclusion of such data in theimplementation standard. Thecollection of demographic data is ameans of monitoring progress towardseliminating disparities in health care forpopulations that historically haveexperienced discrimination anddifferential treatment based on factorssuch as race and national origin. Werecognize the ASC X12N 834 BenefitEnrollment and Maintenancetransaction set as the most favorablevehicle for collecting these data due tothe mostly static nature of demographicinformation. While the public healthand health research community doesnot currently have access to theenrollment data, we support asecondary use of the ASC X12N 834 forpublic health and health research. Wesee this as a mechanism for opening thelines of communication between thehealth data research community and theholders of the data.

Current Departmental policy supportsincreasing the use of demographic datafor researching disparities in health careamong demographic groups. However,the research community generally doesnot have access to the data collected bysponsors on the ASC X12N 834. Whilethe research community is not opposedto collecting demographic data on theASC X12N 834, they have requested thatthis data also be collected on the ASCX12N 837. This request would make nochange to the ASC X12N 834implementation specification. Most ofthe demographic data in the ASC X12N837 implementation specification ismarked as not used. As stated above,most of the demographic data in theASC X12N 834 is currently not availableto the research community. Thebusiness needs of the researchcommunity must be presented to theX12N 837 work group for considerationin a future version of theimplementation specification.

We recognize that the enrollment anddisenrollment in a health plantransaction was designed for use mainlyby sponsors, but sponsors are notrequired by HIPAA to use the standard.Additionally, the conditions for use ofthe demographic data are stringent, asfollows: ‘‘This data should only betransmitted when such transmission isrequired under the insurance contractbetween the sponsor and payer andallowed by federal and stateregulations.’’ Therefore, we would notexpect to see a widespread increase in



the collection of demographic datawhen these standards are implementedfor the first time. Nor would we expectthat this arrangement would providepublic health and researchers withincreased access to demographicinformation because of the difficultycreating dependable linkages betweenenrollment and encounter data.

If demographic data were collectedroutinely, facilities would more easilydemonstrate compliance with Title VIIof the Civil Rights Act of 1964, thenondiscrimination provisions of healthand social services block grantprograms, and other program statutesand regulations which prohibitdiscrimination on the basis of race ornational origin.

Therefore, the Department intends towork with the industry to supportefforts to revise future versions of theHealth Care Claims or EquivalentEncounter Information (ASC X12N 837)implementation specification to allowcollection of demographic data. We alsosupport conditions for collection ofthese data that are less stringent thanspecified in the enrollment anddisenrollment in a health plantransaction implementationspecification. Many claim transactionscannot be linked to their respectiveenrollment data. Allowing transmissionof racial and ethnic data in both theenrollment and disenrollment in ahealth plan and the claim transactionsets will increase the probability thatthis important information is availablefor utilization review, quality of careinitiatives, disparity andnondiscrimination monitoring, andresearch. The Secretary believes it iscritical to collect these data for thefollowing reasons, all of which are highpriorities for the Department:

• The need to measure racial and ethnicdisparities in type, volume andappropriateness of care received.

• The need to focus efforts in areas/populations/health plans where there isevidence of disparities based on race andnational origin.

• The need to monitor progress towardseliminating disparities in health and healthcare.

• The need to monitor and enforce statutesand regulations that prohibit discriminationon the basis of race and national origin.

We strongly recommend that thehealth care industry, including thepublic health and research community,work with the appropriate contentcommittees and standard settingorganizations to come to consensus onan approach that will enhance thecollection of demographic data as wellas be acceptable to the entire health carecommunity. Departmental

representatives to these committees andorganizations will participate actively inthis process, including articulation ofthe essential business needs. A solutionthat has met the test of the consensusprocess may be adopted as a nationalstandard under HIPAA. The solutionshould promote uniformity,comparability, and the increasedavailability of demographic data forentities that depend upon this data tomonitor progress towards eliminatingdisparities in health care. As we workwith the data content committees andstandard setting organizations to reachconsensus on an approach that willenhance the collection of demographicdata, the Department plans to exploreapproaches, including demonstrationprojects, for promoting and facilitatingthe voluntary collection of high qualitydemographic data in the health careenvironment.

vii. Comment: We received severalcomments regarding the role andresponsibility of State agencies’ use ofthe ASC X12N 834. One commenterstated we need to make it clear that ifa State Health Agency does notparticipate in the enrollment function, itis not required to use the standard.

Response: Health plans, includingState health agencies, are not required toconduct a standard transaction basedsolely on the fact that it is a standardtransaction.

viii. Comment: Other commentersalso asked what we recommend as aprocess and structure for the submissionof monthly capitation claims from amanaged care health plan to a StateMedicaid agency.

Response: We interpret ‘‘process andstructure’’ to mean implementationspecification and standard transaction.Monthly capitation claims from amanaged care organization (MCO) to aState Medicaid Agency do not fallwithin the rules we have established fortransactions between health plans. Thetransaction does not meet the definitionof a health care claim or equivalentencounter information transaction. Itdoes not need to be conducted as astandard transaction.

ix. Comment: Another commentersaid that an interface between a Stateand the State’s processing associate,specifically for data entry, should not berequired to be in standard format.

Response: We agree. In this scenario,data entry does not fall within any ofthe definitions for standard transactions.Consequently, the communication fordata entry purposes does not need to bein standard format.

x. Comment: Several commenters saidthat a State Medicaid program isexcepted from using the ASC X12N 834

when contracting with a managed carehealth plan because it is functioning asa sponsor.

Response: A State Medicaid programis acting as a sponsor and is exceptedfrom the HIPAA standard requirementsonly when purchasing coverage for itsemployees. The State Medicaid programis not acting as a sponsor whenenrolling Medicaid recipients incontracted managed care health plans,and thus is not excepted from the law.

xi. Comment: Several commenterssaid that the ASC X12N 834 should notapply to the State ‘‘buy-in’’ process.

Response: The transmission betweena State Medicaid Agency and HCFA forthe purpose of buy-in is outside of thescope of this requirement. State buy-in,the process by which State Medicaidprograms pay only the Medicarepremium for certain categories of duallyeligible individuals, is essentially aMedicaid subsidy, required underFederal law, of Medicare insurance.This transaction is neither anenrollment and disenrollment in ahealth plan nor a health plan premiumpayment transaction. It is a uniquetransaction created solely for thepurpose of the buy-in program. Statesuse a unique flat-file and codingstructure for transmitting to HCFA a listof Medicaid beneficiaries who arealready enrolled in Medicare whoseincome level entitles them to participatein the buy-in program for that month.HCFA then creates an internal billingfile with accretions and deletions foreach state. A paper billing notice,reflecting the total amount of premiumsowed by the state for that month, ismailed to the state. The Medicaidagency sends premium payment toHCFA via Federal Wire to Treasury. Noelectronic health plan premiumpayment transaction occurs betweenHCFA and the Medicaid agency.

f. Transaction Standard for Eligibilityfor a Health Plan. In subpart P,redesignated in this rule as subpart L,we proposed the ASC X12N 270—Health Care Eligibility/Benefit Inquiryand ASC X12N 271—Health CareEligibility/Benefit Response, Version4010, Washington Publishing Company,(004010X092) as the standard foreligibility for a health plan.

Comments and Responses on theTransaction Standard for Eligibility fora Health Plan


i. Of those comments we referred toASC X12N, the work groups determinedthat 224 comments identified areaswhere the implementation specification



could be improved, and the appropriatechanges were made.

ii. Eleven comments identifiedbusiness needs that ASC X12N judgedcould already be met within the currentstandard implementation specification.Detailed information on how the currentimplementation specifications can beused to meet these business needs hasbeen provided by ASC X12N at theInternet site in § 162.920.

iii. Seven comments alleged technicalor editorial errors in the standardimplementation specification. Atechnical review of these issues wasconducted by work groups within ASCX12N. The work groups determined thatthe 7 comments identified areas wherethe implementation specifications werein fact correct and that no changes wereneeded. Changes to the implementationspecification were not required.


v. Comment: We received oneindividual comment requesting changesto a set of codes which were notmaintained by X12 or by a Federalagency, but were maintained by anexternal code source maintaining body.

Response: All code sources external tothe X12 standard are listed in section Cof the implementation specifications.All of these code sources have amechanism for modifying their codes.The contact listed in the X12 codesource list can provide detailedinformation regarding the process forupdating their codes. The X12Nsubcommittee can also assist entities indetermining how to contact an externalcode source maintenance body in orderto request changes to the codes. Codesets not listed in the external code setappendices in the implementationspecifications fall within X12Njurisdiction and are maintained throughthat organization’s data maintenanceprocedures, in conjunction with theDSMOs.

vi. Comment: Several commentersrecommended that we include theNCPDP telecommunications Standard3.2 for the pharmacy service sectoreligibility inquiries. One commentersaid that this is the only automatedeligibility inquiry allowed for use bypharmacy providers. A commenter saidthat it uses the transaction (the NCPDPtelecommunications Standard 3.2) forthe pharmacy service sector for bothclaim and eligibility transactions.Finally, additional commenterssuggested that there is no business needthat should force health care providersto move to the ASC X12N 270/271transaction for the pharmacy servicesector for eligibility inquiries. It wasstated that thousands of eligibilitytransactions are performed each monthby pharmacies and health plans usingthe NCPDP telecommunicationsStandard 3.2. Furthermore, there is nobenefit in moving to the ASC X12N 270/271 for pharmacy eligibility inquiriessince the NCPDP telecommunicationsStandard 3.2 is already fully supported.

Response: We agree with thecommenter that eligibility andenrollment are integral to the NCPDPTelecommunications Standard namedin the proposed rule for retail pharmacyclaims. We name the NCPDPTelecommunications Standard 5.1 andthe NCPDP Batch Standard as thestandard for patient eligibility andcoverage information within the retailpharmacy sector since the eligibilityinformation is part of the NCPDPstandard. We have added thisrequirement to § 162.1202.

vii. Comments: Several commenterssuggested that the ASC X12N 270/271Eligibility Roster implementationspecification for eligibility for a healthplan should be adopted as a HIPAAstandard. One commenter suggested thatthe description of the rosterimplementation is incorrect in that itstates that the roster is a separate partof the 270/271. The commenter went onto explain that the roster is essentiallythe same transaction as that beingrecommended for response to an X12N270 inquiry, but the implementationspecification has different values insome of the segments so that the X12N271 response can be sent without anassociated inquiry, and so that thehierarchy of benefits can be more fullydescribed. It was also suggested that theexample of a health plan sending theX12N 270/271 roster to alert a hospitalabout forthcoming admissions was notrepresentative of the functionality of theroster. The commenter also stated thatthere are health care providers whocurrently use the X12N 270/271electronic roster implementation, and it

was misleading to use the term ‘‘notrecommended’’ in connection with theroster implementation specification.Additionally, the commenter stated thatit is incorrect to say that the rosterimplementation specification is notmillennium compliant and that thestandards development process for theimplementation specification is notcompleted.

Response: We agree that a moreprecise description of the rosterfunctionality would be to refer to it asanother implementation rather thananother part of the standard. Althoughthe current version of thisimplementation specification ismillennium compliant and complete,this was not true at the time theproposed rule was written. Thus, we didnot recommend the use of the ASCX12N 270/271 to provide requests foreligibility. Another implementation ofthe ASC X12N 271 is designed to handlerequests for eligibility ‘‘rosters,’’ whichare essentially lists of entities—subscribers and dependents, health careproviders, employer groups, healthplans—and their relationships to eachother. For example, this transactionmight be used by a health plan tosubmit a roster of patients to a healthcare provider in order to designate aprimary care physician.

The eligibility inquiry and response isthe only implementation proposedunder HIPAA for eligibility for a healthplan. The implementation of the HIPAAstandards will be a great undertakingand at this time we are limiting thetransactions to those identified in theproposed rule. In addition, entities whomove eligibility information in a rosterformat may do so using any availableformat, including the ASC X12N 270/271 roster implementation. After theimplementation specification for theroster function is complete andapproved by an accredited standardsetting organization, we recommendthat a request for adopting the newstandard be submitted to the DSMOs.See § 162.910 for the process to requestnew standards.

viii. Comment: Several commentersrecommended that the InteractiveHealth Care Eligibility/Benefit Inquiry(IHCEBI) transaction set and itscompanion, the Interactive Health CareEligibility/Benefit Response (IHCEBR)transaction set, should also be adopted.

Response: The IHCEBI/IHCEBR isbased on UNEDIFACT syntax, not ASCX12N syntax. At the time of thedevelopment of the proposed rule, thesyntax used was a version subsequentlymodified by UNEDIFACT, resulting inthe need to reformat the messages intothe modified syntax before they could



be adopted by the UNEDIFACT body.Therefore, there was no uniformimplementation specification developedfor these standards. After consideration,we decided that, where possible, thetransactions to be named in theproposed rule should have a uniformsyntax structure. This was possible forall transactions; ASC X12N transactionswere chosen because they met thecriteria of having implementationspecifications and having the same basicsyntax structure. The NCPDP standardsalso met the criteria, and eachtransaction is designed using the samesyntax structure. If, in the future, amillennium compliant interactiveeligibility for a health plan transactionstandard is approved by an ANSIaccredited standards settingorganization and an implementationspecification exists, we shall consider itfor adoption as a HIPAA standard.

ix. Comment: We received onecomment that suggested we clarify thatthe eligibility response sent by a healthplan is not the equivalent of a priorauthorization of services, and does notguarantee coverage of a renderedservice.

Response: We believe that thepurpose and scope of the ASC X12N270/271 is clearly defined in the ASCX12N 270/271 Health Care EligibilityBenefit Inquiry and Responseimplementation specification. Aneligibility response sent by a health planis not the equivalent of a priorauthorization of services and does notguarantee coverage of a renderedservice. Furthermore, the function ofprior authorization of services isexplicitly defined in the ASC X12N 278,Health Care Services Review—Requestfor Review and Responseimplementation specification, which isthe recommended standard for thistransaction.

x. Comment: One commentersuggested that we clarify therequirements to clearly state that whilehealth plans must implement the ASCX12N 270/271 Eligibility Request/Response, they are not required torespond to all requests sent in the ASCX12N 270.

Response: We do not agree. A healthplan may not reject a standardtransaction because it containsinformation the health plan does notwant. This principle applies to the dataelements of all transactions in this rule.Health plans must accept a completeASC X12N 270 and must respond withall applicable responses that areincluded in the ASC X12N 271. If healthplans can arbitrarily respond or notrespond to a standard transaction, thenthe cost saving effect of using the

standards will be blunted by arequirement to negotiate aspects ofevery transaction with every tradingpartner.

xi. Comment: One commenter saidthat the ASC X12N 270 transactionrequires an ASC X12N 271 response toevery record, a one-to-onecorrespondence. The commenterrecommended that the one-to-oneresponse be negotiable between theparties that have a contract to exchangeinformation.

Response: A one-to-onecorrespondence to every record is notrequired. The ASC X12N 270/271transaction sets were built so thattrading partners could use them in realtime or batch mode. We agree thatnegotiation must occur between tradingpartners (including clearinghouses/switches) regarding the processinglimits (i.e., file size, transmissionspeeds).

g. Transaction Standard for HealthPlan Premium Payments. In subpart Q,we proposed the ASC X12N 820—Payment Order/Remittance Advice,Version 4010, Washington PublishingCompany, (004010X061) as the standardfor health plan premium payments.

Comments and Responses on theTransaction Standard for Health PlanPremium Payments


i. Of those comments we referred toASC X12N, the work groups determinedthat 53 comments identified areas wherethe implementation specification couldbe improved, and the appropriatechanges were made.

ii. One comment identified a businessneed that ASC X12N judged couldalready be met within the currentstandard implementation specification.Detailed information on how the currentimplementation specifications can beused to meet these business needs hasbeen provided by ASC X12N at theInternet site in § 162.920.

iii. Six comments alleged technical oreditorial errors in the standardimplementation specification. Atechnical review of these issues wasconducted by work groups within ASCX12N. The work groups determined thatthe 6 comments identified areas wherethe implementation specifications werein fact correct and that no changes wereneeded. Changes to the implementationspecification were not required.

iv. Comment: Several commenterssaid that health plans must be free toaccept premium payment data in non-standard formats if that option is chosenby a sponsor. In the preamble to the

proposed rule, we stated that healthplans must ‘‘accept only the standardspecified in § 142.1704.’’ (63 FR 25295).Commenters suggested that we notinclude the word ‘‘only’’ in the finalrule under the health plan requirements.One commenter suggested that we addlanguage in the rule to state: ‘‘However,health plans may require tradingpartners to use the standard transactionto conduct business.’’

Response: We recognize that entitiessuch as sponsors perform EDI withhealth plans. The proposed rule statedthat health plans are required to useonly the standard specified in§ 142.1702 for electronic health planpremium payments. Sponsors, one ofthe primary trading partners with whomthe health plans exchange health planpremium payment transactions, wereproposed to be excluded. Our referenceto the requirements for health plans toaccept ‘‘only’’ the standard specifiedwas intended to preclude health plansfrom using data in formats other thanstandard when conducting transactionsthat are standard transactions. It was notintended to impose requirements onsponsors. Thus, sponsors remain free tosend health plan premium payments innonstandard format if they choose, andhealth plans are free to accept the data.

We expect that sponsors mayvoluntarily accommodate a healthplan’s request to use the ASC X12N 820by directly submitting the transaction instandard format, or by using a healthcare clearinghouse to translate non-standard data into the standard format.

v. Comment: One commenter said thatVersion 3040 is the most widelyaccepted version of the ASC X12N 820in the financial community and,therefore, recommended its adoption.The commenter reasoned that by settingthe minimum version at 3040, TheSecretary would greatly increase thelikelihood of successful implementationsince it is currently in use fortransmitting premium payments.

Response: We did not recommendversion 3040 because it was notmillennium ready.

vi. Comment: Several commenters,including the Department of theTreasury, said that the ASC X12N 820should not be named as a payment orderformat for use by Treasury-disbursedFederal agencies since they use Federalimplementation conventions andTreasury payment formats that may notbe compatible with this standard. AllFederal payment formats disbursed bythese agencies must go through acommercial financial institution prior todelivery of the payment to the recipient.It was stated a distinction needs to bemade in regard to the function of the



X12N 820. It is used as a ‘‘paymentorder’’ and a ‘‘remittance advice’’delivery.

Response: The ASC X12N 820 is anappropriate format for use by allcovered entities and is designed toprovide the information needed toprocess a payment of health insurancepremiums from an employer or othersponsor of health insurance to a healthplan. If a Federal agency is a coveredentity and conducts a transactionadopted under this part with anothercovered entity electronically, thetransaction must be conducted as astandard transaction. If the other entityis not a covered entity, of course, thestandard transaction need not be usedunless the Federal agency is a healthplan and the other entity requests thestandard transaction.

This standard is quite flexible withrespect to transfers of funds. Theimplementation specification for theASC X12N 820 contains two parts, amechanism for the transfer of dollarsand one for the transfer of informationabout the payment. It allows these twoparts to be transmitted separately.Consistent with the implementationguide, actual payment may be sent in anumber of different, equally acceptableways, including check and severalvarieties of electronic funds transfer, aslong as the detailed informationdescribing the payment is transmitted tothe health plan using the ASC X12N 820directly or indirectly (through a healthcare clearinghouse or financialinstitution). When the transfer of fundsis part of paying a health care premiumthe ACH transaction may continue to beused as a valid part of an ASC X12N 820transaction where the other part of thetransaction is sent to the health plan.Although these standard transactionsallow transmission of one or both partsthrough a financial institution, they donot require both parts to be sent to thefinancial institution, and the financialinstitution is not required by thisregulation to accept or forward suchtransactions. The Department of theTreasury has confirmed that thisstandard does not conflict with theirrequirements for disbursements.

vii. Comment: One commenter askedwhether a sponsor must use the 4010version of the ASC X12N 820.

Response: Section 1172 of the Actidentifies the entities required tocomply with the HIPAA standards.Sponsors are not included in thisprovision. If sponsors choose to use theASC X12N 820, we strongly encouragethat they use the version of the standardnamed in this rule.

h. Transaction Standard for ReferralCertification and Authorization. In

subpart R, redesignated as subpart M,we proposed the ASC X12N 278—Health Care Services Review—Requestfor Review and Response, Version 4010,Washington Publishing Company,(004010X094) as the standard forreferral certifications andauthorizations.

Comments and Responses on theTransaction Standard for ReferralCertification and Authorization



ii. Thirteen comments identifiedbusiness needs that ASC X12N judgedcould already be met within the currentstandard implementation specification.Detailed information on how the currentimplementation specifications can beused to meet these business needs hasbeen provided by ASC X12N at theInternet site in § 162.920.

iii. Three comments alleged technicalor editorial errors in the standardimplementation specification. Atechnical review of these issues wasconducted by work groups within ASCX12N. The work groups determined thatthe 3 comments identified areas wherethe implementation specifications werein fact correct and that no changes wereneeded. Changes to the implementationspecification were not required.


v. Comment: Several commentersrequested that we need to make clearthat if a state health agency does notauthorize referrals it is not required touse the standard.

Response: If a state health agencydoes not conduct referral certificationand authorization, then the health plan

is not required to support thistransaction based solely on the fact thatthe transaction is one named as aHIPAA transaction. However, we notethat most commercially availablesoftware packages are designed tosupport a suite of transactions. Weanticipate that vendors will offer suitesfor all HIPAA transactions, which mayencourage health plans to support thisspecific transaction.

vi. Comment: Several commentersrecommended that we include theInquiry and Response and Notificationimplementations of the ASC X12N 278.

Response: The Request for Reviewand Response is the onlyimplementation proposed under HIPAAfor referral certification andauthorization. We are notaccommodating this request, because atthe time of the development of theproposed rule, the standardsdevelopment process for the ASC X12NInquiry and Response and Notificationimplementation specifications wasincomplete and not supported by anaccredited standard setting organization.The implementation of the HIPAAstandards will be a great undertakingand at this time we are limiting thetransactions to those identified in theproposed rule. Entities who use Inquiryand Response and Notificationimplementations may do so using anyavailable format, including the ASCX12N 278 implementations until suchtime as we may adopt a standard forInquiry and Response and Notificationthrough regulation. After theimplementation specification for thesefunctions is complete and approved byan accredited standard settingorganization, we encourage a request totest a proposed revision to the standardbe submitted to the Secretary (see§ 162.940).

G. Compliance TestingProposal Summary: We identified

three levels of testing that are typicallyperformed in connection with theadoption and implementation of theproposed standards and their requiredcode sets:

• Level 1—developmental testing, thetesting done by the standards settingorganization during the development process

• Level 2—validation testing, the testing ofsample transactions to see whether they arewritten correctly.

• Level 3—production testing, the testingof a transaction from a sender through thereceiver’s system.

Pilot production—Because of thebillions of dollars that change handseach year as a result of health careclaims processing, we stated that webelieve the industry should sponsor



pilot production projects to testtransaction standards that are not in fullproduction prior to the effective date foradoption of the initial HIPAA standardformats.

We also stated that it would be usefulto all participants if pilot productionprojects and the results of pilot projectswere posted on a web site for alltransactions. For the health care claimsor equivalent encounter informationtransactions, we believe that postingpilot production projects and the resultsof pilot projects on a web site must bemandatory.

Comments and Responses onCompliance Testing

Comment: The majority ofcommenters recommended that theposting of pilot production resultsshould be voluntary, not mandatory.

Several commenters suggested that allHIPAA standards projects be posted andthat the government should providefunding or at least publicly advertise theresults of all compliance testingprojects. It was suggested that theElectronic Healthcare NetworkAccreditation Commission (EHNAC)could host a bulletin board or web sitein which tests results could bepublished.

Several commenters asked whetherentities providing validation testing willneed to be certified. They stated thatvalidation testing is only useful ifcertification is obtained. Severalcommenters recommended that theSecretary endorse the StandardTransaction Format Compliance System(STFCS) process established by EHNACfor validation testing, suggesting thatEHNAC certification lends credibilityand reliability to the process. However,other commenters wanted certificationfor compliance to be voluntary.

Several commenters recommendedthat WEDI, X12, or some other groupfurther develop the various types oftesting situations which might occur aswell as tentative protocols for handlingsuch tests.

Several commenters wanted thetesting processes thoroughly definedprior to the implementation of thestandards. For example, commenterswanted costs defined, and testing timeframes, scheduling, and turn aroundtimes established. Others wanted to gainexperience using the transactions firstand allow testing to be done on a goodfaith effort basis.

The majority of commentersrecommended that all of thetransactions should be tested and anynecessary modifications made prior tothe publication of the final rule and asearly as possible.

Response: We agree that posting ofresults for any HIPAA standard shouldbe voluntary. As long as the transactionsare successfully implemented inproduction, posting of the results ismore of a marketing, advertising, andsales issue than a technical concern.

Since the HIPAA provisions do notrequire the Secretary to certifycompliance with HIPAA standards, theSecretary is not conducting certificationreviews or recognizing privateorganizations that have decided toconduct such reviews. Therefore, anycertification of commercial entitiesperforming validation testing willremain in the private domain and bevoluntary. While receivers oftransactions are likely to test whether avendor that claims to be HIPAAcompliant is, in fact, producingcompliant transactions, this is a matterof business practice, and such tests arenot being mandated in this rule.

The HIPAA provisions require theSecretary to adopt standards developedby standards setting organizations(SSOs) whenever possible. With thisapproach, the standards developed by aconsensus of the health care industrywill be implemented by the health careindustry at large. Consistent with thisapproach, the Secretary is relying onthose in the health care arena to comeforward and test the designatedstandards. All of the standards havecompleted levels 1 and 2 of testing.Some of the standards have completedall three levels of testing and are in fullproduction (for example, the NCPDPstandard and many of the data codesets). We urge the health care industryto work in concert with the DSMOs.Health plans and vendors currentlydefine their own test plans and conducttheir own tests. We urge health plans todevelop pilot test plans using theimplementation specifications specifiedby the Secretary.

Certain types of testing are commonlyconducted by organizations thattransmit transactions electronically.These include site, unit, integration,connectivity, end to end, and paralleltesting. ASC X12N has agreed to solicitprivate individuals, organizations,vendors and other interested parties tofacilitate these types of testing anddocument their results and conditionson the X12N web site. Manygovernment agencies will test and postresults as well. X12N intends tocontinue to review and refine its testingprocess to make sure it continues tomeet the requirements of the health careindustry.

H. Enforcement

Proposal Summary: Under the statute,failure to comply with standards mayresult in monetary penalties. TheSecretary is required by statute toimpose penalties of not more than $100per violation on any person who fails tocomply with a standard, except that thetotal amount imposed on any oneperson in each calendar year may notexceed $25,000 for violations of a singlestandard for a calendar year.

We did not propose any enforcementprocedures, but we will do so in a futureFederal Register document.

We did, however, solicit input onappropriate mechanisms to permitindependent assessment of compliance.

Comments and Responses onEnforcement

1. Comment: We received manycomments regarding the timing ofenforcement. Several commenters statedan enforcement and mediating body isneeded immediately. The majority ofcommenters called for the delay ofenforcement. Commenters alsorequested that HCFA permit initialcompliance testing of these standardtransactions to be based on good faith.It was also recommended that actualtesting for compliance occur later.Several commenters said that we shouldnot assess penalties in the first year. Afew commenters requested that weestablish a body to which a health careprovider may go for help. Othersrequested advance notice ofenforcement procedures.

A few commenters requested that wedefine the terms ‘‘person’’ and‘‘violation,’’ as well as provide examplesof violations and provide descriptions ofhow penalties will apply. Severalcommenters requested that fines applyonly to health plans and health careclearinghouses, and not to health careproviders.

One commenter suggested that theElectronic Healthcare NetworkAccreditation Commission (EHNAC) beendorsed as a process for establishingcompliance in using the standards.

Response: The proposed rule, like theother three notices of proposedrulemakings (NPRMs) published in 1998to implement the administrativesimplification requirements of HIPAA,did not contain provisions forcompliance and enforcement. We are,therefore, not adopting any complianceor enforcement provisions in this finalrule. As we indicated in the proposedrule, we will be developing a separatecompliance and enforcement rule toestablish compliance and enforcementprocedures for these and other



administrative simplificationrequirements. We plan to publish anNPRM requesting public comments nextyear, and to subsequently issue a finalcompliance and enforcement regulationthat will become effective prior to thefirst compliance dates of these rules. Weanticipate addressing the specific issuesof compliance, timing, appeals, andtechnical assistance in the projectedcompliance and enforcementrulemaking. We also plan to address thepracticability of using some type of self-certification or certification by externalparties to demonstrate compliance withsome or all of the requirements.

We encourage covered entities,trading partners and business associatesto address issues relating to complianceand resolution of disputes concerninguse of these standards in their tradingpartner agreements. The followingresources are available to assist withquestions of interpretation andapplication of specific transactionsstandards and implementation guides:

For assistance in resolving aparticular X12N issue, submit the issueto the X12N Insurance list serve. Tosubscribe to the X12N Insurance listserve, go to http://www.x12.org.

For additional information regardingthe interpretation of the NCPDPstandards, go to http://www.ncpdp.org.

The Department will develop a planfor providing technical assistance tocovered entities and others affected bythe rule. We plan to announce theavailability of technical assistancethrough the Federal Register, variousweb sites including the Department’sAdministrative Simplification web siteand the web sites identified above, andthrough other means.

2. Comment: Several commenterssuggested we address educationalactivities. It was stated that the changesrequired by the administrativesimplification provisions of HIPAAcannot be implemented without aconcerted and sustained educationaleffort.

Response: We agree that HIPAAeducational activities are critical to thesuccessful implementation of thestandards. Industry organizations, suchas X12N have begun to provideeducation about standard transactions.While not required by this rule, weencourage health care clearinghousesand vendors to educate their customersas well. The Health Care FinancingAdministration (HCFA) has scheduled aseries of regional training sessions forMedicare and Medicaid. They havecontracted with instructors who arenationally recognized experts in EDIstandards. Medicare and Medicaid havealso published health care provider

education articles. Copies of thesearticles may be obtained from localHCFA contractors.

I. New and Revised Standards

We proposed a procedure for entitiesto follow if they want a new standard.We also proposed a procedure that wewould follow if a standard needs to berevised.

Comments and Responses on theProcedures for New and RevisedStandards

1. New Standards for ExistingTransactions

Proposal Summary: To encourageinnovation and promote development ofnew standards, we proposed to developa process that would allow anorganization to request a replacement ofany adopted standard or standards.

An organization could request thereplacement of an adopted standard byrequesting a waiver from the Secretaryof HHS to test a new standard. Theorganization, at a minimum, would haveto demonstrate that the new standardclearly offers an improvement over theadopted standard. If the organizationpresented sufficient documentation thatsupported testing a new standard, wewanted to be able to grant theorganization a temporary waiver to testthe new standard while remaining incompliance with the law. We did notintend to establish a process that wouldallow organizations to request waiversas a mechanism to avoid using anadopted standard.

Comment: Most commenterssupported the proposed process fortesting proposed revisions to standards.Several commenters preferred the word‘‘exemption’’ instead of the word‘‘waiver,’’ since it makes it clearer thatstandards should generally not bewaived. It was also suggested that thecost benefit analysis should apply to thereport developed after the pilot studyand not to the application phase of thetemporary exemption. Anothersuggestion was to have organizationswishing to test a new standard submitwritten concurrences from tradingpartners who will participate in testingthe new standard. Those organizationsmust also assure they will continue tosupport existing standards during thetesting process.

Response: We agree that standardsshould generally not be ‘‘waived.’’ Weagree with the substance of commentersconcern and therefore, we have addedlanguage in § 162.940 to include thesuggested changes and are using theterm ‘‘exception’’ to indicate that thestandard generally applies, but that a

specific group of entities are notrequired to follow all or a portion of onestandard to permit testing of proposedrevisions. While industry practice uses1 year for testing, we have decided togrant an exception for a period not toexceed 3 years. We decided to adopt a3 year time frame because we believethis period gives us flexibility indetermining the extent to which testingmay be required. We emphasize that anew standard is a standard that is notone of the transactions defined in thisrule, including code sets. A revisedstandard is specific to the version of theSecretary’s standard and theimplementation specifications.

2. Revised Standards/Proposals forAdditional Standards

Proposal Summary: We recognizedthe very significant contributions thatthe traditional data content committees(DCCs) (the NUCC, the NUBC, the ADA,and the National Council forPrescription Drug Programs (NCPDP))have made to the content of health caretransactions over the years and, inparticular, the work they contributed tothe content of the proposed standards inthe proposed rule. We proposed thatthese organizations be designated toplay an important role in themaintenance of data content forstandard health care transactions. Weproposed that these organizations,assigned responsibility for maintenanceof data content for standard health caretransactions, would work with X12Ndata maintenance committees to ensurethat implementation documentation isupdated in a consistent and timelyfashion.

We intended that the private sector,with public sector involvement, wouldcontinue to have responsibility fordefining the data content of theadministrative transactions. BothFederal agencies and privateorganizations would continue to beresponsible for maintaining medicaldata code sets.

a. Code Sets. Comment: Severalhealth care systems, State agencies, andinsurance companies submittedcomments agreeing that all codingsystems adopted as HIPAA standardsshould have an open updating process,e.g., the responsible panel or committeeof experts should be representative of abroad cross-section of the relevant stake-holders; all panel or committeemembers should have voting privileges,any interested party should be eligibleto submit proposals for additions andchanges, and the meetings should beannounced in advance and should beopen to the public. They made specificcriticisms of the current processes used



for updating HCPCS (for example, norepresentation from the commercialcompanies that actually pay claims),CPT, and ‘‘The Code’’ (dental).

Commenters made several favorablecomments about the current process forobtaining public input and makingdecisions regarding changes to ICD–9–CM.

Response: We agree that the currentprocess for making decisions regardingupdates to the ICD9–CM provides auseful model, and we consider it to beprobably the most workable approachfor code sets. This process encouragesbroad input but gives final decision-making authority to the organizationsresponsible for developing the code sets.A purely democratic approach, underwhich all changes are put to a vote bythe members of a particular standardscommittee and any organization eligibleto become a voting member, is likely tohave significant drawbacks for routinecode set maintenance, e.g., delays inupdates, inability to make changes thatare essential for a minority of players,and changes in the code set thatundermine its logical structure. Wereceived clarification from thedevelopers of the ‘‘The Code’’ (dental)and the CPT–4 about their updateprocesses that will be in place at thetime these standards are implemented.We are confident that it will be aworkable open updating process.

In response to the commentsregarding the process for updatingHCPCS, we have reviewed our currentpolicies and procedures governing thesubmission of requests from the publicfor revisions/changes to the HCPCS. Wehave ensured that existing proceduresare easy to use and are adequatelycommunicated to the public. Thecurrent process for updating the HCPCSincludes the following features:

• Identification of a central contact forinformation/assistance regarding the processfor submitting requests to modify the codingsystem.

• Advance notice of meeting agendas.• Identification of proposals submitted for

coding consideration.• Opportunity for public comment on the

proposals.• Subsequent posting of coding changes

for public information.

b. Transaction Standards. Comment:While most commenters supported theproposal that the NUCC, NUBC, and theADA be designated as the data contentcommittees (DCCs), several commentersopposed this proposal. Commentersopposing designation of these bodiesrecommended that X12 be named as thesole content body, pointing out that X12is sufficiently open to include viewsfrom the NUCC, NUBC, ADA and

others. Some commenters believe thatthe NUBC and NUCC do not adequatelysupport nor understand the health careproviders they represent, and theirexpertise is grounded in paper ratherthan electronic transactions. Somecommenters opposed selection of theADA as it was perceived to includeinadequate non-health care providerrepresentation for data content issues.Others opposed the selection of theNUCC because it was perceived as non-representative of the full range of healthcare professionals.

Other commenters stated there shouldnot be a separate DCC for each X12Ntransaction because a change in onetransaction may impact another.Another commenter stated X12 shouldbe allowed to have a permanent votingmember on each DCC that is selected,and that X12 should retainresponsibility for the maintenance of thedata dictionary for the selectedtransactions. Some commentersrecommended that the NUCC, NUBC,and ADA continue to interact withX12N, and did not see a need forgovernment oversight of the process.They felt that the current process workswell and should not be tampered with.

Several commenters recommendedthat these multiple content bodiesshould have consistent protocols andshould implement them uniformly.They recommended that the committeeshave meetings open to the public withcross-industry representation, includinginput from the public sector.Commenters also suggested that thecommittees operate under an equitableconsensus process, and that they sign amemo of understanding (MOU) with theSecretary to ensure due process, closecooperation with standard settingorganizations, and balanced voting.They asked that the data maintenanceand change process for the standards beclearly described in the final rule. Arequest was also made for theestablishment of an oversight groupresponsible for arbitrating conflictingdecisions reached by different datacontent committees; handling appealson data content committee decisions;coordinating data requests involvingmore than one data content committee;and centrally coordinating with X12.

Some commenters recommended thatwhile NUCC, NUBC and ADA have aDCC role, this role should focusprimarily on claims information. Thesecommittees were not perceived ashaving experience with enrollment,eligibility, premium payment,remittance, claim status, and referralissues. It was recommended that X12Nor another industry forum serve as the

data content committee for these otherstandards.

A few commenters asked that, as anSSO, the NCPDP’s role in the DCCprocess be addressed in the final rule.A number of comments were alsosubmitted concerning appointment of aDCC for the attachments transactionstandard under HIPAA.

Response: Only the NUCC, NUBC,ADA, NCPDP and X12N expressed aninterest in having a role as a DCC for theX12N standards selected for the HIPAAtransactions in this rule. To address theissues raised by these comments,representatives of the Secretary havecontacted many officers and members ofthe NUCC, NUBC, ADA, NCPDP, X12N,WEDI and other organizations.Discussions centered on the followingissues: Preferences; operational models;control and coordination issues; timeframes for incorporation for a request fora data change in implementationspecifications; membershipcomposition; internal processing rulesand voting requirements; willingness toserve; expectations; publicparticipation; and other details.

In § 162.910, we state that theSecretary may designate anorganization(s) to maintain thestandards, propose modifications toexisting standards, and propose newstandards to the National Committee onVital Health Statistics (NCVHS). Theseorganizations, which can include DCCs(for example, the NUCC) and SSOs (forexample, X12N), also receive andprocess requests for the creation of anew standard, or the modification of anexisting standard. In the proposed rule,we referred to these organizationsstrictly as DCCs and SSOs. In this finalrule, we call the organizations that aredesignated under § 162.910 DesignatedStandard Maintenance Organizations(DSMOs). The DSMOs are a subset ofDCCs and SSOs, and we have publisheda notice announcing these organizationselsewhere in this Federal Register.

We recognize that not every medicalspecialty or health plan may consideritself to have sufficient votingrepresentation or weight within theDSMOs. Therefore, the DSMOs willoperate a process which allows openpublic access for requesting changes tothe standards, consideration of therequest by each organization,coordination and final agreement amongthe DSMOs on the request, an appealsprocess for a requester of a proposedmodification if the final decision is notsatisfactory. The DSMO’s process willalso allow for an expedited process toaddress content needs of the industry,and address new Federal legislationwithin the implementation date



requirements of the law.Recommendations will be presented bythe DSMOs to the NCVHS, whereappropriate. Change requests can besubmitted via a designated web site thatwill be made available to the public.

The DSMOs will also improvecoordination among themselves,publicize open meetings, and, in somecases, expand voting membership. TheDSMOs understand that theirappointments as DSMOs will bereconsidered if they fail to perform,coordinate, and respond to the public asdescribed in § 162.910.

J. Proposed Impact Analysis

Proposal Summary: On the same daythat we proposed the standards that arethe subject of this final rule, we alsopublished a rule to propose the nationalprovider identifier (NPI)(63 FR 25320).In that rule, we set forth an impactanalysis that covered the collectiveimpact of most of the administrativesimplification standards (includingstandards for security and the uniqueidentifiers, but not including the costsof privacy standards, which will bedetailed in the privacy final rule) sinceestimating the impact of themindividually would be misleading. Wedid provide an impact analysis that wasspecific to each standard, but the impactanalysis assessed only the relativeimpact of implementing a givenstandard.

Conclusion of impact analysis ofproposed rules

We estimated that the impact of theproposed rules would result in netsavings to health plans and health careproviders of $1.5 billion during the firstfive years; use of the standards wouldcontinue to save the industry money.

Comments and Responses on theProposed Impact Analysis—General

1. Cost/Benefit Analysis

a. Comment: Several commentersquestioned the validity of the projectedcost of implementing electronic datainterchange standards (EDI) because itwas based largely on data compiled in1992 by WEDI. The WEDI reportprojected implementation costs rangingbetween $5.3 billion and $17.3 billionwith annual savings projected to bebetween $8.9 billion and $20.5 billion.It was stated the WEDI report projectedthe costs as being much higher. Onereason the projected cost was inflated byWEDI is because the HIPAA complianceprocess will be spread out over a longerperiod of time than is provided for inthe statute. The HIPAA standards willrequire additional data elements, will

replace local coding schemes withnational ones, and will affect manybusiness process associated with healthplans and health care providers.Therefore, the modifications to existingsystems will be extensive and timeconsuming, with a high degree ofuncertainty regarding the projectedbenefits. The estimates in this sectionneed to be recalculated taking intoaccount more current figures and trends.

Response: The cost estimates used inthe proposal cost analysis were basedlargely on data compiled in 1992 butupdated to reflect 1998 costs. The reportdeveloped by WEDI projectsimplementation costs ranging frombetween $5.3 billion and $17.3 billionwith annual savings projected to bebetween $8.9 billion and $20.5 billion.The Department has obtained morecurrent data and information on costsand market trends, and these data areused in the final cost analysis. It is anaccurate statement that the HIPAAstandards would create new dataelements and would remove localcoding schemes in favor of nationalones. However, some of the factors thatwould cause health care providers orhealth plans to incur a substantialfinancial burden have been spread outover a longer period of time than wassuggested by the commenters. Theremoval of local coding schemes, forexample, will not occur immediately,but will occur over a two year timeperiod following the publication of thisfinal rule. A longer time frame willspread out the implementation costsand therefore will not pose as great aburden as previously expected. Withregard to Medicaid specifically, some ofthe unusual service type codes (i.e. taxiservices) will also not have to beremoved.

a. Comment: One commenter statedthat although the methodology used inthe WEDI report served as a basis fordetermining the cost/benefit analysisexplored within the proposed rule, theconcept of cost-benefit analysis is vagueand resembles something of a ‘‘blackart.’’ Because of the large number ofvariables and the complexity of theassumptions with which health careproviders and health plans will have todeal in implementing of HIPAA, it ishard to determine the actual advantagesor disadvantages for the HIPAAstandards as a group.

Response: It is difficult to assess thecost and benefits of the HIPAAstandards with absolute certainty. Whilethere are no standard methods for doingthese analyses, an effort was made notto overstate the benefits or understatethe costs of implementation. The WEDIreport is the most extensive industry

analysis of the effects of EDI standardsavailable.

c. Comment: Several commentersstated that the sweeping changes thatHIPAA mandates make it difficult to doa precise cost-benefit analysis. Onecommenter noted that additionalactuarial studies should be done, withthe cooperation of health plans andhealth care providers. The commenteralso stated that pilot programs should beinitiated in different geographic regionsin order to identify the feasibility of thescope and time frames for HIPAAimplementation. Another commenterstated that they believed that the costsassociated with the NPI and subsequentsystem changes required of coveredentities may run into the six-figurerange, which is not mentioned in theproposed rule.

Response: It is difficult to assess thecost and benefits of the HIPAAstandards with complete accuracy. Thisis particularly true considering thatthese changes have no historicalprecedent. While initiating pilotprograms in each region and conductingfurther actuary studies may providedetailed analysis, it is neither feasiblenor practical. The time frame forimplementation, as mandated by thestatute, precludes this. The analysisgiven was derived from aggregate figuresthat provided the most realistic impactin terms of costs and savings. NPI costsare currently being evaluated by theDepartment of Health and HumanServices and will be published in thefinal rule regarding the NPI.

d. Comment: Several commentersexpressed concern with the cost-benefitanalysis in regard to Medicaid. Onecommenter stated that dismantling 80%of the Medicaid systems that processEDI in order to accommodate the HIPAAstandards will result in a loss.Furthermore, it was noted that the useof a dual health care providerassignment number will continue to beused in their Medicaid ManagementInformation System (MMIS) whichwould mitigate any cost savings benefit.

Response: The rationale behind theImpact Analysis was to evaluate the costand savings for the health care systemas a whole. While the cost to a specifichealth plan or health care provider mayoutweigh the benefits to that entity, ouranalysis showed overall savings to thehealth care system. There is a greaterpossibility for savings in the future dueto use of a common identifiers, theincreased simplicity of processingtransactions, and the overallcoordination of benefits. We do notanticipate an immediate need tooverhaul an entire system, but we doexpect some implementation costs



which have been factored into theanalysis. Translation software may bepurchased at reasonable cost thusavoiding major reprogramming. (Sincethe translators will not affect the issuesraised, they should have no impact.)Health plans and health care providersmay also use a health care clearinghouseto perform the translation. We believeentities that use health careclearinghouses will see costs reduced orat least stabilized.

We do acknowledge that the $1million cost estimate for redesigning aState Medicaid system to accommodatethese standards may have been too low.Further analysis indicated that costs toindividual State Medicaid programsmay be in the $10 million range. Whilethe cost in each State may differsomewhat, the Federal government willpay approximately 75–90 percent ofthese costs, leaving the costs to eachState near the $1–2.5 million range. Webelieve that long-term benefits to Stateswill outweigh the costs.

e. Comment: Several commentersstated that many of the numbersassociated with our analysis were basedupon calculations using aggregate datainstead of evaluating the standardsindividually. It was stated that aseparate assessment of each standardwould yield more realistic resultsbecause the staged release of theproposed rules led to the impressionthat the HIPAA standards will beimplemented in a staggered fashion.Assessing the cost of implementing eachstandard independently would not yieldinflated costs, but would yield numbersthat would approximate what the actualcosts will be. A number of commenterssuggested different approaches to makethe rules more effective and beneficial,as well as make the implementationmore orderly. One such approach wasthat the implementation of all of thestandards be postponed until all of theproposed rules are published (e.g., asingle harmonized implementation datebased on the date of the last publishedrule), perhaps with the exception ofthose standards that have been deferredsuch as the First Report of Injury andthe Patient Identifier. Another would beto break down the implementation intophases. The first phase would be fullimplementation of the standards within2 years of the publication dates of thefinal rule for identifiers for health careproviders, employers, and health plans.Phase 2 would be the fullimplementation of all the transactionsincluding attachments and the securityrule within 2 years of the publication ofthe last of these final rules. Phase 3would be the implementation of theindividual identifier within 2 years after

the publication of the identifier finalrule. The last recommended approach isthe simultaneous publication of thefinal rules for the health care provider,health plan and employer identifiers;the transaction sets, including the FirstReport of Injury and the attachments;and the security regulations. Thismethod would ensure that health careproviders and vendors will have thechanges necessary for both internalapplication systems and externalcommunications.

Response: While the original plan wasto implement all of the standards at thesame time, the realities of the regulatoryprocess and the impact of millenniumactivities will cause a variety of effectivedates. This rule is the first to bepublished, with other rules forstandards following shortly. It isdifficult to assess the cost-benefit ofeach standard individually becausethere are costs and benefits associatedwith the interaction of many of thestandards. It is more realistic to assesscost-benefits of standardizing EDI ingeneral, using aggregate data to give amore complete picture, than attemptingto measure the impact of each standard.Many of the numbers associated withthis analysis are based uponcalculations using aggregate data.

2. Implementation Costsa. Comment: One commenter noted

that a translator does not address theproblems health care providers willhave in relating their health careprovider type to State billing systems orin billing local codes.

Response: The local code issue hasbeen addressed in this rule. The healthcare provider type issue will beaddressed in the final rule for theNational Provider Identifier. Translatorswill allow health care providers toaccommodate most of the businessprocess changes required by this rule.

b. Comment: Several commentersstated that we greatly underestimatedthe implementation costs. They claimedthat the costs associated with translatordevices were not included, andupgrades to EDI systems could continueannually and could involve multiplestandards which would not be classifiedas short-term costs. Furthermore, it wasstated that all methods of complyingwith the HIPAA requirements will havecosts associated with them that will notbe limited to the first three years ofimplementation. There will be ongoingcosts for training and support that willsurpass the estimates given by theimpact analysis. In addition, third-partyadministrators opting for in-houseprogramming have already spent largesums of money to prepare for

administrative simplification beforecompliance is mandated. Somecommenters fear that health careclearinghouses will potentially chargehigh yearly fees and high transactionfees due to an increase in demand. Theybelieve high fees will not be eliminatedafter the three year time frame hasended and the costs could be passed onto health care providers, health plansand purchasers. Finally, while theproposed rule proposed the eliminationof data entry clerks and mailing costs,it did not account for software engineersthat will be needed to redesign orreprogram a system. The personnel costsassociated with these individuals couldbe 4–6 times as high as a data entryclerk.

Response: These comments raiseseveral important issues. The first onedeals specifically with the cost of atranslator. The cost of translators, infact, were included in estimatingupgrade costs. In addition, some ofthese EDI standards would haveoccurred without the passage of HIPAAdue to the demands of the health careindustry. Many of the other costsmentioned, such as costs for trainingand support, would have also occurredwhether or not standards weremandated, so we do not believe themrelevant to the impact of this rule. Thefinancial data given in the ImpactAnalysis was based on the mostreasonable estimates available and tookinto account the implementation costs,including software engineering, thatwill be incurred during the first threeyears. This justifies the categorization ofexpenditures associated with the HIPAAstandards as one-time or short-term. Allof the costs associated with a systemupgrade have been included in theimplementation time-frame noted in theProposed Rule. Finally, redesigning orreprogramming work that will be donein accordance with this regulation hasbeen included in the implementationcosts. While it is an aggregate amount,it provides the most realistic estimatebased on available data. Health careclearinghouse charges can be expectedto decrease due to market forces.

c. Comment: One commenter notedthat the statement that increased EDIclaims submission has the potential toimprove cash flow because those whouse EDI get their payments faster runscounter to HCFA’s decision to instructits contractors to increase the waitingperiod before they issue checks to ahealth care provider. It was stated thatHCFA’s decision may cause cash flowproblems for physicians and mute thebenefits of increased efficiency that aresupposed to be generated by electronicclaims submission. It was also stated



that HCFA needs to refrain from takingactions that run counter to realizing thebenefits envisioned by Congress andspecified in the statute.

Response: Health care providers willshare in many benefits of administrativesimplification. HCFA is fully supportiveof administrative simplification and willexamine this issue carefully to ensurethat there is no conflict. We have notinstructed our contractors to change thewaiting period for payment of Medicareclaims, be they paper or electronic.

d. Comment: One commenter statedthat before the industry begins to useany of the transactions in production,the National Provider System (NPS)should be fully loaded and tested. It wasrecommended that all health careproviders be enumerated and NPS datashould be ready for use on alltransaction sets required under HIPAAwithin the first six months of theimplementation period.

Response: The proposed ruleacknowledged that there is a stronglikelihood that implementationproblems will result in rejectedtransactions, manual exceptionprocessing, payment delays, andrequests for additional information.Therefore, the transaction formats allowfor the use of current/legacy identifiersuntil the NPS is fully implemented. Asrecommended by a number ofcommenters, we have concluded that itwould be best to implement thetransactions and make sure they areimplemented correctly before we beginrequiring the identifiers be to used inthe transactions.

e. Comment: Several commentersrepresenting Medicaid have raised thenotion that costs, both initial and long-term, will be far more expensive thanoriginally anticipated. For example, onecommenter stated that they currentlyuse intelligent health care providernumbers with extensive hard codingand editing. Changing their MMISwould require changing the basic logicof 11 subsystems and 3 million lines ofcode. Another commenter estimatedthey will spend $6.5 million toimplement the HIPAA standards despitethe fact that 78% of their claims arealready submitted electronically.

Response: The Impact Analysisgeneralized that standardization can beexpected to lead to cost-effectivenessand avoidance of burden (see also theresponse to the comment in J. 1. d. inthis section of the preamble). A numberof States have provided cost estimateswhich indicate that the $1 million figuregiven may be too low. We do notdisagree with this assertion, but believethat the costs will be spread out over alonger period of time than expected, and

will not be as severe as anticipated. Thecosts to States to implement the HIPAAstandards were carefully considered, butwere not the only factor considered indeveloping the individual standards. Anumber of guiding principles (see B.Guiding Principles for StandardSelection in section IV. of thispreamble) were followed and the overalladequacy and acceptance of thesestandards is dependent upon thestandards meeting these guidingprinciples.

f. Comment: Several commentersexpressed concern that theimplementation time frame falls withinthe time period required to makemillennium and Medicare BalancedBudget Act (BBA) changes. It was statedthat the industry was given littleflexibility in determining the most cost-effective way to implement the HIPAAstandards.

Response: The Impact Analysis statesthat health care providers haveconsiderable flexibility in determininghow and when to accomplish changesin their systems to accommodate theHIPAA standards. Due to the longerthan expected time to publish this finalrule, the implementation time framewill fall beyond millennium changesand most BBA changes. Therefore, it isstill possible to evaluate the most cost-effective approach.

g. Comment: One commenter statedthat the impact analysis did notspecifically mention who wouldprovide the translator software thatwould be integrated into an existingsystem. If small physician practices areusing older ‘‘legacy’’ type systems, theymay not be able to create an interfacewith a translator that would accept thestandard data. A complete systemoverhaul would be extremely costly tothese specific health care providergroups.

Response: The Impact Analysis didnot specifically mention who wouldprovide the translator software thatwould be integrated into an existingsystem because we expect such softwareto be readily available on the openmarket. However, it did includeestimates from the WEDI reports whichwere updated to reflect the current costsfor small practices to convert theirsystems in order to use the standardformats. These estimates indicate anoverall cost savings for physicianpractices. The most efficient way forsmall physician practices to circumventhigh implementation costs may be touse a health care clearinghouse. Ifhealth care providers cannot create aninterface with a translator, they have theoption to use a health careclearinghouse. This would avoid the

need to overhaul older type systems inorder to accommodate the HIPAAstandards. Furthermore, the costs forvendors and health care clearinghousesshould be reduced due to the use ofnational EDI standards as well as theNPI. The overall homogeneity of theseEDI formats should significantly reducethe high costs associated with theprocessing of different electronic claimsformats. In turn, this would allowvendors and health care clearinghousesto provide services at lower costs, whichshould enable savings to be passed onto health care providers. In this regard,we also anticipate that marketcompetition should tend to keep costsdown.

h. Comment: One commenter believedthat as part of a 1999 Presidentialproposal, Medicare will charge onedollar for each paper Medicare claimthat a physician submits. Thecommenter stated that this unfairlyundermines a physician’s ability tocontinue to submit paper claims.

Response: Medicare has not instituteda user fee for paper claims.

3. Benefits of Increased EDI for HealthCare Transactions

Comment: One commenter stated thatthe impact analysis should factor in thecost of dismantling existing electronicinterchange systems. It was also statedthat health care providers may movefrom electronic to paper submission ifthey feel that the costs and burdensassociated with the new standards aretoo great.

Response: There is no need todismantle entire systems. Rather,provisions need to be made toaccommodate the new standards. Webelieve that the benefits health careproviders are currently realizingthrough EDI will continue and willincrease with the adoption of thesestandards. Unlike current practiceswhich compel health care providers touse multiple formats when sending andreceiving, health care providers willonly need to use one format for eachHIPAA standard when they send andreceive. If health care providers areunwilling to upgrade their EDI system,they have the option of using a healthcare clearinghouse, or reverting to paperclaim submission.

4. The Role of Standards in Increasingthe Efficiency of EDI

Comment: One commenter stated thatthere are many factors affecting a healthcare provider’s decision as to when toconvert to EDI. Thus, the idea that ahealth care provider may decide todelay conversion to EDI until it is ‘‘cost-effective’’ is made moot by other forces



affecting a health care provider’sdecision making process.

Response: Health care providers mustuse the standards if they wish to dobusiness electronically. While otherfactors will impact their decision to dobusiness electronically, we believe thatthe HIPAA standards will produce costsavings and efficiencies in EDI whichshould help convince health careproviders of the benefits of EDI.

All known factors that may influencea health care provider’s decision weretaken into account when the proposedrule was written and published.However, other factors may arise thatwere not accounted for. It is impossibleto account for every possible scenariofor every health care provider. TheImpact Analysis took into accountfactors based on the data available at thetime. These factors, which represent awide spectrum of possibilities, wereincluded in the cost-effectivenessfigures and the overall decision makingprocess.

5. Cost/Benefit Tablesa. Comment: Several commenters

representing Medicaid had a number ofcomments regarding these tables. First,with respect to Table 1 (63 FR 25344)(see VI. Final Impact Analysis, I. Cost/Benefit Tables of this preamble for theupdated table) they stated it wasdifficult to assess where Medicaid wasrepresented or whether any otherFederal program was included. Second,regarding that same table, it was statedthat the method of allocating savingswas imprecise and illogical whenconsideration is given to existing EDIsystems that will have to be changed.For high end-users, the costs to convertwill consume most of the savings.Third, because so much of Medicaid isautomated already, the estimatedsavings that will offset 50% of theupgrade cost will be less. The costassumptions are also not inclusive ofthe numerous operational activitiesassociated with the possible role of theenumerator. One Medicaid Agencyspecifically mentioned that they paytheir fiscal associate $.2672 to processany type of claim. They stated that thesavings estimates based on $1 per claimfor health plans and physicians and $.75per claim for hospitals and other healthcare providers does not relate to theirexperience.

Response: Medicare and Medicaidprogram costs and savings were notincluded in the table on cost andsavings to health plans because theImpact Analysis was done for privatesector health plans only, as required.Cost estimates were made using theWEDI report and may not be specific to

Medicaid or other State Agencies. Theyare also not specific to any uniqueexperience. The savings mentioned inthe analysis are based on overallutilization.

b. Comment: Several commentersstated that the pharmacist enumerationcosts were underestimated. Table 2 (63FR 25344) (see VI. Final ImpactAnalysis, I. Cost Benefit/Tables of thispreamble for the updated table) lists70,100 pharmacies; however, no datawas included regarding the number ofpharmacists. There are about 200,000pharmacists. It was stated that theenumeration costs should be adjustedaccordingly.

Response: We did not enumeratepharmacists, because the pharmacy isthe entity that does most of the billingand, therefore, is the appropriate unitfor analysis.

c. Comment: One commenter raisedseveral questions regarding Table 4a (63FR 25346), which shows relative savingsand volume of other transactions (note,Table 4a corresponds to Table 5 in VI.Final Impact Analysis, I. Cost/BenefitTables of this preamble): (1) Was theASC X12N 997 transaction included inthe ‘‘Claim’’ transaction in Table 4a; (2)was the ASC X12N 277 included in the‘‘Claims Inquiry’’ transaction; (3) doesthe ‘‘Remittance Advice’’ includepayment data and Electronic FundsTransfer (EFT) payment; (4) hasallowance been made for any charges bybanks for passing on the payment data;(5) is the ASC X12N 275 included inone of the transactions listed; and (6)how was the ‘‘Average Cost for Non-EDIHealth Plans’’ calculated?

Response: (1) The ASC X12N 997 isnot a HIPAA transaction standard andwas not included. (2) The ASC X12N277 does represent a HIPAA transactionstandard and was included in theanalysis. (3) The ‘‘Remittance Advice’’includes payment data and EFTpayment. (4) The cost of the banksprocessing data was not included in theimpact analysis because the EFT processwill remain the same under thestandards. Banks are not required to usethe HIPAA standards; however, most, ifnot all, are expected to continue to usethe Automated Clearinghouse (ACH)standard which they are now using forEFT (and which would be compliantwith these standards). (5) The ASCX12N 275 was not included in thetransactions listed. (6) The cost to non-EDI health plans was computed asfollows: total entities × (1 ¥ EDI %) ×average upgrade cost × 0.5.

d. Comment: One commenter statedthat more information is needed on themethodology used to calculate the costs/

benefits in order for each hospital tomodel the cost/benefits.

Response: The methodology forcalculating the costs/benefits for healthcare providers was derived from theWEDI report and was mentioned at thebeginning of the Impact Analysis. TheWEDI report also documents how thatmethodology was applied.

6. Quantitative Impacts ofAdministrative Simplification

a. Comment: In regard to Medicaid,commenters noted that with themandatory nature of EDI rules, theobligation to coordinate ‘‘who payswhen’’ was not included (i.e., Medicaidis the payer of last resort). It was statedthat standardization of data andtransactions alone will not help unlesshealth plans pass on those rules.Administrative simplification couldfacilitate coordination of benefits byhaving a standardized set of data that isknown to all parties, along withstandardized name and addressinformation that tells where to routetransactions.

Response: We agree thatstandardization will facilitatecoordination of benefits by having inplace a standardized set of data. This isone of the goals of administrativesimplification. The HIPAA standards dorequire health plans to use the standardCOB transaction for exchanging COBwith other health plans.

b. Comment: Some comments statedthat the administrative burden forhealth plans may increase as more datavalidation occurs in a post-adjudicationenvironment. It was stated that theexample of staff translation of codes dueto standardized codes was misleading,since individuals must still performcoding actions in order to enter patientdata into the hospital informationsystem or other patient data systems.

Response: The implementation of theHIPAA standards will actually reducethe overall need for data validation as itwill reduce the need for clerical entry.Although there may still be individualmanipulation or translation of codes, itwill be less labor intensive; this resultwill be due to the replacement ofmultiple EDI formats with one set ofnationally accepted standards.

c. Comment: One commenter statedthat the cost to maintain a proprietaryhealth care provider file may remainbasically the same or may increase asthere may be an increased need tovalidate data between the proprietaryfile and the National Provider Systemdatabase (NPS); this result would morethan offset any savings that may havebeen realized through the elimination ofother health care provider numbers.



Response: When the NPI isimplemented, there will be a one timecost to entities to align their proprietaryhealth care provider files to NPS dataand add the NPI to their files. Once theNPI has been added, though, we wouldexpect ongoing costs for severalfunctions (COB, health care providermonitoring, communications withhealth care providers, etc.) to bereduced because of the uniformnumbering system and the eliminationof health care provider enumerationactivities by individual health plans.

7. Regulatory Flexibility Analysisa. Comment: One commenter

recommended that the statement ‘‘costsavings will be passed on to customersof health care clearinghouses and billingagencies’’ should be reworded to statethat cost savings ‘‘should’’ be passed onrather than imply that they will. It ispossible that these savings won’t bepassed on because health careclearinghouses may be in a position toprofit from the increased demand fortheir services. The possibility also existsthat costs will decrease, and as a resultprices will drop to reflect these savings.

Response: We believe that marketforces will drive down costs, and as aresult savings will be passed on tocustomers of health care clearinghousesand billing agencies.

b. Comment: One commenter statedthat there is no guarantee that smallhealth care providers will embrace EDI.There should be information abouteducational campaigns and how thateducational outreach will occur.

Response: The Impact Analysisacknowledges that not everyone willmove to the HIPAA standards and useEDI. However, since the catalyst behindthis statute was the health care industry,we expect that health plans and otherswill recognize the benefits they canenjoy through administrativesimplification, and will educate healthcare providers so that benefits will berealized.

8. Unfunded Mandatesa. Comment: Several commenters

stated that it is possible that a portionof the costs which managed careorganizations will incur due to HIPAAwill be passed onto the Medicaidprogram in the form of increasedcapitation payments. It was stated thatwhile the Secretary puts forth a CostBudget Office (CBO) analysis indicatingthat States ‘‘have the option tocompensate by reducing otherexpenditures,’’ they have first-handknowledge of the challenges associatedwith ‘‘reducing’’ expendituresassociated with entitlement programs.

Furthermore, enrollment of Medicaidrecipients into managed care programsdoes not eliminate the need for fee-for-service claims processing under the newstandards. One commenter noted that $2million is a conservative estimate of thecost to a State to modify its MMIS tocomply with the HIPAA mandates. Theimprovements offered are gearedtowards EDI between commercial healthplans and their health care providers.Benefits of increased EDI and healthcare provider enumeration accrue to allEDI participants at the expense of theMedicaid program.

Response: We do not agree that thebenefits of EDI for the health carecommunity would increase at theexpense of the Medicaid program. Weacknowledge that the implementationcosts for each State may beunderestimated. However, the benefitsof administrative simplification shouldaccrue to every health care entity,whether public or private. The costs tothe Medicaid program will be spreadout over a longer period of time thanexpected, which will mitigate any largefinancial impact. Additional provisionswere also included for specializeddelivery services. The Department willmatch 75–90% of the costs associatedwith the MMIS and the new softwarethat will be integrated for the HIPAAstandards. The long-term savings willoffset implementation costs. Werecognize that fee-for-service claimsprocessing will continue.

b. Comment: Several commentersstated that it may be an inaccurateconclusion that the unfunded mandatesof HIPAA will not result in significantcosts to State governments. In fact, itmay cost States between $2 and $10million to restructure for HIPAAcompliance. Furthermore, the start-upcosts will be high in order to aligncurrent health care provider files withthe NPS so that matches can be made.Start-up costs will probably exceed $1million per health plan. There are alsoadditional indirect costs which are notmentioned. Indirect costs may arisefrom having to reorganize businessfunctions and possibly having to pay theimplementation costs of health careproviders, health care clearinghousesand health plans.

Response: We agree that thecalculated costs may be underestimatedand the Impact Analysis does state thatit is difficult to assess cost/benefits ofsuch a sweeping change. Many of thecosts mentioned in the comment areshort-term costs. The long-term savingsthat will accrue from administrativesimplification will offset the short-termexpenditures. Each health care providerwill have to determine how to treat

these initial costs until the savings beginto accrue.

c. Comment: One commenter statedthat many areas of the paymentprocesses are still done manually.Changes/upgrades to bulletin board typesystems that receive electronic billingdata from health care providers will alsoimpact the costs of this unfundedmandate.

Response: The costs associated withthese bulletin board type systems havebeen included in the estimated cost ofsystem upgrades mentioned in theImpact Analysis.

IV. Summary of Changes to theRegulations

Listed below is a summary of changesmade to 45 CFR.

• Added Part 160 and movedproposed §§ 142.101, 142.103, and142.106 to Part 160.

• Added definitions for the followingterms in § 160.103: ‘‘business associate,’’‘‘compliance date,’’ ‘‘covered entity,’’‘‘implementation specification,’’‘‘modify,’’ ‘‘standard settingorganization,’’ ‘‘state,’’ ‘‘trading partneragreement,’’ and ‘‘workforce.’’

• Added definitions for the followingterms in § 162.103: ‘‘code setmaintaining organization,’’ ‘‘datacondition,’’ ‘‘data content,’’ ‘‘dataelement,’’ ‘‘data set,’’ ‘‘descriptor,’’‘‘designated standard maintenanceorganization,’’ ‘‘direct data entry,’’‘‘electronic media,’’ ‘‘format,’’‘‘maintenance,’’ ‘‘maximum defineddata set,’’ ‘‘segment,’’ ‘‘standardtransaction.’’

• Deleted definitions for ‘‘ASC X12,’’ASC X12N,’’ ‘‘medical care,’’ and‘‘participant.’’

• Added § 160.104 to describe theeffective date and compliance date of amodification to an established standard.

• Included the word ‘‘retail’’ whenreferring to the NCPDP standard.

• Included language in § 162.923(formerly 142.102) to include therequirements for the use of direct dataentry and to clarify requirements forcovered entities.

• Added § 162.910 to address theprocess for maintenance of thestandards.

• Added section § 162.915 to includethe requirements of trading partneragreements.

• Removed the words ‘‘at no cost’’ in§ 162.920(a) when referring to theacquisition of implementationspecifications.

• Revised language in § 162.925(formerly § 142.104) to state that ahealth plan may not delay thetransaction or attempt to adverselyaffect the entity or the transaction on the



basis that the transaction is a standardtransaction. Added COB and code setrequirements.

• Included language in § 162.930 toclarify compliance of health careclearinghouses.

• Added § 162.940 to include theprocess for requesting an exception totest proposed modifications tostandards.

• Revised language in § 162.1000 toinclude the requirement for the use ofapplicable medical code sets and, in§ 162.1002, we listed the name of all thestandard medical code sets.

• Added § 162.1011 to addresscompliance dates for maintenancechanges to code sets.

• Corrected language in § 162.1102 toreflect the correct version of the NCPDPBatch Standard, Version 1 Release 0.

• Added language in § 162.1602 toinclude the NCPDP standard for healthcare payment and remittance advicewithin the retail pharmacy sector.

• Added language in § 162.1202 toinclude the NCPDP standard for patienteligibility and coverage informationwithin the retail pharmacy sector.

• Included the description of eachtransaction in subparts K through R,§§ 162.1101, 162.1201, 162.1301,162.1401, 162.1501, 162.1601, 162.1701,and 162.1801.

V. Collection of InformationRequirements

Under the Paperwork Reduction Actof 1995 (PRA), agencies are required toprovide a 30-day notice in the FederalRegister and solicit public comment ona collection of information requirementsubmitted to the Office of Managementand Budget (OMB) for review andapproval. In order to fairly evaluatewhether an information collectionshould be approved by OMB, section3506(c)(2)(A) of the PRA requires thatwe solicit comment on the followingissues:

• Whether the information collectionis necessary and useful to carry out theproper functions of the agency.

• The accuracy of the agency’sestimate of the information collectionburden.

• The quality, utility, and clarity ofthe information to be collected.

• Recommendations to minimize theinformation collection burden on theaffected public, including automatedcollection techniques.

We are soliciting public comment oneach of these issues for the followingsections of this document that containinformation collection requirements:

In summary, each of the sectionsidentified below require health careplans, and/or health care providers to

use the standards referenced in thisregulation for all electronicallytransmitted standard transactions thatrequire it on and after the effective dategiven to it.

Subpart I—General Provisions forTransactions

Section 162.923 Requirements forcovered entities

Section 162.925 Additionalrequirements for health plans

Discussion: As referenced in theproposed rule, the emerging andincreasing use of health care EDIstandards and transactions has raisedthe issue of the applicability of the PRA.As such, we solicited comment onwhether a regulation that adopts an EDIstandard used to exchange certaininformation constitutes an informationcollection is subject to the PRA. Publiccomments were presented whichsuggested that the use of an EDIstandard is not an informationcollection and under the PRA. TheOffice of Management and Budget,however, has determined that thisregulatory requirement (whichmandates that the private sector discloseinformation and do so in a particularformat) constitutes an agency sponsoredthird-party disclosure as defined underthe Paperwork Reduction Act of 1995(PRA).

HIPAA mandates the Secretary toadopt standards that have beendeveloped, adopted, or modified by astandard setting organization, unlessthere is no such standard, or unless adifferent standard would substantiallyreduce administrative costs. OMB hasconcluded that the scope of its reviewunder the PRA would be limited to thereview and approval of this regulatoryrequirement, that is, the Secretary’sdecision to adopt or reject anestablished industry standard, based onthe HIPAA criterion of whether adifferent standard would substantiallyreduce administrative costs. Forexample, if OMB concluded under thePRA that a different standard wouldsubstantially reduce administrativecosts as compared to an establishedindustry standard, the Secretary wouldbe required to reconsider its decisionunder the HIPAA standards. TheSecretary would be required to make anew determination of whether it isappropriate to adopt an establishedindustry standard or whether it shouldenter into negotiated rulemaking todevelop an alternative standard (section1172(c)(2)(A)).

The burden associated with theserequirements, which is subject to thePRA, is the initial one-time burden on

the entities identified above to modifytheir current computer systemrequirements. However, the burdenassociated with the routine or ongoinguse of these requirements is exemptfrom the PRA as defined in 5 CFR1320.3(b)(2).

Based on the assumption that theburden associated with HIPAA, Title IIsystems modifications may overlap andthe HIPAA standards would replace theuse of multiple standards, resulting in areduction of burden, commentersshould take into consideration whendrafting comments that: (1) One or moreof these standards may not be used; (2)some of the these standards may alreadybe in use by several of the estimatedentities; (3) systems modifications maybe performed in an aggregate mannerduring the course of routine businessand/or; (4) systems modifications maybe made by contractors such as practicemanagement vendors, in a single effortfor a multitude of affected entities.

As required by section 3504(h) of thePaperwork Reduction Act of 1995, wehave submitted a copy of this documentto the Office of Management and Budget(OMB) for its review of theseinformation collection requirements.

If you comment on these informationcollection and recordkeepingrequirements, please e-mail commentsto [email protected] (Attn:HCFA–0149) or mail copies directly to thefollowing:Health Care Financing Administration,

Office of Information Services,Information Technology InvestmentManagement Group, Division ofHCFA Enterprise Standards, RoomC2–26–17, 7500 Security Boulevard,Baltimore, MD 21244–1850, Attn:HCFA–0149

AndOffice of Information and Regulatory

Affairs, Office of Management andBudget, Room 10235, New ExecutiveOffice Building, Washington, DC20503, Attn: Allison Herron Eydt,HCFA Desk Officer

VI. Final Impact Analysis

A. Executive Summary

Title II of the Health InsurancePortability and Accountability Act(HIPAA) provides a statutory frameworkfor the establishment of acomprehensive set of standards for theelectronic transmission of healthinformation. Pursuant to this Title, theDepartment of Health and HumanServices published proposed regulationsconcerning electronic transactions andcode sets (May, 1998), national standardhealth care provider identifier (May,1998), national standard employer



identifier (June, 1998), security andelectronic signature standards (August,1998), and standards for privacy ofindividually identifiable healthinformation (November, 1999).

Currently, there are numerouselectronic codes available in the market.Without government action, a commonstandard might eventually emerge as theresult of technological or marketdominance. However, the unevendistribution of costs and benefits mayhave hindered the development of avoluntary industry-wide standard.Congress concluded that the currentmarket is deadlocked and that thehealth care industry would benefit inthe long run if government action weretaken now to establish an industrystandard. This approach, however, doesentail some risks. For example,whenever the government chooses astandard, even one that is the bestavailable at any point in time, theincentives to develop a better standardmay be diminished because there isvirtually no market competition andgovernment-led standards often takelonger to develop than those developedas the result of market pressures. Theapproach taken in this regulation isdesigned to encourage and capitalize onmarket forces to update standards asneeds and technology change and havethe government respond as quickly andefficiently as possible to them.

As discussed in the proposals, theregulations will provide a consistentand efficient set of rules for thehandling and protection of healthinformation. The framework establishedby these administrative simplificationregulations is sufficiently flexible toadapt to a health system that isbecoming increasingly complex throughmergers, contractual relationships, andtechnical and telecommunicationchanges. Moreover, the promulgation ofa final privacy standard will enhancepublic confidence that highly personaland sensitive information is beingproperly protected, and therefore, it willenhance the public acceptance ofincreased use of electronic systems.Collectively, the standards that will bepromulgated under Title II can beexpected to accelerate the growth ofelectronic transactions and informationexchange in health care.

The final Impact Analysis providesestimates based on more currentinformation and more refinedassumptions than the original NPRManalysis. Since the original estimateswere made, some of the voluntarydevelopment and investment intechnology that was anticipated at thetime of the proposal was diverted ordelayed because of Y2K concerns; the

investment is still expected but thetiming of it has been delayed. Theanalysis utilizes more current data andreflects refinements in underlyingassumptions based on the publiccomments and other information thathas been collected on market changes.In addition, this analysis extended thetime period for measuring costs andsavings from five years to ten years.Given that the HIPAA provisionsrequire initial expenses butsubsequently produce a steady stream ofsavings, a ten year analysis moreaccurately measures the impact of theregulations.

This final rule has been classified asa major rule subject to Congressionalreview. The effective date is October 16,2000. If, however, at the conclusion ofthe Congressional review process theeffective date has been changed, we willpublish a document in the FederalRegister to establish the actual effectivedate or to issue a notice of terminationof the final rule action.

Therefore, the following analysisincludes the expected costs and benefitsof the administration simplificationregulations related to electronic systemsfor ten years. Although only theelectronic transactions standards arebeing promulgated in this regulation,the Department expects affected partiesto make systems complianceinvestments collectively because theregulations are so integrated. Moreover,the data available to us are also basedon the collective requirements of theregulations; it is not feasible to identifythe incremental technological andcomputer costs for each regulationbased on currently available data. TheDepartment acknowledges that theaggregate impact analysis does notprovide the information necessary toassess the choice of specific standards.

The costs of implementing thestandards specified in the statute areprimarily one-time or short-term costsrelated to conversion. These costsinclude system conversion/upgradecosts, start-up costs of automation,training costs, and costs associated withimplementation problems. These costswill be incurred during the first threeyears of implementation. Although theremay be some ongoing maintenance costsassociated with these changes, vendorsare likely to include these costs as partof the purchase price. Plans andproviders may choose to upgrade theirsystems beyond the initial upgraderequired by the rule as technologyimproves over time. Since the rule onlyrequires an initial systems upgrade, thecosts of future upgrades are notincluded in the cost estimate of the rule.The benefits of EDI include reduction in

manual data entry, elimination of postalservice delays, elimination of the costsassociated with the use of paper forms,and the enhanced ability of participantsin the market to interact with eachother.

In this analysis, the Department hasused conservative assumptions and ithas taken into account the effects of thetrend in recent years toward electronichealth care transactions. Based on thisanalysis, the Department hasdetermined that the benefits attributableto the implementation of administrativesimplification regulations will accruealmost immediately but will not exceedcosts incurred by health care providersand health plans until after the secondyear of implementation. After thesecond year, however, the benefits willcontinue to accrue for an extendedperiod of time. The total net savings forthe period 2002–2011 will be $29.9billion (a net savings of $13.1 billion forhealth plans, and a net savings of $16.7billion for health care providers). Thesingle year net savings for the year 2011will be $5.6 billion ($2.5 billion forhealth plans and $3.1 billion for healthcare providers). The discounted presentvalue of these savings is $19.1 billionover the ten years. These estimates donot include the sizeable secondarybenefits that are likely to occur throughexpanded e-commerce resulting fromstandardized systems.

In accordance with the provisions ofExecutive Order 12866, this rule wasreviewed by the Office of Managementand Budget.

B. Guiding Principles for StandardSelection

The implementation teams chargedwith designating standards under thestatute have defined, with significantinput from the health care industry, aset of common criteria for evaluatingpotential standards. These criteria arebased on direct specifications in theHIPAA, the purpose of the law, andprinciples that support the regulatoryphilosophy set forth in Executive Order12866 of September 30, 1993, and thePaperwork Reduction Act of 1995. Inorder to be designated as a standard, aproposed standard should:

• Improve the efficiency andeffectiveness of the health care systemby leading to cost reductions for orimprovements in benefits fromelectronic HIPAA health caretransactions. This principle supports theregulatory goals of cost-effectivenessand avoidance of burden.

• Meet the needs of the health datastandards user community, particularlyhealth care providers, health plans, andhealth care clearinghouses. This



principle supports the regulatory goal ofcost-effectiveness.

• Be consistent and uniform with theother HIPAA standards (that is, theirdata element definitions and codes andtheir privacy and security requirements)and with other private and public sectorhealth data standards to the extentpossible. This principle supports theregulatory goals of consistency andavoidance of incompatibility, and itestablishes a performance objective forthe standard.

• Have low additional developmentand implementation costs relative to thebenefits of using the standard. Thisprinciple supports the regulatory goalsof cost-effectiveness and avoidance ofburden.

• Be supported by an ANSI-accredited standard setting organizationor other private or public organizationthat will ensure continuity and efficientupdating of the standard over time. Thisprinciple supports the regulatory goal ofpredictability.

• Have timely development, testing,implementation, and updatingprocedures to achieve administrativesimplification benefits faster. Thisprinciple establishes a performanceobjective for the standard.

• Be technologically independent ofthe computer platforms andtransmission protocols used in HIPAAhealth transactions, except when theyare explicitly part of the standard. Thisprinciple establishes a performanceobjective for the standard and supportsthe regulatory goal of flexibility.

• Be precise and unambiguous but assimple as possible. This principlesupports the regulatory goals ofpredictability and simplicity.

• Keep data collection and paperworkburdens on users as low as is feasible.This principle supports the regulatorygoals of cost-effectiveness andavoidance of duplication and burden.

• Incorporate flexibility to adapt moreeasily to changes in the health careinfrastructure (such as new services,organizations, and health care providertypes) and information technology. Thisprinciple supports the regulatory goalsof flexibility and encouragement ofinnovation.

C. Introduction

The Department assessed severalstrategies for determining the impact ofthe various standards that the Secretarywill designate under the statute. Thecosts and savings of each individualstandard could be analyzedindependently, or the Department couldanalyze the costs and savings of all thestandards in the aggregate. The decisionwas made to base the analysis on the

aggregate impact of all the standards.Given that all the standards are likely tobe made final within a reasonableperiod of one another, it is likely thatorganizations will seek to make changesto comply with all the regulations at thesame time, at least for those componentsof the regulations that require computerand technology changes. This will bethe most efficient investment for mostaffected organizations, and the estimatesthe Department has obtained fromindustry sources are based on thisassumption.

The statute gives health careproviders and health plans 24 months(36 months for small health plans) toimplement each standard after theeffective date of the final rule. Thisprovides the industry flexibility indetermining the most cost-effectivemeans of implementing the standards.Dictated by their own business needs,health plans and health care providersmay decide to implement more than onestandard at a time or to combineimplementation of a standard with othersystem changes. As a result, overallestimates will be more accurate thanindividual estimates.

Assessing the benefits ofimplementing each standardindependently could also be inaccurate.While each individual standard isbeneficial, the standards as a wholehave a synergistic effect on savings. Forexample, the combination of thestandard health plan identifier and thestandard claim format will improve thecoordination of benefits process to amuch greater extent than use of eitherstandard individually.

It is difficult to assess the costs andbenefits of such a sweeping changebecause no-one has historicalexperience with this unique area.Moreover, the standardization ofelectronic transactions will spursecondary innovations, particularly in e-commerce, that may be describedgenerally but are too new to assessquantitatively. Consequently, theanalysis of these secondary benefits willbe qualitative.

D. Overall Cost/Benefit AnalysisTo assess the impact of the HIPAA

administrative simplificationprovisions, it is important to understandcurrent industry practices. A 1993 studyby Lewin-VHI estimated thatadministrative costs comprised 17percent of total health expenditures.Paperwork inefficiencies are acomponent of those costs, as are theinefficiencies caused by the more than400 different data transmission formatscurrently in use. Industry groups suchas ANSI ASC X12N have developed

standards for EDI transactions which areused by some health plans and healthcare providers. However, migration tothese recognized standards has beenhampered by the inability to develop aconcerted approach. For example, even‘‘standard’’ formats such as the UniformBill (UB–92), the standard Medicarehospital claim form (which is used bymost hospitals, skilled nursing facilities,and home health agencies for inpatientand outpatient claims) are customizedby health plans and health careproviders.

Several reports have made estimatesof the costs and/or benefits ofimplementing EDI standards. Inassessing the impact of the HIPAAadministrative simplificationprovisions, the Congressional BudgetOffice reported that:

‘‘The direct cost of the mandates in TitleII of the bill would be negligible. Healthplans (and those health care providers whochoose to submit claims electronically)would be required to modify their computersoftware to incorporate new standards asthey are adopted or modified...Uniformstandards would generate offsetting savingsfor health plans and health care providers bysimplifying the claims process andcoordination of benefits.’’ (Page 4 of theEstimate of Costs of Private Sector Mandatesin the Congressional Budget Office report)

The most extensive industry analysisof the effects of EDI standards wasdeveloped by WEDI in 1993, whichbuilt upon a similar 1992 report. TheWEDI report used an extensive amountof information and analysis to developits estimates, including data from anumber of EDI pilot projects. The reportincluded a number of electronictransactions that are not covered byHIPAA, such as materials management.The WEDI report projectedimplementation costs ranging between$5.3 billion and $17.3 billion (3, p. 9–4) and annual savings for thetransactions covered by HIPAA rangingfrom $8.9 billion and $20.5 billion (3,pp. 9–5 and 9–6). Lewin estimated thatthe data standards proposed in theHealthcare Simplification andUniformity Act of 1993 would save from2.0 to 3.9 percent in administrative costsannually ($2.6 to $5.2 billion based on1991 costs) (1, p.12). A 1995 studycommissioned by the New JerseyLegislature estimated yearly savings of$760 million related to EDI claimsprocessing, reducing claims rejection,performing eligibility checks, decreasingaccounts receivable, and other potentialEDI applications in New Jersey alone (4,p.316).

We have drawn on the 1993 WEDIreport for many of our estimates becauseit is the most comprehensive available.



However, our conclusions differ,especially in the area of savings, for anumber of reasons. The WEDI reportwas intended to assess the savings in anEDI environment that is much broaderthan is covered by HIPAA. Furthermore,EDI continued to grow through the1990’s (see Faulkner & Gray, 2000), andit is reasonable to assume that EDIwould continue to grow for theforeseeable future even without HIPAA.The Department’s objective in thisanalysis is to assess the effect of thelegislation and these regulations on thehealth care sector; only a portion of thebenefits of EDI identified by WEDIwould be attributable to HIPAA.

E. Implementation Costs

The costs of implementing thestandards specified in the statute areprimarily one-time or short-term costsrelated to conversion. They can becharacterized as follows:

1. System Conversion/Upgrade—Health care providers and health planswill incur costs to convert existingsoftware to utilize the standards. Healthplans and large health care providersgenerally have their own informationsystems, which they maintain with in-house or contract support. Small healthcare providers are more likely to use off-the-shelf software developed andmaintained by a vendor. Examples ofsoftware changes include the ability togenerate and accept transactions usingthe standard (for example, claims,remittance advices) and converting orcross walking medical code sets tochosen standards. However, health careproviders have considerable flexibilityin determining how and when toaccomplish these changes. Onealternative to a complete systemredesign would be to purchase atranslator that reformats existing systemoutputs into standard transactionformats. A health plan or health careprovider could also decide toimplement two or more relatedstandards at once or to implement oneor more standards during a softwareupgrade. Each health care provider’sand health plan’s situation will differ,and each will select a cost-effectiveimplementation scheme. Many healthcare providers use billing associates orhealth care clearinghouses to facilitateEDI. (Although we discuss billingassociates and health careclearinghouses as separate entities inthis impact analysis, billing associatesare considered to be the same as healthcare clearinghouses for purposes ofadministrative simplification if theymeet the definition of a health careclearinghouse). Those entities would

also have to reprogram to accommodatestandards.

2. Start-up Cost of Automation—Thestatute does not require health careproviders to conduct transactionselectronically. To benefit from EDI,health care providers who choose toconduct electronic transactions but donot currently have electroniccapabilities would have to purchase andinstall computer hardware and softwareas well as train their staffs to use thetechnology. However, this conversion islikely to be less costly once standardsare in place because there will be morevendors providing support services.Furthermore, providers withoutelectronic capabilities are more likely toconclude that the benefits of conductingtransactions electronically justify acapital investment in EDI technology.

3. Training—Health care provider andhealth plan personnel will requiretraining on the use of the variousstandard identifiers, formats, and codesets. For the most part, training will bedirected toward administrativepersonnel, though clinical staff will alsoneed training on the new code sets.With standardization, however, vendorsare more likely to offer assistance intraining as a means of increasing sales,thereby reducing the per unit cost oftraining.

4. Implementation Problems—Theimplementation of any industry-widestandards will inevitably createadditional complexity in regard to howhealth plans and health care providersconduct business. Health plans andhealth care providers will need to workon re-establishing communication withtheir trading partners, and processtransactions using the new formats,identifiers, and code sets. This is likelyto result in a temporary increase inrejected transactions, manual exceptionprocessing, payment delays, andrequests for additional information.

While the majority of costs are one-time costs related to implementation,there are also on-going costs associatedwith administrative simplification, suchas subscribing to or purchasingdocumentation and implementationspecifications related to code sets andstandard formats and obtaining currenthealth plan and health care provideridentifier directories or data files.Because covered entities are alreadyincurring most of these costs, the costsunder HIPAA will be marginal. Thesesmall ongoing costs are included in theestimate of the system conversion andupgrade costs.

In addition, EDI could affect cash flowthroughout the health insuranceindustry. Electronic claims reach thehealth plan faster and can be processed

faster. This has the potential to improvehealth care providers’ cash flowsituations while decreasing healthplans’ earnings on cash reserves.However, improved cash flow isgenerally considered a benefit,particularly for small businesses.

F. Benefits of Increased Use of EDI forHealth Care Transactions

Some of the benefits attributable toincreased EDI can be readily quantified,while others are more intangible. Forexample, it is easy to compute thesavings in postage from EDI claims, butattributing a dollar value to processingefficiencies is difficult.

The benefits of EDI to the industry ingeneral are well documented in theliterature. One of the most significantbenefits of EDI is the reduction inmanual data entry. The paperprocessing of business transactionsrequires manual data entry when thedata are received and entered into asystem. For example, the data on apaper health care transaction from ahealth care provider to a health planhave to be manually entered into thehealth plan’s business system. If thepatient has more than one health plan,the second health plan would also haveto manually enter the data into itssystem if it cannot receive theinformation electronically. Repeatedkeying of information transmitted viapaper results in increased labor as wellas significant opportunities for keyingerrors. EDI permits direct datatransmission between computer systemswhich, in turn, reduces the need torekey data.

Another problem with paper-basedtransactions is that these documents areprimarily mailed. Normal delivery timesof mailings can vary anywhere from oneto several days for normal first classmail. Shipping paper documents morequickly can be expensive. While bulkmailings can reduce some costs, papermailings remain costly. Using postalservices can also lead to someuncertainty as to whether thetransaction was received, unless moreexpensive certified mail options arepursued. A benefit of EDI is that thecapability exists for the sender of thetransaction to receive an electronicacknowledgment once the data isopened by the recipient. Also, becauseEDI involves direct computer tocomputer data transmission, theassociated delays with postal servicesare eliminated. With EDI,communication service providers suchas value added networks function aselectronic post offices and provide 24-hour service. Value added networks



deliver data instantaneously to thereceiver’s electronic mailbox.

In addition to mailing time delays,there are other significant costs in usingpaper forms. These include the costs ofmaintaining an inventory of forms,typing data onto forms, addressingenvelopes, and the cost of postage. Theuse of paper also requires significantstaff resources to receive and store thepaper during normal processing. Thepaper must be organized to permit easyretrieval if necessary.

G. The Role of Standards in Increasingthe Efficiency of EDI

There was a steady increase in the useof EDI in the health care market throughthe late 1990’s, and there is likely to besome continued growth, even withoutnational standards. However, theupward trend in EDI health caretransactions will be enhanced by havingnational standards in place. Becausenational standards are not in placetoday, there continues to be aproliferation of proprietary formats inthe health care industry. Proprietaryformats are those that are unique to anindividual business. Due to proprietaryformats, business partners that wish toexchange information via EDI mustagree on which formats to use. Sincemost health care providers do businesswith a number of health plans, theymust produce EDI transactions in manydifferent formats. For small health careproviders facing the requirement ofmaintaining multiple formats, this is asignificant disincentive to converting toEDI.

National standards will allow forcommon formats and translations ofelectronic information that will beunderstandable to both the sender andreceiver. Multiple electronic formatsincrease associated labor costs becausemore personnel time and more skills arerequired to link or translate differentsystems. These costs are reflected inincreased office overhead, a reliance onpaper and third party vendors, andcommunication delays. Nationalstandards eliminate the need todetermine what format a trading partneris using. Standards also reduce softwaredevelopment and maintenance coststhat are required for operating orconverting multiple proprietary formats.Health care transaction standards willimprove the efficiency of the EDI marketand will help further persuade reluctantindustry partners to choose EDI overtraditional mail services.

The statute directs the Secretary toestablish standards and sets out thetimetable for doing so. The Secretarymust designate a standard for each ofthe specified transactions and medical

code sets. Health plans and health careproviders generally conduct EDI withmultiple partners and the choice of atransaction format is a bilateral decisionbetween the sender and receiver. Manyhealth care providers and health plansneed to support many differenttransaction formats in order to meet theneeds of all of their trading partners.Single standards will maximize netbenefits and minimize ongoingconfusion.

Health care providers and healthplans have a great deal of flexibility inhow and when they will implementstandards. The statute specifies dates bywhich health plans will have to useadopted standards, however, healthplans can determine if, when, and inwhich order they will implementstandards before the date of mandatorycompliance. Health care providers havethe flexibility to determine when it iscost-effective for them to convert to EDI.Health plans and health care providershave a wide range of vendors andtechnologies from which to choose inimplementing standards and can chooseto utilize a health care clearinghouse totransmit (produce and receive) standardtransactions.

H. Updated Cost and BenefitAssumptions

As mentioned above, we have madechanges to the original impact analysispublished in the NPRM. In response tothe public comments regarding theNPRM impact analysis, the Departmentdid a thorough review of the originalassumptions and data sources. In thereview process, it became clear that theoriginal data sources required updatingand that there were someinconsistencies in the originalassumptions. What follows is anexplanation of each change and therationale behind the new methodology.

Ten Year Time-Frame: This ImpactAnalysis changes the original NPRM’stime-frame from five years to ten years.The need for this change results fromthe nature of the HIPAA regulations:there will be significant one-time initialinvestments followed by many years ofsavings. Because a five year impactanalysis will show the full cost of theregulations but truncate the savingssignificantly, a ten year time-frameallows for a fuller presentation of thebenefits administrative simplificationoffers the health care industry. As anillustration of the difference between afive year and a ten year time frame, theinitial NPRM Impact Analysis estimated$1.5 billion in net savings to theindustry, but a ten year analysis usingidentical assumptions as the originalNPRM would estimate $24.2 billion in

net savings. The Department believes itis more appropriate to use a time framethat more accurately estimates the longterm impact of the regulations.

New Data: Given the length of timebetween the publication of the NPRMand the final rule, it was necessary toupdate data for the number of plans andproviders, the number of claims, and thecurrent proportion of claims that areelectronic in the health care industry.Updated data on the number of differenttypes of plans and providers wereobtained from a variety of sources,including the 1997 Economic Census,the 1999 Statistical Abstract of theUnited States, the American MedicalAssociation and other industry groups,the Department of Labor, and theDepartment of Health and HumanServices. In the NPRM, the 1993 WEDIreport was used to determine the totalnumber of claims in the health careindustry for 1993, which was trendedforward using data from the 1996edition of Faulkner and Gray’s HealthData Directory to estimate the number ofclaims annually over the 1998 to 2002time frame. For the final impactanalysis, we used 1999 data (the mostrecent available) from the 2000 editionof Faulkner and Gray’s Health DataDirectory to determine the total numberof claims in the industry, the number ofclaims by provider type, and the percentof claims that are billed electronicallyby provider type.

The baseline rate of growth in thenumber of claims and the rate of growthin the proportion of electronic claimswere revised using historical trend datafrom the 2000 Faulkner and Gray report.In the final impact analysis, the averageannual rate of growth over the 1995 to1999 period is used to determine theannual increase in the number of claimsand in the proportion of claims that areelectronic, for all claims in the industryand by provider type.

New Electronic Claims GrowthAssumptions: This Impact Analysismakes a refinement to the originalassumptions for determining the rate ofincrease in electronic claims due toHIPAA. The model assumes thatelectronic claims submissions willincrease in the first three years after theimplementation at a rapid pace as manyhealth care providers and health plansmake the switch to electronic formatsbut then the rate will decrease overtime. The model also assumes someproviders will not make the transition toEDI during the ten year period.Specifically, we assumed that theproportion of manual claims willdecrease by twenty percent annuallyfrom 2002 to 2005 and then willdecrease by ten percent annually from



2006 to 2011. By contrast, the originalNPRM model assumed the rate ofincrease in electronic claims wouldgrow by two additional percentagepoints above the baseline rate each year.

Savings per Claim: This impactanalysis uses more consistentassumptions for the savings per claim.In the original NPRM, the savings perclaim for payers and each provider typewas based on the ranges developed byWEDI. However, the NPRM did notconsistently pick from a given point inthe WEDI ranges, but rather variouspoints were chosen for different groupsbased on limited anecdotal information.Upon further analysis, the Departmentno longer believes there is a justifiablebasis to pick from different parts of theWEDI ranges, given the lack ofadditional evidence to support moreprecise assumptions. Therefore, thefinal impact analysis assumes thesavings per claim will be at the mid-point of the WEDI ranges for payers andall providers.

Inflation Adjustment: The finalImpact Analysis corrects aninconsistency found in the NPRMregarding an inflation adjustment to theannual savings per claim assumptions.Specifically, the NPRM increased thesavings per claim by 3% annually toaccount for inflation. This adjustmentwas an inconsistency because no otherfigures in the NPRM impact analysiswere adjusted for inflation. Therefore,for the final impact analysis, all dollarestimates, including the savings perclaim, are in current 2000 dollars.

First Year Savings: Another changemade to the impact analysis was toinclude savings in the first year ofmandatory compliance with the rule.The NPRM assumed that there would beno savings in the first year of mandatorycompliance, yet we believe that thisassumption was in error because mostentities must comply no later than twoyears after the effective date of the finalrule (three years for small health plans),and therefore some savings will begintwo years after publication of the rule.In fact, it could be argued that someentities will come into compliance priorto the two year deadline and begin toproduce savings, but in order to producea conservative estimate, this analysisonly assumes that savings begin in thefirst year of mandatory compliance.

Impact of Changes: The cumulativeeffect of the changes made to the impactanalysis increases the net savings fromadministrative simplification. Althoughthe NPRM only showed five year costsand savings, the underlying analysisincluded ten year estimates as well.Compared to the original impactanalysis, the final impact analysis

increases the estimated gross costs ofthe rule from $5.8 billion to $7.0 billionover ten years. The original impactanalysis produced gross savings of $30billion and net savings of $24.2 billionover ten years while the new impactanalysis produces gross savings of $36.9billion and net savings of $29.9 billionover ten years. Although the new impactanalysis now shows an additional $5.7billion in savings over ten years, theDepartment believes the revisedassumptions underlying these estimatesare based on better, more up-to-datedata, are more consistent, and are morereasonable. The discounted presentvalue of the savings is $19.1 billion overten years. Furthermore, the updatedimpact analysis still produces aconservative estimate of the impact ofadministrative simplification. Forexample, the new impact analysisassumes that over the ten-year post-implementation period, only 11.2% ofthe growth in electronic claims will beattributable to HIPAA. Given the widelyrecognized benefits standardizationoffers the health care industry, assumingthat only 11.2% of all health claims willbe affected by HIPAA represents areasonably conservative estimate of theimpact .

I. Cost/Benefit TablesThe tables below illustrate the

essential costs and savings for healthplans and health care providers toimplement the standards and thesavings that will occur over time as aresult of the HIPAA administrativesimplification provisions. All estimatesare stated in 2000 dollars. The costs arebased on estimates of a moderatelycomplex set of software upgrades,which were provided by the industry.The range of costs and savings thathealth plans and health care providerswill incur is quite large and is based onsuch factors as the size and complexityof the existing systems, ability toimplement using existing low-costtranslator software, and reliance onhealth care clearinghouses to createstandard transactions. The cost of amoderately complex upgrade representsa reasonable mid-point in this range. Inaddition, we assume that health plansand health care providers that operateEDI systems will incur implementationcosts related to manual operations tomake those processes compatible withthe EDI systems. For example, manualprocesses may be converted to producepaper remittance advices that containthe same data elements as the EDIstandard transaction. These costs areestimated to equal 50 percent of thesoftware upgrade cost. Health careproviders that do not have existing EDI

systems will also incur some costs dueto HIPAA, even if they choose not toimplement EDI for all of the HIPAAtransactions. For example, a health careprovider may have to change accountingpractices in order to process the revisedpaper remittance advice discussedabove. We have assumed the averagecost for non-EDI health care providersand health plans to be half that ofalready-automated health care providersand health plans.

Savings due to standardization comefrom three sources. First, there aresavings due to increased use ofelectronic claims submissionsthroughout the health care industry.Second, there will be savings based onsimplification of the manual claims thatremain in the system. Finally, there willbe savings due to increased electronicnon-claims transactions, such aseligibility verifications and coordinationof benefits. It is important to view theseestimates as an attempt to furnish arealistic context rather than as precisebudgetary predictions. The estimatesalso do not include any benefitsattributable to the qualitative aspects ofadministrative simplification, nor isthere any inclusion of secondarybenefits. Industry people have arguedthat standardization will acceleratemany forms of new e-commerce. Theseinnovations may generate significantsavings to the health care system orimprovements in the quality of healthbut they have not been included here.

More detailed information regardingdata sources and assumptions isprovided in the explanations for thespecific tables.

Table 1 below shows estimated costsand savings for health plans. Thenumber of plans listed in the chart isderived from the 1993 WEDI report,trade publications, and data from theDepartment of Labor. The cost perhealth plan for software upgrades isbased on the WEDI report, whichestimated a range of costs required toimplement a fully capable EDIenvironment, and more currentestimates provided by the industry. Thehigh-end estimates ranged from two toten times higher than the low-endestimates. Lower end estimates wereused in most cases because, asexplained above, HIPAA does notrequire changes as extensive asenvisioned by WEDI. The estimatedpercentages of health plans that acceptelectronic billing are based on reports inthe 2000 edition of Faulkner & Gray’sHealth Data Directory (5). The total costfor each type of health plan is the sumof the cost for EDI and non-EDI healthplans. Cost for EDI health plans iscomputed as follows:



(Total Entities × EDI % × AverageUpgrade Cost × 1.5)

Note: As described above, EDI health planswould incur costs both to upgrade softwareand to make manual operations compatiblewith EDI systems. The cost of changingmanual processes is estimated to be half thecost of system changes.

Cost for non-EDI health plans iscomputed as follows:Total entities × (1¥EDI %) × Average

Upgrade Cost × 0.5Note: As described above, cost to non-EDI

health plans is assumed to be half the costof systems changes for EDI plans.

The data available permit us to makereasonable estimates of the costs that

will be borne by different types ofhealth plans (Table 1). Unfortunately,though we can estimate the overallsavings, we cannot reliably estimatetheir distributional effects. Hence, onlythe aggregate savings estimates arepresented.

TABLE 1.—HEALTH PLAN IMPLEMENTATION COSTS AND SAVINGS

[2002–2011]

Type of health plan Number ofhealth plans

Averagecost % EDI Total cost

(in millions)Savings

(in millions)

Large commercials ................................................................................... 250 $1,000,000 90 $350Small commercials ................................................................................... 400 500,000 50 200Blue Cross/Blue Shield ............................................................................ 48 1,000,000 100 98Third-party administrators ........................................................................ 750 500,000 50 375HMO/PPO ................................................................................................ 1,630 250,000 60–85 487Self-administered ..................................................................................... 50,000 50,000 25 1,875Other employer health plans ................................................................... 2,550,000 100 00 127

Total (Undiscounted) ........................................................................ .................... .................... .................... $3,512 $16,600Total (Discounted) ............................................................................ .................... .................... .................... $3,300 $11,600

Note: The estimates in Table 1 show costsavings in 2000 dollars (estimates in theproposed rule were in 1998 dollars). TheOffice of Management and Budget nowrequires all agencies to provide estimatesusing a net present value calculation.Furthermore, OMB recommends the use of a7 percent discount rate based on the currentcost of capital. The discounted totals in thetable are based on this rate beginning in2003.

Table 2 illustrates the costs andsavings attributable to various types ofhealth care providers.

The number of entities (practices orestablishments, not individual healthcare providers) is based on the 1997Economic Census, the 1999 StatisticalAbstract of the United States, theAmerican Medical Association’s

Physician Characteristics andDistribution in the U.S. (2000–2001edition), and Department of Health andHuman Services data trended to 2002.Estimated percentages of EDI billing arebased on the 2000 edition of Faulkner& Gray’s Health Data Directory or areDepartmental estimates.

The cost of software upgrades forpersonal computers (PCS) in providerpractices or establishments is based onreports of the cost of software upgradesto translate and communicatestandardized claims forms. The low endof the range of costs is used for smallerpractices or establishments and the highend of the range of costs for largerpractices/establishments with PCS. Thecost per upgrade estimate for hospitals

and other facilities is a Departmentalestimate derived from estimates byWEDI and estimates of the cost of newsoftware packages in the literature. Theestimates fall within the range of theWEDI estimates, but that range is quitelarge. For example, WEDI estimates thatthe cost for a large hospital upgrade willbe from $50,000 to $500,000.

The $20.2 billion in savings in Table4 represents savings to health careproviders for the first ten years ofimplementation. The discountedpresent value of these savings is $19.1billion over ten years. They are includedto provide a sense of how the HIPAAadministrative simplification provisionswill affect various entities.

TABLE 2.—HEALTH CARE PROVIDER IMPLEMENTATION COSTS AND SAVINGS

[2002–2011]

Type of health care provider

Number ofhealth careproviders

(2002 est.)



(in millions)

Federal Hospitals ..................................................................................... 266 $250,000 88 $92Non-Federal Hospitals <100 beds ........................................................... 2,639 100,000 88 364Non-Federal Hospitals 100+ beds ........................................................... 2,780 250,000 88 960Nursing facility <100 beds ....................................................................... 9,606 10,000 90 134Nursing facility 100+ beds ....................................................................... 8,833 20,000 90 247Home health agency ................................................................................ 8,900 10,000 90 184Hospice .................................................................................................... 2,027 10,000 90 28Residential Mental Health/Retardation/Substance Abuse Facilities ........ 22,339 10,000 10 134Outpatient care centers ........................................................................... 24,034 10,000 75 300Pharmacy ................................................................................................. 43,900 4,000 96 256Medical labs ............................................................................................. 9,500 4,000 85 51Dental labs ............................................................................................... 7,900 1,500 50 12DME ......................................................................................................... 112,200 1,500 50 168Physicians solo and groups less than 3 .................................................. 193,000 1,500 50 290Physicians groups 3+ with computers ..................................................... 20,000 4,000 90 112Physicians groups 3+ no automation ...................................................... 1,000 0 00 0Osteopaths ............................................................................................... 13,600 1,500 10 12



TABLE 2.—HEALTH CARE PROVIDER IMPLEMENTATION COSTS AND SAVINGS—Continued[2002–2011]

Type of health care provider

Number ofhealth careproviders

(2002 est.)



(in millions)

Dentists .................................................................................................... 120,000 1,500 30 144Podiatrists ................................................................................................ 9,100 1,500 05 8Chiropractors ........................................................................................... 32,000 1,500 05 26Optometrists ............................................................................................. 18,800 1,500 05 16Other professionals .................................................................................. 33,400 1,500 05 28

Total (Undiscounted) ........................................................................ .................... .................... .................... $3,566 $20,200Total (Discounted) ............................................................................ .................... .................... .................... $3,300 $14,100

Note: The estimates in Table 2 show costsavings in 2000 dollars (estimates in theproposed rule were in 1998 dollars). TheOffice of Management and Budget nowrequires all agencies to provide estimatesusing a net present value calculation.Furthermore, OMB recommends the use of a7 percent discount rate based on the currentcost of capital. The discounted totals in thetable are based on this rate beginning in2003.

Table 3 shows the estimates we usedto determine the portion of EDI claimsincrease attributable to the HIPAA

administrative simplificationprovisions. The proportion of claimsthat would be processed electronicallyeven without HIPAA is assumed to growat the same rate from 2002 through 2011as it did from 1995–1999. Theproportion of ‘‘other’’ health careprovider claims is high because itincludes pharmacies that generate largevolumes of claims and have a high rateof electronic billing.

The increase in EDI claimsattributable to HIPAA is highly

uncertain and is critical to the savingsestimate. These estimates are based onan analysis of the current EDIenvironment. Most of the growth rate inelectronic billing is attributable toMedicare and Medicaid; smaller privateinsurers and third party administrators(who are not large commercial insurers)have lower rates of electronic billingand may benefit significantly fromstandardization.

TABLE 3.—PERCENT GROWTH IN EDI CLAIMS ATTRIBUTABLE TO HIPAA AS PROVISIONS

[Cumulative]

Type of health care provider 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

Physician:Percent before HIPAA .................................................. 53 55 58 61 63 65 67 69 71 73Percent after HIPAA ..................................................... 63 72 80 83 86 88 90 91 93 94Difference ...................................................................... 10 17 21 22 23 23 22 22 22 21

Hospital:Percent before HIPAA .................................................. 87 88 89 89 90 91 91 92 92 93Percent after HIPAA ..................................................... 90 93 95 95 96 97 97 98 98 98Difference ...................................................................... 3 5 6 6 6 6 6 6 6 6

Other:Percent before HIPAA .................................................. 83 84 86 87 88 89 90 91 92 93Percent after HIPAA ..................................................... 87 91 93 95 96 96 97 98 98 99Difference ...................................................................... 4 6 7 7 7 7 7 6 6 6

Table 4 shows the annual costs,savings, and net savings over a ten yearimplementation period which aregained by using the HIPAA standards.Virtually all of the costs attributable toHIPAA will be incurred within the firstthree years of implementation, since thestatute requires health plans other thansmall health plans to implement thestandards within 24 months and smallhealth plans to implement the standardswithin 36 months of the effective dateof the final rule. As each health planimplements a standard, health careproviders that conduct electronictransactions with that health plan willalso implement the standard. No netsavings would accrue in the first yearbecause not enough health plans andhealth care providers will have

implemented the standards. Savingswill increase as more health plans andhealth care providers implement thestandards, thus exceeding costs in thefourth year. At that point, the majorityof health plans and health careproviders will have implemented thestandards and, as a result, costs willdecrease and benefits will increase.

The savings per claim processedelectronically instead of manually isbased on the mid-point of the rangeestimated by WEDI.: $1 per claim forhealth plans, $1.49 for physicians, $0.86for hospitals and $0.83 for others. Theseestimates are based on surveys of healthcare providers and health plans. Totalsavings are computed by multiplyingthe per claim savings by the number ofEDI claims attributed to HIPAA. The

total number of EDI claims is used incomputing the savings to health plans,while the savings for specific healthcare provider groups is computed usingonly the number of EDI claimsgenerated by that group (for example,savings to physicians is computed usingonly physician EDI claims).

WEDI also estimated savings resultingfrom other HIPAA transactions, such aseligibility verifications, coordination ofbenefits, and claims inquiries (amongothers). The average savings pertransaction was slightly higher than thesavings from electronic billing, but thenumber of transactions was muchsmaller than the number of claimstransactions. The estimates fortransactions other than claims werederived by approximating a number of



transactions and estimating theanticipated savings associated with eachtransaction relative to those assumed forthe savings for electronic billing (seetable 5). In general, the approximationsare close to those used by WEDI. Forthese non-billing transactions, theDepartment assumed that thesimplification promoted by HIPAA willfacilitate a significant conversion frommanual to electronic formats. While

today it is estimated that about 44% ofthese non-billing transactions areelectronic, by the end of the ten yearperiod it is estimated that 92% willbecome electronic.

Savings can also be expected fromsimplifications in manual claims. Thebasic assumption is that the savings areten percent of savings per claim that areprojected for conversion from manual toelectronic billing. However, it is also

assumed that the standards will onlygradually allow health care providersand health plans to abandon old manualforms and identifiers by 10% annually;this staged transition is inevitablebecause many of the relationships thathave been established with otherentities will require a period of overlapduring transitioning with entities withwhich they do business.

TABLE 4.—TEN YEAR NET SAVINGS[$ Billions]

Costs and savings 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 Total(Undiscounted)

Total(Discounted)

Costs:.H.C. Provider ........................................... 1.2 1.2 1.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 3.5 3.3Health Plan .............................................. 1.2 1.2 1.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 3.5 3.3

Total ..................................................... 2.4 2.4 2.2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 7.0 6.8

Savings from Claims Processing:H.C. Provider ........................................... 0.4 0.7 1.0 1.1 1.1 1.2 1.2 1.3 1.3 1.3 10.7 7.7Health Plan .............................................. 0.4 0.6 0.8 0.9 1.0 1.0 1.1 1.1 1.1 1.1 9.1 6.5

Total ..................................................... 0.8 1.4 1.8 2.0 2.0 2.2 2.3 2.4 2.4 2.5 19.8 14.2

Savings from Other Transactions:H.C. Provider ........................................... 0.1 0.3 0.5 0.7 0.9 1.0 1.2 1.4 1.5 1.7 9.3 6.2Health Plan .............................................. 0.1 0.2 0.4 0.6 0.7 0.8 0.9 1.1 1.2 1.4 7.3 4.9

Total ..................................................... 0.1 0.5 0.8 1.3 1.6 1.9 2.1 2.4 2.7 3.1 16.6 11.1

Savings from Manual Transactions:H.C. Provider ........................................... 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.3 0.2Health Plan .............................................. 0.0 0.0 0.0 0.0 0.0 0.1 0.0 0.0 0.0 0.0 0.2 0.1

Total ..................................................... 0.0 0.0 0.0 0.0 0.1 0.1 0.1 0.1 0.1 0.1 0.5 0.3

Total Savings:H.C. Provider ........................................... 0.5 1.0 1.5 1.8 2.1 2.3 2.5 2.7 2.9 3.1 20.2 14.1Health Plan .............................................. 0.4 0.8 1.2 1.5 1.7 1.9 2.0 2.2 2.4 2.5 16.6 11.6

Total ..................................................... 0.9 1.9 2.7 3.3 3.8 4.1 4.5 4.9 5.2 5.6 36.9 25.6

Net:H.C. Provider ........................................... ¥0.7 ¥0.3 0.4 1.8 2.1 2.3 2.5 2.7 2.9 3.1 16.7 10.8Health Plan .............................................. ¥0.8 ¥0.4 0.1 1.5 1.7 1.9 2.0 2.2 2.4 2.5 13.1 8.3

Total ..................................................... ¥1.5 ¥0.5 0.5 3.3 3.8 4.1 4.5 4.9 5.2 5.6 29.9 19.07

Note: Figures do not total due to rounding.Note: The estimates in Table 4 show cost savings in 2000 dollars (estimates in the proposed rule were in 1998 dollars). The Office of Management and Budget

now requires all agencies to provide estimates using a net present value calculation. Furthermore, OMB recommends the use of a 7 percent discount rate based onthe current cost of capital. The discounted totals in the table are based on this rate beginning in 2003.

The ratios in Table 5 were derivedfrom the WEDI Report, which estimatedthe volume and savings of the listednon-billing transactions. By comparingthe relationship between billing volumeand savings to non-billing volume andsavings, it is possible to estimate totalsavings due to other transactions. Theseratios were used because the billing datahas been updated by the Faulkner andGray Health Data Directory, but WEDIhas not updated the estimates for non-billing transactions. Therefore, thismodel implicitly assumes that the ratioof billing transactions to non-billingtransactions has remained constantsince 1993.

TABLE 5.—RELATIVE SAVINGS ANDVOLUME OF OTHER TRANSACTIONS

Transaction Savings Volume

Claim ....................... 1.0 1.0Claims inquiry ......... 4.0 0.5Remittance advice .. 1.5 0.10Coordination of ben-

efits ...................... 0.5 0.10Eligibility inquiry ...... 0.5 0.05Enrollment/

disenrollment ....... 0.5 0.01Referral ................... 0.1 0.10

J. Qualitative Impacts of AdministrativeSimplification

Administration simplificationproduces more than hard-dollar savings.

There are also qualitative benefits thatare less tangible, but neverthelessimportant. These changes becomepossible when data can be more easilyintegrated across entities. WEDI suggestsin its 1993 report that theimplementation of an EDI infrastructurewill cause a ‘‘ripple-effect’’ on thewhole health care delivery system; thischain reaction will occur because therewill be a reduction in duplicate medicalprocedures and processes as a patient ishandled by a continuum of health careproviders during an episode of care.WEDI also suggests that there will be areduction in the exposure to health carefraud as security controls on electronic



1 The SBA size standard for computer softwarerelated industries (SIC 7371–7379) is $18.0 millionor less. Between 81% and 99% of the companiesin these categories qualify.

transactions will prevent unauthorizedaccess to financial data.

Standards may also reduceadministrative burden and improve jobsatisfaction. For example, feweradministrative staff will be required totranslate procedural codes, since acommon set of codes will be used. Allcodes used in these transactions will bestandardized, eliminating differentvalues for data elements (for example,place of service).

Administrative simplification willpromote the accuracy, reliability andusefulness of the information shared.For example, today there are anynumber of transaction formats in use.There are over 400 variations ofelectronic formats for claimstransactions alone. As noted earlier,these variations make it difficult forparties to exchange informationelectronically. At a minimum, itrequires data to be translated from thesender’s own format to the differentformats specified by each intendedreceiver. Translation usually requiresadditional equipment and labor.

Administrative simplification greatlyenhances the sharing of data bothwithin entities and across entities. Itfacilitates the coordination of benefitsinformation by having in place astandardized set of data that is knownto all parties, along with standardizedname and address information that tellswhere to route transactions. Today,health care providers are reluctant tofile claims with multiple health planson behalf of the patient becauseinformation about a patient’s eligibilityin a health plan is difficult to verify.Most claims filed by patients today aresubmitted in hard copy. We anticipatethat more health care providers will fileclaims and coordinate benefits on thepatient’s behalf once standardtransactions are adopted and thisinformation is made availableelectronically.

K. Regulatory Flexibility Analysis

The Regulatory Flexibility Act (RFA)of 1980, Public Law 96–354, requiresthe Department to prepare a regulatoryflexibility analysis if the Secretarycertifies that a proposed regulation willhave a significant economic impact ona substantial number of small entities.In the health care sector, a small entityis one with less than $5 million inannual revenues. For the purposes ofthis analysis (pursuant to the RFA),nonprofit organizations are consideredsmall entities; however, individuals andStates are not included in the definitionof a small entity. We have attempted toestimate the number of small entities

and provide a general discussion of theeffects of the statute.

For the purpose of this analysis, all 31nonprofit Blue Cross-Blue Shield HealthPlans are considered small entities. 28%of HMOs are considered small entitiesbecause of their nonprofit status.Doctors of osteopathy, dentistry,podiatry, as well as chiropractors, andsolo and group physicians’ offices withfewer than three physicians, areconsidered small entities. Forty percentof group practices with 3 or morephysicians and 100 percent ofoptometrist practices are consideredsmall entities. Seventy-two percent ofall pharmacies, 88% of medicallaboratories, 100% of dental laboratoriesand 90% of durable medical equipmentsuppliers are assumed to be smallentities as well.

We found the best source forinformation about the health datainformation industry is Faulkner &Gray’s Health Data Directory. Thispublication is the most comprehensivedata dictionary of its kind that we couldfind. The information in this directoryis gathered by Faulkner & Gray editorsand researchers who called all of themore than 3,000 organizations that arelisted in the book in order to elicitinformation about their operations. It isimportant to note that some businessesare listed as more than one type ofbusiness entity; this is because inreporting the information, companiescould list themselves as many as threedifferent types of entities. For example,some businesses listed themselves asboth practice management vendors andclaims software vendors because theirpractice management software was ‘‘EDIenabled.’’

All the statistics referencing Faulkner& Gray’s come from the 2000 edition ofits Health Data Directory. It lists 78claims clearinghouses, which areentities under contract that takeelectronic and paper health care claimsdata from health care providers andbilling companies that prepare bills ona health care provider’s behalf. Theclaims clearinghouse acts as a conduitfor health plans; it batches claims androutes transactions to the appropriatehealth plan in a form that expeditespayment.

Of the 78 claims clearinghouses listedin this publication, eight processedmore that 20 million electronictransactions per month. Another 15handled 2 million or more transactionsper month and another 4 handled overa million electronic transactions permonth. The remaining 39 entities listedin the data dictionary processed lessthan a million electronic transactionsper month. Almost all of these entities

have annual revenues of under $5million and would therefore beconsidered small entities.

Another entity that is involved in theelectronic transmission of health caretransactions is materials management/supply ordering software companies(value added networks). They areinvolved in the electronic transmissionof data over telecommunication lines.Faulkner & Gray list 21 materialsmanagement/supply ordering softwarevendors that handle health caretransactions. We believe that almost allof these companies meet the definitionof a small business. 1

A billing company is another entityinvolved in the electronic routing ofhealth care transactions. It worksprimarily with physicians in office andhospital-based settings. Billingcompanies, in effect, take over the officeadministrative functions for a physician;they take information such as copies ofmedical notes and records and prepareclaim forms that are then forwarded toan insurer for payment. Billingcompanies may also handle the receiptof payments, including posting paymentto the patient’s record on behalf of thehealth care provider. They can belocated within or outside of thephysician’s practice setting.

In the proposed rule we stated thatThe International Billing Association, atrade association representing billingcompanies, estimated that there were4,500 billing companies in business inthe United States. The InternationalBilling Association’s estimates are basedon the number of names and addressesof actual billing companies on itsmailing list. Since we were unable tofind more recent information aboutthese entities, we are assuming that thenumber of billing companies has notchanged significantly and that all of the4,500 billing companies continue tohave revenues under $5 millionannually.

Software system vendors providecomputer software applications supportto health care clearinghouses, billingcompanies, and health care providers.In particular, they work with health careproviders’ practice management andhealth information systems. Thesebusinesses provide integrated softwareapplications for such services asaccounts receivable management,electronic claims submission (patientbilling), record keeping, patientcharting, practice analysis and patientscheduling. Some software vendors are



also involved in providing applicationsfor translating paper and nonstandardcomputer documents into standardizedformats that are acceptable to healthplans.

Faulkner & Gray list 78 physicianpractice management vendors andsuppliers, 76 hospital informationsystems vendors and suppliers, 140software vendors and suppliers forclaims-related transactions, and 20translation vendors (now known asInterface Engines/ Integration Tools).We were unable to determine thenumber of these entities with revenuesover $5 million, but we assume most ofthese businesses would be consideredsmall entities.

As discussed earlier in this analysis,the cost of implementing the standardsspecified in the statute are primarilyone-time or short-term costs related toconversion. They were characterized asfollows: software conversion; cost ofautomation; training; implementationproblems; and cost of documentationand implementation specifications.Rather than repeat that informationhere, we refer you to the beginning ofthis impact analysis.

1. Health care Providers and HealthPlans

As a result of standard data formatand content, health care providers andhealth plans that wish to do businesselectronically will be able to do soknowing that capital outlays they makeare likely to be worthwhile, with somecertainty on the return of theirinvestment. This is because coveredentities that exchange electronic healthcare transactions will be required toreceive and send transactions in thesame standard formats. We believe thiswill be an incentive for smallphysicians’ offices to convert frompaper to EDI. In a 1996 Office of theInspector General study entitled‘‘Encouraging Physicians to UsePaperless Claims,’’ the Office of theInspector General and HCFA agreed thatover $36 million in annual Medicareclaims processing savings could beachieved if all health care providerssubmitting 50 or more Medicare claimsper month submitted themelectronically. Establishment of EDIstandards will make it financiallybeneficial for many small health careproviders to convert to electronic claimsubmissions because all health planswill accept the same formats.

Additionally, health care providersthat currently use health careclearinghouses and billing agencies willsee costs stabilize and will potentiallyenjoy some cost reduction. This willresult from the increased efficiency that

health care clearinghouses and billingcompanies will realize from being ableto more easily link with health careindustry business partners.

2. Third Party VendorsThird party vendors include third

party processors/health careclearinghouses (including value addednetworks), billing companies, andsoftware system vendors. While themarket for third party vendors willchange as a result of standardization,these changes will be positive for theindustry and its customers over the longterm. However, the short term/one timecosts discussed above will apply to thethird party vendor community.

a. Health Care Clearinghouses andBilling Companies. As noted above,health care clearinghouses are entitiesthat take health care transactions,convert them into standardized formats,and forward them to the insurer. Billingcompanies take on the administrativefunctions of a physician’s office. Themarket for health care clearinghouseand billing company services willdefinitely be affected by the HIPAAadministrative simplificationprovisions; however, there appears to besome debate on how the market forthese services will be affected.

It is likely that competition amonghealth care clearinghouses and billingcompanies will increase over time asstandards reduce some of the technicallimitations that currently inhibit healthcare providers from conducting theirown EDI. For example, by eliminatingthe requirement to maintain severaldifferent claims standards for differenttrading partners, health care providerswill be able to more easily linkthemselves directly to health plans. Thiscould negatively affect the market forhealth care clearinghouses and systemvendors that do translation services;however, standards should increase theefficiency in which health careclearinghouses operate by allowingthem to more easily link to multiplehealth plans. The increased efficiency inoperations resulting from standardscould, in effect, lower their overheadcosts as well as attract new health careclearinghouse customers to offset anyloss in market share that they mightexperience.

Another potential area of change isthat brought about through standardizedcode sets. Standard code sets will lowercosts and break down logistical barriersthat discouraged some health careproviders from doing their own codingand billing. As a result, some healthcare providers may choose an in-housetransaction system rather than using abilling company as a means of

exercising more control overinformation. Conversely, health careclearinghouses may acquire some short-term increase in business from thosehealth care providers that are automatedbut do not use the selected standards.These health care providers will hirehealth care clearinghouses to take datafrom the nonstandard formats they areusing and convert them into theappropriate standards. Generally, healthcare clearinghouses can also beexpected to identify opportunities inwhich they could add value totransaction processing and to find newbusiness opportunities, such as intraining health care providers on thenew transaction sets. Standards willincrease the efficiency of health careclearinghouses, which could in turndrive costs for these services down.Health care clearinghouses may be ableto operate more efficiently or at a lowercost based on their ability to gain marketshare. Some small billing companiesmay be consumed by health careclearinghouses that may begin offeringbilling services to augment their healthcare clearinghouse activities. However,most health care providers that usebilling companies will probablycontinue to do so because of thecomprehensive and personalizedservices these companies offer.

Value added networks transmit dataover telecommunication lines. Weanticipate that the demand for valueadded network services will increase asadditional health care providers andhealth plans move to electronic dataexchange. Standards will eliminate theneed for data to be reformatted, whichwill allow health care providers topurchase value added network servicesindividually rather than as a componentof the full range of health careclearinghouse services.

b. Software Vendors. As noted above,software vendors provide computersoftware applications support to healthcare clearinghouses and health careproviders. In particular, they work withhealth care providers’ practicemanagement and health informationsystems. These entities will be affectedpositively, at least in the short term. Theimplementation of administrativesimplification will enhance theirbusiness opportunities as they becomeinvolved in developing computerizedsoftware solutions that allow health careproviders and other entities thatexchange health care data to integratethe new transaction set into theirexisting systems.

L. Unfunded mandatesWe have identified the private sector

costs associated with the



implementation of these standards.Although these costs are unfunded, weexpect that they will be offset bysubsequent savings as detailed in thisimpact analysis.

Most costs to health care providersand health plans will occur in the first3 years following the adoption of theHIPAA standards, with savings to healthcare providers and health plansexceeding costs in the fourth year. Thetotal net savings for the period 2001–2011 will be $29.8 billion (a net savingsof $13.1 billion for health plans, and anet savings of $16.7 billion for healthcare providers). The single year netsavings for the year 2011 will be $5.6billion ($2.5 billion for health plans and$3.1 billion for health care providers).The discounted present value of thesesavings is $19.1 billion over ten years.These estimates do not include thesecondary benefits that will be realizedthrough expanded e-commerce resultingfrom standardized systems.

The costs to State and localgovernments and tribal organizationsare also unfunded, but we do not havesufficient information for programsother than Medicaid to provideestimates of the impact of thesestandards on those entities. Asdiscussed previously, several StateMedicaid agencies have estimated that itmay cost as much as $10 million perstate to implement all the HIPAAstandards. However, the CongressionalBudget Office analysis stated that‘‘States are already in the forefront inadministering the Medicaid programelectronically; the only costs—whichshould not be significant—wouldinvolve bringing the software andcomputer systems for the Medicaidprograms into compliance with the newstandards.’’ The report went on to pointout that Medicaid State agencies havethe option to compensate for costs byreducing other expenditures. State andlocal government agencies are likely toincur less in the way of costs since mostof them will have fewer enrollees thanMedicaid agencies. Moreover, theFederal government pays a portion ofthe cost of converting State MedicaidManagement Information Systems(MMIS) as Federal FinancialParticipation—75 percent for systemmaintenance changes and 90 percent fornew software (if approved). Many Statesare in the process of changing systemsas they convert many of the currentfunctions in the move to enrollMedicaid beneficiaries in managed care.The net effect is that some States mayhave to pay $1 million to comply;however, numerous States may havealready incurred some of these costs,

though the Department does not have acomplete record of State changes.

M. Code Sets—Specific Impact ofAdoption of Code Sets for Medical Data

Affected Entities

Standard codes and classifications arerequired in some segments ofadministrative and financialtransactions. Covered entities that createand process administrative transactionsmust implement the standard codesaccording to the implementationspecifications adopted for each codingsystem and each transaction. Those thatreceive standard electronicadministrative transactions must be ableto receive and process all standardcodes irrespective of local policiesregarding reimbursement for certainconditions or procedures, coveragepolicies, or need for certain types ofinformation that are part of a standardtransaction.

The adoption of standard code setsand coding guidelines for medical datasupports the regulatory goals of cost-effectiveness and the avoidance ofduplication and burden. The code setsthat are being proposed as initial HIPAAstandards are already in use by mosthealth plans, health care clearinghouses,and health care providers.

Health care providers currently usethe recommended code set for reportingdiagnoses and one or more of therecommended procedure codingsystems for reporting procedures/services. Since health plans can differwith respect to the codes they accept,many health care providers use differentcoding guidelines for dealing withdifferent health plans, sometimes for thesame patient. (Anecdotal informationleads us to believe that use of othercodes is widespread, but we cannotquantify the number.) Some of thesedifferences reflect variations in coveredservices that will continue to existirrespective of data standardization.Others reflect differences in a healthplan’s ability to accept as valid a claimthat may include more information thanis needed or used by that health plan.The requirement to use standard codingguidelines will eliminate this lattercategory of differences and shouldsimplify claims submission for healthcare providers that deal with multiplehealth plans.

Currently, there are health plans thatdo not adhere to official codingguidelines and have developed theirown plan-specific guidelines for usewith the standard code sets, which donot permit the use of all valid codes.Again, we cannot quantify how manyhealth plans do this, but we are aware

of some instances when this occurs.When the HIPAA code set standardsbecome effective, these health plans willhave to receive and process all standardcodes, without regard to local policiesregarding reimbursement for certainconditions or procedures, coveragepolicies, or need for certain types ofinformation that are part of a standardtransaction.

We believe that there is significantvariation in the reporting of anesthesiaservices, with some health plans usingthe anesthesia section of CPT and othersrequiring the anesthesiologist or nurseanesthetist to report the code for thesurgical procedure itself. When theHIPAA code sets become effective,health plans following the latterconvention will have to begin acceptingcodes from the anesthesia section.

We note that by adopting standardsfor code sets we are requiring that allparties accept these codes within theirelectronic transactions. We are notrequiring payment for all of theseservices. Those health plans that do notadhere to official coding guidelinesmust therefore undertake a one-timeeffort to modify their systems to acceptall valid codes in the standard code setsor engage a health care clearinghouse topreprocess the standard claims data forthem. Health plans should be able tomake modifications to meet thedeadlines specified in the legislation,but some temporary disruption ofclaims processing could result.

There may be some temporarydisruption of claims processing ashealth plans and health careclearinghouses modify their systems toaccept all valid codes in the standardcode sets.

N. Transaction Standards

1. Specific Impact of Adoption of theNational Council of Prescription DrugPrograms (NCPDP) TelecommunicationClaim

a. Affected Entities. Health careproviders that submit retail pharmacyclaims, and health care plans thatprocess retail pharmacy claims,currently use the NCPDP format. TheNCPDP claim and equivalent encounteris used either in on-line interactive orbatch mode. Since all pharmacy healthcare providers and health plans use theNCPDP claim format, there are nospecific impacts to health careproviders.

b. Effects of Various Options. TheNCPDP format met all of the 10 guidingprinciples used to designate a standardas a HIPAA standard, and there are noother known options for a standardretail pharmacy claim transaction.



2. Specific Impact of Adoption of theASC X12N 837 for Submission ofInstitutional Health Care Claims,Professional Health Care Claims, DentalClaims, and Coordination of Benefits

a. Affected Entities. All health careproviders and health plans that conductEDI directly and use other electronicformat(s), and all health care providersthat decide to change from a paperformat to an electronic one, would haveto begin to use the ASC X12N 837 forsubmitting electronic health care claims(hospital, physician/supplier anddental). (Currently, about 3 percent ofMedicare health care providers use thisstandard for claims; it is used less fornon-Medicare claims.)

Some of the possible effects ofadopting the ASC X12N 837 include thepossibility of an initial disruption inclaim processing and payment during ahealth plan’s transition to the standardformat and the possibility that healthcare providers could react adversely toimplementation costs and thus revert tohard copy claims.

Despite the initial problems healthcare providers may encounter withadministrative simplification, healthcare providers will, in the long run,enjoy the advantages associated withnot having to keep track of and usedifferent electronic formats for differentinsurers. This will simplify health careprovider billing systems and processesas well as reduce administrativeexpenses.

Health plans will, as long as theymeet the deadlines specified in thestatute, be able to schedule theirimplementation of the ASC X12N 837 ina manner that best fits their needs, thusallaying some costs throughcoordination of conversion to otherstandards. Although the costs ofimplementing the ASC X12N 837 aregenerally one-time costs related toconversion, the cost of systems upgradesfor some smaller health care providers,health plans, and health careclearinghouses may be prohibitive.Health care providers and health planshave the option of using a health careclearinghouse to satisfy the HIPAAstandard requirements.

Coordination of benefits. Once theASC X12N 837 has been implemented,health plans that perform coordinationof benefits will be able to eliminate thesupport of multiple proprietaryelectronic claim formats, thussimplifying claims receipt andprocessing as well as reducingadministrative costs. Coordination ofbenefits activities will also be greatlysimplified because all health plans willuse the same standard format. There is

no doubt that standardization incoordination of benefits will greatlyenhance and improve efficiency in theoverall claims process and thecoordination of benefits.

From a non-systems perspective(meaning policy and program issues),there should not be an adverse effect onthe coordination of benefits process.The COB transaction will continue toconsist of the incoming electronic claimand the data elements provided on aremittance advice. Standardization ofthe information needed for coordinationof benefits will clearly increaseefficiency in the electronic processesutilized by the health care providers,health care clearinghouses, and healthplans.

b. Effects of Various Options. Weassessed the various options for astandard claim transaction against theprinciples, listed at the beginning of thisimpact analysis above, with the overallgoal of achieving the maximum benefitfor the least cost. We found that the ASCX12N 837 for institutional claims,professional claims, dental claims, andcoordination of benefits met all of the 10guiding principles that were used todesignate a standard as a HIPAAstandard, but no other candidatestandard transaction met all theprinciples.

Since the majority of dental claims aresubmitted on paper and those submittedelectronically are being transmittedusing a variety of proprietary formats,the only viable choice for the standardis the ASC X12N 837. The AmericanDental Association (ADA) alsorecommended the ASC X12N 837 forthe dental claim standard.

The ASC X12N 837 was selected asthe standard for the professional(physician/supplier) claim because itmet the principles above. The only othercandidate standard, the NationalStandard Format, was developedprimarily by HCFA for Medicare claims.While it is widely used, it is not alwaysused in a standard manner. Thus, wedeclined to adopt the National StandardFormat. Many variations of the NationalStandard Format are in use. Moreover,the NUCC, the AMA, and WEDIrecommended the ASC X12N 837 forthe professional claim standard.

The ASC X12N 837 was selected asthe standard for the institutional(hospital, nursing facilities and similarinpatient institutions) claim because itmet the principles above. The only othercandidate standard was the UB–92Format developed by HCFA forMedicare claims. While the UB–92 iswidely used, it is not always used in astandard manner. Consequently, we didnot elect to adopt the UB–92.

The selection of the ASC X12N 837does not impose a greater burden on theindustry than the nonselected optionsbecause the nonselected formats are notused in a standard manner by theindustry and they do not incorporate theflexibility necessary to adapt easily tochange. The ASC X12N 837 presentssignificant advantages in terms ofuniversality and flexibility.

3. Specific Impact of Adoption of theASC X12N 835 for Receipt of HealthCare Remittance

a. Affected Entities. Health careproviders that conduct EDI with healthplans and that do not wish to changetheir internal systems will have toconvert the ASC X12N 835 transactionsreceived from health plans into a formatcompatible with their internal systemseither by using a translator or a healthcare clearinghouse. Health plans thatwant to transmit remittance advicedirectly to health care providers andthat do not use the ASC X12N 835 willalso incur costs to convert to thestandard. Many health care providersand health plans do not use thisstandard at this time. We do not haveinformation to quantify the standard’suse outside the Medicare program.However, according to Medicarestatistics, in 1996, 15.9 percent of partB health care providers and 99.4 percentof part A health care providers wereable to receive this standard. AllMedicare contractors must be able tosend the standard.

Some of the possible effects ofadopting the ASC X12N 835 include thepotential for an initial delay in paymentor the issuance of electronic remittanceduring a plan’s transition to thestandard format and the possibility thathealth care providers could reactadversely to implementation costs andthus, revert to hard copy remittancenotices in lieu of an electronictransmission.

Despite the initial problems healthcare providers may encounter withadministrative simplification, healthcare providers will, in the long run,enjoy the advantage associated with nothaving to keep track of or acceptdifferent electronic payment/remittanceadvice formats issued by differenthealth plans. This will simplifyautomatic posting of all electronicpayment/remittance advice data, thusreducing administrative expenses. Thiswill also reduce or eliminate thepractice of posting payment/remittanceadvice data manually from hard copynotices, again reducing administrativeexpenses. Most manual posting occurscurrently in response to the problem of



multiple formats; using standardtransactions will eliminate this burden.

Additionally, once the ASC X12N 835has been implemented, health plans’coordination of benefits activities,which will use the ASC X12N 837format supplemented with limited datafrom the ASC X12N 835, will be greatlysimplified because all health plans willuse the same standard format.

As long as they meet the deadlinesspecified in the statute, health planswill be able to schedule theirimplementation of the ASC X12N 835 ina manner that best fits their needs, thusallaying some costs throughcoordination of conversion to otherstandards.

The selection of the ASC X12N 835does not impose a greater burden on theindustry than the nonselected optionsbecause the nonselected formats are notused in a standard manner by theindustry and they do not incorporate theflexibility necessary to adapt easily tochange. The ASC X12N 835 presentssignificant advantages in terms ofuniversality and flexibility.

b. Effects of Various Options. Weassessed the various options for astandard payment/remittance advicetransaction against the principles listedabove which aim at achieving themaximum benefit for the least cost. Wefound that the ASC X12N 835 met allthe principles, but no other candidatestandard transaction met all theprinciples, or even those principlessupporting the regulatory goal of cost-effectiveness.

The ASC X12N 835 was selected as itmet the principles above. The only othercandidate standard, the ASC X12N 820,was not selected because, although itwas developed for paymenttransactions, it was not developed forhealth care claims payment purposes.The ASC X12N subcommittee itselfrecognized this in its decision todevelop the ASC X12N 835.

4. Specific Impact of Adoption of theASC X12N 276/277 for Health CareClaim Status/Response

a. Affected Entities. Most health careproviders that are currently using anelectronic format for claim statusinquiries (of which there are currentlyvery few) and that wish to request claimstatus electronically using the ASCX12N 276/277 will incur conversioncosts. We cannot quantify the number ofhealth care providers that will have toconvert to the standard, but we do knowthat no Medicare contractors use thestandard; thus, we assume that fewhealth care providers are able to use itat this time.

After implementation, health careproviders will be able to request andreceive the status of claims in onestandard format from all health careplans. This will eliminate their need tomaintain redundant software and willmake electronic claim status requestsand receipt of responses feasible forsmall health care providers, eliminatingtheir need to manually send and reviewclaim status requests and responses.

Health plans that do not currentlydirectly accept electronic claim statusrequests and do not directly sendelectronic claims status responses willhave to modify their systems to acceptthe ASC X12N 276 and to send the ASCX12N 277. No disruptions in claimsprocessing or payment should occur.

After implementation, health planswill be able to submit claim statusresponses in one standard format to allhealth care providers. Administrativecosts incurred by supporting multipleformats and manually responding toclaim status requests will be greatlyreduced.

b. Effects of Various Options. Thereare no known options for a standardclaims status and response transaction.

5. Specific Impact of Adoption of theASC X12N 834 for Enrollment andDisenrollment in a Health Plan

a. Affected entities. The ASC X12N834 may be used by an employer orother sponsor to electronically enroll ordisenroll its subscribers into or out of ahealth plan. Currently, most small andmedium size employers and othersponsors conduct their subscriberenrollments using paper forms. Wecannot quantify how many of thesesponsors use paper forms, but anecdotalinformation indicates that most usepaper. We understand that largeemployers and other sponsors are morelikely to electronically conductsubscriber enrollment transactionsbecause this method makes it easier torespond to the many changes that occurin a large workforce; for example,hirings, firings, retirements, marriages,births, and deaths. Large employerscurrently use proprietary electronic datainterchange formats, which differ amonghealth plans, in order to conductsubscriber enrollment. Nonetheless, it isour understanding, based on anecdotalinformation, that health plans still usepaper to conduct most of theirenrollment transactions.

We expect that the impact of the ASCX12N 834 transaction standard willdiffer, at least in the beginning,according to the current use ofelectronic transactions. As stated earlier,at the present time, most small andmedium size employers and other

sponsors do not use electronictransactions and will thereforeexperience little immediate impact fromthe adoption of the ASC X12N 834transaction. The ASC X12N 834 willoffer large employers, currentlyconducting enrollment transactionselectronically, the opportunity to shiftto a single standard format. A singlestandard will be most attractive to thoselarge employers that offer theirsubscribers choices among multiplehealth plans. Thus, the early benefits ofthe ASC X12N 834 will accrue to largeemployers and other sponsors that willbe able to eliminate duplicativehardware and software, and humanresources required to support multipleproprietary electronic data interchangeformats. In the long run, we expect thatthe standards will lower the costs ofconducting enrollment transactions,thus making it possible for small andmedium size companies to achievesignificant additional savings byconverting from paper to electronictransactions.

Overall, employers and othersponsors, and the health plans withwhich they deal, stand to benefit fromthe adoption of the ASC X12N 834 andelectronic data interchange. The ASCX12N 834 and electronic datainterchange will facilitate theperformance of enrollment anddisenrollment functions. Further, theASC X12N 834 supports detailedenrollment information on thesubscriber’s dependents, which is oftenlacking in current practice. Ultimately,reductions in administrative overheadmay be passed along in lower premiumsto subscribers and their dependents.

b. Effects of Various Options. Theonly other option, the NCPDP MemberEnrollment Standard, does not meet theselection criteria and would not beimplemented in the larger healthindustry setting.

6. Specific Impact of Adoption of theASC X12N 270/271 for Eligibility for aHealth Plan

a. Affected Entities. The ASC X12N270/271 transaction may be used by ahealth care provider to electronicallyrequest and receive eligibilityinformation from a health care planprior to providing or billing for a healthcare service. Many health care providersroutinely verify health insurancecoverage and benefit limitations bothprior to providing treatment and/orbefore preparing claims for submissionto the insured patient and his or herhealth plan. Currently, health careproviders secure most of these eligibilitydeterminations through telephone calls,proprietary point of sale terminals, or



using proprietary electronic formats thatdiffer from health plan to health plan.Since many health care providersparticipate in multiple health plans,these health care providers mustmaintain duplicative software andhardware, as well as human resources toobtain eligibility information. Thisprocess is inefficient, often burdensome,and takes valuable time that couldotherwise be devoted to patient care.

The lack of a health care industrystandard may have imposed a costbarrier to the widespread use ofelectronic data interchange. The ASCX12N 270/271 is used widely, but notexclusively, by health care plans andhealth care providers; this may be due,in part, to the lack of an industry-wideimplementation specification for thesetransactions in health care. We expectthat adoption of the ASC X12N 270/271and its implementation specificationwill lower the cost of using electroniceligibility verifications. Use of the ASCX12N 270/271 and its implementationspecification will benefit health careproviders because they will be able tomove to a single standard format.Consequently, electronic datainterchange will be feasible for the firsttime for small health plans and healthcare providers that rely currently on thetelephone, paper forms, or proprietarypoint of sale terminals and software.

b. Effect of Various Options. Therewere two other options, the ASC X12NIHCEBI, and its companion, IHCEBR,and the NCPDP TelecommunicationsStandard Format. None of these meetthe selection criteria and thus theywould not be implementable.

7. Specific Impact of Adoption of theASC X12N 820 for Payroll Deducted andOther Group Premium Payment forInsurance Product

a. Affected Entities. An employer orsponsor can respond to a bill from ahealth plan by using the ASC X12N 820to electronically transmit a remittancenotice to accompany a payment forhealth insurance premiums. Paymentmay be in the form of a paper check oran electronic funds transfer transaction.The ASC X12N 820 can be sent withelectronic funds transfer instructionsthat are routed directly to the FederalReserve System’s automated health careclearinghouses or with paymentsgenerated directly by the employer’s orother sponsor’s bank. The ASC X12N820 transaction is widely used by manyindustries (manufacturing, for instance)and government agencies (Departmentof Defense) in addition to the insuranceindustry in general. However, the ASCX12N 820 is not widely used in thehealth insurance industry and is not

widely used by employers and othersponsors to make premium payments totheir health insurers. This may be due,in part, to the lack of an implementationspecification specifically for healthinsurance.

Currently, most payment transactionsare conducted on paper, and those thatare conducted electronically useproprietary electronic data interchangestandards that differ across health plans.We cannot quantify how many of thesetransactions are conducted on paper,but anecdotal information suggests thatmost are. We believe that the lack of ahealth care industry standard may haveimposed a cost barrier to the use ofelectronic data interchange; largeremployers and other sponsors that oftentransact business with multiple healthplans need to retain duplicativehardware and software, and humanresources to support multipleproprietary electronic premiumpayment standards. We expect that theadoption of national standards willlower the cost of using electronicpremium payments. This will benefitlarge employers that can move to asingle standard format; nationalstandards will make electronictransmissions of premium paymentsfeasible for the first time for smalleremployers and other sponsors whosepayment transactions have beenperformed almost exclusively in paper.

At some point, an organization’s sizeand complexity will require it toconsider switching its businesstransactions from paper to electronicformats, due to the savings andefficiencies conversion would produce.The ASC X12N 820 would facilitatepremium payment by eliminatingredundant proprietary formats that arecertain to arise when there are nowidely accepted common standards. Byeliminating the software, hardware, andhuman resources associated withredundancy, a business may reach thepoint where it becomes cost beneficialto convert from paper to electronictransactions. Also, those sponsors andhealth care plans that already supportmore than one proprietary format willincur some additional expense in theconversion to the standard, but theywould enjoy longer term savings thatresult from eliminating theredundancies.

b. Effects of Various Options. Thereare no known options for premiumpayment transactions.

8. Specific Impact of Adoption of ASCX12N 278 for Referral Certification andAuthorization

a. Affected Entities. The ASC X12N278 may be used by a health care

provider to electronically request andreceive approval from a health planprior to providing a health care service.Prior approvals have become standardoperating procedure for most hospitals,physicians and other health careproviders due to the rapid growth ofmanaged care. Health care providerssecure most of their prior approvalsthrough telephone calls, paper forms orproprietary electronic formats that differfrom health plan to health plan. Sincemany health care providers participatein multiple managed care health plans,they must devote redundant software,hardware, and human resources toobtaining prior authorization; thisprocess is often untimely andinefficient.

The lack of a health care industrystandard may have imposed a costbarrier to the widespread use ofelectronic data interchange. The ASCX12N 278 is not widely used by healthplans and health care providers, whichmay be due, in part, to the lack of anindustry-wide implementationspecification for it. The adoption of theASC X12N 278 and its implementationspecification will lower the cost of usingelectronic prior authorizations. Thiswill benefit health care providers thatcan move to a single standard format;the standard transaction will also makeelectronic data interchange feasible forthe first time for smaller health plansand health care providers that performthese transactions almost exclusivelyusing the telephone or paper.

At some point, an organization’s sizeand complexity will require it toconsider switching its businesstransactions from paper to electronicform, due to the savings and efficienciesconversion would produce. The ASCX12N 278 will facilitate that byeliminating duplicative proprietaryformats that are certain to arise whenthere are no widely accepted standards.By eliminating the software, hardware,and human resources associated withredundancy, a business may reach thepoint where it becomes cost beneficialto convert from paper to electronictransactions. Health plans and healthcare providers that already supportmore than one proprietary format willincur some additional expense inconverting to the standard, but willenjoy longer term savings that resultfrom eliminating the redundancies.

b. Effects of Various Options. Thereare no known options for referral andcertification authorization transactions.

VII. FederalismExecutive Order 13132 of August 4,

1999, Federalism, published in theFederal Register on August 10, 1999 (64



FR 43255) requires us to ensuremeaningful and timely input by Stateand local officials in the development ofrules that have Federalism implications.Although the proposed rule (63 FR25272) was published before theenactment of this Executive Order, theDepartment consulted with State andlocal officials as part of an outreachprogram early in the process ofdeveloping the proposed regulation. TheDepartment received comments on theproposed rule from State agencies andfrom entities who conduct transactionswith State agencies. Many of thecomments referred to the costs incurredby State and local governments whichwill result from implementation of theHIPAA standards. We assume thatgovernment entities will have thesecosts offset by future savings, consistentwith our projections for the privatesector. A Congressional Budget Officeanalysis made the following points:States are already in the forefront ofadministering the Medicaid programelectronically, Medicaid State agenciescan compensate (for these costs) byreducing other expenditures, and theFederal government pays a portion ofthe cost of converting State MedicaidManagement Information Systems.

Other comments regarding Statesexpressed the need for clarification as towhen State agencies were subject to thestandards. Responses to comments fromStates and State organizations regardingthe standard transactions set forth inthis rule are found in this preamble.

In complying with the requirementsof part C of title XI, the Secretaryestablished interdepartmentalimplementation teams who consultedwith appropriate State and Federalagencies and private organizations.These external groups consisted of theNCVHS Subcommittee on Standardsand Security, the Workgroup forElectronic Data Interchange (WEDI), theNational Uniform Claim Committee(NUCC), the National Uniform BillingCommittee (NUBC) and the AmericanDental Association (ADA). The teamsalso received comments on theproposed regulation from a variety oforganizations, including State Medicaidagencies and other Federal agencies.

VIII. Interaction with PrivacyThe Secretary has developed this rule

in conjunction with the development ofstandards to protect the privacy ofindividually identifiable healthinformation, including information thatwill be transmitted pursuant to thesetransaction standards. Compliance withthe privacy standards will be required atapproximately the same time as thecompliance dates of this rule. If the

privacy standards are substantiallydelayed, or if Congress fails to adoptcomprehensive and effective privacystandards that supercede the standardswe are developing, we would seriouslyconsider suspending the application ofthe transaction standards or takingaction to withdraw this rule.

List of Subjects

45 CFR Part 160

Electronic transactions, Health,Health care, Health facilities, Healthinsurance, Health records, Medicaid,Medical research, Medicare, Reportingand recordkeeping requirements.

45 CFR Part 162

Administrative practice andprocedure, Electronic transactions,Health facilities, Health insurance,Hospitals, Incorporation by reference,Medicare, Medicaid, Reporting andrecordkeeping requirements.

For the reasons set forth in thepreamble, 45 CFR subtitle A, subchapterC, is added to read as follows:

SUBCHAPTER C—ADMINISTRATIVE DATASTANDARDS AND RELATEDREQUIREMENTS

PART 160—GENERALADMINISTRATIVE REQUIREMENTS

Subpart A—General Provisions

Sec.160.101 Statutory basis and purpose.160.102 Applicability.160.103 Definitions.160.104 Modifications.

Subpart B—[Reserved]

Authority: Secs. 1171 through 1179 of theSocial Security Act (42 U.S.C. 1320d–1320d–8), as added by sec. 262 of Pub. L. 104–191,110 Stat. 2021–2031, and sec. 264 of Pub. L.104–191, 110 Stat. 2033–2034 (42 U.S.C.1320d–2 (note)).


§ 160.101 Statutory basis and purpose.

The requirements of this subchapterimplement sections 1171 through 1179of the Social Security Act (the Act), asadded by section 262 of Public Law104–191, and section 264 of Public Law104–191.

§ 160.102 Applicability.

Except as otherwise provided, thestandards, requirements, andimplementation specifications adoptedunder this subchapter apply to thefollowing entities:

(a) A health plan.(b) A health care clearinghouse.(c) A health care provider who

transmits any health information in

electronic form in connection with atransaction covered by this subchapter.

§ 160.103 Definitions.Except as otherwise provided, the

following definitions apply to thissubchapter:

Act means the Social Security Act.ANSI stands for the American

National Standards Institute.Business associate means a person

who performs a function or activityregulated by this subchapter on behalfof a covered entity, as defined in thissection. A business associate may be acovered entity. Business associateexcludes a person who is part of thecovered entity’s workforce as defined inthis section.

Compliance date means the date bywhich a covered entity must complywith a standard, implementationspecification, or modification adoptedunder this subchapter.

Covered entity means one of thefollowing:

(1) A health plan.(2) A health care clearinghouse.(3) A health care provider who

transmits any health information inelectronic form in connection with atransaction covered by this subchapter.

Group health plan (also see definitionof health plan in this section) means anemployee welfare benefit plan (asdefined in section 3(1) of the EmployeeRetirement Income Security Act of 1974(ERISA)(29 U.S.C. 1002(1)), includinginsured and self-insured plans, to theextent that the plan provides medicalcare, as defined in section 2791(a)(2) ofthe Public Health Service (PHS) Act, 42U.S.C. 300gg–91(a)(2), including itemsand services paid for as medical care, toemployees or their dependents directlyor through insurance, reimbursement, orotherwise, that—

(1) Has 50 or more participants (asdefined in section 3(7) of ERISA, 29U.S.C. 1002(7)); or

(2) Is administered by an entity otherthan the employer that established andmaintains the plan.

HCFA stands for Health CareFinancing Administration within theDepartment of Health and HumanServices.

HHS stands for the Department ofHealth and Human Services.

Health care means care, services, orsupplies furnished to an individual andrelated to the health of the individual.Health care includes the following:

(1) Preventive, diagnostic,therapeutic, rehabilitative, maintenance,or palliative care; counseling; service; orprocedure with respect to the physicalor mental condition, or functionalstatus, of an individual or affecting thestructure or function of the body.



(2) Sale or dispensing of a drug,device, equipment, or other item inaccordance with a prescription.

(3) Procurement or banking of blood,sperm, organs, or any other tissue foradministration to individuals.

Health care clearinghouse means apublic or private entity that does eitherof the following (Entities, including butnot limited to, billing services, repricingcompanies, community healthmanagement information systems orcommunity health information systems,and ‘‘value-added’’ networks andswitches are health care clearinghousesfor purposes of this subchapter if theyperform these functions.):

(1) Processes or facilitates theprocessing of information received fromanother entity in a nonstandard formator containing nonstandard data contentinto standard data elements or astandard transaction.

(2) Receives a standard transactionfrom another entity and processes orfacilitates the processing of informationinto nonstandard format or nonstandarddata content for a receiving entity.

Health care provider means aprovider of services as defined insection 1861(u) of the Act, 42 U.S.C.1395x(u), a provider of medical or otherhealth services as defined in section1861(s) of the Act, 42 U.S.C. 1395x(s),and any other person or organizationwho furnishes, bills, or is paid forhealth care in the normal course ofbusiness.

Health information means anyinformation, whether oral or recorded inany form or medium, that —

(1) Is created or received by a healthcare provider, health plan, public healthauthority, employer, life insurer, schoolor university, or health careclearinghouse; and

(2) Relates to the past, present, orfuture physical or mental health orcondition of an individual; theprovision of health care to anindividual; or the past, present, orfuture payment for the provision ofhealth care to an individual.

Health insurance issuer (as defined insection 2791(b) of the PHS Act, 42U.S.C. 300gg-91(b)(2), and used in thedefinition of health plan in this section)means an insurance company, insuranceservice, or insurance organization(including an HMO) that is licensed toengage in the business of insurance ina State and is subject to State law thatregulates insurance. Such term does notinclude a group health plan.

Health maintenance organization(HMO) (as defined in section 2791 of thePHS Act, 42 U.S.C. 300gg–91(b)(3), andused in the definition of health plan inthis section) means a Federally qualified

HMO, an organization recognized as anHMO under State law, or a similarorganization regulated for solvencyunder State law in the same manner andto the same extent as such an HMO.

Health plan means an individual orgroup plan that provides, or pays thecost of, medical care (as defined insection 2791(a)(2) of the PHS Act, 42U.S.C. 300gg–91(a)(2)). Health planincludes, when applied to governmentfunded programs, the components of thegovernment agency administering theprogram. Health plan includes thefollowing, singly or in combination:

(1) A group health plan, as defined inthis section.

(2) A health insurance issuer, asdefined in this section.

(3) An HMO, as defined in thissection.

(4) Part A or Part B of the Medicareprogram under title XVIII of the Act.

(5) The Medicaid program under titleXIX of the Act, 42 U.S.C. 1396 et seq.

(6) An issuer of a Medicaresupplemental policy (as defined insection 1882(g)(1) of the Act, 42 U.S.C.1395ss(g)(1)).

(7) An issuer of a long-term carepolicy, excluding a nursing home fixed-indemnity policy.

(8) An employee welfare benefit planor any other arrangement that isestablished or maintained for thepurpose of offering or providing healthbenefits to the employees of two or moreemployers.

(9) The health care program for activemilitary personnel under title 10 of theUnited States Code.

(10) The veterans health care programunder 38 U.S.C. chapter 17.

(11) The Civilian Health and MedicalProgram of the Uniformed Services(CHAMPUS), as defined in 10 U.S.C.1072(4).

(12) The Indian Health Serviceprogram under the Indian Health CareImprovement Act (25 U.S.C. 1601 etseq.).

(13) The Federal Employees HealthBenefit Program under 5 U.S.C. 8902 etseq.

(14) An approved State child healthplan under title XXI of the Act,providing benefits that meet therequirements of section 2103 of the Act,42 U.S.C. 1397 et seq.

(15) The Medicare + Choice programunder part C of title XVIII of the Act, 42U.S.C. 1395w–21 through 1395w–28.

(16) Any other individual or groupplan, or combination of individual orgroup plans, that provides or pays forthe cost of medical care (as defined insection 2791(a)(2) of the PHS Act, 42U.S.C. 300gg–91(a)(2)).

Implementation specification meansthe specific instructions forimplementing a standard.

Modify or modification refers to achange adopted by the Secretary,through regulation, to a standard or animplementation specification.

Secretary means the Secretary ofHealth and Human Services or any otherofficer or employee of the Department ofHealth and Human Services to whomthe authority involved has beendelegated.

Small health plan means a healthplan with annual receipts of $5 millionor less.

Standard means a prescribed set ofrules, conditions, or requirementsdescribing the following information forproducts, systems, services or practices:

(1) Classification of components.(2) Specification of materials,

performance, or operations.(3) Delineation of procedures.Standard setting organization (SSO)

means an organization accredited by theAmerican National Standards Institutethat develops and maintains standardsfor information transactions or dataelements, or any other standard that isnecessary for, or will facilitate theimplementation of, this part.

State refers to one of the following:(1) For health plans established or

regulated by Federal law, State has themeaning set forth in the applicablesection of the United States Code foreach health plan.

(2) For all other purposes, State meansthe United States, the District ofColumbia, the Commonwealth of PuertoRico, the Virgin Islands, and Guam.

Trading partner agreement means anagreement related to the exchange ofinformation in electronic transactions,whether the agreement is distinct or partof a larger agreement, between eachparty to the agreement. (For example, atrading partner agreement may specify,among other things, the duties andresponsibilities of each party to theagreement in conducting a standardtransaction.)

Transaction means the exchange ofinformation between two parties tocarry out financial or administrativeactivities related to health care. Itincludes the following types ofinformation exchanges:

(1) Health care claims or equivalentencounter information.

(2) Health care payment andremittance advice.

(3) Coordination of benefits.(4) Health care claim status.(5) Enrollment and disenrollment in a

health plan.(6) Eligibility for a health plan.(7) Health plan premium payments.



(8) Referral certification andauthorization.

(9) First report of injury.(10) Health claims attachments.(11) Other transactions that the

Secretary may prescribe by regulation.Workforce means employees,

volunteers, trainees, and other personsunder the direct control of a coveredentity, whether or not they are paid bythe covered entity.

§ 160.104 Modifications.(a) Except as provided in paragraph

(b) of this section, the Secretary mayadopt a modification to a standard orimplementation specification adoptedunder this subchapter no morefrequently than once every 12 months.

(b) The Secretary may adopt amodification at any time during the firstyear after the standard orimplementation specification is initiallyadopted, if the Secretary determines thatthe modification is necessary to permitcompliance with the standard.

(c) The Secretary establishes thecompliance date for any standard orimplementation specification modifiedunder this section.

(1) The compliance date for amodification is no earlier than 180 daysafter the effective date of the final rulein which the Secretary adopts themodification.

(2) The Secretary may consider theextent of the modification and the timeneeded to comply with the modificationin determining the compliance date forthe modification.

(3) The Secretary may extend thecompliance date for small health plans,as the Secretary determines isappropriate.

Subpart B—[Reserved]

PART 162—ADMINISTRATIVEREQUIREMENTS

Subpart A—General ProvisionsSec.162.100 Applicability.162.103 Definitions.

Subparts B–H—[Reserved]

Subpart I—General Provisions forTransactions162.900 Compliance dates of the initial

implementation of the code sets andtransaction standards.

162.910 Maintenance of standards andadoption of modifications and newstandards.

162.915 Trading partner agreements.162.920 Availability of implementation

specifications.162.923 Requirements for covered entities.162.925 Additional requirements for health

plans.162.930 Additional rules for health care

clearinghouses.

162.940 Exceptions from standards topermit testing of proposed modifications.

Subpart J—Code Sets162.1000 General requirements.162.1002 Medical data code sets.162.1011 Valid code sets.

Subpart K—Health Care Claims orEquivalent Encounter Information162.1101 Health care claims or equivalent

encounter information transaction.162.1102 Standards for health care claims

or equivalent encounter information.

Subpart L—Eligibility for a Health Plan162.1201 Eligibility for a health plan

transaction.162.1202 Standards for eligibility for a

health plan.

Subpart M—Referral Certification andAuthorization162.1301 Referral certification and

authorization transaction.162.1302 Standard for referral certification

and authorization.

Subpart N—Health Care Claim Status162.1401 Health care claim status

transaction.162.1402 Standard for health care claim

status.

Subpart O—Enrollment and Disenrollmentin a Health Plan162.1501 Enrollment and disenrollment in

a health plan transaction.162.1502 Standard for enrollment and

disenrollment in a health plan.

Subpart P—Health Care Payment andRemittance Advice162.1601 Health care payment and

remittance advice transaction.162.1602 Standards for health care payment

and remittance advice.

Subpart Q—Health Plan Premium Payments162.1701 Health plan premium payments

transaction.162.1702 Standard for health plan premium

payments.

Subpart R—Coordination of Benefits162.1801 Coordination of benefits

transaction.162.1802 Standards for coordination of

benefits.

Authority: Secs. 1171 through 1179 of theSocial Security Act (42 U.S.C. 1320d—1320d–8), as added by sec. 262 of Pub. L.104–191, 110 Stat. 2021–2031, and sec. 264of Pub. L. 104–191, 110 Stat. 2033–2034 (42U.S.C. 1320d–2 (note)).


§ 162.100 Applicability.Covered entities (as defined in

§ 160.103 of this subchapter) mustcomply with the applicablerequirements of this part.

§ 162.103 Definitions.For purposes of this part, the

following definitions apply:

Code set means any set of codes usedto encode data elements, such as tablesof terms, medical concepts, medicaldiagnostic codes, or medical procedurecodes. A code set includes the codesand the descriptors of the codes.

Code set maintaining organizationmeans an organization that creates andmaintains the code sets adopted by theSecretary for use in the transactions forwhich standards are adopted in thispart.

Data condition means the rule thatdescribes the circumstances underwhich a covered entity must use aparticular data element or segment.

Data content means all the dataelements and code sets inherent to atransaction, and not related to theformat of the transaction. Data elementsthat are related to the format are notdata content.

Data element means the smallestnamed unit of information in atransaction.

Data set means a semanticallymeaningful unit of informationexchanged between two parties to atransaction.

Descriptor means the text defining acode.

Designated standard maintenanceorganization (DSMO) means anorganization designated by the Secretaryunder § 162.910(a).

Direct data entry means the directentry of data (for example, using dumbterminals or web browsers) that isimmediately transmitted into a healthplan’s computer.

Electronic media means the mode ofelectronic transmission. It includes theInternet (wide-open), Extranet (usingInternet technology to link a businesswith information only accessible tocollaborating parties), leased lines, dial-up lines, private networks, and thosetransmissions that are physically movedfrom one location to another usingmagnetic tape, disk, or compact diskmedia.

Format refers to those data elementsthat provide or control the envelopingor hierarchical structure, or assist inidentifying data content of, atransaction.

HCPCS stands for the Health [CareFinancing Administration] CommonProcedure Coding System.

Maintain or maintenance refers toactivities necessary to support the use ofa standard adopted by the Secretary,including technical corrections to animplementation specification, andenhancements or expansion of a codeset. This term excludes the activitiesrelated to the adoption of a newstandard or implementationspecification, or modification to an



adopted standard or implementationspecification.

Maximum defined data set means allof the required data elements for aparticular standard based on a specificimplementation specification.

Segment means a group of relateddata elements in a transaction.

Standard transaction means atransaction that complies with theapplicable standard adopted under thispart.

Subparts B—H [Reserved]

Subpart I—General Provisions forTransactions

§ 162.900—Compliance dates of the initialimplementation of the code sets andtransaction standards.

(a) Health care providers. A coveredhealth care provider must comply withthe applicable requirements of subpartsI through N of this part no later thanOctober 16, 2002.

(b) Health plans. A health plan mustcomply with the applicablerequirements of subparts I through R ofthis part no later than one of thefollowing dates:

(1) Health plans other than smallhealth plans— October 16, 2002.

(2) Small health plans— October 16,2003.

(c) Health care clearinghouses. Ahealth care clearinghouse must complywith the applicable requirements ofsubparts I through R of this part no laterthan October 16, 2002.

§ 162.910 Maintenance of standards andadoption of modifications and newstandards.

(a) Designation of DSMOs. (1) TheSecretary may designate as a DSMO anorganization that agrees to conduct, tothe satisfaction of the Secretary, thefollowing functions:

(i) Maintain standards adopted underthis subchapter.

(ii) Receive and process requests foradopting a new standard or modifyingan adopted standard.

(2) The Secretary designates a DSMOby notice in the Federal Register.

(b) Maintenance of standards.Maintenance of a standard by theappropriate DSMO constitutesmaintenance of the standard forpurposes of this part, if done inaccordance with the processes theSecretary may require.

(c) Process for modification of existingstandards and adoption of newstandards. The Secretary considers arecommendation for a proposedmodification to an existing standard, ora proposed new standard, only if the

recommendation is developed through aprocess that provides for the following:

(1) Open public access.(2) Coordination with other DSMOs.(3) An appeals process for each of the

following, if dissatisfied with thedecision on the request:

(i) The requestor of the proposedmodification.

(ii) A DSMO that participated in thereview and analysis of the request forthe proposed modification, or theproposed new standard.

(4) Expedited process to addresscontent needs identified within theindustry, if appropriate.

(5) Submission of therecommendation to the NationalCommittee on Vital and HealthStatistics (NCVHS).

§ 162.915 Trading partner agreements.A covered entity must not enter into

a trading partner agreement that woulddo any of the following:

(a) Change the definition, datacondition, or use of a data element orsegment in a standard.

(b) Add any data elements orsegments to the maximum defined dataset.

(c) Use any code or data elements thatare either marked ‘‘not used’’ in thestandard’s implementation specificationor are not in the standard’simplementation specification(s).

(d) Change the meaning or intent ofthe standard’s implementationspecification(s).

§ 162.920 Availability of implementationspecifications.

(a) Access to implementationspecifications. A person or organizationmay request copies (or access forinspection) of the implementationspecifications for a standard describedin subparts K through R of this part byidentifying the standard by name,number, and version. Theimplementation specifications areavailable as follows:

(1) ASC X12N specifications. Theimplementation specifications for ASCX12N standards may be obtained fromthe Washington Publishing Company,PMB 161, 5284 Randolph Road,Rockville, MD, 20852–2116; telephone301–949–9740; and FAX: 301–949–9742. They are also available throughthe Washington Publishing Company onthe Internet at http://www.wpc-edi.com.The implementation specifications areas follows:

(i) The ASC X12N 837—Health CareClaim: Dental, Version 4010, May 2000,Washington Publishing Company,004010X097, as referenced in§§ 162.1102 and 162.1802.

(ii) The ASC X12N 837—Health CareClaim: Professional, Volumes 1 and 2,Version 4010, May 2000, WashingtonPublishing Company, 004010X098, asreferenced in §§ 162.1102 and 162.1802.

(iii) The ASC X12N 837—Health CareClaim: Institutional, Volumes 1 and 2,Version 4010, May 2000, WashingtonPublishing Company, 004010X096, asreferenced in §§ 162.1102 and 162.1802.

(iv) The ASC X12N 270/271—HealthCare Eligibility Benefit Inquiry andResponse, Version 4010, May 2000,Washington Publishing Company,004010X092, as referenced in§ 162.1202.

(v) The ASC X12N 278—Health CareServices Review—Request for Reviewand Response, Version 4010, May 2000,Washington Publishing Company,004010X094, as referenced in§ 162.1302.

(vi) The ASC X12N 276/277 HealthCare Claim Status Request andResponse, Version 4010, May 2000,Washington Publishing Company,004010X093, as referenced in§ 162.1402.

(vii) The ASC X12N 834—BenefitEnrollment and Maintenance, Version4010, May 2000, Washington PublishingCompany, 004010X095, as referenced in§ 162.1502.

(viii) The ASC X12N 835—HealthCare Claim Payment/Advice, Version4010, May 2000, Washington PublishingCompany, 004010X091, as referenced in§ 162.1602.

(ix) The ASC X12N 820—PayrollDeducted and Other Group PremiumPayment for Insurance Products,Version 4010, May 2000, WashingtonPublishing Company, 004010X061, asreferenced in § 162.1702.

(2) Retail pharmacy specifications.The implementation specifications forall retail pharmacy standards may beobtained from the National Council forPrescription Drug Programs (NCPDP),4201 North 24th Street, Suite 365,Phoenix, AZ, 85016; telephone 602–957–9105; and FAX 602–955–0749. Itmay also be obtained through theInternet at http://www.ncpdp.org. Theimplementation specifications are asfollows:

(i) The Telecommunication StandardImplementation Guide, Version 5Release 1, September 1999, NationalCouncil for Prescription Drug Programs,as referenced in §§ 162.1102, 162.1202,162.1602, and 162.1802.

(ii) The Batch Standard BatchImplementation Guide, Version 1Release 0, February 1, 1996, NationalCouncil for Prescription Drug Programs,as referenced in §§ 162.1102, 162.1202,162.1602, and 162.1802.



(b) Incorporations by reference. TheDirector of the Office of the FederalRegister approves the implementationspecifications described in paragraph (a)of this section for incorporation byreference in subparts K through R of thispart in accordance with 5 U.S.C. 552(a)and 1 CFR part 51. A copy of theimplementation specifications may beinspected at the Office of the FederalRegister, 800 North Capitol Street, NW,Suite 700, Washington, DC.

§ 162.923 Requirements for coveredentities.

(a) General rule. Except as otherwiseprovided in this part, if a covered entityconducts with another covered entity(or within the same covered entity),using electronic media, a transaction forwhich the Secretary has adopted astandard under this part, the coveredentity must conduct the transaction as astandard transaction.

(b) Exception for direct data entrytransactions. A health care providerelecting to use direct data entry offeredby a health plan to conduct atransaction for which a standard hasbeen adopted under this part must usethe applicable data content and datacondition requirements of the standardwhen conducting the transaction. Thehealth care provider is not required touse the format requirements of thestandard.

(c) Use of a business associate. Acovered entity may use a businessassociate, including a health careclearinghouse, to conduct a transactioncovered by this part. If a covered entitychooses to use a business associate toconduct all or part of a transaction onbehalf of the covered entity, the coveredentity must require the businessassociate to do the following:

(1) Comply with all applicablerequirements of this part.

(2) Require any agent or subcontractorto comply with all applicablerequirements of this part.

§ 162.925 Additional requirements forhealth plans.

(a) General rules. (1) If an entityrequests a health plan to conduct atransaction as a standard transaction,the health plan must do so.

(2) A health plan may not delay orreject a transaction, or attempt toadversely affect the other entity or thetransaction, because the transaction is astandard transaction.

(3) A health plan may not reject astandard transaction on the basis that itcontains data elements not needed orused by the health plan (for example,coordination of benefits information).

(4) A health plan may not offer anincentive for a health care provider to

conduct a transaction covered by thispart as a transaction described under theexception provided for in § 162.923(b).

(5) A health plan that operates as ahealth care clearinghouse, or requires anentity to use a health care clearinghouseto receive, process, or transmit astandard transaction may not chargefees or costs in excess of the fees or costsfor normal telecommunications that theentity incurs when it directly transmits,or receives, a standard transaction to, orfrom, a health plan.

(b) Coordination of benefits. If ahealth plan receives a standardtransaction and coordinates benefitswith another health plan (or anotherpayer), it must store the coordination ofbenefits data it needs to forward thestandard transaction to the other healthplan (or other payer).

(c) Code sets. A health plan must meeteach of the following requirements:

(1) Accept and promptly process anystandard transaction that contains codesthat are valid, as provided in subpart Jof this part.

(2) Keep code sets for the currentbilling period and appeals periods stillopen to processing under the terms ofthe health plan’s coverage.

§ 162.930 Additional rules for health careclearinghouses.

When acting as a business associatefor another covered entity, a health careclearinghouse may perform thefollowing functions:

(a) Receive a standard transaction onbehalf of the covered entity andtranslate it into a nonstandardtransaction (for example, nonstandardformat and/or nonstandard data content)for transmission to the covered entity.

(b) Receive a nonstandard transaction(for example, nonstandard format and/or nonstandard data content) from thecovered entity and translate it into astandard transaction for transmission onbehalf of the covered entity.

§ 162.940 Exceptions from standards topermit testing of proposed modifications.

(a) Requests for an exception. Anorganization may request an exceptionfrom the use of a standard from theSecretary to test a proposedmodification to that standard. For eachproposed modification, the organizationmust meet the following requirements:

(1) Comparison to a current standard.Provide a detailed explanation, no morethan 10 pages in length, of how theproposed modification would be asignificant improvement to the currentstandard in terms of the followingprinciples:

(i) Improve the efficiency andeffectiveness of the health care system

by leading to cost reductions for, orimprovements in benefits from,electronic health care transactions.

(ii) Meet the needs of the health datastandards user community, particularlyhealth care providers, health plans, andhealth care clearinghouses.

(iii) Be uniform and consistent withthe other standards adopted under thispart and, as appropriate, with otherprivate and public sector health datastandards.

(iv) Have low additional developmentand implementation costs relative to thebenefits of using the standard.

(v) Be supported by an ANSI-accredited SSO or other private orpublic organization that would maintainthe standard over time.

(vi) Have timely development, testing,implementation, and updatingprocedures to achieve administrativesimplification benefits faster.

(vii) Be technologically independentof the computer platforms andtransmission protocols used inelectronic health transactions, unlessthey are explicitly part of the standard.

(viii) Be precise, unambiguous, and assimple as possible.

(ix) Result in minimum datacollection and paperwork burdens onusers.

(x) Incorporate flexibility to adaptmore easily to changes in the health careinfrastructure (such as new services,organizations, and provider types) andinformation technology.

(2) Specifications for the proposedmodification. Provide specifications forthe proposed modification, includingany additional system requirements.

(3) Testing of the proposedmodification. Provide an explanation,no more than 5 pages in length, of howthe organization intends to test thestandard, including the number andtypes of health plans and health careproviders expected to be involved in thetest, geographical areas, and beginningand ending dates of the test.

(4) Trading partner concurrences.Provide written concurrences fromtrading partners who would agree toparticipate in the test.

(b) Basis for granting an exception.The Secretary may grant an initialexception, for a period not to exceed 3years, based on, but not limited to, thefollowing criteria:

(1) An assessment of whether theproposed modification demonstrates asignificant improvement to the currentstandard.

(2) The extent and length of time ofthe exception.

(3) Consultations with DSMOs.(c) Secretary’s decision on exception.

The Secretary makes a decision and



notifies the organization requesting theexception whether the request is grantedor denied.

(1) Exception granted. If the Secretarygrants an exception, the notificationincludes the following information:

(i) The length of time for which theexception applies.

(ii) The trading partners andgeographical areas the Secretaryapproves for testing.

(iii) Any other conditions forapproving the exception.

(2) Exception denied. If the Secretarydoes not grant an exception, thenotification explains the reasons theSecretary considers the proposedmodification would not be a significantimprovement to the current standardand any other rationale for the denial.

(d) Organization’s report on testresults. Within 90 days after the test iscompleted, an organization that receivesan exception must submit a report onthe results of the test, including a cost-benefit analysis, to a location specifiedby the Secretary by notice in the FederalRegister.

(e) Extension allowed. If the reportsubmitted in accordance with paragraph(d) of this section recommends amodification to the standard, theSecretary, on request, may grant anextension to the period granted for theexception.

Subpart J—Code Sets

§ 162.1000 General requirements.When conducting a transaction

covered by this part, a covered entitymust meet the following requirements:

(a) Medical data code sets. Use theapplicable medical data code setsdescribed in § 162.1002 as specified inthe implementation specificationadopted under this part that are valid atthe time the health care is furnished.

(b) Nonmedical data code sets. Usethe nonmedical data code sets asdescribed in the implementationspecifications adopted under this partthat are valid at the time the transactionis initiated.

§ 162.1002 Medical data code sets.

The Secretary adopts the followingcode set maintaining organization’scode sets as the standard medical datacode sets:

(a) International Classification ofDiseases, 9th Edition, ClinicalModification, (ICD–9–CM), Volumes 1and 2 (including The Official ICD–9–CM Guidelines for Coding andReporting), as maintained anddistributed by HHS, for the followingconditions:

(1) Diseases.

(2) Injuries.(3) Impairments.(4) Other health problems and their

manifestations.(5) Causes of injury, disease,

impairment, or other health problems.(b) International Classification of

Diseases, 9th Edition, ClinicalModification, Volume 3 Procedures(including The Official ICD–9–CMGuidelines for Coding and Reporting),as maintained and distributed by HHS,for the following procedures or otheractions taken for diseases, injuries, andimpairments on hospital inpatientsreported by hospitals:

(1) Prevention.(2) Diagnosis.(3) Treatment.(4) Management.(c) National Drug Codes (NDC), as

maintained and distributed by HHS, incollaboration with drug manufacturers,for the following:

(1) Drugs(2) Biologics.(d) Code on Dental Procedures and

Nomenclature, as maintained anddistributed by the American DentalAssociation, for dental services.

(e) The combination of Health CareFinancing Administration CommonProcedure Coding System (HCPCS), asmaintained and distributed by HHS, andCurrent Procedural Terminology, FourthEdition (CPT–4), as maintained anddistributed by the American MedicalAssociation, for physician services andother health care services. Theseservices include, but are not limited to,the following:

(1) Physician services.(2) Physical and occupational therapy

services.(3) Radiologic procedures.(4) Clinical laboratory tests.(5) Other medical diagnostic

procedures.(6) Hearing and vision services.(7) Transportation services including

ambulance.(f) The Health Care Financing

Administration Common ProcedureCoding System (HCPCS), as maintainedand distributed by HHS, for all othersubstances, equipment, supplies, orother items used in health care services.These items include, but are not limitedto, the following:

(1) Medical supplies.(2) Orthotic and prosthetic devices.(3) Durable medical equipment.

§ 162.1011 Valid code sets.

Each code set is valid within the datesspecified by the organizationresponsible for maintaining that codeset.

Subpart K—Health Care Claims orEquivalent Encounter Information

§ 162.1101 Health care claims orequivalent encounter informationtransaction.

The health care claims or equivalentencounter information transaction is thetransmission of either of the following:

(a) A request to obtain payment, andthe necessary accompanyinginformation from a health care providerto a health plan, for health care.

(b) If there is no direct claim, becausethe reimbursement contract is based ona mechanism other than charges orreimbursement rates for specificservices, the transaction is thetransmission of encounter informationfor the purpose of reporting health care.

§ 162.1102 Standards for health careclaims or equivalent encounter information.

The Secretary adopts the followingstandards for the health care claims orequivalent encounter informationtransaction:

(a) Retail pharmacy drug claims. TheNational Council for Prescription DrugPrograms (NCPDP) TelecommunicationStandard Implementation Guide,Version 5 Release 1, September 1999,and equivalent NCPDP Batch StandardBatch Implementation Guide, Version 1Release 0, February 1, 1996. Theimplementation specifications areavailable at the addresses specified in§ 162.920(a)(2).

(b) Dental Health Care Claims. TheASC X12N 837—Health Care Claim:Dental, Version 4010, May 2000,Washington Publishing Company,004010X097. The implementationspecification is available at theaddresses specified in § 162.920(a)(1).

(c) Professional Health Care Claims.The ASC X12N 837—Health Care Claim:Professional, Volumes 1 and 2, Version4010, May 2000, Washington PublishingCompany, 004010X098. Theimplementation specification isavailable at the addresses specified in§ 162.920(a)(1).

(d) Institutional Health Care Claims.The ASC X12N 837—Health Care Claim:Institutional, Volumes 1 and 2, Version4010, May 2000, Washington PublishingCompany, 004010X096. Theimplementation specification isavailable at the addresses specified in§ 162.920(a)(1).

Subpart L—Eligibility for a Health Plan

§ 162.1201 Eligibility for a health plantransaction.

The eligibility for a health plantransaction is the transmission of eitherof the following:



(a) An inquiry from a health careprovider to a health plan, or from onehealth plan to another health plan, toobtain any of the following informationabout a benefit plan for an enrollee:

(1) Eligibility to receive health careunder the health plan.

(2) Coverage of health care under thehealth plan.

(3) Benefits associated with thebenefit plan.

(b) A response from a health plan toa health care provider’s (or anotherhealth plan’s) inquiry described inparagraph (a) of this section.

§ 162.1202 Standards for eligibility for ahealth plan.

The Secretary adopts the followingstandards for the eligibility for a healthplan transaction:

(a) Retail pharmacy drugs. TheNCPDP Telecommunication StandardImplementation Guide, Version 5Release 1, September 1999, andequivalent NCPDP Batch StandardBatch Implementation Guide, Version 1Release 0, February 1, 1996. Theimplementation specifications areavailable at the addresses specified in§ 162.920(a)(2).

(b) Dental, professional, andinstitutional. The ASC X12N 270/271–Health Care Eligibility Benefit Inquiryand Response, Version 4010, May 2000,Washington Publishing Company,004010X092. The implementationspecification is available at theaddresses specified in § 162.920(a)(1).

Subpart M—Referral Certification andAuthorization

§ 162.1301 Referral certification andauthorization transaction.

The referral certification andauthorization transaction is any of thefollowing transmissions:

(a) A request for the review of healthcare to obtain an authorization for thehealth care.

(b) A request to obtain authorizationfor referring an individual to anotherhealth care provider.

(c) A response to a request describedin paragraph (a) or paragraph (b) of thissection.

§ 162.1302 Standard for referralcertification and authorization.

The Secretary adopts the ASC X12N278—Health Care Services Review—Request for Review and Response,Version 4010, May 2000, WashingtonPublishing Company, 004010X094 asthe standard for the referral certificationand authorization transaction. Theimplementation specification isavailable at the addresses specified in§ 162.920(a)(1).

Subpart N—Health Care Claim Status

§ 162.1401 Health care claim statustransaction.

A health care claim status transactionis the transmission of either of thefollowing:

(a) An inquiry to determine the statusof a health care claim.

(b) A response about the status of ahealth care claim.

§ 162.1402 Standard for health care claimstatus.

The Secretary adopts the ASC X12N276/277 Health Care Claim StatusRequest and Response, Version 4010,May 2000, Washington PublishingCompany, 004010X093 as the standardfor the health care claim statustransaction. The implementationspecification is available at theaddresses specified in § 162.920(a)(1).

Subpart O—Enrollment andDisenrollment in a Health Plan

§ 162.1501 Enrollment and disenrollmentin a health plan transaction.

The enrollment and disenrollment ina health plan transaction is thetransmission of subscriber enrollmentinformation to a health plan to establishor terminate insurance coverage.

§ 162.1502 Standard for enrollment anddisenrollment in a health plan.

The Secretary adopts the ASC X12N834—Benefit Enrollment andMaintenance, Version 4010, May 2000,Washington Publishing Company,004010X095 as the standard for theenrollment and disenrollment in ahealth plan transaction. Theimplementation specification isavailable at the addresses specified in§ 162.920(a)(1).

Subpart P—Health Care Payment andRemittance Advice

§ 162.1601 Health care payment andremittance advice transaction.

The health care payment andremittance advice transaction is thetransmission of either of the followingfor health care:

(a) The transmission of any of thefollowing from a health plan to a healthcare provider’s financial institution:

(1) Payment.(2) Information about the transfer of

funds.(3) Payment processing information.(b) The transmission of either of the

following from a health plan to a healthcare provider:

(1) Explanation of benefits.(2) Remittance advice.

§ 162.1602 Standards for health carepayment and remittance advice.

The Secretary adopts the followingstandards for the health care paymentand remittance advice transaction:

(a) Retail pharmacy drug claims andremittance advice. The NCPDPTelecommunication StandardImplementation Guide, Version 5Release 1, September 1999, andequivalent NCPDP Batch StandardBatch Implementation Guide, Version 1Release 0, February 1, 1996. Theimplementation specifications areavailable at the addresses specified in§ 162.920(a)(2).

(b) Dental, professional, andinstitutional health care claims andremittance advice. The ASC X12N835—Health Care Claim Payment/Advice, Version 4010, May 2000,Washington Publishing Company,004010X091. The implementationspecification is available at theaddresses specified in § 162.920(a)(1).

Subpart Q—Health Plan PremiumPayments

§ 162.1701 Health plan premium paymentstransaction.

The health plan premium paymenttransaction is the transmission of any ofthe following from the entity that isarranging for the provision of healthcare or is providing health care coveragepayments for an individual to a healthplan:

(a) Payment.(b) Information about the transfer of

funds.(c) Detailed remittance information

about individuals for whom premiumsare being paid.

(d) Payment processing information totransmit health care premium paymentsincluding any of the following:

(1) Payroll deductions.(2) Other group premium payments.(3) Associated group premium

payment information.

§ 162.1702 Standard for health planpremium payments.

The Secretary adopts the ASC X12N820—Payroll Deducted and Other GroupPremium Payment for InsuranceProducts, Version 4010, May 2000,Washington Publishing Company,004010X061 as the standard for thehealth plan premium paymentstransaction. The implementationspecification is available at theaddresses specified in § 162.920(a)(1).

Subpart R—Coordination of Benefits

§ 162.1801 Coordination of benefitstransaction.

The coordination of benefitstransaction is the transmission from any



entity to a health plan for the purposeof determining the relative paymentresponsibilities of the health plan, ofeither of the following for health care:

(a) Claims.(b) Payment information.

§ 162.1802 Standards for coordination ofbenefits.

The Secretary adopts the followingstandards for the coordination ofbenefits information transaction:

(a) Retail pharmacy drug claims. TheNCPDP Telecommunication StandardImplementation Guide, Version 5Release 1, September 1999, andequivalent NCPDP Batch StandardBatch Implementation Guide, Version 1Release 0, February 1, 1996. Theimplementation specifications are

available at the addresses specified in§ 162.920(a)(2).

(b) Dental claims. The ASC X12N837—Health Care Claim: Dental,Version 4010, May 2000, WashingtonPublishing Company, 004010X097. Theimplementation specification isavailable at the addresses specified in§ 162.920(a)(1).

(c) Professional health care claims.The ASC X12N 837—Health Care Claim:Professional, Volumes 1 and 2, Version4010, May 2000, Washington PublishingCompany, 004010X098. Theimplementation specification isavailable at the addresses specified in§ 162.920(a)(1).

(d) Institutional health care claims.The ASC X12N 837—Health Care Claim:Institutional, Volumes 1 and 2, Version

4010, May 2000, Washington PublishingCompany, 004010X096. Theimplementation specification isavailable at the addresses specified in§ 162.920(a)(1).

Authority: Secs. 1171 through 1179 of theSocial Security Act (42 U.S.C. 1320d-1320d-8), as added by sec. 262 of Public Law 104–191, 110 Stat. 2021–2031, and sec. 264 ofPub. L. 104–191, 110 Stat. 2033–2034 (42U.S.C. 1320d-2 (note)).

(Catalog of Federal Domestic AssistanceProgram No. 93.774, Medicare—Supplementary Medical Insurance Program)

Dated: July 24, 2000.Donna Shalala,Secretary.[FR Doc. 00–20820 Filed 8–11–00; 3:41 pm]BILLING CODE 4120–01–U
