federal register - hhs

fede

ral r

egiste

r

43241

WednesdayAugust 12, 1998

Part III

Department ofHealth and HumanServicesOffice of the Secretary

45 CFR Part 142Security and Electronic SignatureStandards; Proposed Rule

43242 Federal Register / Vol. 63, No. 155 / Wednesday, August 12, 1998 / Proposed Rules

DEPARTMENT OF HEALTH ANDHUMAN SERVICES

Office of the Secretary

45 CFR Part 142

[HCFA–0049–P]

RIN 0938–AI57

Security and Electronic SignatureStandards

AGENCY: Health Care FinancingAdministration (HCFA), HHS.ACTION: Proposed rule.

SUMMARY: This rule proposes standardsfor the security of individual healthinformation and electronic signature useby health plans, health careclearinghouses, and health careproviders. The health plans, health careclearinghouses, and health careproviders would use the securitystandards to develop and maintain thesecurity of all electronic individualhealth information. The electronicsignature standard is applicable onlywith respect to use with the specifictransactions defined in the HealthInsurance Portability andAccountability Act of 1996, and when ithas been determined that an electronicsignature must be used.

The use of these standards wouldimprove the Medicare and Medicaidprograms, and other Federal healthprograms and private health programs,and the effectiveness and efficiency ofthe health care industry in general. Thisrule would implement some of therequirements of the AdministrativeSimplification subtitle of the HealthInsurance Portability andAccountability Act of 1996.DATES: Comments will be considered ifwe receive them at the appropriateaddress, as provided below, no laterthan 5 p.m. on October 13, 1998.ADDRESSES: Mail written comments (1original and 3 copies) to the followingaddress: Health Care FinancingAdministration, Department of Healthand Human Services, Attention: HCFA–0049–P, P.O. Box 26585, Baltimore, MD21207–0519.

If you prefer, you may deliver yourwritten comments (1 original and 3copies) to one of the followingaddresses:Room 309–G, Hubert H. Humphrey

Building, 200 Independence Avenue,SW., Washington, DC 20201, or

Room C5–09–26, 7500 SecurityBoulevard, Baltimore, MD 21244–1850.Comments may also be submitted

electronically to the following e-mail

address: [email protected]. Fore-mail comment procedures, see thebeginning of SUPPLEMENTARYINFORMATION. For further information onordering copies of the Federal Registercontaining this document and onelectronic access, see the beginning ofSUPPLEMENTARY INFORMATION.FOR FURTHER INFORMATION CONTACT: JohnParmigiani, (410) 786–2976.SUPPLEMENTARY INFORMATION:

E-Mail, Comments, Procedures,Availability of Copies, and ElectronicAccess

E-mail comments should include thefull name, postal address, and affiliation(if applicable) of the sender and must besubmitted to the referenced address tobe considered. All comments should beincorporated in the e-mail messagebecause we may not be able to accessattachments.

Because of staffing and resourcelimitations, we cannot accept commentsby facsimile (FAX) transmission. Incommenting, please refer to file codeHCFA–0049–P and the specific sectionor sections of the proposed rule. Bothelectronic and written commentsreceived by the time and date indicatedabove will be available for publicinspection as they are received,generally beginning approximately 3weeks after publication of a document,in Room 309–G of the Department’soffices at 200 Independence Avenue,SW., Washington, DC, on Mondaythrough Friday of each week from 8:30a.m. to 5 p.m. (phone: (202) 690–7890).Electronic and legible written commentswill also be posted, along with thisproposed rule, at the following web site:http://aspe.os.dhhs.gov/admnsimp/.

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.

This Federal Register document isalso available from the Federal Registeronline database through GPO Access, a

service of the U.S. Government PrintingOffice. Free public access is available ona Wide Area Information Server (WAIS)through the Internet and viaasynchronous dial-in. Internet users canaccess the database by using the WorldWide Web, http://www.access.gpo.gov/nara/, by using local WAIS clientsoftware, or by telnet toswais.access.gpo.gov, then login as guest(no password required). Dial-in usersshould use communications softwareand modem to call (202) 512–1661; typeswais, then login as guest (no passwordrequired).

I. Background

[Please label written or e-mailed commentsabout this section with the subject:Background]

In order to administer their programs,the Department of Health and HumanServices, other Federal agencies, StateMedicaid agencies, private health plans,health care providers, and health careclearinghouses must assure theircustomers (such as patients, insured,providers, and health care plans) thatthe confidentiality and privacy of healthcare information they electronicallycollect, maintain, use, or transmit issecure. Security of health information isespecially important when healthinformation can be directly linked to anindividual.

Confidentiality is threatened not onlyby the risk of improper access toelectronically stored information, butalso by the risk of interception duringelectronic transmission of theinformation.

In addition to the need to ensureelectronic health care information issecure and confidential, there is apotential need to associate signaturecapability with information beingelectronically stored or transmitted.Today, there are numerous forms ofelectronic signatures, ranging frombiometric devices to digital signature.To satisfy the legal and time-testedcharacteristics of a written signature,however, an electronic signature mustdo the following:

• Identify the signatory individual,• Assure the integrity of a document’s

content, and• Provide for nonrepudiation; that is,

strong and substantial evidence that willmake it difficult for the signer to claimthat the electronic representation is notvalid. Currently, the only technicallymature electronic signature meeting theabove criteria is the digital signature.There is no national standard forsecurity or electronic signatures. Ofnecessity, each health care provider,health care plan, and health care entity

43243Federal Register / Vol. 63, No. 155 / Wednesday, August 12, 1998 / Proposed Rules

has defined its own securityrequirements.

A. LegislationThe Congress included provisions to

address the need for security andelectronic signature standards 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–191affects 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 Cis to improve the Medicare andMedicaid programs, in particular, andthe efficiency and effectiveness of thehealth care system, in general, byencouraging the development of ahealth information system through theestablishment of standards andrequirements to facilitate the electronicmaintenance and transmission of certainhealth information.

Part C of title XI of the Act consistsof sections 1171 through 1179. Thesesections define various terms andimpose several requirements on HHS,health plans, health care clearinghouses,and certain health care providersconcerning electronic transmission ofhealth information.

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,individually identifiable healthinformation, standard, and standardsetting organization.

Section 1172 of the Act makes anystandard adopted under part Capplicable to: (1) Health plans, (2)health care clearinghouses, and (3)health care providers that transmit anyhealth information in electronic form inconnection with the transactionsreferred to in section 1173(a)(1) of theAct. The security standard to be adoptedunder Part C is not restricted to thetransactions referred to in section1173(a)(1) of the Act, but is applicableto any health information pertaining toan individual that is electronicallymaintained or transmitted. This sectionalso contains the followingrequirements concerning standardsetting:

• The Secretary may adopt a standarddeveloped, adopted, or modified by astandard setting organization (that is, an

organization accredited by the AmericanNational Standards Institute (ANSI))that has consulted with the NationalUniform Billing Committee (NUBC), theNational Uniform Claim Committee(NUCC), Workgroup for Electronic DataInterchange (WEDI), and the AmericanDental 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 must rely on therecommendations of the NationalCommittee on Vital and HealthStatistics (NCVHS) and consult witheach of the above-named groups.

In complying with the requirementsof part C of title XI, the Secretary mustrely on the recommendations of theNCVHS, consult with appropriate State,Federal, and private agencies ororganizations, and publish the NCVHSrecommendations in the FederalRegister.

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 claims, health encounterinformation, health claims attachments,health plan enrollments anddisenrollments, health plan eligibility,health care payment and remittanceadvice, health plan premium payments,first report of injury, health claim status,and referral certification andauthorization. In addition, the Secretaryis required to adopt standards for anyother financial and administrativetransactions that are determined to beappropriate by the Secretary.

Paragraph (b) of section 1173 of theAct requires the Secretary to adoptstandards for unique health identifiersfor all individuals, employers, healthplans, and health care providers andrequires further that the adoptedstandards specify for what purposesunique health identifiers may be used.

Paragraphs (c) through (f) of section1173 of the Act require the Secretary toestablish standards for code sets foreach data element for each health caretransaction listed above, securitystandards for health care informationsystems, standards for electronicsignatures (established together with the

Secretary 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 requirements forwritten signatures with respect to thetransactions listed in paragraph (a) ofsection 1173 of the Act.

In section 1174 of the Act, theSecretary is required to establishstandards for all of the abovetransactions, except claims attachments,by February 21, 1998. The standards forclaims attachments must be establishedby February 21, 1999. Generally, after astandard is established, it cannot bechanged during the first year afteradoption except for changes that arenecessary to permit compliance with thestandard. Modifications to any of thesestandards may be made after the firstyear, but not more frequently than onceevery 12 months. The Secretary mustalso ensure that procedures exist for theroutine maintenance, testing,enhancement, and expansion of codesets and that there are crosswalks fromprior versions.

Section 1175 of the Act prohibitshealth plans from refusing to process ordelaying the processing of a transactionthat is presented in standard format.The Act’s requirements are not limitedto health plans; however, each person towhom a standard or implementationspecification applies is required tocomply with the standard within 24months (or 36 months for small healthplans) of its adoption. A health plan orother entity may, of course, complyvoluntarily before the effective date. Aperson may comply by using a healthcare clearinghouse to transmit or receivethe standard transactions. Compliancewith modifications to standards orimplementation specifications must beaccomplished by a date designated bythe Secretary. This date may not beearlier than 180 days from the notice ofchange.

Section 1176 of the Act establishes acivil monetary penalty 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 and not morethan $25,000 per person for violations ofa single standard for a calendar year.The procedural provisions in section1128A of the Act, ‘‘Civil MonetaryPenalties,’’ are applicable.

Section 1177 of the Act establishespenalties for a knowing misuse ofunique health identifiers andindividually identifiable healthinformation: (1) A fine of not more than$50,000 and/or imprisonment of not


more than 1 year; (2) if misuse is ‘‘underfalse pretenses,’’ a fine of not more than$100,000 and/or imprisonment of notmore than 5 years; and (3) if misuse iswith intent to sell, transfer, or useindividually identifiable healthinformation for commercial advantage,personal gain, or malicious harm, a fineof not more than $250,000 and/orimprisonment of not more than 10years. Note that these penalties do notaffect any other penalties which may beimposed by other Federal programs,including ERISA.

Under section 1178 of the Act, theprovisions of part C of title XI of theAct, as well as any standardsestablished under them, supersede anyState law that is contrary to them.However, the Secretary may, forstatutorily-specified reasons, waive thisprovision.

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

(Concerning this last provision, theconference report, in its discussion onsection 1178, states:

‘‘The conferees do not intend to excludethe activities of financial institutions or theircontractors from compliance with thestandards adopted under this part if suchactivities would be subject to this part.However, conferees intend that this part doesnot apply to use or disclosure of informationwhen an individual utilizes a paymentsystem to make a payment for, or related to,health plan premiums or health care. Forexample, the exchange of informationbetween participants in a credit card systemin connection with processing a credit cardpayment for health care would not becovered by this part. Similarly sending achecking account statement to an accountholder who uses a credit or debit card to payfor health care services, would not becovered by this part. However, this part doesapply if a company clears health care claims,the health care claims activities remainsubject to the requirements of this part.’’)(H.R. Rep. No. 736, 104th Cong., 2nd Sess.268–269 (1996))

B. Process for Developing NationalStandards

The Secretary has formulated a five-part strategy for developing andimplementing the standards mandatedunder part C of title XI of the Act:

1. To ensure necessary interagencycoordination and required interactionwith other Federal departments and theprivate sector, establishinterdepartmental implementationteams to identify and assess potentialstandards for adoption. The subject

matter of the teams includes claims/encounters, identifiers, enrollment/eligibility, systems security andelectronic signature, and medical codingclassification. Another team addressescross-cutting issues and coordinates thesubject matter teams. The teams consultwith external groups such as theNCVHS’ Workgroup on Data Standards,WEDI, the ANSI’s HealthcareInformatics Standards Board (HISB), theNUCC, the NUBC, and the ADA. Theteams are charged with developingregulations and other necessarydocuments and makingrecommendations for the variousstandards to the HHS Data Councilthrough its Committee on Health DataStandards. (The HHS Data Council isthe focal point for consideration of datapolicy issues. It reports directly to theSecretary and advises the Secretary ondata standards and privacy issues.)

2. Develop recommendations forstandards to be adopted.

3. Publish proposed rules in theFederal Register describing thestandards. Each proposed rule providesthe public with a 60-day commentperiod.

4. Analyze public comments andpublish the final rules in the FederalRegister.

5. Distribute standards and coordinatepreparation and distribution ofimplementation guides.

This strategy affords manyopportunities for involvement ofinterested and affected parties instandards development and adoption byenabling them to:

• Participate with standards settingorganizations.

• Provide written input to theNCVHS.

• Provide written input to theSecretary of HHS.

• Provide testimony at NCVHS’’public meetings.

• Comment on the proposed rules foreach of the proposed standards.

• Invite HHS staff to meetings withpublic and private sector organizationsor meet directly with senior HHS staffinvolved in the implementation process.

The implementation teams chargedwith reviewing standards fordesignation as required nationalstandards under the statute havedefined, with significant input from thehealth care industry, a set of principlesfor guiding choices for the standards tobe adopted by the Secretary. Theseprinciples are based on directspecifications in HIPAA, the purpose ofthe law, and generally desirableprinciples. To be designated as anHIPAA standard, each standard should:

1. Improve the efficiency andeffectiveness of the health care systemby leading to cost reductions for orimprovements in benefits fromelectronic 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 HIPAA standards—their dataelement definitions and codes and theirprivacy and security requirements—and, secondarily, with other private andpublic sector health data standards.

4. Have low additional developmentand implementation costs relative to thebenefits of using the standard.

5. Be supported by an ANSI-accredited standards developingorganization or other private or publicorganization that will ensure continuityand efficient updating of the standardover time.

6. Have timely development, testing,implementation, and updatingprocedures to achieve administrativesimplification benefits faster.

7. Be technologically independent ofthe computer platforms andtransmission protocols used inelectronic health transactions, exceptwhen they are explicitly part of thestandard.

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

9. Keep data collection andpaperwork burdens on users as low asis feasible.

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

A master data dictionary providing forcommon data definitions across thestandards selected for implementationunder HIPAA will be developed andmaintained. We intend for the dataelement definitions to be precise,unambiguous, and consistently applied.The transaction-specific reports andgeneral reports from the master datadictionary will be readily available tothe public. At a minimum, theinformation presented will include dataelement names, definitions, andappropriate references to thetransactions where they are used.

This proposed rule would establishthe security standard and electronicsignature standard for health careinformation and individuallyidentifiable health care informationmaintained or transmittedelectronically. The remaining standardsare grouped, to the extent possible, bysubject matter and audience in otherregulations. We anticipate publishing


several separate regulation documentsto promulgate the remaining standardsrequired under HIPAA.

II. Provisions of this Proposed Rule

[Please label written comments or e-mailedcomments about this section with the subject:Introduction/Applicability]

We propose to add a new part to title45 of the Code of Federal Regulationsfor health plans, health care providers,and health care clearinghouses ingeneral. The new part would be part 142of title 45 and would be titled‘‘Administrative Requirements.’’Subpart A would contain the generalprovisions for this part, including thegeneral definitions and generalrequirements for health plans. Subpart Cwould contain provisions specific tosecuring health information used in anyelectronic transmission or stored format.

In this proposed rule, we propose astandard for security of healthinformation. This rule would establishthat health plans, health careclearinghouses, and health careproviders must have the securitystandard in place to comply with thestatutory requirement that health careinformation and individuallyidentifiable health care information beprotected to ensure privacy andconfidentiality when health informationis electronically stored, maintained, ortransmitted. The Congress mandated aseparate standard for electronicsignature, therefore, this proposedsecurity standard also addresses theselected standard for electronicsignature. The proposed securitystandard does not require the use of anelectronic signature, but specifies thestandard for an electronic signature thatmust be followed if such a signature isused. If an entity elects to use anelectronic signature, it must complywith the electronic signature standard.

A. ApplicabilityWith the exception of the security

provisions, section 262 of HIPAAapplies to any health plan, any healthcare clearinghouse, and any health careprovider that transmits any healthinformation in electronic form inconnection with transactions referred toin section 1173(a)(1) of the Act. Thesecurity provisions of section 262 ofHIPAA apply to any health plan, anyhealth care clearinghouse, and anyhealth care provider that electronicallymaintains or transmits any healthinformation relating to an individual.

Our proposed rules (at 45 CFR142.102) would apply to the healthplans and health care clearinghouses aswell, but we would clarify the statutorylanguage in our regulations for health

care providers. With the exception ofthe security regulation, we would havethe regulations apply to any health careprovider only when electronicallytransmitting any of the transactions towhich section 1173(a)(1) of the Actrefers.

Electronic transmissions wouldinclude transactions using all media,even when the information is physicallymoved from one location to anotherusing magnetic tape, disk, or compactdisc (cd) media. Transmissions over theInternet (wide-open), Extranet (usingInternet technology to link a businesswith information only accessible tocollaborating parties), leased lines, dial-up lines, and private networks are allincluded. Telephone voice response and‘‘faxback’’ (a request for informationmade via voice using a fax machine andrequested information returned via thatsame machine as a fax) systems wouldnot be included. We solicit commentsconcerning any adverse impact theabove statement concerning voiceresponse or faxback may have upon thesecurity of the health information in thecommenter’s care.

With the exception of the securityregulation, our regulations would applyto health care clearinghouses whentransmitting transactions to, andreceiving transactions from, a healthcare provider or health plan thattransmits and receives standardtransactions (as defined under‘‘transaction’’) and at all times whentransmitting to or receiving electronictransactions from another health careclearinghouse. The security regulationwould apply to health care clearinghouses electronically maintaining ortransmitting any health informationpertaining to an individual.

Entities that offer on-line interactivetransmission must comply with thestandards. The Hypertext MarkupLanguage (HTML) interaction between aserver and a browser by which the dataelements of a transaction are solicitedfrom a user would not have to use thestandards (with the exception of thesecurity standard), 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.

With the exception of the securityportion, the law would apply to eachhealth care provider when transmittingor receiving any of the specifiedelectronic transactions. The securityregulation would apply to each healthcare provider electronically maintainingor transmitting any health informationpertaining to an individual.

The law applies to health plans for alltransactions. Section 142.104 wouldcontain the following provisions (fromsection 1175 of the Act):

If a person desires to conduct atransaction (as defined in § 142.103)with a health plan as a standardtransaction, the following apply:

(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 basisthat the transaction is a standardtransaction.

(3) The information transmitted andreceived in connection with thetransaction must be in the form ofstandard data elements of healthinformation.

As a further requirement, we wouldprovide that a health plan that conductstransactions through an agent assurethat the agent meets all the requirementsof part 142 that apply to the health plan.

Section 142.105 would state that aperson or other entity may meet thetransaction requirements of § 142.104 byeither—

(1) Transmitting and receivingstandard data elements, or

(2) Submitting nonstandard dataelements to a health care clearinghousefor processing into standard dataelements and transmission by the healthcare clearinghouse and receivingstandard data elements through theclearinghouse.

Health care clearinghouses would beable to accept nonstandard transactionsfor the sole purpose of translating theminto standard transactions for sendingcustomers and would be able to acceptstandard transactions and translate theminto nonstandard formats for receivingcustomers. We would state in § 142.105that the transmission of nonstandardtransactions, under contract, between ahealth plan or a health care providerand a health care clearinghouse wouldnot violate the law.

With the exception of the securitystandard, transmissions within acorporate entity would not be requiredto comply with the standards. Ahospital that is wholly owned by amanaged care company would not haveto use the transaction standards to passencounter information back to the homeoffice, but it would have to use thestandard claims transaction to submit aclaim to another payer. Anotherexample might be transactions withinFederal agencies and their contractorsand between State agencies within thesame State. For example, Medicareenters into contracts with insurance


companies and common working filesites that process Medicare claims usinggovernment furnished software. There isconstant communication, on a privatenetwork, between HCFA Central Officeand the Medicare carriers,intermediaries, and common workingfile sites. This communication maycontinue in nonstandard mode.However, these contractors would berequired to comply with the transactionstandards when exchanging any of thetransactions covered by HIPAA with anentity outside these ‘‘corporate’’boundaries.

The security standard is applicable toall health care informationelectronically maintained or used in anelectronic transmission, regardless offormat (standard transaction or aproprietary format); no distinction ismade between internal corporate entitycommunication or communicationexternal to the corporate entity.

Although there are situations inwhich the use of the standards is notrequired (for example, health careproviders may continue to submit paperclaims and employers are not requiredto use any of the standard transactions),we stress that a standard may be usedvoluntarily in any situation in which itis not required.

This proposed regulation would notmandate the use of electronic signatureswith any specific transaction at thistime. Instead, the regulation proposesthat whenever an electronic signature isrequired for an electronic transaction bylaw, regulation, or contract, thesignature must meet the standardestablished in the regulation at§ 142.310. Use of this standard wouldsatisfy any Federal or State requirementfor a signature, either electronic or onpaper.

We note that the ANSI X12Nstandards for individual transactionswhich have been proposed for adoptionas national standards in a separateproposed rule do not require the use ofelectronic signatures. Standards foradditional transactions that theSecretary may propose for adoption inthe future, including one for claimsattachments, may contain suchrequirements. We solicit comments onwhether electronic signatures should berequired for any specific transactions orunder specific circumstances and whateffect such requirements would have onelectronic health care transactions.

We also note that the NCVHS isrequired by HIPAA to report to theSecretary recommendations andlegislative proposals for uniform datastandards for patient medical recordinformation and the electronic exchangeof such information, with the

implication that HHS should rely onsuch recommendations to adopt suchstandards or propose the passage ofsuch legislation by the Congress. Wesolicit comments on whether thestandard proposed below for electronicsignatures would be appropriate forconsideration as part of such standards.

B. Definitions

[Please label written or e-mailed commentsabout this section with the subject:Definitions]

Section 1171 of the Act definesseveral terms and our proposed ruleswould, for the most part, simply restatethe law. The terms that we are definingin this proposed rule follow:

1. Code SetWe would define ‘‘code set’’ as

section 1171(1) of the Act does: ‘‘codeset’’ means any set of codes used forencoding data elements, such as tablesof terms, medical concepts, medicaldiagnostic codes, or medical procedurecodes.

2. Health Care ClearinghouseWe would define ‘‘health care

clearinghouse’’ as section 1171(2) of theAct does, but we are adding a further,clarifying sentence. The statute definesa ‘‘health care clearinghouse’’ as apublic or private entity that processes orfacilitates the processing of nonstandarddata elements of health information intostandard data elements. We wouldfurther explain that such an entity isone that currently receives health caretransactions from health care providersor other entities, translates the data froma given format into one acceptable to theintended recipient and forwards theprocessed transaction to appropriatepayers and clearinghouses, as necessary,for further action.

There are currently a number ofprivate clearinghouses that perform thisfunction for health care providers. Forpurposes of this rule, we wouldconsider billing services, repricingcompanies, community healthmanagement information systems orcommunity health information systems,value-added networks, and switchesthat perform this function to be healthcare clearinghouses.

3. Health Care ProviderAs defined by section 1171(3) of the

Act, a ‘‘health care provider’’ is aprovider of services as defined insection 1861(u) of the Act, a provider ofmedical or other health services asdefined in section 1861(s) of the Act,and any other person who furnisheshealth care services or supplies. Ourregulations would define ‘‘health care

provider’’ as the statute does and clarifythat the definition of a health careprovider is limited to those entities thatfurnish, or bill and are paid for, healthcare services in the normal course ofbusiness.

For a more detailed discussion of thedefinition of health care provider, werefer the reader to our proposed rule,HCFA–0045-P, Standard Health CareProvider, 63 FR 25320, published May7, 1998.

4. Health Information‘‘Health information,’’ as defined in

section 1171 of the Act, means anyinformation, whether oral or recorded inany form or medium, that—

• Is created or received by a healthcare provider, health plan, public healthauthority, employer, life insurer, schoolor university, or health careclearinghouse; and

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

We propose the same definition forour regulations.

5. Health PlanWe propose that a ‘‘health plan’’ be

defined essentially as section 1171 ofthe Act defines it. Section 1171 of theAct cross refers to definitions in section2791 of the Public Health Service Act(as added by Public Law 104–191, 42U.S.C. 300gg-91); we would incorporatethose definitions as currently stated intoour proposed definitions for theconvenience of the public. We note thatthe term ‘‘health plan’’ is also definedin other statutes, such as the EmployeeRetirement Income Security Act of 1974(ERISA). Our definitions are based onthe roles of plans in conductingadministrative transactions, and anydifferences should not be construed toaffect other statutes.

For purposes of implementing theprovisions of administrativesimplification, a ‘‘health plan’’ would bean individual or group health plan thatprovides, or pays the cost of, medicalcare. This definition includes, but is notlimited to, the 13 types of plans listedin the statute. On the other hand, planssuch as property and casualty insuranceplans and workers compensation plans,which may pay health care costs in thecourse of administering nonhealth carebenefits, are not considered to be healthplans in the proposed definition ofhealth plan. Of course, these plans mayvoluntarily adopt these standards fortheir own business needs. At some


future time, the Congress may choose toexpressly include some or all of theseplans in the list of health plans thatmust comply with the standards.

Health plans often carry out theirbusiness functions through agents, suchas plan administrators (including thirdparty administrators), entities that areunder ‘‘administrative services only’’(ASO) contracts, claims processors, andfiscal agents. These agents may or maynot be health plans in their own right;for example, a health plan acting asanother health plan’s agent as anotherline of business. As stated earlier, ahealth plan that conducts HIPAAtransactions through an agent isrequired to assure that the agent meetsall HIPAA requirements that apply tothe plan itself.

‘‘Health plan’’ includes the following,singly or in combination:

a. ‘‘Group health plan’’ (as currentlydefined by section 2791(a) of the PublicHealth Service Act). A group healthplan is a plan that has 50 or moreparticipants (as the term ‘‘participant’’ iscurrently defined by section 3(7) ofERISA) or is administered by an entityother than the employer that establishedand maintains the plan. This definitionincludes both insured and self-insuredplans. We define ‘‘participant’’separately below.

Section 2791(a)(1) of the PublicHealth Service Act defines ‘‘grouphealth plan’’ as an employee welfarebenefit plan (as defined in currentsection 3(1) of ERISA) to the extent thatthe plan provides medical care,including items and services paid for asmedical care, to employees or theirdependents directly or throughinsurance, or otherwise.

b. ‘‘Health insurance issuer’’ (ascurrently defined by section 2791(b) ofthe Public Health Service Act).

Section 2791(b) of the Public HealthService Act currently defines a ‘‘healthinsurance issuer’’ as an insurancecompany, insurance service, orinsurance organization that is licensedto engage in the business of insurancein a State and is subject to State law thatregulates insurance.

c. ‘‘Health maintenance organization’’(as currently defined by section 2791(b)of the Public Health Service Act).

Section 2791(b) of the Public HealthService Act currently defines a ‘‘healthmaintenance organization’’ as aFederally qualified health maintenanceorganization, an organization recognizedas such under State law, or a similarorganization regulated for solvencyunder State law in the same manner andto the same extent as such a healthmaintenance organization. Theseorganizations may include preferred

provider organizations, providersponsored organizations, independentpractice associations, competitivemedical plans, exclusive providerorganizations, and foundations formedical care.

d. Part A or Part B of the Medicareprogram (title XVIII of the Act).

e. The Medicaid program (title XIX ofthe Act).

f. A ‘‘Medicare supplemental policy’’as defined under section 1882(g)(1) ofthe Act.

Section 1882(g)(1) of the Act definesa ‘‘Medicare supplemental policy’’ as ahealth insurance policy that a privateentity offers a Medicare beneficiary toprovide payment for expenses incurredfor services and items that are notreimbursed by Medicare because ofdeductible, coinsurance, or otherlimitations under Medicare. Thestatutory definition of a Medicaresupplemental policy excludes a numberof plans that are generally considered tobe Medicare supplemental plans, suchas health plans for employees andformer employees and for members andformer members of trade associationsand unions. A number of these healthplans may be included under thedefinitions of ‘‘group health plan’’ or‘‘health insurance issuer’’, as defined inparagraphs a. and b. above.

g. A ‘‘long-term care policy,’’including a nursing home fixed-indemnity policy. A ‘‘long-term carepolicy’’ is considered to be a health planregardless of how comprehensive it is.We recognize the long-term careinsurance segment of the industry islargely unautomated and we welcomecomments regarding the impact ofHIPAA on the long-term care segment.

h. 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. This includes plans that arereferred to as multiple employer welfarearrangements (‘‘MEWAs’’).

i. The health care program for activemilitary personnel under title 10 of theUnited States Code.

j. The veterans health care programunder chapter 17 of title 38 of theUnited States Code.

This health plan primarily furnishesmedical care through hospitals andclinics administered by the Departmentof Veterans Affairs for veterans with aservice-connected disability that iscompensable. Veterans with nonservice-connected disabilities (and no otherhealth benefit plan) may receive healthcare under this health plan to the extentresources and facilities are available.

k. The Civilian Health and MedicalProgram of the Uniformed Services(CHAMPUS), as defined in 10 U.S.C.1072(4).

CHAMPUS primarily covers servicesfurnished by civilian medical providersto dependents of active duty members ofthe uniformed services and retirees andtheir dependents under age 65.

l. The Indian Health Service programunder the Indian Health CareImprovement Act (25 U.S.C. 1601 etseq.).

This program furnishes services,generally through its own health careproviders, primarily to persons who areeligible to receive services because theyare of American Indian or AlaskanNative descent.

m. The Federal Employees HealthBenefits Program under 5 U.S.C. chapter89.

This program consists of healthinsurance plans offered to active andretired Federal employees and theirdependents. Depending on the healthplan, the services may be furnished ona fee-for-service basis or through ahealth maintenance organization.

(Note: Although section 1171(5)(M) of theAct refers to the ‘‘Federal Employees HealthBenefit Plan,’’ this and any other rulesadopting administrative simplificationstandards will use the correct name, theFederal Employees Health Benefits Program.One health plan does not cover all Federalemployees; there are over 350 health plansthat provide health benefits coverage toFederal employees, retirees, and their eligiblefamily members. Therefore, we will use thecorrect name, the Federal Employees HealthBenefits Program, to make clear that theadministrative simplification standards applyto all health plans that participate in theProgram.)

n. Any other individual or grouphealth plan, or combination thereof, thatprovides or pays for the cost of medicalcare.

We would include a fourteenthcategory of health plan in addition tothose specifically named in HIPAA, asthere are health plans that do notreadily fit into the other categories butwhose major purpose is providinghealth benefits. The Secretary woulddetermine which of these plans arehealth plans for purposes of title II ofHIPAA. This category would includethe Medicare Plus Choice plans that willbecome available as a result of section1855 of the Act as amended by section4001 of the Balanced Budget Act of 1997(Public Law 105–33) to the extent thatthese health plans do not fall under anyother category.


6. Small Health PlanWe would define a ‘‘small health

plan’’ as a group health plan with fewerthan 50 participants.

The HIPAA does not define a ‘‘smallhealth plan’’ but instead leaves thedefinition to be determined by theSecretary. The Conference Reportsuggests that the appropriate definitionof a ‘‘small health plan’’ is found incurrent section 2791(a) of the PublicHealth Service Act, which is a grouphealth plan with fewer than 50participants. We would also definesmall individual health plans as thosewith fewer than 50 participants.

7. Individually Identifiable HealthInformation

Section 1171(6) states the term‘‘individually identifiable healthinformation’’ means any information,including demographic informationcollected from an individual, that—

a. Is created or received by a healthcare provider, health plan, employer, orhealth care clearinghouse; and

b. Relates to the past, present or futurephysical or mental health or conditionof an individual, the provision of healthcare to an individual, or the past,present, or future payment for theprovision of health care to anindividual, and

(i) Identifies the individual, or(ii) With respect to which there is a

reasonable basis to believe that theinformation can be used to identify theindividual.

8. StandardSection 1171 of the Act defines

‘‘standard,’’ when used with referenceto a data element of health informationor a transaction referred to in section1173(a)(1) of the Act, as any such dataelement or transaction that meets eachof the standards and implementationspecifications adopted or established bythe Secretary with respect to the dataelement or transaction under sections1172 through 1174 of the Act.

Under our definition, the securitystandard would be a set of requirementsadopted or established to preserve andmaintain the confidentiality and privacyof electronically stored, maintained, ortransmitted health informationpromulgated either by an organizationaccredited by the ANSI or HHS.

9. Transaction‘‘Transaction’’ would mean the

exchange of information between twoparties to carry out financial andadministrative activities related tohealth care. A transaction would be (a)any of the transactions listed in section1173(a)(2) of the Act, and (b) any

determined appropriate by the Secretaryin accordance with section 1173(a)(1)(B)of the Act. We present them below inthe order in which we propose to listthem in the regulations text.

A ‘‘transaction’’ would mean any ofthe following:

a. Health claims or equivalentencounter information. This transactionmay be used to submit health care claimbilling information, encounterinformation, or both, from health careproviders to payers, either directly orvia intermediary billers and claimsclearinghouses.

b. Health care payment andremittance advice. This transaction maybe used by a health plan to make apayment to a financial institution for ahealth care provider (sending paymentonly), to send an explanation of benefitsremittance advice directly to a healthcare provider (sending data only), or tomake payment and send an explanationof benefits remittance advice to a healthcare provider via a financial institution(sending both payment and data).

c. Coordination of benefits. Thistransaction set can be used to transmithealth care claims and billing paymentinformation between payers withdifferent payment responsibilities wherecoordination of benefits is required orbetween payers and regulatory agenciesto monitor the furnishing, billing, and/or payment of health care serviceswithin a specific health care/insuranceindustry segment.

In addition to the nine electronictransactions specified in section1173(a)(2) of the Act, section 1173(f)directs the Secretary to adopt standardsfor transferring standard data elementsamong health plans for coordination ofbenefits. This particular provision doesnot state that these should be standardsfor electronic transfer of standard dataelements among health plans. However,we believe that the Congress, whenwriting this provision, intended forthese standards to be an electronic formof transactions for coordination ofbenefits and sequential processing ofclaims. The Congress expressed itsintent on these matters generally insection 1173(a)(1)(B) of the Act, wherethe Secretary is directed to adopt ‘‘otherfinancial and administrativetransactions * * * consistent with thegoals of improving the operation of thehealth care system and reducingadministrative costs.’’

d. Health claim status. Thistransaction may be used by health careproviders and recipients of health careproducts or services (or their authorizedagents) to request the status of a healthcare claim or encounter from a healthplan.

e. Enrollment and disenrollment in ahealth plan. This transaction may beused to establish communicationbetween the sponsor of a health benefitand the payer. It provides enrollmentdata, such as subscriber anddependents, employer information, andprimary care health care providerinformation. A sponsor is the backer ofthe coverage, benefit, or product. Asponsor can be an employer, union,government agency, association, orinsurance company. The health planrefers to an entity that pays claims,administers the insurance product orbenefit, or both.

f. Eligibility for a health plan. Thistransaction may be used to inquireabout the eligibility, coverage, orbenefits associated with a benefit plan,employer, plan sponsor, subscriber, or adependent under the subscriber’spolicy. It also can be used tocommunicate information about orchanges to eligibility, coverage, orbenefits from information sources (suchas insurers, sponsors, and payers) toinformation receivers (such asphysicians, hospitals, third partyadministrators, and governmentagencies).

g. Health plan premium payments.This transaction may be used by, forexample, employers, employees, unions,and associations to make and keep trackof payments of health plan premiums totheir health insurers. This transactionmay also be used by a health careprovider, acting as liaison for thebeneficiary, to make payment to a healthinsurer for coinsurance, copayments,and deductibles.

h. Referral certification andauthorization. This transaction may beused to transmit health care servicereferral information between health careproviders, health care providersfurnishing services, and payers. It canalso be used to obtain authorization forcertain health care services from ahealth plan.

i. First report of injury. Thistransaction may be used to reportinformation pertaining to an injury,illness, or incident to entities interestedin the information for statistical, legal,claims, and risk management processingrequirements.

j. Health claims attachments. Thistransaction may be used to transmithealth care service information, such assubscriber, patient, demographic,diagnosis, or treatment data for thepurpose of a request for review,certification, notification, or reportingthe outcome of a health care servicesreview.

k. Other transactions as the Secretarymay prescribe by regulation.


Under section 1173(a)(1)(B) of theAct, the Secretary may adopt standards,and data elements for those standards,and for other financial andadministrative transactions deemedappropriate by the Secretary. Thesetransactions would be consistent withthe goals of improving the operation ofthe health care system and reducingadministrative costs.

C. Effective Dates—General

[Please label written comments or e-mailedcomments about this section with the subject:effective dates]

In general, any given standard wouldbe effective 24 months after the effectivedate (36 months for small health plans)of the final rule for that standard.Because there are other standards to beestablished than those in this proposedrule, we specify the date for a givenstandard under the subpart for thatstandard.

Health plans would be required bypart 142 to comply with ourrequirements as follows:

1. Each health plan that is not a smallplan would have to comply with therequirements of part 142 no later than24 months after the effective date of thefinal rule.

2. Each small health plan would haveto comply with the requirements of part142 no later than 36 months after theeffective date of the final rule.

Health care providers and health careclearinghouses would be required tobegin using the standard by 24 monthsafter the effective date of the final rule.(The effective date of the final rule willbe 60 days after the final rule ispublished in the Federal Register.)

Provisions of trading partneragreements that stipulate data content,format definitions, or conditions thatconflict with the adopted standardwould be invalid beginning 36 monthsfrom the effective date of the final rulefor small health plans, and 24 monthsfrom the effective date of the final rulefor all other health plans.

If the HHS adopts a modification to animplementation specification or astandard, the implementation date ofthe modification would be no earlierthan the 180th day following theadoption of the modification. HHSwould determine the actual date, takinginto account the time needed to complydue to the nature and extent of themodification. HHS would be able toextend the time for compliance for smallhealth plans. This provision would be at§ 142.106.

Any of the health plans, health careclearinghouses, and health careproviders may implement a given

standard earlier than the date specifiedin the subpart created for that standard.We realize that this may create someproblems temporarily, as earlyimplementers would have to be able tocontinue using old standards until thenew one must, by law, be in place.

D. Security Standard

[Please label written comments or e-mailedcomments about this section with the subject:Security Standard—General]

Section 142.308 would set forth thesecurity standard. There is norecognized single standard thatintegrates all the components of security(administrative procedures, physicalsafeguards, technical security services,and technical mechanisms) that must bein place to preserve health informationconfidentiality and privacy as definedin the law. Therefore, we aredesignating a new, comprehensivestandard, which defines the securityrequirements to be fulfilled.

In fact, there are numerous securityguidelines and standards in existencetoday, focusing on the differenttechniques available for implementingthe various aspects of security. Wethoroughly researched the existingguidelines and standards, and consultedextensively with the organizations thatdeveloped them. A list of theorganizations with which we consultedcan be found in section G. below. As aresult of these consultations and ourresearch, we identified several high-level concepts on which the standard isbased:

• The standard must becomprehensive.

• Consultation with standardsdevelopment organizations, such asANSI-accredited organizations, as wellas business interest organizations,revealed the need for a standard thataddressed all aspects of security in aconcerted fashion. The HISB noted in itsreport to the Secretary that:

‘‘Comprehensive adoption of securitystandards in health care, not piecemealimplementation, is advocated to providesecurity to data that is exchangedbetween health care entities.

By definition, if a system orcommunications between two systems,were implemented with technology(s)meeting standards in a general systemsecurity framework (Identification andAuthentication; Authorization andAccess Control; Accountability;Integrity and Availability; Security ofCommunication; and SecurityAdministration.) that system would beessentially secure.

* * * no single standardsdevelopment organization (SDO) isaddressing all aspects of health care

information security andconfidentiality, and specifically, nosingle SDO is developing standards thatcover every category of the securityframework.’’ [Page 189]

• The standard must be technology-neutral.

Our proposed standard does notreference or advocate specifictechnology because security technologyis changing quickly. We want to giveproviders/plans/clearinghousesflexibility to choose their own technicalsolutions. A standard that is dependenton a specific technology or technologieswould not be flexible enough to usefuture advances.

• The standard must be scalable.The standard must be able to be

implemented by all the affected entities,from the smallest provider to the largestclearinghouse. A single approach wouldbe neither economically feasible noreffective in safeguarding health data.For example, in a small physicianpractice, a contingency plan for systememergencies might be only a few pageslong, and cover issues such as wherebackup diskettes must be stored, and thelocation of a backup personal computer(PC). At a large health plan, thecontingency plan might consist ofmultiple volumes and cover issues suchas remote hot site operations and secureoff-site storage of electronic media. Thephysician office solution would notprotect the large plan’s data, and theplan’s solution would not beeconomically feasible (or necessary) forthe physician office. Moreover, thestatute specifically directed theSecretary to take into account the needsand capabilities of small and ruralhealth care providers, as those terms aredefined by the Secretary. The scalabilityof our approach addresses thisdirection. We are not proposing specificdefinitions of ‘‘small’’ and ‘‘rural’’health care providers because the statuteprovides no exemptions or specialbenefits for these two groups. However,we solicit comments on the necessity todefine these terms.

General ApproachWe would define the security

standard as a set of requirements withimplementation features that providers,plans, and clearinghouses must includein their operations to assure thatelectronic health information pertainingto an individual remains secure. Theimplementation features addressspecific aspects of the requirements.The standard does not reference oradvocate specific technology. Thiswould allow the security standard to bestable, yet flexible enough to takeadvantage of state-of-the-art technology.


The standard does not address theextent to which a particular entityshould implement the specific features.Instead, we would require that eachaffected entity assess its own securityneeds and risks and devise, implement,and maintain appropriate security toaddress its business requirements. Howindividual security requirements wouldbe satisfied and which technology to usewould be business decisions that eachorganization would have to make.

The recommendations contained inthe National Research Council’s 1997report For The Record: ProtectingElectronic Health Information supportour approach to the development of asecurity standard. This report presentsfindings and recommendations relatedto health data security, and is widelyviewed as an authoritative andcomprehensive source on the subject.The report concludes that appropriatesecurity practices are highly dependenton individual circumstances, but goeson to suggest that:

‘‘It is therefore not possible to prescribe indetail specific practices for all organizations;rather, each organization must analyze itssystems, vulnerabilities, risks, and resourcesto determine optimal security measures.Nevertheless, the committee believes that aset of practices can be articulated in asufficiently general way that they can beadopted by all health care organizations inone form or another.’’ (Page 168)

The specific requirements andsupporting implementation featuresdetailed in the next section representthis general set of practices. Manyhealth care entities have alreadyimplemented some or all of thesepractices. We believe they representthose practices that are necessary inorder to conduct business electronicallyin the health care industry today and,therefore, are normal business costs.

Inherent in this approach is a balancebetween the need to secure health dataagainst risk and the economic cost ofdoing so. Health care entities mustconsider both aspects in devising theirsecurity solutions.

Specific RequirementsThe proposed standard requires that

each health care entity engaged inelectronic maintenance or transmissionof health information assess potentialrisks and vulnerabilities to theindividual health data in its possessionin electronic form, and develop,implement, and maintain appropriatesecurity measures. Most importantly,these measures must be documentedand kept current.

The proposed security standardconsists of the requirements that ahealth care entity must address in order

to safeguard the integrity,confidentiality, and availability of itselectronic data. It also describes theimplementation features that must bepresent in order to satisfy eachrequirement. The proposedrequirements and implementationfeatures were developed by theimplementation team based onknowledge of security procedures andexisting standards and guidelinesdescribed above. This was an iterativeprocess that involved extensiveoutreach with a number of health careindustry and Department of Commercesecurity experts. We also drew uponRecommendations 1 and 3 in theNational Research Council’s 1997report, For The Record, that wererecommended for immediateimplementation.

‘‘Recommendation 1: Allorganizations that handle patient-identifiable health care information—regardless of size—should adopt the setof technical and organizational policies,practices, and procedures describedbelow to protect such information.’’

The proposed security standardaddresses the following policies,practices, and procedures that werelisted under Recommendation 1:• Organizational Practices

1. Security and confidentialitypolicies

2. Information security officers3. Education and training programs,

and4. Sanctions

• Technical Practices and Procedures1. Individual authentication of users2. Access controls3. Audit trails4. Physical security and disaster

recovery5. Protection of remote access points6. Protection of external electronic

communications7. Software discipline, and8. System assessment‘‘Recommendation 3: The federal

government should work with industryto promote and encourage an informedpublic debate to determine anappropriate balance between theprimary concerns of patients and theinformation needs of various users ofhealth care information.’’

This proposed security standard wasdeveloped in the spirit ofRecommendation 3. The securitystandard development process has beenan open one with invitations to anumber of organizations to participatein the security discussions. Althoughimplementation team membership waslimited to government employees,nongovernmental organizations;

business organizations; individualsknowledgeable in security; andeducational institutions have beenencouraged to express their views.

As a result of the collaborativesecurity regulation developmentprocess, the implementation team haschosen to divide the proposed securityrequirements, for purposes ofpresentation only, into the followingfour categories:

• Administrative procedures to guarddata integrity, confidentiality, andavailability—these are documented,formal practices to manage the selectionand execution of security measures toprotect data and the conduct ofpersonnel in relation to the protection ofdata.

• Physical safeguards to guard dataintegrity, confidentiality, andavailability—these relate to theprotection of physical computer systemsand related buildings and equipmentfrom fire and other natural andenvironmental hazards, as well as fromintrusion. Physical safeguards also coverthe use of locks, keys, andadministrative measures used to controlaccess to computer systems andfacilities.

• Technical security services to guarddata integrity, confidentiality, andavailability—these include theprocesses that are put in place to protectand to control and monitor informationaccess, and

• Technical security mechanisms—these include the processes that are putin place to prevent unauthorized accessto data that is transmitted over acommunications network.

It should be noted that the onlynecessity is that the requirements wouldbe met, not that they be presented inthese four categories. Under thisproposed rule, a business entity couldchoose to order the requirements in anymanner that suits its business.

We then determined the requirementsand implementation features that healthplans, providers, and clearinghouseswould implement. The implementationfeatures describe the requirements ingreater detail. Some requirements do notrequire this additional level of detail.Within the four categories, therequirements and implementationfeatures are presented in alphabeticalorder to ensure that no one item isconsidered to be more important thananother. The relative importance of therequirements and implementationfeatures would depend on thecharacteristics of each organization.

The four categories of the matrix aredescribed in greater detail in § 142.308and are depicted in tabular form alongwith the electronic signature standard in


a combined matrix located atAddendum 1. We have not included thematrix in the proposed regulation text.We invite your comments concerningthe appropriateness and usefulness ofincluding the matrix in the finalregulation text. We also solicitcomments as to the level of detailexpressed in requirementimplementation features; i.e., do anyrepresent a level of detail that goesbeyond what is necessary orappropriate. We have also provided aglossary of terms to facilitate a commonunderstanding of the matrix entries. The

glossary can be found at Addendum 2.Finally, we have included currentlyexisting standards and guidelinesmapped to the proposed securitystandard. This mapping is not allinclusive and is located at Addendum 3.

1. Administrative Procedures

[Please label written comments or e-mailedcomments about this section with the subject:administrative procedures]

In this proposed rule, theadministrative requirements andsupporting implementation features arepresented at § 142.308(a). We would

require each to be documented. Wewould require the documentation to bemade available to those individualsresponsible for implementing theprocedures and would require it to bereviewed and updated periodically. Thefollowing matrix depicts therequirements and supportingimplementation features for theAdministrative Procedures category.Following the matrix is a discussion ofeach of the requirements under thatcategory.

ADMINISTRATIVE PROCEDURES TO GUARD DATA INTEGRITY, CONFIDENTIALITY, AND AVAILABILITY

Requirement Implementation

CertificationChain of trust partner agreementContingency plan (all listed implementation features must be imple-

mented).Applications and data criticality analysis.Data backup plan.Disaster recovery plan.Emergency mode operation plan.Testing and revision.

Formal mechanism for processing recordsInformation access control (all listed implementation features must be

implemented).Access authorization.Access establishment.Access modification.

Internal auditPersonnel security (all listed implementation features must be imple-

mented).Assure supervision of maintenance personnel by authorized, knowl-

edgeable person.Maintenance of record of access authorizations.Operating, and in some cases, maintenance personnel have proper ac-

cess authorization.Personnel clearance procedure.Personnel security policy/procedure.System users, including maintenance personnel, trained in security.

Security configuration mgmt. (all listed implementation features must beimplemented).

Documentation.Hardware/software installation & maintenance review and testing for

security features.Inventory.Security Testing.Virus checking.

Security incident procedures (all listed implementation features must beimplemented).

Report procedures.Response procedures.

Security management process (all listed implementation features mustbe implemented).

Risk analysis.Risk management.Sanction policy.Security policy.

Termination procedures (all listed implementation features must be im-plemented).

Combination locks changed.Removal from access lists.Removal of user account(s).Turn in keys, token or cards that allow access.

Training (all listed implementation features must be implemented) ........ Awareness training for all personnel (including mgmt)Periodic security reminders.User education concerning virus protection.User education in importance of monitoring log in success/failure, and

how to report discrepancies.User education in password management

a. Certification. Each organizationwould be required to evaluate itscomputer system(s) or network design(s)to certify that the appropriate securityhas been implemented. This evaluationcould be performed internally or by anexternal accrediting agency.

We are, at this time, soliciting inputon appropriate mechanisms to permitindependent assessment of compliance.We would be particularly interested ininput from those engaging in health careelectronic data interchange (EDI), aswell as independent certification andauditing organizations addressing issues

of documentary evidence of steps takenfor compliance; need for, or desirabilityof, independent verification, validation,and testing of system changes; andcertifications required for off-the-shelfproducts used to meet the requirementsof this regulation.


We also solicit comments on theextent to which obtaining externalcertification would create an undueburden on small or rural providers.

b. Chain of Trust Partner Agreement.If data are processed through a thirdparty, the parties would be required toenter into a chain of trust partneragreement. This is a contract in whichthe parties agree to electronicallyexchange data and to protect thetransmitted data. The sender andreceiver are required and depend uponeach other to maintain the integrity andconfidentiality of the transmittedinformation. Multiple two-partycontracts may be involved in movinginformation from the originating partyto the ultimate receiving party. Forexample, a provider may contract witha clearinghouse to transmit claims to theclearinghouse; the clearinghouse, inturn, may contract with anotherclearinghouse or with a payer for thefurther transmittal of those claims.These agreements are important so thatthe same level of security will bemaintained at all links in the chainwhen information moves from oneorganization to another.

c. Contingency Plan. We wouldrequire a contingency plan to be ineffect for responding to systememergencies. The organization would berequired to perform periodic backups ofdata, have available critical facilities forcontinuing operations in the event of anemergency, and have disaster recoveryprocedures in place. To satisfy therequirement, the plan would include thefollowing:

• Applications and data criticalityanalysis,

• A data backup plan,• A disaster recovery plan,• An emergency mode operation

plan, and• Testing and revision procedures.d. Formal Mechanism for Processing

Records There would be a formalmechanism for processing records, thatis, documented policies and proceduresfor the routine and nonroutine receipt,manipulation, storage, dissemination,transmission, and/or disposal of healthinformation. This is important to limitthe inadvertent loss or disclosure ofsecure information because of processissues.

e. Information Access Control. Anentity would be required to establishand maintain formal, documentedpolicies and procedures for grantingdifferent levels of access to health careinformation. To satisfy this requirement,the following features would beprovided:

• Access authorization policies andprocedures.

• Access establishment policies andprocedures.

• Access modification policies andprocedures.

Access control is also discussed laterin this document in the personnelsecurity requirement and under thephysical safeguards, technical securityservices, and technical securitymechanisms categories.

f. Internal Audit. There would be arequirement for an ongoing internalaudit process, which is the in-housereview of the records of system activity(for example, logins, file accesses,security incidents) maintained by anentity. This is important to enable theorganization to identify potentialsecurity violations.

g. Personnel Security. There would bea requirement that all personnel withaccess to health information must beauthorized to do so after receivingappropriate clearances. This isimportant to prevent unnecessary orinadvertent access to secureinformation. The personnel securityrequirement would require entities tomeet the following conditions:

• Assure supervision of personnelperforming technical systemsmaintenance activities by authorized,knowledgeable persons.

• Maintain access authorizationrecords.

• Insure that operating, and in somecases, maintenance personnel haveproper access.

• Employ personnel clearanceprocedures

• Employ personnel security policy/procedures.

• Ensure that system users, includingtechnical maintenance personnel aretrained in system security.

h. Security ConfigurationManagement. The organization wouldbe required to implement measures,practices, and procedures for thesecurity of information systems. Thesewould be coordinated and integratedwith other system configurationmanagement practices in order to createand manage system integrity. Thisintegration process is important toensure that routine changes to systemhardware and/or software do notcontribute to or create securityweaknesses. This requirement wouldinclude the following:

• Documentation.• Hardware/software installation and

maintenance review and testing forsecurity features.

• Inventory procedures.• Security testing.• Virus checking.i. Security Incident Procedures. There

would be a requirement to implement

accurate and current security incidentprocedures. These are formal,documented instructions for reportingsecurity breaches, so that securityviolations are reported and handledpromptly. These instructions wouldinclude the following:

• Report procedures.• Response procedures.j. Security Management Process. A

process for security management wouldbe required. This involves creating,administering, and overseeing policiesto ensure the prevention, detection,containment, and correction of securitybreaches. We would require theorganization to have a formal securitymanagement process in place to addressthe full range of security issues. Securitymanagement includes the followingmandatory implementation features:

• Risk analysis.• Risk management.• A sanction policy.• A security policy.k. Termination Procedures. There

would be a requirement to implementtermination procedures, which areformal, documented instructions,including appropriate securitymeasures, for the ending of anemployee’s employment or an internal/external user’s access. These proceduresare important to prevent the possibilityof unauthorized access to secure data bythose who are no longer authorized toaccess the data. Termination procedureswould include the following mandatoryimplementation features:

• Changing combination locks.• Removal from access lists.• Removal of user account(s).• Turn in of keys, tokens, or cards

that allow access.1. Training. This proposed rule would

require security training for all staffregarding the vulnerabilities of thehealth information in an entity’spossession and procedures which mustbe followed to ensure the protection ofthat information. This is importantbecause employees need to understandtheir security responsibilities and makesecurity a part of their day-to-dayactivities. The implementation featuresthat would be required to beincorporated follow:

• Awareness training for allpersonnel, including management, (thisis also included as a requirement underphysical safeguards).

• Periodic security reminders.• User education concerning virus

protection.• User education in importance of

monitoring login success/failure, andhow to report discrepancies.

• User education in passwordmanagement.


2. Physical Safeguards To Guard DataIntegrity, Confidentiality, andAvailability

[Please label written comments or e-mailedcomments about this section with the subject:Physical Safeguards]

The requirements andimplementation features for physicalsafeguards are presented at § 142.308(b)of this proposed rule. We would requireeach of these safeguards to bedocumented. We would require thisdocumentation to be made available tothose individuals responsible for

implementing the safeguards and to bereviewed and updated periodically. Thefollowing matrix depicts therequirements and implementationfeatures for the Physical Safeguardscategory. Following the matrix is adiscussion of each of the requirementsunder that category.

PHYSICAL SAFEGUARDS TO GUARD DATA INTEGRITY, CONFIDENTIALITY, AND AVAILABILITY


Assigned security responsibilityMedia controls (all listed implementation features must be imple-

mented).Access control.Accountability (tracking mechanism).Data backup.Data storage.Disposal.

Physical access controls (limited access) (all listed implementation fea-tures must be implemented).

Disaster recovery.Emergency mode operation.Equipment control (into and out of site).Facility security plan.Procedures for verifying access authorizations prior to physical access.Maintenance records.Need-to-know procedures for personnel access.Sign-in for visitors and escort, if appropriate.Testing and revision.

Policy/guideline on work station useSecure work station locationSecurity awareness training.

a. Assigned Security Responsibility.We would require the securityresponsibility to be assigned to aspecific individual or organization, andthe assignment be documented. Theseresponsibilities would include themanagement and supervision of (1) theuse of security measures to protect data,and (2) the conduct of personnel inrelation to the protection of data. Thisassignment is important to provide anorganizational focus and importance tosecurity and to pinpoint responsibility.

b. Media Controls. Media controlswould be required in the form of formal,documented policies and proceduresthat govern the receipt and removal ofhardware/software (for example,diskettes, tapes) into and out of afacility. They are important to ensuretotal control of media containing healthinformation. These controls wouldinclude the following mandatoryimplementation features:

• Controlled access to media.• Accountability (tracking

mechanism).• Data backup.• Data storage.• Disposal.c. Physical Access Controls. Physical

access controls (limited access) wouldbe required. These would be formal,documented policies and procedures forlimiting physical access to an entitywhile ensuring that properly authorizedaccess is allowed. These controls wouldbe extremely important to the security

of health information by preventingunauthorized physical access toinformation and ensuring thatauthorized personnel have properaccess. These controls would includethe following mandatoryimplementation features:

• Disaster recovery.• Emergency mode operation.• Equipment control (into and out of

site).• A facility security plan.• Procedures for verifying access

authorizations prior to physical access.• Maintenance records.• Need-to-know procedures for

personnel access.• Sign-in for visitors and escort, if

appropriate.• Testing and revision.d. Policy/Guideline on Workstation

Use. Each organization would berequired to have a policy/guideline onworkstation use. These documentedinstructions/procedures woulddelineate the proper functions to beperformed and the manner in whichthose functions are to be performed (forexample, logging off before leaving aterminal unattended). This would beimportant so that employees willunderstand the manner in whichworkstations must be used to maximizethe security of health information.

e. Secure Workstation Location. Eachorganization would be required to put inplace physical safeguards to eliminateor minimize the possibility of

unauthorized access to information.This would be important especially inpublic buildings, provider locations,and in areas where there is heavypedestrian traffic.

f. Security Awareness Training.Security awareness training would berequired for all employees, agents, andcontractors. This would be importantbecause employees would need tounderstand their securityresponsibilities based on their jobresponsibilities in the organization andmake security a part of their dailyactivities.

3. Technical Security Services To GuardData Integrity, Confidentiality, andAvailability

[Please label written comments or e-mailedcomments about this section with the subject:Technical Security Services]

The proposed requirements andimplementation features for technicalsecurity services are presented at§ 142.308(c). We would require each ofthese services to be implemented anddocumented. The documentation wouldbe made available to those individualsresponsible for implementing theservices and would be reviewed andupdated periodically. The followingmatrix depicts the requirements andimplementation features for theTechnical Security Services category.Following the matrix is a discussion of


each of the requirements under thatcategory.

TECHNICAL SECURITY SERVICES TO GUARD DATA INTEGRITY, CONFIDENTIALITY, AND AVAILABILITY


Access control (The following implementation feature must be imple-mented: Procedure for emergency access. In addition, at least one ofthe following three implementation features must be implemented:Context-based access, Role-based access, User-based access. Theuse of Encryption is optional).

Context-based access.Encryption.Procedure for emergency access.Role-based access.User-based access.

Audit controlsAuthorization control (At least one of the listed implementation features

must be implemented).Role-based access.User-based access.

Data AuthenticationEntity authentication (The following implementation features must be

implemented: Automatic logoff, Unique user identification. In addition,at least one of the other listed implementation features must be im-plemented).

Automatic logoff.Biometric.Password.PIN.Telephone callback.Token.Unique user identification.

a. Access Control. There would be arequirement for access control whichwould restrict access to resources andallow access only by privileged entities.It would be important to limit access tohealth information to those employeeswho have a business need to access it.Types of access control include, amongothers, mandatory access control,discretionary access control, time-of-day, classification, and subject-objectseparation. The followingimplementation feature would be used:

• Procedure for emergency access.In addition, at least one of the

following three implementation featureswould be used:

• Context-based access.• Role-based access.• User-based access.The use of the encryption

implementation feature would beoptional.

b. Audit Controls. Each organizationwould be required to put in place auditcontrol mechanisms to record andexamine system activity. They would beimportant so that the organization canidentify suspect data access activities,assess its security program, and respondto potential weaknesses.

c. Authorization Control. There wouldbe a requirement to put in place amechanism for obtaining consent for the

use and disclosure of healthinformation. These controls would benecessary to ensure that healthinformation is used only by properlyauthorized individuals. Either of thefollowing implementation features maybe used:

• Role-based access.• User-based access (see access

control, above.).d. Data Authentication. Each

organization would be required to beable to provide corroboration that datain its possession has not been altered ordestroyed in an unauthorized manner.Examples of how data corroborationmay be assured include the use of acheck sum, double keying, a messageauthentication code, or digital signature.

e. Entity Authentication. Eachorganization would be required toimplement entity authentication, whichis the corroboration that an entity iswho it claims to be. Authenticationwould be important to prevent theimproper identification of an entity whois accessing secure data. The followingimplementation features would be used:

• Automatic log off.• Unique user identification.In addition, at least one of the

following implementation featureswould be used:

• A biometric identification system.

• A password system.

• A personal identification number(PIN).

• Telephone callback.

• A token system which uses aphysical device for user identification.

4. Technical Security Mechanisms ToGuard Against Unauthorized Access toData That Is Transmitted Over aCommunications Network

[Please label written comments or e-mailedcomments about this section with the subject:Technical Security Mechanisms]

In this proposed rule, therequirements and implementationfeatures for technical securitymechanisms are presented at§ 142.308(d). Each of these mechanismswould need to be documented. Thedocumentation would be made availableto those individuals responsible forimplementing the mechanisms andwould be reviewed and updatedperiodically. The following matrixdepicts the requirement andimplementation features for theTechnical Security Mechanismscategory. Following the matrix is adiscussion of the requirement underthat category.


TECHNICAL SECURITY MECHANISMS TO GUARD AGAINST UNAUTHORIZED ACCESS TO DATA THAT IS TRANSMITTED OVER ACOMMUNICATIONS NETWORK


Communications/network controls (If communications or networking isemployed, the following implementation features must be imple-mented: Integrity controls, Message authentication. In addition, oneof the following implementation features must be implemented: Ac-cess controls, Encryption. In addition, if using a network, the follow-ing four implementation features must be implemented: Alarm, Audittrail, Entity authentication, Event reporting).

Access controls.Alarm.Audit trail.Encryption.Entity authentication.Event reporting.Integrity controls.Message authentication.

Each organization that usescommunications or networks would berequired to protect communicationscontaining health information that aretransmitted electronically over opennetworks so that they cannot be easilyintercepted and interpreted by partiesother than the intended recipient, and toprotect their information systems fromintruders trying to access systemsthrough external communication points.When using open networks, some formof encryption should be employed. Theutilization of less open systems/networks such as those provided by avalue-added network (VAN) or private-wire arrangement provides sufficientaccess controls to allow encryption to bean optional feature. These controlswould be important because of thepotential for compromise of informationover open systems such as the Internetor dial-in lines.

The following implementationfeatures would be in place:

• Integrity controls.• Message authentication.One of the following implementation

features would be in place:• Access controls.• Encryption.In addition, if using a network for

communications, the followingimplementation features would be inplace:

• Alarm.• Audit trail.• Entity authentication.• Event reporting.Small or Rural Provider Example. The

size and organizational structure of theentities that would be required toimplement this standard varytremendously. Therefore, it would beimpossible to provide examples thatwould cover every possibleimplementation of security in the healthcare industry. Nevertheless, we haveincluded an example describing themanner in which a small or ruralprovider might choose to implement therequirements of the standard. (Forpurposes of this example, we woulddescribe a small or rural provider as a

one to four physician office, with two tofive additional employees. The officeuses a PC-based practice managementsystem, which is used to communicateintermittently with a clearinghouse forsubmission of electronic claims. Thenumber of providers is of lessimportance for this example than therelatively simple technology in use andthe fact that there is insufficient volumeor revenue to justify employment of acomputer system administrator.) Wewant to emphasize that there arenumerous ways in which an entitycould implement these requirementsand features. This example does notnecessarily represent the best way or theonly way in which an entity couldchoose to implement security.

We anticipate that the small or ruralprovider office, as described above,would normally evaluate and self-certifythat the appropriate security is in placefor its computer system and officeprocedures. This evaluation could bedone by a knowledgeable person on thestaff, or more likely, by a consultant orby the vendor of the practicemanagement system as a service to itscustomers. First, the office might assessactual and potential risks to itsinformation assets. Then, to establishappropriate security, the office woulddevelop policies and procedures tomitigate and manage those risks. Thesewould include an overall frameworkoutlining information security activitiesand responsibilities, and repercussionsfor failure to meet those responsibilities.

Next, this office might developcontingency plans to reduce or negatethe damage resulting from processinganomalies; for example, establish aroutine process for maintaining back upfloppy disks at a second location, obtaina PC maintenance contract, and arrangefor use of a backup PC should the needarise. This office would need toperiodically review its plan todetermine whether it still met theoffice’s needs.

The office would need to create anddocument a personnel security policyand procedures to be followed. A key

individual on the office staff should becharged with the responsibility forassuring the Personnel Securityrequirement is met. This responsibilitywould include seeing that the accessauthorization levels granted aredocumented and kept current (forexample, records are kept of everyonewho is permitted to use the PC and whatfiles they may access), and training allpersonnel in security. Again, weemphasize that these requirements arescalable. The requirement for PersonnelClearance Procedures could be met in asmall office with standard personal andprofessional reference checks, while alarge organization may employ moreformal, rigorous backgroundinvestigations.

This same individual could also becharged with the responsibility forSecurity Configuration Management andTermination Procedures. For our smallprovider, the Security ConfigurationManagement requirement would berelatively easy to satisfy; the necessaryfeatures could be part of a purchasedhardware/software package (forexample, a new PC might be equippedwith virus checking software), orincluded as part of the support suppliedwith the purchase of equipment andsoftware. Termination procedureswould incorporate specific securityactions to be taken as a result of anemployee’s termination, such asobtaining all keys and changingcombinations or passwords. A ‘‘positiondescription’’ document describing thisperson’s duties could specify the levelof detail necessary.

The small or rural provider officewould also need to ensure that theyhave activated the internal auditingcapability of the software used tomanage health data files so that it trackswho has accessed the data. (We expectthat the capability of keeping audit trailswill become standard in all health caresoftware in the near future, spurred onby the health information privacydebates in the Congress and elsewhere.)

A small or rural provider maydocument compliance with many of the


foregoing administrative securityrequirements by including them in an‘‘office procedures’’ type of documentthat should be required reading by newemployees and always available forreference. Requirements that wouldlend themselves to inclusion in an‘‘office procedures’’ document include:contingency plans, formal recordsprocessing procedures, informationaccess controls (rules for grantingaccess, actual establishment of access,and procedures for modifying suchaccess), security incident procedures(for example, who is to be notified if itappears that medical information hasbeen accessed by an unauthorizedparty), and training. Periodic securityreminders could include visual aids,such as posters and screen savers, andoral reminders in recurring meetings.

Physical Access controls would berelatively straightforward for this smallor rural office, using locked rooms and/or closets to secure equipment andmedia from unauthorized access. The‘‘office procedures/policies’’ manualshould include directions forauthorizing access and keeping recordsof authorized accesses. Media Controlsand Workstation Use policy instructionswould be developed by the office andwould include additional instructionson such items as where to store backed-up data, how to dispose of data nolonger needed, or logging off whenleaving terminals unattended.

Safeguards for the security ofworkstation location(s) would dependupon the physical surroundings in thesmall or rural office. Our small or ruralprovider may meet the requirements bylocating equipment in areas that aregenerally populated by office staff andhave some degree of physical separationfrom the public. Security AwarenessTraining would be part of the newemployee orientation process andwould be a periodic recurringdiscussion item in staff meetings.

The Technical Security Servicesrequirements for Access Control, EntityAuthentication, and AuthorizationControl may be achieved simply byimplementing a user-based data accessmodel (assigning a user-name andpassword combination to eachauthorized employee). Other access

models could be employed if desired,but would prove unwieldy for the smalloffice. For example, the role-basedaccess process groups users with similardata access needs, and context-basedaccess is based upon the context of atransaction—not on the attributes of theinitiator. By assigning full access rightsto a minimum of two key individuals inthe office, implementation of theEmergency Access feature could besatisfied. Audit control mechanisms, bynecessity, would be provided bysoftware featuring that capability. Byestablishing and using a messageauthentication code, DataAuthentication would be achieved. Useof the password system mentionedabove could also satisfy the Unique UserIdentification requirement.

As our example provider contractswith a third party to handle claimsprocessing, the claims processingcontract would be the vehicle to providefor a chain of trust (requiring thecontractor to implement the samesecurity requirements and takeresponsibility for protecting the data itreceives).

If this provider chooses to use theInternet to transmit or receive healthinformation, some form of encryptionmust be used. For example, the providercould procure and use commercialsoftware to provide protection againstunauthorized access to the datatransmitted or received. (This decisionmust take into account what encryptionsystem the message recipient uses.) Onthe other hand, health informationwhen transmitted via other means suchas VANs, private wires, or even dial-upconnections may not require suchabsolute protection as is provided byencryption. This small or rural providerwould likely not be part of a networkconfiguration, therefore, only integritycontrols and message authenticationwould be required and could beprovided by currently available softwareproducts, most likely provided as part oftheir contract with their health careclearinghouse.

Small providers may need guidanceregarding the content of the documentsrequired by this rule (for example,specifics of a chain of trust partneragreement). We would expect models of

the documentation discussed in thisexample to be developed by industryassociations and vendors. If this modeldocumentation is not developed, DHHSwould work with the industry todevelop them.

E. Electronic Signature Standard

[Please label written comments or e-mailedcomments about this section with the subject:Electronic Signature Standard]

HIPAA directs the Secretary of theDepartment of Health and HumanServices to coordinate with theSecretary of the Department ofCommerce in adopting standards for theelectronic transmission andauthentication of signatures withrespect to the transactions referred to inthe law. This rule was developed incoordination with the Department ofCommerce’s National Institute ofStandards and Technology. We proposeto adopt a cryptographically baseddigital signature as the standard.

Whenever a HIPAA specifiedtransaction requires the use of anelectronic signature, the standard mustbe used. It should be noted that anelectronic signature is not required forany of the currently proposed standardtransactions.

In the electronic environment, thesame legal weight associated with anoriginal signature on a paper documentmay be needed for electronic data. Useof an electronic signature refers to theact of attaching a signature by electronicmeans. The electronic signature processinvolves authentication of the signer’sidentity, a signature process accordingto system design and softwareinstructions, binding of the signature tothe document and non-alterability afterthe signature has been affixed to thedocument. The generation of electronicsignatures requires the successfulidentification and authentication of thesigner at the time of the signature.

The proposed standard for electronicsignature is presented at § 142.310 andwould be digital.

The following matrix depicts therequirement and implementationfeatures for electronic signatures.Following the matrix is a discussion ofthe electronic signature requirement.


ELECTRONIC SIGNATURE


Digital signature (If digital signature is employed, the following three im-plementation features must be implemented: Message integrity, Non-repudiation, User authentication. Other implementation features areoptional).

Ability to add attributes.Continuity of signature capability.Countersignatures.Independent verifiability.Interoperability.Message integrity.Multiple Signatures.Nonrepudiation.Transportability.User authentication.

Various technologies may fulfill oneor more of the requirements specified inthe matrix. Authentication systems(passwords, biometrics, physical featureauthentication, behavioral actions andtoken-based authentication) can becombined with cryptographictechniques to form an electronicsignature. However, a completeelectronic signature system may requiremore than one of the technologiesmentioned above. If electronicsignatures would be used, certainimplementation features must beincluded, specifically:

• Message integrity.• Nonrepudiation.• User authentication.Currently there are no technically

mature techniques that provide thesecurity service of nonrepudiation in anopen network environment, in theabsence of trusted third parties, otherthan digital signature-based techniques.Therefore, if electronic signatures areemployed, we would require that digitalsignature technology be used. A digitalsignature is formed by applying amathematical function to the electronicdocument. This process yields a uniquebit string, referred to as a messagedigest. The digest (only) is encryptedusing the originator’s private key andthe resulting bit stream is appended tothe electronic document. The recipientof the transmitted document decryptsthe message digest with the originator’spublic key, applies the same messagehash function to the document, thencompares the resulting digest with thetransmitted version. If they areidentical, then the recipient is assuredthat the message is unaltered and theidentity of the signer is proven. Sinceonly the signatory authority can holdthe Private Key used to digitally sign thedocument, the critical feature ofnonrepudiation is enforced. Otherelectronic signature implementationfeatures that may be used follow:

• Ability to add attributes.• Continuity of signature capability.• Countersignatures capability.• Independent verifiability.

• Interoperability.• Multiple signatures.• Transportability.This standard is described in greater

detail in § 142.310 of the regulation textand is depicted in tabular form alongwith the security standard in acombined matrix located at Addendum1. We have not included the matrix inthe proposed regulation text. We inviteyour comments concerning theappropriateness and usefulness ofincluding the matrix in the finalregulation text. We have also provideda glossary of terms to facilitate acommon understanding of the matrixentries. The glossary can be found atAddendum 2. Finally, we have includedcurrently existing standards andguidelines mapped to the proposedelectronic signature standard. Thismapping is not all inclusive and islocated at Addendum 3.

F. Selection Criteria

Each individual implementation teamweighted the criteria described insection I.B. above, Process forDeveloping National Standards, in termsof the standard it was addressing. As weassessed security and electronicsignatures, it became apparent thatwhile the security standard set forth in§ 142.308 and the electronic signaturestandard set forth in § 142.310 satisfy allthe criteria described above, they moststrongly address criteria 1, 3, 7, 9, and10. These criteria are described below inthe specific context of these standards.

1. Improve the efficiency andeffectiveness of the health care system.

The security and electronic signaturestandards would be integrated with theelectronic transmission of health careinformation to improve the overalleffectiveness of the health care system.This integration would assure thatelectronic health care informationwould not be accessible to anyunauthorized person or organization,but would be both accurate andavailable to those who are authorized toreceive it.

3. Be consistent and uniform with theother HIPAA standards and, secondly,with other private and public sectorhealth data standards.

The security and electronic signaturestandards were developed after acomprehensive review of existingstandards and guidelines, withsignificant input by a wide range ofindustry experts. As indicated inAddendum 3, the standards map well toexisting standards and guidelines.

7. Be technologically independent ofcomputer platforms and transmissionprotocols.

We have defined the security andelectronic signature standards in termsof requirements that would allowbusinesses in the health care industry toselect the technology that best meetstheir business requirements while stillallowing them to comply with thestandards.

9. Keep data collection andpaperwork burdens on users as low asis feasible.

The security and electronic signaturestandards would allow individualhealth care industry businesses toascertain the level of securityinformation that would be needed. Theconfidentiality level associated withindividual data elements concerninghealth care information woulddetermine the appropriate securityapplication to be used. The securitystandard would define the requirementsto be met to achieve the privacy andconfidentiality goal, but each businessentity, driven by its businessrequirements, would decide whattechniques and controls would provideappropriate and adequate electronicdata protection. This would allow datacollection and the paperwork burden tobe as low as is feasible.

10. Incorporate flexibility to adaptmore easily to changes in the health careinfrastructure and informationtechnology.

A technologically neutral securitystandard would be more adaptable tochanges in infrastructure andinformation technology.


G. Consultations

In the development of the securityand electronic signature standards, weconsulted with many organizations,including those the legislation requires(section 1172(c)(3)(B) of the Act):

1. The NCVHS held two days ofpublic hearings on security issues inAugust 1997, and made arecommendation to the Secretary ofHHS, as required by the legislation. TheNCVHS recommendation to theSecretary of HHS, as required by thelegislation, was for a technologicallyneutral standard. It identified certaincriteria to be established for a healthinformation system to be secure. Theproposed security standard complieswith the NCVHS securityrecommendation.

2. The ANSI Accredited StandardsCommittee (ASC) X12 subcommitteeson communication and control,insurance and government werecontacted. Their current standardsdevelopment effort is focused onmessaging rather than on securityrequirements.

3. American Society for Testing andMaterials (ASTM), Committee E31 onComputerized Systems participated inthe security discussions.

4. Association for Electronic HealthCare Transactions (AFEHCT), theclearinghouse organization, providedinformation on its health caretransaction process requirements andemphasized that the security standardmust be adaptable to different businessneeds.

5. Computer-based Patient RecordInstitute (CPRI) was consulted becausethe Work Group on Confidentiality,Privacy and Security is working on theestablishment of guidelines,confidentiality agreements, securityrequirements, and frameworks. CPRIworks closely with accredited standardsdevelopment organizations.

6. Health Level Seven (HL–7) hasbeen contacted through its participationat the HISB meetings.

7. NUCC and the NUBC were apprisedof the different implementation teams’efforts. NUBC has not addressedsecurity issues at any of the publicmeetings. NUCC identified a number ofissues at its November 18–19 meetingand provided written comments to us.

H. Rules for Security Standards andElectronic Signature Standard

1. Health Plansa. In § 142.306(a), we would require

health plans to accept and apply thesecurity standard to all health careinformation pertaining to an individualthat is electronically maintained or

electronically transmitted. Federalagencies and States may placeadditional requirements on their healthplans. In addition, trading partners maymutually agree to implement additionalsecurity measures.

b. In § 142.310(a), entities would notbe required to use an electronicsignature. However, if a plan elects touse an electronic signature in one of thetransactions named in the law, it wouldbe required to apply the electronicsignature standard described in§ 142.310(b) to that transaction. In thefuture, we anticipate that the standardsfor other transactions may includerequirements for signatures. Inparticular, the proposed standard forclaims attachments, which will beissued in a separate regulations packagelater, may include signaturerequirements on some or all of theattachments. If the proposedattachments standard includes suchsignature requirements, we will addressthe issue of how to reconcile suchrequirements with existing State andFederal requirements for writtensignatures as part of the proposed rule.

2. Health Care Clearinghouses

a. We would require in § 142.306(b)that each health care clearinghousecomply with the security standard toensure all health care information andactivities are protected fromunauthorized access. If theclearinghouse is part of a largerorganization, then security must beimposed to prevent unauthorized accessby the larger organization. The securitystandards apply to all healthinformation pertaining to an individualthat is electronically maintained orelectronically transmitted.


3. Health Care Providersa. In § 142.306(a), we would require

each health care provider to apply thesecurity standard to all healthinformation pertaining to an individualthat is electronically maintained orelectronically transmitted.


I. Effective DatesHealth plans would be required to

comply with the security and electronicsignature standards as follows:

1. Each health plan that is not a smallhealth plan would have to comply withthe requirements of §§ 142.306, 142.308,and 142.310 no later than 24 monthsafter publication of the final rule.

2. Each small health plan would haveto comply with the requirements of§§ 142.306, 142.308, and 142.310 nolater than 36 months after the date ofpublication of the final rule.

3. If the effective date for theelectronic transaction standards is laterthan the effective date for the securitystandard, implementation of thesecurity standard would not be delayeduntil the standard transactions are inuse. The security standard would stillbe effective with respect toelectronically stored or maintained data.Security of health information wouldnot be solely tied to the standardtransactions but would apply to allindividual health informationelectronically stored, maintained, ortransmitted.

4. Under this proposed rule, in somecases, a health plan could choose toconvert from paper to standard EDItransactions prior to the effective date ofthe security standard. We wouldrecommend that the security standardbe implemented at that time in order tosafeguard the data in those transactions.We invite comments on this issue.


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

We are not proposing anyenforcement procedures at this time, butwe plan to do so in a future FederalRegister document once the industryhas some experience with using thestandards. These procedures will be inplace by the time the standards areimplemented by industry. We envisionthe monitoring and enforcement processas a partnership between the Federalgovernment and the private sector.Some private accreditation bodies havealready exhibited interest in certifyingcompliance with the securityrequirements as part of theiraccreditation reviews. Small providersmay be able to self-certify throughindustry-developed checklists. HHSwould likely retain the finalresponsibility for determining violationsand imposing the penalties specified bythe statute. We welcome comments onthis approach.

III. ImplementationIf an entity elects to use an electronic

signature in a transaction, or if anelectronic signature is required by atransaction standard adopted by theSecretary, the entity must apply theelectronic signature standard describedin § 142.310(b).

How the security standard would beimplemented is dependent uponindustry trading partner agreements forelectronic transmissions. The healthcare industry would be able to adapt thesecurity matrix to meet its businessneeds. We propose that therequirements of the security standard beimplemented over time. However, wewould require implementation to becomplete by the applicable effectivedate. We would encourage, but notrequire that entities comply with thesecurity standard as soon as practicable,preferably before implementing thetransactions standards.

The security standard wouldsupersede contrary provisions of Statelaw including State law requiringmedical or health plan records to bemaintained or transmitted in otherelectronic formats. There are certainexceptions when the standards wouldnot supersede contrary provisions ofState law; section 1178 identifies thoseconditions and directs the Secretary todetermine whether a particular State

provision falls within one or more of theexceptions.

The electronic signature standard(digital signature) would be deemed tosatisfy Federal and State statutoryrequirements for written signatures withrespect to the named transactionsreferred to in the legislation.

Several accreditation organizationssuch as the Electronic HealthcareNetwork Accreditation Commission(EHNAC), the Joint Commission onAccreditation of HealthcareOrganizations (JCAHO), and theNational Committee for QualityAssurance (NCQA), indicate that one oftheir accreditation requirements will becompliance with the HIPAA securityand electronic signature (if applicable)standards.

IV. New and Revised Standards

To encourage innovation and promotedevelopment, we plan to establish aprocess to allow an organization torequest a revision or replacement to anyadopted standard or standards. Anorganization could request a revision orreplacement to an adopted standard byrequesting a waiver from the Secretaryof Health and Human Services to test arevised or new standard. Theorganization would be required, at aminimum, to demonstrate that therevised or new standard offers a clearimprovement over the adoptedstandard. If the organization presentssufficient documentation that supportstesting of a revised or new standard, wewant to be able to grant the organizationa temporary waiver to test whileremaining in compliance with the law.We do not intend to establish a processthat would allow an organization toavoid using any adopted standard.

We would welcome comments on thefollowing: (1) How we should establishthis process, (2) the length of time aproposed standard should be testedbefore we decide whether to adopt it, (3)whether we should solicit publiccomments before implementing achange in a standard, and (4) otherissues and recommendations we shouldconsider. Comments should besubmitted to the addresses presented inthe ADDRESSES section of this document.

The following is one possible process:• Any organization that wishes to

revise or replace an adopted standardwould submit its waiver request to anHHS evaluation committee (to beestablished or defined). Theorganization would do the following foreach standard it wishes to revise orreplace:

+ Provide a detailed explanation, nomore than 10 pages, of how the revision

or replacement would be a clearimprovement over the current standard.

+ Provide specifications andtechnical capabilities on the revised ornew standard, including any additionalsystem requirements.

+ Provide an explanation, no morethan five pages, of how the organizationintends to test the standard.

• The committee’s evaluation would,at a minimum, be based on thefollowing:

+ A cost-benefit analysis.+ An assessment of whether the

proposed revision or replacementdemonstrates a clear improvement to anexisting standard.

+ The extent and length of time of thewaiver.

• The evaluation committee wouldinform the organization requesting thewaiver within 30 working days of thecommittee’s decision on the waiverrequest. If the committee decides togrant a waiver, the notification mayinclude the following:

+ Committee comments such as thefollowing:—The length of time for which the

waiver applies if it differs from thewaiver request.

—The sites the committee believes areappropriate for testing if they differfrom the waiver request.

—Any pertinent information regardingthe conditions of an approved waiver.• Any organization that receives a

waiver would be required to submit areport containing the results of thestudy, no later than 3 months after thestudy is completed.

• The committee would evaluate thereport and determine whether thebenefits of the proposed revision or newstandard significantly outweigh thedisadvantages of implementing it andmake a recommendation to theSecretary.

V. Response to Comments

Because of the large number of itemsof correspondence we normally receiveon Federal Register documentspublished for comment, we are not ableto acknowledge or respond to themindividually. We will consider allcomments we receive by the date andtime specified in the DATES section ofthis preamble, and, if we proceed witha subsequent document, we willrespond to the major comments in thepreamble of that document.

VI. Impact Analysis

As the effect of any one standard isaffected by the implementation of otherstandards, it can be misleading todiscuss the impact of one standard byitself. Therefore, we did an impact


analysis on the total effect of all thestandards in the proposed ruleconcerning the national provideridentifier (HCFA–0045–P), which waspublished on May 7, 1998 (63 FR25320).

We intend to publish in eachproposed rule an impact analysis that isspecific to the standard or standardsproposed in that rule, but the impactanalysis will assess only the relativecost impact of implementing a givenstandard. Thus, the followingdiscussion contains the impact analysisfor the security standard and theelectronic signature standard proposedin this rule. As stated in the generalimpact analysis in HCFA–0045–P, wedo not intend to associate costs andsavings to specific standards.

Although we cannot determine thespecific economic impact of thestandards being proposed in this rule(and individually each standard maynot have a significant impact), theoverall impact analysis makes clear that,collectively, all the standards will havea significant impact of over $100 millionon the economy. Also, while eachstandard may not have a significantimpact on a substantial number of smallentities, the combined effects of all theproposed standards may have asignificant effect on a substantialnumber of small entities. Therefore, thefollowing impact analysis should beread in conjunction with the overallimpact analysis.

The following describes the specificimpacts that relate to the security andelectronic signature standards. Securityprotection for health care information isnot a ‘‘stand-alone’’ type requirement.Appropriate security protections will bea business enabler, encouraging thegrowth and use of electronic datainterchange. The synergistic effect of theemployment of the recommendedsecurity practices, procedures andtechnologies will enhance all aspects ofHIPAA’s Administrative Simplificationrequirements. In addition, it isimportant to recognize that security isnot a product, but is an on-going,dynamic process.

In accordance with the provisions ofExecutive Order 12866, this proposedrule was reviewed by the Office ofManagement and Budget.

A. Security StandardHIPAA requires that all health plans,

health care providers, and health careclearinghouses that maintain or transmithealth information electronicallyestablish and maintain reasonable andappropriate administrative, technical,and physical safeguards to ensureintegrity, confidentiality, and

availability of the information. Thesafeguards also protect the informationagainst any reasonably anticipatedthreats or hazards to the security orintegrity of the information and protectit against unauthorized use ordisclosure. Recommendation 1 from theNational Research Council’s (NRC)report For the Record: ProtectingElectronic Health Information (‘‘Allorganizations that handle patient-identifiable health care information—regardless of size—should adopt the setof technical and organization policies,practices, and procedures described* * * to protect such information.’’)would apply to all health care providersregardless of size, health careclearinghouses, and health plans. Weagree with the NRC’s belief thatimplementation of the practices andtechnologies delineated inRecommendation 1 would be possibletoday, and at a reasonable cost.

Health care providers that conductelectronic transactions with healthplans would have to comply with therecommendation(s) for securityprotection. There is, however, norequirement to maintain health recordselectronically or transmit health careinformation by electronic means. Theremay also be health care providers thatcurrently submit health careinformation on paper but archiverecords electronically. These entitieswill need to ensure that their existingelectronic systems conform to securityrequirements for maintaining healthinformation. Once they have done so,however, they may also take advantageof all the other benefits of electronicrecordkeeping and transmittal.Therefore, no individual small entity isexpected to experience direct costs thatexceed benefits as a result of this rule.Furthermore, because almost all of theNRC recommendations reflectcontemporary security measures andcontrols, most organizations thatcurrently have security measures shouldhave to make few, if any, modificationsto their systems to meet therequirements proposed in the securitystandard.

The singular exception to the abovelies in the area of providing security forthe electronic transmission of healthcare information over insecure, publicmedia. Here, the choice of a method touse is driven by economic factors. If anorganization wishes to use an insecuretransmission media such as the Internet,and take advantage of the low costsinvolved, off-setting costs may need tobe incurred to provide for an acceptableform of encryption so that healthinformation will be protected fromintercept and possible misuse.

One alternative course of action toencrypting the information would be touse the services of a VAN. VANs do notmanipulate data, but rather transmitdata in its native form overtelecommunication lines. We anticipatethat VANs would be positively affectedby administrative simplification,because use of the proposedtransactions standards would eliminatethe need for data to be reformatted. Thiswould allow providers to purchase theservices of a VAN directly, rather thanas a service bundled with the functionsof other clearinghouses. Another courseof action might be to use private lineswhich would provide an appropriatelevel of protection for data intransmission.

B. Electronic Signature StandardHIPAA does not require the use of

electronic signatures. This particularcapability, however, would be necessaryfor a completely paperless environment.Certain features of the digital signaturetype of electronic signature make thisparticular system the most desirable.Only digital signatures, using currenttechnology, provide the combination ofauthenticity, message integrity, andnonrepudiation which is viewed as adesirable complement to the securitystandards required by the law.

The use of digital signatures requiresa certain infrastructure (Public KeyInfrastructure) that may necessitate theexpenditure of initial and recurringcosts for users. We do not know whatthese costs are presently, due to the lackof maturity of digital signaturetechnology, and minimal use in themarketplace today. It is noted thatpublic key certificate managementsystems and services do exist today, andit is presumed more quantifiableinformation will be forthcoming, as topotential costs and savings that can beassociated with the use of digitalsignature systems. Other forms ofelectronic signature were considered,such as biometric and digitizedsignatures. While they provide a usefulcapability in certain circumstances, webelieve that digital signature technologyis most appropriate for this particularapplication.

C. 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 regulatory


philosophy set forth in EO 12866 ofSeptember 30, 1993. In order to bedesignated as a standard, EO 12866requires that a proposed standard:

• 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. Thisprinciple 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, secondarily, with other private andpublic sector health data standards. Thisprinciple supports the regulatory goalsof consistency and avoidance ofincompatibility, and it establishes aperformance objective for the 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 standards developingorganization or other private or publicorganization that would ensurecontinuity and efficient updating of thestandard over time. This principlesupports 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 provider types) and

information technology. This principlesupports the regulatory goals offlexibility and encouragement ofinnovation.

We assessed a wide variety of securitystandards, guidelines and electronicsignature standards against theprinciples listed above, with the overallgoal of achieving the maximum benefitfor the least cost. We found that thereexists no single standard for security orelectronic signature that encompassesall the requirements that have beendeemed necessary. However, in thisparticular area, technology is rapidlydeveloping enhancements and bettermeans for accomplishing the statedgoals.

D. Affected Entities

1. Health Care Providers

Health care providers that conductbusiness using electronic transactionswith other health care participants (suchas other health care providers, healthplans, and employers) or maintainelectronic health information areencouraged, but are not required tosimultaneously implement the proposedsecurity standard. However, if theeffective date for the electronictransaction standards is later than theeffective date for the security standard,the implementation of the securitystandard will not be delayed until thestandard transactions are in use.

Health care providers that transmit,receive, or maintain health informationwould incur implementation costs forestablishing or updating their securitysystems. Any negative impact on thesehealth care providers caused byimplementing the proposed securitystandard would generally be related tothe initial implementation period for thespecific requirements of the securitystandard. Health care providers that areindirectly involved in electronictransactions (for example, those whosubmit a paper claim that the healthplan transmits electronically to asecondary payer) and do not maintainelectronic health information would notbe affected.

2. Health Plans

Health plans that engage in electronichealth care transactions would have tomodify their systems to use the securitystandard and the electronic signaturestandard, if used. Health plans thatmaintain electronic health informationwould also have to modify their systemsto use the security standard. Thisconversion would have a one-time costimpact on Federal, State and privateplans alike.

We recognize that this conversionprocess has the potential to causebusiness disruption of some healthplans. However, health plans would beable to schedule their implementation ofthe security standard and otherstandards in a way that best fits theirneeds, as long as they meet thedeadlines specified in the law.

Implementation of the securitystandard and the electronic signaturestandard, if used by the entities, wouldenhance payment safeguard activitiesand protect the integrity of the Medicaretrust fund by reducing fraud and abusethat occurs when health careinformation is used by those who arenot authorized to receive it. In additionthese standards would assist the plans,providers, and clearinghouses to moreeffectively maintain the security of allhealth information in their databases.

3. ClearinghousesHealth care clearinghouses would face

impacts similar to those experienced byhealth care providers and health plans.Systems vendors, that provide computersoftware applications to health careproviders and other billers of healthcare services, would likely be positivelyaffected. These vendors would have todevelop software solutions that wouldallow health care providers and otherbillers of health care transactions toprotect the information in theirdatabases from unwanted access to theirsystems.

4. Unfunded MandatesThis proposed rule has been reviewed

in accordance with the UnfundedMandates Reform Act of 1995 (UMRA)(U.S.C. 1501 et seq.) and ExecutiveOrder 12875. As discussed in thecombined impact analysis referencedabove (see Federal Register, Volume 63,No. 88), DHHS estimates thatimplementation of the standards willrequire the expenditure of more than$100 million by the private sector.Therefore, the rule establishes a Federalprivate sector mandate and is asignificant regulatory action within themeaning of section 202 of UMRA (2U.S.C. 1532). DHHS has included thisstatement to address the anticipatedeffects of the proposed rules pursuant tosection 202.

These standards also apply to Stateand local governments in their roles ashealth plans or health care providers.Thus, the proposed rules imposeunfunded mandates on these entities.While we do not have sufficientinformation to provide estimates ofthese impacts, several State Medicaidagencies have estimated that it wouldcost $1 million per State to implement


all of the HIPAA standards. However,the Congressional Budget Officeanalysis stated that ‘‘States are alreadyin the forefront in administering theMedicaid program electronically; theonly costs—which should not besignificant—would involve bringing thesoftware and computer systems for theMedicaid programs into compliancewith the new standards.’’

The anticipated benefits and costs ofthis proposed standard, and other issuesraised in section 202 of the UMRA, areaddressed in the analysis below, and inthe combined impact analysis. Inaddition, under section 205 of theUMRA (2 U.S.C. 1535), havingconsidered a reasonable number ofalternatives as outlined in the preambleto this rule and in the followinganalysis, the Department has concludedthat the rule is the most cost-effectivealternative for implementation ofDHHS’’ statutory objective ofadministrative simplification.

5. Regulatory Flexibility Act

The Regulatory Flexibility Act (RFA)of 1980, Public Law 96-354, requires usto prepare a regulatory flexibilityanalysis if the Secretary certifies that aproposed regulation would have asignificant economic impact on asubstantial number of small entities.The security and electronic signaturestandards will affect small entities, suchas providers. A more detailed analysisof the impact on small entities is part ofthe impact analysis we published onMay 7, 1998 (63 FR 25320) for all theHIPAA standards. A detailedillustration of the potential impact ofthe security standard on a small healthcare provider can be found in thepreamble in section D.

E. Factors in Establishing the SecurityStandard

1. Selection of Security Systems andProcedures

Because there is no national securitystandard in widespread use throughoutthe industry, adopting any of thecandidate standards would require mosthealth care providers, health plans andhealth care clearinghouses to conform tothe new standard. Implementation ofthe security standard would require allhealth plans, health care providers, andhealth care clearinghouses to establishor revise their security precautionsbecause the proposed standard is notcurrently in use. The selection of thesecurity standard does not impose agreater burden on the industry than thenonselected options, and presentssignificant advantages in terms ofuniversality, uniqueness and flexibility.

Only those plans, providers, andclearinghouses that decide to use thedigital signature would be affected bythe electronic signature standard. Somelarge health plans, health careproviders, and health careclearinghouses that currently exchangehealth information among tradingpartners may have security systems andprocedures in place to protect theinformation from unauthorized access.These entities may not incur significantcosts to meet the proposed securitystandard and if they opt not to use thedigital signature they would not incurcosts to meet the electronic signaturerequirements. Also, some entities thatcurrently use electronic signatures as anadded security measure may also beusing digital signature technology. Atmost, large entities that may havesophisticated security systems in placemay only need to revise or update theirsystems to meet the proposed securitystandard and electronic signaturestandard.

2. Complexity of ConversionThe complexity of the conversion

would be significantly affected by thevolume of claims health plans processelectronically and the desire to transmitthe claims themselves or to use theservices of a VAN or a clearinghouse. Ifthey chose to transmit themselves, theywould need to convert to the proposedtransaction standards. Specifictechnology limitations of existingsystems could affect the complexity ofthe conversion. For example, someentities may only have a minimum levelof security and procedures in place andtherefore may require a full upgrade,while others may already have a verysophisticated system and proceduresand require very little enhancement.

3. Cost of ConversionWe expect that most providers, health

plans, and clearinghouses that transmitor store data electronically have alreadyimplemented some security measuresand will primarily need to assessexisting security, identify areas of risk,and implement additional measures. Wecannot estimate the per-entity cost ofimplementation because there is noinformation available regarding theextent to which providers’, plans’, andclearinghouses’ current securitypractices are deficient. Moreover, somesecurity solutions are almost cost-free toimplement (e.g., reminding employeesnot to post passwords on their monitors)while others are not.

Affected entities will have manychoices regarding how they willimplement security. Some may chooseto assess security using in-house staff,

while others will utilize consultants.Practice management software vendorsmay also provide security consultationservices to their customers. Entities mayalso choose to implement securitymeasures that require hardware orsoftware purchases at the time they doroutine equipment upgrades.

The security requirements we areproposing were developed withconsiderable input from the health careindustry, including providers, healthplans, clearinghouses, vendors, andstandards organizations. Industrymembers strongly advocated thisflexible approach, which permits eachaffected entity to develop cost-effectivesecurity measures. We believe that thisapproach will yield the lowestimplementation cost to industry whileassuring that health information issafeguarded. We solicit input regardingimplementation costs.

We are unable to estimate, of thenation’s 4 million-plus health plans and1.2 million-plus providers, the numberof entities that would require securitysystems and procedures because theyconduct electronic transactions ormaintain electronic health information.Nor are we able to estimate the numberof entities that neither conductelectronic transactions nor maintainelectronic health information but maychoose to do so at some future time.(These would be entities that send andreceive paper transactions and maintainpaper records and thus would not beaffected because they would have noneed to implement security standards.)However, we are aware of the possibilitythat those small entities that currentlyprocess claims electronically ormaintain electronic health informationmay not be able to continue to do so dueto the cost of establishing securitysystems to meet the requirements of theproposed security standard. Thoseentities that are not able to bill andexchange health informationelectronically may use clearinghouses.We believe that the proposed securitystandard represents the minimumnecessary for adequate protection ofhealth information in an electronicformat. As discussed earlier in thispreamble, the security requirements areboth scalable and technically flexible;and while the law requires each healthplan that is not a small plan to complywith the security and electronicsignature requirements no later than 24months after the effective date of thefinal rule, small plans will be allowedan additional 12 months to comply.

Since we are unable to estimate thenumber of entities, we are also unableto estimate the cost to the entities thatwill process electronic transactions.


However, we believe that the cost ofestablishing security systems andprocedures is a portion of the costsassociated with converting to thetransaction standards that are requiredunder HIPAA.

This discussion on conversion costsrelates only to health plans, health careproviders, and health careclearinghouses that are required tofollow the security standard tomaintain, transmit or receive electronichealth information. Other entities wouldnot be required to follow the securitystandard and procedures until theychoose to maintain, transmit, or receiveelectronic health information. The costof establishing security systems andprocedures for entities that do nottransmit, receive or maintain healthinformation electronically is notincluded in our estimates.

VII. Collection of InformationRequirements

Under the Paperwork Reduction Actof 1995, we are required to provide 60-day notice in the Federal Register andsolicit public comment before acollection of information requirement issubmitted 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 PaperworkReduction Act of 1995 requires that wesolicit comment on the following issues:

• The need for the informationcollection and its usefulness in carryingout the proper functions of our agency.

• The accuracy of our estimate of theinformation collection burden.

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

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

As discussed below, we are solicitingcomment on the recordkeepingrequirements, as referenced in § 142.308of this document. In addition, we aresoliciting comment on the applicabilityof the PRA as it may relate to therequirement to use the standard adoptedin § 142.310 of this regulation.

Section 142.308 Security Standard

In summary, each entity designated in§ 142.302 must maintain documentationdemonstrating the development,implementation, and maintenance ofappropriate security measures thatinclude, at a minimum, therequirements and implementationfeatures set forth in this section. Inaddition, entities must maintainnecessary documentation to

demonstrate that these measures havebeen periodically reviewed, validated,updated, and kept current.

While we solicit comment on theserecordkeeping requirements weexplicitly solicit comment on theburden associated with maintainingdocumentation related to theimplementation the requirements setforth in § 142.308. Since the level ofdocumentation necessary todemonstrate compliance with theserequirements is dependent uponindividual business needs and the factthat we do not prescribe the form,format, or degree of documentationnecessary to demonstrate compliance,we are currently unable to accuratelyestimate the degree of recordkeepingburden that will be experienced by thevarying entities. Therefore, commentorsshould provide an estimate of: (1) theinitial recordkeeping burden associatedwith meeting these requirements and (2)the recordkeeping burden associatedwith maintaining documentation todemonstrate that the measures havebeen periodically reviewed, validated,updated, and kept current.

Below is a discussion of theapplicability of the PRA as it may relateto the adoption of the standardreferenced in § 142.310 of thisregulation.

Section 142.310 Electronic SignatureStandard

In summary, any entity electing to usean electronic signature in a transactionas defined in § 142.103, or if anelectronic signature is required by atransaction standard adopted by theSecretary, the entity must apply theelectronic signature standard describedin paragraph (b) of this section to thattransaction.

Discussion

The emerging and increasing use ofhealth care EDI standards andtransactions raises the issue of theapplicability of the PRA. The questionarises whether a regulation that adoptsan EDI standard used to exchangecertain information constitutes aninformation collection subject to thePRA.

In particular, we are still consideringwhether the use of any EDI transactionstandard, such as the electronicsignature described in this regulation,should be viewed or regarded as astandardized electronic collection ofinformation. If it is a standardizedelectronic information collection, thenthe requirement by the Federalgovernment on the industry to acceptand transmit the information may be

subject to OMB review and approvalunder the PRA.

We invite public comment on theissues discussed above. If therequirements, as set forth in § 142.310are determined to be subject to the PRA,we will submit these requirements toOMB for PRA approval. If you commenton these information collection andrecordkeeping requirements, please e-mail comments to [email protected](Attn: HCFA–0049) or mail copiesdirectly to the following:Health Care Financing Administration,

Office of Information Services,Security and Standards Group,Division of HCFA EnterpriseStandards, Room N2–14–26, 7500Security Boulevard, Baltimore, MD21244–1850. Attn: John Burke HCFA–0049, HCFA Reports Clearance Officer

AndOffice of Information and Regulatory

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

List of Subjects in 45 CFR Part 142

Administrative practice andprocedure, Health facilities, Healthinsurance, Hospitals, Medicaid,Medicare, Report and recordkeepingrequirement.

45 CFR subtitle A, subchapter B,would be amended by adding part 42 toread as follows:

Note to Reader: This proposed rule is oneof several proposed rules that are beingpublished to implement the administrativesimplification provisions of the HealthInsurance Portability and Accountability Actof 1996. We propose to establish a new 45CFR Part 142. Proposed Subpart A—GeneralProvisions is exactly the same in each ruleunless we have added new sections ordefinitions to incorporate additional generalinformation. The subparts that follow relateto the specific provisions announcedseparately in each proposed rule. When wepublish the first final rule, each subsequentfinal rule will revise or add to the text thatis set out in the first final rule.

PART 142—ADMINISTRATIVEREQUIREMENTS

Subpart A—General Provisions

Sec.142.101 Statutory basis and purpose.142.102 Applicability.142.103 Definitions.142.104 General requirements for health

plans.142.105 Compliance using a health care

clearinghouse.142.106 Effective dates of a modification to

a standard or implementationspecification.


Subpart B—Reserved

Subpart C—Security and ElectronicSignature Standards

Sec.142.302 Applicability and scope.142.304 Definitions.142.306 Rules for the security standard.142.308 Security standard.142.310 Electronic signature standard.142.312 Effective date of the initial

implementation of the security andelectronic standards.

Authority: Sections 1173 and 1175 of theSocial Security Act (42 U.S.C. 1320d–2 and1320d–4).

Subpart A—General Provisions

§ 142.101 Statutory basis and purpose.Sections 1171 through 1179 of the

Social Security Act, 42 U.S.C. 1320d, asadded by section 262 of the HealthInsurance Portability andAccountability Act of 1996, require HHSto adopt national standards for theelectronic exchange of healthinformation in the health care system.The purpose of the sections of this partis to promote administrativesimplification.

§ 142.102 Applicability.(a) The standards adopted or

designated under this part apply, inwhole or in part, to the following:

(1) A health plan.(2) A health care clearinghouse when

doing the following:(i) Transmitting a standard transaction

(as defined in § 142.103) to a health careprovider or health plan.

(ii) Receiving a standard transactionfrom a health care provider or healthplan.

(iii) Transmitting and receiving thestandard transactions when interactingwith another health care clearinghouse.

(3) A health care provider whentransmitting an electronic transaction asdefined in § 142.103.

(b) Means of compliance are stated ingreater detail in § 142.105.

§ 142.103 Definitions.For purposes of this part, the

following definitions apply:Code set means any set of codes used

for encoding data elements, such astables of terms, medical concepts,medical diagnostic codes, or medicalprocedure codes.

Health care clearinghouse means apublic or private entity that processes orfacilitates the processing of nonstandarddata elements of health information intostandard data elements. The entityreceives health care transactions fromhealth care providers or other entities,translates the data from a given formatinto one acceptable to the intended

payer or payers, and forwards theprocessed transaction to appropriatepayers and clearinghouses. Billingservices, repricing companies,community health managementinformation systems, community healthinformation systems, and ‘‘value-added’’networks and switches are considered tobe health care clearinghouses forpurposes of this part.

Health care provider means aprovider of services as defined insection 1861(u) of the Social SecurityAct, 42 U.S.C. 1395x, a provider ofmedical or other health services asdefined in section 1861(s) of the SocialSecurity Act, and any other person whofurnishes or bills and is paid for healthcare services or supplies in the normalcourse of business.

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 plan means an individual orgroup plan that provides, or pays thecost of, medical care. Health planincludes the following, singly or incombination:

(1) Group health plan. A group healthplan is an employee welfare benefit plan(as currently defined in section 3(1) ofthe Employee Retirement Income andSecurity Act of 1974, 29 U.S.C. 1002(1)),including insured and self-insuredplans, to the extent that the planprovides medical care, including itemsand services paid for as medical care, toemployees or their dependents directlyor through insurance, or otherwise,and—

(i) Has 50 or more participants; or(ii) Is administered by an entity other

than the employer that established andmaintains the plan.

(2) Health insurance issuer. A healthinsurance issuer is an insurancecompany, insurance service, orinsurance organization that is licensedto engage in the business of insurancein a State and is subject to State law thatregulates insurance.

(3) Health maintenance organization.A health maintenance organization is aFederally qualified health maintenanceorganization, an organization recognizedas a health maintenance organizationunder State law, or a similar

organization regulated for solvencyunder State law in the same manner andto the same extent as such a healthmaintenance organization.

(4) Part A or Part B of the Medicareprogram under title XVIII of the SocialSecurity Act.

(5) The Medicaid program under titleXIX of the Social Security Act.

(6) A Medicare supplemental policy(as defined in section 1882(g)(1) of theSocial Security Act, 42 U.S.C. 1395ss).

(7) A long-term care policy, includinga 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 HealthBenefits Program under 5 U.S.C. chapter89.

(14) Any other individual or grouphealth plan, or combination thereof, thatprovides or pays for the cost of medicalcare.

Medical care means the diagnosis,cure, mitigation, treatment, orprevention of disease, or amounts paidfor the purpose of affecting any bodystructure or function of the body;amounts paid for transportationprimarily for and essential to theseitems; and amounts paid for insurancecovering the items and thetransportation specified in thisdefinition.

Participant means any employee orformer employee of an employer, or anymember or former member of anemployee organization, who is or maybecome eligible to receive a benefit ofany type from an employee benefit planthat covers employees of that employeror members of such an organization, orwhose beneficiaries may be eligible toreceive any of these benefits.‘‘Employee’’ includes an individual whois treated as an employee under section401(c)(1) of the Internal Revenue Codeof 1986 (26 U.S.C. 401(c)(1)).

Small health plan means a grouphealth plan or individual health planwith fewer than 50 participants.


Standard means a set of rules for a setof codes, data elements, transactions, oridentifiers promulgated either by anorganization accredited by the AmericanNational Standards Institute or HHS forthe electronic transmission of healthinformation.

Transaction means the exchange ofinformation between two parties tocarry out financial and administrativeactivities related to health care. Itincludes the following:

(1) Health claims or equivalentencounter information.

(2) Health care payment andremittance advice.

(3) Coordination of benefits.(4) Health claims status.(5) Enrollment and disenrollment in a

health plan.(6) Eligibility for a health plan.(7) Health plan premium payments.(8) Referral certification and

authorization.(9) First report of injury.(10) Health claims attachments.(11) Other transactions as the

Secretary may prescribe by regulation.

§ 142.104 General requirements for healthplans.

If a person conducts a transaction (asdefined in § 142.103) with a health planas a standard transaction, the followingapply:

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

(b) 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.

(c) The health information transmittedand received in connection with thetransaction must be in the form ofstandard data elements of healthinformation.

(d) A health plan that conductstransactions through an agent mustassure that the agent meets all therequirements of this part that apply tothe health plan.

§ 142.105 Compliance using a health careclearinghouse.

(a) Any person or other entity subjectto the requirements of this part maymeet the requirements to accept andtransmit standard transactions byeither—

(1) Transmitting and receivingstandard data elements; or

(2) Submitting nonstandard dataelements to a health care clearinghousefor processing into standard dataelements and transmission by the healthcare clearinghouse and receiving

standard data elements through thehealth care clearinghouse.

(b) The transmission, under contract,of nonstandard data elements between ahealth plan or a health care providerand its agent health care clearinghouseis not a violation of the requirements ofthis part.

§ 142.106 Effective dates of a modificationto a standard or implementationspecification.

HHS may modify a standard orimplementation specification after thefirst year in which HHS requires thestandard or implementationspecification to be used, but not morefrequently than once every 12 months.If HHS adopts a modification to astandard or implementationspecification, the implementation dateof the modified standard orimplementation specification may be noearlier than 180 days following theadoption of the modification. HHSdetermines the actual date, taking intoaccount the time needed to comply dueto the nature and extent of themodification. HHS may extend the timefor compliance for small health plans.

Subpart B—[Reserved]

Subpart C—Security and ElectronicSignature Standards

§ 142.302 Applicability and scope.

The standards adopted or designatedunder this subpart apply, in whole or inpart, to the following:

(a) A health plan.(b) A health care clearinghouse or

health care provider that takes one ofthe following actions:

(1) Processes any electronictransmission between any combinationof health care entities listed in thissection.

(2) Electronically maintains anyhealth information used in an electronictransmission that has been sent orreceived between any combination ofhealth care entities listed in this section.

§ 142.304 Definitions.

For purposes of this subpart, thefollowing definitions apply:

Access refers to the ability or themeans necessary to read, write, modify,or communicate data/information orotherwise make use of any systemresource.

Access control refers to a method ofrestricting access to resources, allowingonly privileged entities access. Types ofaccess control include, among others,mandatory access control, discretionaryaccess control, time-of-day, andclassification.

Authentication refers to thecorroboration that an entity is the oneclaimed.

Contingency plan refers to a plan forresponding to a system emergency. Theplan includes performing backups,preparing critical facilities that can beused to facilitate continuity ofoperations in the event of an emergency,and recovering from a disaster.

Encryption (or encipherment) refers totransforming confidential plaintext intociphertext to protect it. An encryptionalgorithm combines plaintext with othervalues called keys, or ciphers, so thedata becomes unintelligible. Onceencrypted, data can be stored ortransmitted over unsecured lines.Decrypting data reverses the encryptionalgorithm process and makes theplaintext available for furtherprocessing.

Password refers to confidentialauthentication information composed ofa string of characters.

Role-based access control (RBAC) isan alternative to traditional accesscontrol models (e.g., discretionary ornon-discretionary access controlpolicies) that permits the specificationand enforcement of enterprise-specificsecurity policies in a way that mapsmore naturally to an organization’sstructure and business activities. WithRBAC, rather than attempting to map anorganization’s security policy to arelatively low-level set of technicalcontrols (typically, access control lists),each user is assigned to one or morepredefined roles, each of which hasbeen assigned the various privilegesneeded to perform that role.

Token refers to a physical itemnecessary for user identification whenused in the context of authentication.For example, an electronic device thatcan be inserted in a door or a computersystem to obtain access.

User-based access refers to a securitymechanism used to grant users of asystem access based upon the identity ofthe user.

§ 142.306 Rules for the security standard.

(a) An entity must apply the securitystandard described in § 142.308 to allhealth information pertaining to anindividual that is electronicallymaintained or electronicallytransmitted.

(b) If a health care clearinghouse ispart of a larger organization, it mustassure that all health informationpertaining to an individual is protectedfrom unauthorized access by the largerorganization.


§ 142.308 Security standard.

Each entity designated in § 142.302must assess potential risks andvulnerabilities to the individual healthdata in its possession and develop,implement, and maintain appropriatesecurity measures. These measures mustbe documented and kept current, andmust include, at a minimum, thefollowing requirements andimplementation features:

(a) Administrative procedures toguard data integrity, confidentiality,and availability (documented, formalpractices to manage the selection andexecution of security measures toprotect data, and to manage the conductof personnel in relation to the protectionof data). These procedures include thefollowing requirements:

(1) Certification. (The technicalevaluation performed as part of, and insupport of, the accreditation processthat establishes the extent to which aparticular computer system or networkdesign and implementation meet a pre-specified set of security requirements.This evaluation may be performedinternally or by an external accreditingagency.)

(2) A chain of trust partner agreement(a contract entered into by two businesspartners in which the partners agree toelectronically exchange data and protectthe integrity and confidentiality of thedata exchanged).

(3) A contingency plan, a routinelyupdated plan for responding to a systememergency, that includes performingbackups, preparing critical facilities thatcan be used to facilitate continuity ofoperations in the event of an emergency,and recovering from a disaster. The planmust include all of the followingimplementation features:

(i) An applications and data criticalityanalysis (an entity’s formal assessmentof the sensitivity, vulnerabilities, andsecurity of its programs and informationit receives, manipulates, stores, and/ortransmits).

(ii) Data backup plan (a documentedand routinely updated plan to createand maintain, for a specific period oftime, retrievable exact copies ofinformation).

(iii) A disaster recovery plan (the partof an overall contingency plan thatcontains a process enabling anenterprise to restore any loss of data inthe event of fire, vandalism, naturaldisaster, or system failure).

(iv) Emergency mode operation plan(the part of an overall contingency planthat contains a process enabling anenterprise to continue to operate in theevent of fire, vandalism, naturaldisaster, or system failure).

(v) Testing and revision procedures(the documented process of periodictesting of written contingency plans todiscover weaknesses and the subsequentprocess of revising the documentation,if necessary).

(4) Formal mechanism for processingrecords (documented policies andprocedures for the routine, andnonroutine, receipt, manipulation,storage, dissemination, transmission,and/or disposal of health information).

(5) Information access control (formal,documented policies and procedures forgranting different levels of access tohealth care information) that includesall of the following implementationfeatures:

(i) Access authorization (information-use policies and procedures thatestablish the rules for granting access,(for example, to a terminal, transaction,program, process, or some other user.)

(ii) Access establishment (securitypolicies and rules that determine anentity’s initial right of access to aterminal, transaction, program, processor some other user).

(iii) Access modification (securitypolicies and rules that determine thetypes of, and reasons for, modificationto an entity’s established right of access,to a terminal, transaction, program,process, or some other user.)

(6) Internal audit (in-house review ofthe records of system activity (such aslogins, file accesses, and securityincidents) maintained by anorganization).

(7) Personnel security (all personnelwho have access to any sensitiveinformation have the requiredauthorities as well as all appropriateclearances) that includes all of thefollowing implementation features:

(i) Assuring supervision ofmaintenance personnel by anauthorized, knowledgeable person.These procedures are documentedformal procedures and instructions forthe oversight of maintenance personnelwhen the personnel are near healthinformation pertaining to an individual.

(ii) Maintaining a record of accessauthorizations (ongoing documentationand review of the levels of accessgranted to a user, program, or procedureaccessing health information).

(iii) Assuring that operating andmaintenance personnel have properaccess authorization (formaldocumented policies and procedures fordetermining the access level to begranted to individuals working on, ornear, health information).

(iv) Establishing personnel clearanceprocedures (a protective measureapplied to determine that anindividual’s access to sensitive

unclassified automated information isadmissible).

(v) Establishing and maintainingpersonnel security policies andprocedures (formal, documentation ofprocedures to ensure that all personnelwho have access to sensitiveinformation have the required authorityas well as appropriate clearances).

(vi) Assuring that system users,including maintenance personnel,receive security awareness training.

(8) Security configurationmanagement (measures, practices, andprocedures for the security ofinformation systems that must becoordinated and integrated with eachother and other measures, practices, andprocedures of the organizationestablished in order to create a coherentsystem of security) that includes all ofthe following implementation features:

(i) Documentation (written securityplans, rules, procedures, andinstructions concerning all componentsof an entity’s security).

(ii) Hardware and softwareinstallation and maintenance reviewand testing for security features (formal,documented procedures for connectingand loading new equipment andprograms, periodic review of themaintenance occurring on thatequipment and programs, and periodicsecurity testing of the security attributesof that hardware/software).

(iii) Inventory (the formal,documented identification of hardwareand software assets).

(iv) Security testing (process used todetermine that the security features of asystem are implemented as designedand that they are adequate for aproposed applications environment; thisprocess includes hands-on functionaltesting, penetration testing, andverification).

(v) Virus checking. (The act ofrunning a computer program thatidentifies and disables:

(A) Another ‘‘virus’’ computerprogram, typically hidden, that attachesitself to other programs and has theability to replicate.

(B) A code fragment (not anindependent program) that reproducesby attaching to another program.

(C) A code embedded within aprogram that causes a copy of itself tobe inserted in one or more otherprograms.)

(9) Security incident procedures(formal documented instructions forreporting security breaches) that includeall of the following implementationfeatures:

(i) Report procedures (documentedformal mechanism employed todocument security incidents).


(ii) Response procedures (documentedformal rules or instructions for actionsto be taken as a result of the receipt ofa security incident report).

(10) Security management process(creation, administration, and oversightof policies to ensure the prevention,detection, containment, and correctionof security breaches involving riskanalysis and risk management). Itincludes the establishment ofaccountability, management controls(policies and education), electroniccontrols, physical security, andpenalties for the abuse and misuse of itsassets (both physical and electronic)that includes all of the followingimplementation features:

(i) Risk analysis, a process wherebycost-effective security/control measuresmay be selected by balancing the costsof various security/control measuresagainst the losses that would beexpected if these measures were not inplace.

(ii) Risk management (process ofassessing risk, taking steps to reducerisk to an acceptable level, andmaintaining that level of risk).

(iii) Sanction policies and procedures(statements regarding disciplinaryactions that are communicated to allemployees, agents, and contractors; forexample, verbal warning, notice ofdisciplinary action placed in personnelfiles, removal of system privileges,termination of employment, andcontract penalties). They must includeemployee, agent, and contractor noticeof civil or criminal penalties for misuseor misappropriation of healthinformation and must make employees,agents, and contractors aware thatviolations may result in notification tolaw enforcement officials andregulatory, accreditation, and licensureorganizations.

(iv) Security policy (statement(s) ofinformation values, protectionresponsibilities, and organizationcommitment for a system). This is theframework within which an entityestablishes needed levels of informationsecurity to achieve the desiredconfidentiality goals.

(11) Termination procedures (formaldocumented instructions, whichinclude appropriate security measures,for the ending of an employee’semployment or an internal/externaluser’s access) that include proceduresfor all of the following implementationfeatures:

(i) Changing locks (a documentedprocedure for changing combinations oflocking mechanisms, both on arecurring basis and when personnelknowledgeable of combinations nolonger have a need to know or require

access to the protected facility orsystem).

(ii) Removal from access lists(physical eradication of an entity’saccess privileges).

(iii) Removal of user account(s)(termination or deletion of anindividual’s access privileges to theinformation, services, and resources forwhich they currently have clearance,authorization, and need-to-know whensuch clearance, authorization and need-to-know no longer exists).

(iv) Turning in of keys, tokens, orcards that allow access (formal,documented procedure to ensure allphysical items that allow a terminatedemployee to access a property, building,or equipment are retrieved from thatemployee, preferably beforetermination).

(12) Training (education concerningthe vulnerabilities of the healthinformation in an entity’s possessionand ways to ensure the protection ofthat information) that includes all of thefollowing implementation features:

(i) Awareness training for allpersonnel, including managementpersonnel (in security awareness,including, but not limited to, passwordmaintenance, incident reporting, andviruses and other forms of malicioussoftware).

(ii) Periodic security reminders(employees, agents, and contractors aremade aware of security concerns on anongoing basis).

(iii) User education concerning virusprotection (training relative to userawareness of the potential harm that canbe caused by a virus, how to prevent theintroduction of a virus to a computersystem, and what to do if a virus isdetected).

(iv) User education in importance ofmonitoring log-in success or failure andhow to report discrepancies (training inthe user’s responsibility to ensure thesecurity of health care information).

(v) User education in passwordmanagement (type of user training in therules to be followed in creating andchanging passwords and the need tokeep them confidential).

(b) Physical safeguards to guard dataintegrity, confidentiality, andavailability. Protection of physicalcomputer systems and related buildingsand equipment from fire and othernatural and environmental hazards, aswell as from intrusion. It covers the useof locks, keys, and administrativemeasures used to control access tocomputer systems and facilities.Physical safeguards must include all ofthe following requirements andimplementation features:

(1) Assigned security responsibility(practices established by management tomanage and supervise the execution anduse of security measures to protect dataand to manage and supervise theconduct of personnel in relation to theprotection of data).

(2) Media controls (formal,documented policies and proceduresthat govern the receipt and removal ofhardware/software (such as diskettesand tapes) into and out of a facility) thatinclude all of the followingimplementation features:

(i) Access control.(ii) Accountability (the property that

ensures that the actions of an entity canbe traced uniquely to that entity).

(iii) Data backup (a retrievable, exactcopy of information).

(iv) Data storage (the retention ofhealth care information pertaining to anindividual in an electronic format).

(v) Disposal (final disposition ofelectronic data, and/or the hardware onwhich electronic data is stored).

(3) Physical access controls (limitedaccess) (formal, documented policiesand procedures to be followed to limitphysical access to an entity whileensuring that properly authorized accessis allowed) that include all of thefollowing implementation features:

(i) Disaster recovery (the processenabling an entity to restore any loss ofdata in the event of fire, vandalism,natural disaster, or system failure).

(ii) An emergency mode operation(access controls in place that enable anentity to continue to operate in theevent of fire, vandalism, naturaldisaster, or system failure).

(iii) Equipment control (into and outof site) (documented securityprocedures for bringing hardware andsoftware into and out of a facility andfor maintaining a record of thatequipment. This includes, but is notlimited to, the marking, handling, anddisposal of hardware and storagemedia.)

(iv) A facility security plan (a plan tosafeguard the premises and building(exterior and interior) fromunauthorized physical access and tosafeguard the equipment therein fromunauthorized physical access,tampering, and theft).

(v) Procedures for verifying accessauthorizations before granting physicalaccess (formal, documented policies andinstructions for validating the accessprivileges of an entity before grantingthose privileges).

(vi) Maintenance records(documentation of repairs andmodifications to the physicalcomponents of a facility, such as


hardware, software, walls, doors, andlocks).

(vii) Need-to-know procedures forpersonnel access (a security principlestating that a user should have accessonly to the data he or she needs toperform a particular function).

(viii) Procedures to sign in visitorsand provide escorts, if appropriate(formal documented proceduregoverning the reception and hosting ofvisitors).

(ix) Testing and revision (therestriction of program testing andrevision to formally authorizedpersonnel).

(4) Policy and guidelines on workstation use (documented instructions/procedures delineating the properfunctions to be performed, the mannerin which those functions are to beperformed, and the physical attributesof the surroundings of a specificcomputer terminal site or type of site,dependent upon the sensitivity of theinformation accessed from that site).

(5) A secure work station location(physical safeguards to eliminate orminimize the possibility ofunauthorized access to information; forexample, locating a terminal used toaccess sensitive information in a lockedroom and restricting access to that roomto authorized personnel, not placing aterminal used to access patientinformation in any area of a doctor’soffice where the screen contents can beviewed from the reception area).

(6) Security awareness training(information security awareness trainingprograms in which all employees,agents, and contractors must participate,including, based on job responsibilities,customized education programs thatfocus on issues regarding use of healthinformation and responsibilitiesregarding confidentiality and security).

(c) Technical security services toguard data integrity, confidentiality,and availability (the processes that areput in place to protect information andto control individual access toinformation). These services include thefollowing requirements andimplementation features:

(1) The technical security servicesmust include all of the followingrequirements and the specifiedimplementation features:

(i) Access control that includes:(A) A procedure for emergency access

(documented instructions for obtainingnecessary information during a crisis),and

(B) At least one of the followingimplementation features:

(1) Context-based access (an accesscontrol procedure based on the contextof a transaction (as opposed to being

based on attributes of the initiator ortarget)).

(2) Role-based access.(3) User-based access.(C) The optional use of encryption.(ii) Audit controls (mechanisms

employed to record and examine systemactivity).

(iii) Authorization control (themechanism for obtaining consent for theuse and disclosure of healthinformation) that includes at least one ofthe following implementation features:

(A) Role-based access.(B) User-based access.(iv) Data authentication. (The

corroboration that data has not beenaltered or destroyed in an unauthorizedmanner. Examples of how datacorroboration may be assured includethe use of a check sum, double keying,a message authentication code, or digitalsignature.)

(v) Entity authentication (thecorroboration that an entity is the oneclaimed) that includes:

(A) Automatic logoff (a securityprocedure that causes an electronicsession to terminate after apredetermined time of inactivity, suchas 15 minutes), and

(B) Unique user identifier (acombination name/number assignedand maintained in security proceduresfor identifying and tracking individualuser identity).

(C) At least one of the followingimplementation features:

(1) Biometric identification (anidentification system that identifies ahuman from a measurement of aphysical feature or repeatable action ofthe individual (for example, handgeometry, retinal scan, iris scan,fingerprint patterns, facialcharacteristics, DNA sequencecharacteristics, voice prints, and handwritten signature)).

(2) Password.(3) Personal identification number

(PIN) (a number or code assigned to anindividual and used to provideverification of identity).

(4) A telephone callback procedure(method of authenticating the identity ofthe receiver and sender of informationthrough a series of ‘‘questions’’ and‘‘answers’’ sent back and forthestablishing the identity of each). Forexample, when the communicatingsystems exchange a series ofidentification codes as part of theinitiation of a session to exchangeinformation, or when a host computerdisconnects the initial session before theauthentication is complete, and the hostcalls the user back to establish a sessionat a predetermined telephone number.

(5) Token.

(2) [Reserved](d) Technical security mechanisms

(processes that are put in place to guardagainst unauthorized access to data thatis transmitted over a communicationsnetwork).

(1) If an entity uses communicationsor network controls, its securitystandards for technical securitymechanisms must include thefollowing:

(i) The following implementationfeatures:

(A) Integrity controls (a securitymechanism employed to ensure thevalidity of the information beingelectronically transmitted or stored).

(B) Message authentication (ensuring,typically with a message authenticationcode, that a message received (usuallyvia a network) matches the messagesent).

(ii) One of the followingimplementation features:

(A) Access controls (protection ofsensitive communications transmissionsover open or private networks so thatthey cannot be easily intercepted andinterpreted by parties other than theintended recipient).

(B) Encryption.(2) If an entity uses network controls

(to protect sensitive communication thatis transmitted electronically over opennetworks so that it cannot be easilyintercepted and interpreted by partiesother than the intended recipient), itstechnical security mechanisms mustinclude all of the followingimplementation features:

(i) Alarm. (In communication systems,any device that can sense an abnormalcondition within the system andprovide, either locally or remotely, asignal indicating the presence of theabnormality. The signal may be in anydesired form ranging from a simplecontact closure (or opening) to a time-phased automatic shutdown and restartcycle.)

(ii) Audit trail (the data collected andpotentially used to facilitate a securityaudit).

(iii) Entity authentication (acommunications or network mechanismto irrefutably identify authorized users,programs, and processes and to denyaccess to unauthorized users, programs,and processes).

(iv) Event reporting (a networkmessage indicating operationalirregularities in physical elements of anetwork or a response to the occurrenceof a significant task, typically thecompletion of a request for information).

§ 142.310 Electronic signature standard.(a) General rule. If an entity elects to

use an electronic signature in a


transaction as defined in § 142.103, or ifan electronic signature is required by atransaction standard adopted by theSecretary, the entity must apply theelectronic signature standard describedin paragraph (b) of this section to thattransaction.

(b) Standard.(1) An electronic signature is the

attribute affixed to an electronicdocument to bind it to a particularentity. An electronic signature securesthe user authentication (proof ofclaimed identity) at the time thesignature is generated; creates thelogical manifestation of signature(including the possibility for multipleparties to sign a document and have theorder of application recognized andproven); supplies additionalinformation such as time stamp andsignature purpose specific to that user;and ensures the integrity of the signeddocument to enable transportability ofdata, interoperability, independentverifiability, and continuity of signaturecapability. Verifying a signature on adocument verifies the integrity of thedocument and associated attributes andverifies the identity of the signer.

(2) The standard for electronicsignature is a digital signature. A‘‘digital signature’’ is an electronicsignature based upon cryptographicmethods of originator authentication,computed by using a set of rules and aset of parameters so that the identity ofthe signer and the integrity of the datacan be verified.

(c) Required implementation features.If an entity uses electronic signatures,the signature method must assure all ofthe following features:

(1) Message integrity (the assurance ofunaltered transmission and receipt of amessage from the sender to the intendedrecipient).

(2) Nonrepudiation (strong andsubstantial evidence of the identity of

the signer of a message, and of messageintegrity, sufficient to prevent a partyfrom successfully denying the origin,submission, or delivery of the messageand the integrity of its contents).

(3) User authentication (the provisionof assurance of the claimed identity ofan entity).

(d) Optional implementation features.If an entity uses electronic signatures,the entity may also use, among others,any of the following implementationfeatures:

(1) Ability to add attributes (onepossible capability of a digital signaturetechnology; for example, the ability toadd a time stamp as part of a digitalsignature).

(2) Continuity of signature capability(the concept that the public verificationof a signature must not compromise theability of the signer to apply additionalsecure signatures at a later date).

(3) Countersignatures. (The capabilityto prove the order of application ofsignatures. This is analogous to thenormal business practice ofcountersignatures, where a party signs adocument that has already been signedby another party.)

(4) Independent verifiability (thecapability to verify the signaturewithout the cooperation of the signer).

(5) Interoperability (the applicationsused on either side of a communication,between trading partners and/orbetween internal components of anentity, are able to read and correctlyinterpret the information communicatedfrom one to the other).

(6) Multiple signatures. (With thisfeature, multiple parties are able to signa document. Conceptually, multiplesignatures are simply appended to thedocument.)

(7) Transportability of data (the abilityof a signed document to be transportedover an insecure network to anothersystem, while maintaining the integrityof the document, including content,

signatures, signature attributes, and (ifpresent) document attributes).

§ 142.312 Effective date of the initialimplementation of the security andelectronic signature standards.

(a) General rules.(1) Except for a small health plan

(defined at § 142.103), each entitydesignated in § 142.302 must complywith the requirements of this subpart by[24 months after the effective date of thefinal rule in the Federal Register].

(2) A delay in an effective date forusing a standard transaction describedin this part does not delay the effectivedates described in paragraphs (a)(1) and(b) of this section.

(3) The requirements of the securitystandard may be implemented overtime. Implementation must becompleted by the applicable effectivedate.

(b) Small health plans. A small healthplan must comply with therequirements of this subpart by [36months after the effective date of thefinal rule in the Federal Register].

Authority: Sections 1173 and 1175 of theSocial Security Act (42 U.S.C. 1320d–2 and1320d–4).

Dated: July 15, 1998.Donna E. Shalala,Secretary.

Note: The following appendix will notappear in the Code of Federal Regulations.

Addendum 1

HIPAA Security Matrix

Please Note: (1) While we have attemptedto categorize security requirements for ease ofunderstanding and reading clarity, there areoverlapping areas on the matrix in which thesame requirements are restated in a slightlydifferent context. (2) To ensure that noRequirement or Implementation feature isconsidered more important than another, thismatrix has been presented, within eachsubject area, in alphabetical order.



CertificationChain of trust partner agreementContingency plan (all listed implementation features must be imple-

mented).Applications and data criticality analysis.Data backup plan.Disaster recovery plan.Emergency mode operation plan.Testing and revision.

Formal mechanism for processing records.Information access control (all listed implementation features must be

implemented).Access authorization.Access establishment.Access modification.

Internal audit


ADMINISTRATIVE PROCEDURES TO GUARD DATA INTEGRITY, CONFIDENTIALITY, AND AVAILABILITY—Continued


Personnel security (all listed implementation features must be imple-mented).

Assure supervision of maintenance personnel by authorized, knowl-edgeable person.

Maintainance of record of access authorizations.Operating, and in some cases, maintenance personnel have proper ac-

cess authorization.Personnel clearance procedure.Personnel security policy/procedure.System users, including maintenance personnel, trained in security.

Security configuration mgmt. (all listed implementation features must beimplemented).

Documentation.Hardware/software installation & maintenance review and testing for

security features.Inventory.Security Testing.Virus checking.

Security incident procedures (all listed implementation features must beimplemented).

Report procedures.Response procedures.

Security management process (all listed implementation features mustbe implemented).

Risk analysis.Risk management.Sanction policy.Security policy.

Termination procedures (all listed implementation features must be im-plemented).

Combination locks changed.Removal from access lists.Removal of user account(s).Turn in keys, token or cards that allow access.

Training (all listed implementation features must be implemented) ........ Awareness training for all personnel (including mgmt).Periodic security reminders.User education concerning virus protection.User education in importance of monitoring log in success/failure, and

how to report discrepancies.User education in password management.



Assigned security responsibilityMedia controls (all listed implementation features must be imple-

mented).Access control.Accountability (tracking mechanism).Data backup.Data storage.Disposal.

Physical access controls (limited access) (all listed implementation fea-tures must be implemented).

Disaster recovery.Emergency mode operation.Equipment control (into and out of site).Facility security plan.Procedures for verifying access authorizations prior to physical access.Maintenance records.Need-to-know procedures for personnel access.Sign-in for visitors and escort, if appropriate.Testing and revision.

Policy/guideline on work station useSecure work station locationSecurity awareness training



Access control (The following implementation feature must be imple-mented: Procedure for emergency access. In addition, at least one ofthe following three implementation features must be implemented:Context-based access, Roll-based access, User-based access. Theuse of Encryption is optional).

Context-based access.Encryption.Procedure for emergency access.Role-based access.User-based access.

Audit controlsAuthorization Control (At least one of the listed implementation features

must be implemented).Role-based access.User-based access

Data Authentication


TECHNICAL SECURITY SERVICES TO GUARD DATA INTEGRITY, CONFIDENTIALITY, AND AVAILABILITY—Continued


Entity Authentication (The following implementation features must beimplemented: Automatic logoff, Unique user identification. In addition,at least one of the other listed implementation features must be im-plemented).

Automatic logoff.Biometric.Password.PIN.Telephone callback.Token.Unique user identification.

TECHNICAL SECURITY MECHANISMS TO GUARD AGAINST UNAUTHORIZED ACCESS TO DATA THAT IS TRANSMITTED OVER ACOMMUNICATIONS NETWORK


Communications/network controls (The following implementation features must be imple-mented: Integrity controls, Message authentication. If communications or networking is em-ployed, one of the following implementation features must be implemented: Access controls,Encryption. In addition, if using a network, the following four implementation features must beimplemented: Alarm, Audit trail, Entity authentication, Event reporting).

Access controls.Alarm.Audit trail.Encryption.Entity authentication.Event reporting.Integrity controls.Message authentication.



Digital signature (If digital signature is employed, the following three im-plementation features must be implemented: Message integrity, Non-repudiation, User authentication. Other implementation features areoptional).

Ability to add attributes.Continuity of signature capability.Counter signatures.Independent verifiability.Interoperability.Message integrity.Multiple Signatures.Non-repudiation.Transportability.User authentication.

Addendum 2—HIPAA Security andElectronic Signature Standards Glossary ofTerms

Please Note:(1) While we have attempted to categorize

security requirements for ease ofunderstanding and reading clarity, there areoverlapping areas on the matrix in which thesame requirements are restated in a slightlydifferent context.

(2) While not appearing on the matrix, anumber of terms listed below do appear inthe glossary descriptions and have beensupplied for additional clarity:

(3) The definitions provided in thisdocument have been obtained from multiplesources.Ability to add attributes:

One possible capability of a digitalsignature technology, for example, theability to add a time stamp as part of adigital signature.

Part of digital signature on the matrix.Access:

The ability or the means necessary to read,write, modify, or communicate data/information or otherwise make use ofany system resource.

Access authorization:Information-use policies/procedures that

establish the rules for granting and/or

restricting access to a user, terminal,transaction, program, or process.

Part of information access control on thematrix.

Access control:A method of restricting access to resources,

allowing only privileged entities access.(PGP, Inc.)

Types of access control include, amongothers, mandatory access control,discretionary access control, time-of-day,classification, and subject-objectseparation.

Part of Media Controls on the matrix.Part of technical security services to

control and monitor access toinformation on the matrix.

Access controls:The protection of sensitive

communications transmissions overopen or private networks so that itcannot be easily intercepted andinterpreted by parties other than theintended recipient.

Part of mechanisms to preventunauthorized access to data that istransmitted over a communicationsnetwork on the matrix.

Access establishment:The security policies, and the rules

established therein, that determine an

entity’s initial right of access to aterminal, transaction, program, orprocess.


Access Level:A level associated with an individual who

may be accessing information (forexample, a clearance level) or with theinformation which may be accessed (forexample, a classification level). (NRC,1991, as cited in HISB, DRAFTGLOSSARY OF TERMS RELATED TOINFORMATION SECURITY IN HEALTHCARE INFORMATION SYSTEMS draftGlossary of Terms Related to InformationSecurity in Health Care InformationSystems)

Access modification:The security policies, and the rules

established therein, that determine typesof, and reasons for, modification to anentity’s established right of access to aterminal, transaction, program, orprocess.


Accountability:The property that ensures that the actions

of an entity can be traced uniquely tothat entity. (ASTM E1762—95)


Part of media controls on the matrix.Administrative procedures to guard data

integrity, confidentiality and availability:Documented, formal practices to manage

(1) the selection and execution ofsecurity measures to protect data, and (2)the conduct of personnel in relation tothe protection of data.

A section of the matrix.Alarm, event reporting, and audit trail:

(1) Alarm: In communication systems, anydevice that can sense an abnormalcondition within the system andprovide, either locally or remotely, asignal indicating the presence of theabnormality. (188) NOTE: The signalmay be in any desired form ranging froma simple contact closure (or opening) toa time-phased automatic shutdown andrestart cycle. (Glossary of INFOSEC andINFOSEC Related Terms—Idaho StateUniversity)

(2) Event reporting: Network messageindicating operational irregularities inphysical elements of a network or aresponse to the occurrence of asignificant task, typically the completionof a request for information. (Glossary ofINFOSEC and INFOSEC Related Terms—Idaho State University)

(3) Audit trail: Data collected andpotentially used to facilitate a securityaudit. (ISO 7498–2, as cited in HISB,DRAFT GLOSSARY OF TERMSRELATED TO INFORMATIONSECURITY IN HEALTH CAREINFORMATION SYSTEMS draftGlossary of Terms Related to InformationSecurity in Health Care InformationSystems)


Applications and data criticality analysis:An entity’s formal assessment of the

sensitivity, vulnerabilities, and securityof its programs and information itreceives, manipulates, stores, and/ortransmits.

Part of contingency plan on the matrix.Assigned security responsibility:

Practices put in place by management tomanage and supervise (1) the executionand use of security measures to protectdata, and (2) the conduct of personnel inrelation to the protection of data.

Part of Physical safeguards to guard dataintegrity, confidentiality, and availabilityon the matrix.

Assure supervision of maintenance personnelby authorized, knowledgeable person:

Documented formal procedures/instructionfor the oversight of maintenancepersonnel when such personnel are inthe vicinity of health informationpertaining to an individual.

Part of personnel security on the matrix.Asymmetric encryption:

Encryption and decryption performedusing two different keys, one of which isreferred to as the public key and one ofwhich is referred to as the private key.

Also known as public-key encryption.(Stallings)

Asymmetric key:

One half of a key pair used in anasymmetric (‘‘public-key’’) encryptionsystem. Asymmetric encryption systemshave two important properties: (1) thekey used for encryption is different fromthe one used for decryption (2) neitherkey can feasibly be derived from theother. (CORBA Security Services, 1997)

Audit controls:The mechanisms employed to record and

examine system activity.Part of technical security services to

control and monitor access toinformation on the matrix.

Authorization control:The mechanism for obtaining consent for

the use and disclosure of healthinformation.

Part of technical security services tocontrol and monitor access toinformation on the matrix.

Automatic logoff:After a pre-determined time of inactivity

(for example, 15 minutes), an electronicsession is terminated.

Part of entity authentication on the matrix.Availability:

The property of being accessible anduseable upon demand by an authorizedentity. (ISO 7498–2, as cited in the HISBdraft Glossary of Terms Related toInformation Security In Health careInformation Systems)

Awareness training for all personnel(including management):

All personnel in an organization shouldundergo security awareness training,including, but not limited to, passwordmaintenance, incident reporting, and aneducation concerning viruses and otherforms of malicious software.

Part of Training on the matrix.Biometric:.

A biometric identification system identifiesa human from a measurement of aphysical feature or repeatable action ofthe individual (for example, handgeometry, retinal scan, iris scan,fingerprint patterns, facialcharacteristics, DNA sequencecharacteristics, voice prints, and handwritten signature). (ASTM E1762—95, ascited in the HISB draft Glossary of TermsRelated to Information Security In Healthcare Information Systems)

Part of entity authentication on the matrix.Certification:

The technical evaluation performed as partof, and in support of, the accreditationprocess that establishes the extent towhich a particular computer system ornetwork design and implementationmeet a pre-specified set of securityrequirements. This evaluation may beperformed internally or by an externalaccrediting agency.

Part of administrative procedures to guarddata integrity, confidentiality, andavailability.

Chain of Trust Partner Agreement:Contract entered into by two business

partners in which it is agreed toexchange data and that the first partywill transmit information to the secondparty, where the data transmitted isagreed to be protected between the

partners. The sender and receiverdepend upon each other to maintain theintegrity and confidentiality of thetransmitted information. Multiple suchtwo-party contracts may be involved inmoving information from the originatorto the ultimate recipient, for example, aprovider may contract with a clearinghouse to transmit claims to the clearinghouse; the clearing house, in turn, maycontract with another clearing house orwith a payer for the further transmittalof those same claims.

Part of administrative procedures to guarddata integrity, confidentiality andavailability on the matrix..

Classification:Protection of data from unauthorized

access by the designation of multiplelevels of access authorization clearancesto be required for access, dependentupon the sensitivity of the information.

A type of access control on the matrix.Clearing House:

* * * a public or private entity thatprocesses or facilitates the processing ofnonstandard data elements of healthinformation into standard data elements.(HIPAA, Subtitle F, Section 262(a)Section 1171(2))

Combination locks changed:Documented procedure for changing

combinations of locking mechanisms,both on a recurring basis and whenpersonnel knowledgeable ofcombinations no longer have a need toknow or a requirement for access to theprotected facility/system.

Part of termination procedures on thematrix.

Confidentiality:The property that information is not made

available or disclosed to unauthorizedindividuals, entities or processes. (ISO7498–2, as cited in the HISB draftGlossary of Terms Related to InformationSecurity In Health care InformationSystems) .

Context-based access:An access control based on the context of

a transaction (as opposed to being basedon attributes of the initiator or target).The ‘‘external’’ factors might includetime of day, location of the user, strengthof user authentication, etc.

Part of access control on the matrix.Contingency Plan:

A plan for responding to a systememergency. The plan includesperforming backups, preparing criticalfacilities that can be used to facilitatecontinuity of operations in the event ofan emergency, and recovering from adisaster. (O’Reilly, 1992, as cited in theHISB draft Glossary of Terms Related toInformation Security In Health careInformation Systems) Contingency plansshould be updated routinely.

Part of Administrative procedures to guarddata integrity, confidentiality andavailability on the matrix.

Continuity of signature capability:The public verification of a signature shall

not compromise the ability of the signerto apply additional secure signatures ata later date. (ASTM E 1762—95)


Part of digital signature on the matrix.Counter signatures:

It shall be possible to prove the order ofapplication of signatures. This isanalogous to the normal businesspractice of countersignatures, wheresome party signs a document which hasalready been signed by another party.(ASTM E 1762 -95)

Part of digital signature on the matrix.Data:

A sequence of symbols to which meaningmay be assigned. (NRC, 1991, as cited inthe HISB draft Glossary of Terms Relatedto Information Security In Health careInformation Systems)

Data authentication:The corroboration that data has not been

altered or destroyed in an unauthorizedmanner. Examples of how datacorroboration may be assured includethe use of a check sum, double keying,a message authentication code, or digitalsignature.

Part of technical security services tocontrol and monitor access toinformation on the matrix

Data backup:A retrievable, exact copy of information.Part of media controls on the matrix.

Data backup plan:A documented and routinely updated plan

to create and maintain, for a specificperiod of time, retrievable exact copies ofinformation.

Part of contingency plans on the matrix.Data Integrity:

The property that dat has [sic] not beenaltered or destroyed in an unauthorizedmanner. (ASTM E1762–95).

Data storage:The retention of health care information

pertaining to an individual in anelectronic format.

Part of media controls on the matrix.Digital signature:

An electronic signature based uponcryptographic methods of originatorauthentication, computed by using a setof rules and a set of parameters such thatthe identity of the signer and theintegrity of the data can be verified.(FDA Electronic Record; ElectronicSignatures; Final Rule)

Part of electronic signature on the matrix.Disaster recovery:

The process whereby an enterprise wouldrestore any loss of data in the event offire, vandalism, natural disaster, orsystem failure. (CPRI, 1996c, as cited inHISB, DRAFT GLOSSARY OF TERMSRELATED TO INFORMATIONSECURITY IN HEALTH CAREINFORMATION SYSTEMS draftGlossary of Terms Related to InformationSecurity in Health Care InformationSystems)

Part of physical access controls (limitedaccess) on the matrix.

Disaster recovery plan:Part of an overall contingency plan. The

plan for a process whereby an enterprisewould restore any loss of data in theevent of fire, vandalism, natural disaster,or system failure. (CPRI, 1996c, as cited

in HISB, DRAFT GLOSSARY OF TERMSRELATED TO INFORMATIONSECURITY IN HEALTH CAREINFORMATION SYSTEMS draftGlossary of Terms Related to InformationSecurity in Health Care InformationSystems)

Part of contingency plan on the matrix.Discretionary access control:

Discretionary Access Control (DAC) is usedto control access by restricting a subject’saccess to an object. It is generally usedto limit a user’s access to a file. In thistype of access control it is the owner ofthe file who controls other users’accesses to the file.

A type of access control on the matrix.Disposal:

The final disposition of electronic data,and/or the hardware on which electronicdata is stored.

Part of media controls on the matrix.Documentation:

Written security plans, rules, procedures,and instructions concerning allcomponents of an entity’s security.

Part of security configuration mgmt on thematrix.

Electronic data interchange (EDI):Intercompany, computer-to-computer

transmission of business information ina standard format. For EDI purists,‘‘computer-to-computer’’ means directtransmission from the originatingapplication program to the receiving, orprocessing, application program, and anEDI transmission consists only ofbusiness data, not any accompanyingverbiage or free-form messages. Puristsmight also contend that a standardformat is one that is approved by anational or international standardsorganization, as opposed to formatsdeveloped by industry groups orcompanies. (EDI Security, Control, andAudit)

Electronic signature:The attribute that is affixed to an electronic

document to bind it to a particularentity. An electronic signature processsecures the user authentication (proof ofclaimed identity, such as by biometrics(fingerprints, retinal scans, hand writtensignature verification, etc.), tokens orpasswords) at the time the signature isgenerated; creates the logicalmanifestation of signature (including thepossibility for multiple parties to sign adocument and have the order ofapplication recognized and proven) andsupplies additional information such astime stamp and signature purposespecific to that user; and ensures theintegrity of the signed document toenable transportability, interoperability,independent verifiability, and continuityof signature capability. Verifying asignature on a document verifies theintegrity of the document and associatedattributes and verifies the identity of thesigner. There are several technologiesavailable for user authentication,including passwords, cryptography, andbiometrics. (ASTM 1762–95, as cited inthe HISB draft Glossary of Terms Related

to Information Security In Health careInformation Systems)

Emergency mode operation:Access controls in place that enable an

enterprise to continue to operate in theevent of fire, vandalism, natural disaster,or system failure.


Emergency mode operation plan:Part of an overall contingency plan. The

plan for a process whereby an enterprisewould be able to continue to operate inthe event of fire, vandalism, naturaldisaster, or system failure.

Part of contingency plan on the matrix.Encryption:

Transforming confidential plaintext intociphertext to protect it. Also calledencipherment. An encryption algorithmcombines plaintext with other valuescalled keys, or ciphers, so the databecomes unintelligible. Once encrypted,data can be stored or transmitted overunsecured lines. (EDI Security, Control,and Audit)

Decrypting data reverses the encryptionalgorithm process and makes theplaintext available for further processing.

Part of access control on the matrix.Entity authentication:

1. The corroboration that an entity is theone claimed. (ISO 7498–2, as cited in theHISB draft Glossary of Terms Related toInformation Security In Health careInformation Systems)

Part of technical security services tocontrol and monitor access toinformation on the matrix.

2. A communications/network mechanismto irrefutably identify authorized users,programs, and processes, and to denyaccess to unauthorized users, programsand processes.


Equipment control (into and out of site):Documented security procedures for

bringing hardware and software into andout of a facility and for maintaining arecord of that equipment. This includes,but is not limited to, the marking,handling, and disposal of hardware andstorage media.


Facility security plan:A plan to safeguard the premises and

building(s) (exterior and interior) fromunauthorized physical access, and tosafeguard the equipment therein fromunauthorized physical access, tampering,and theft.


Formal mechanism for processing records:Documented policies and procedures for

the routine, and non-routine, receipt,manipulation, storage, dissemination,transmission, and/or disposal of healthinformation.


Part of administrative procedures to guarddata integrity, confidentiality, andavailability on the matrix.

Hardware/software installation &maintenance review and testing forsecurity features:

Formal, documented procedures for (1)connecting and loading new equipmentand programs, (2) periodic review of themaintenance occurring on thatequipment and programs, and (3)periodic security testing of the securityattributes of that hardware/software.


Independent verifiability:The capability to verify the signature

without the cooperation of the signer.Technically, it is accomplished using thepublic key of the signatory, and it is aproperty of all digital signaturesperformed with asymmetric keyencryption

Part of digital signature on the matrix.Information:

Data to which meaning is assigned,according to context and assumedconventions. (National Security Council,1991, as cited in the HISB draft Glossaryof Terms Related to Information SecurityIn Health care Information Systems)

Information access control:Formal, documented policies and

procedures for granting different levelsof access to health care information.

Part of administrative procedures to ensureintegrity and confidentiality on thematrix.

Integrity controls:Security mechanism employed to ensure

the validity of the information beingelectronically transmitted or stored.


Internal audit:The in-house review of the records of

system activity (for example, logins, fileaccesses, security incidents) maintainedby an organization.


Interoperability:The applications used on either side of a

communication, between tradingpartners and/or between internalcomponents of an entity, being able toread and correctly interpret theinformation communicated from one tothe other.

Part of digital signature on the matrix.Inventory:

Formal, documented identification ofhardware and software assets.


Key:An input that controls the transformation

of data by an encryption algorithm (NRC,1991, as cited in the HISB draft Glossary

of Terms Related to Information SecurityIn Health care Information Systems)

Maintenance of record of accessauthorizations:

Ongoing documentation and review of thelevels of access granted to a user,program, or procedure accessing healthinformation.

Part of personnel security on the matrix.Maintenance records:

Documentation of repairs andmodifications to the physicalcomponents of a facility, for example,hardware, software, walls, doors, locks.


Mandatory Access Control (MAC):A means of restricting access to objects that

is based on fixed security attributesassigned to users and to files and otherobjects. The controls are mandatory inthe sense that they cannot be modifiedby users or their programs. (Stallings,1995) (as cited in the HISB draft Glossaryof Terms Related to Information SecurityIn Health care Information Systems)

A type of access control on the matrix.Media controls:

Formal, documented policies andprocedures that govern the receipt andremoval of hardware/software (forexample, diskettes, tapes) into and out ofa facility.

Part of physical safeguards to guard dataintegrity, confidentiality, and availabilityon the matrix.

Message:A digital representation of information.

(ABA Digital Signatures Guidelines)Message authentication:

Ensuring, typically with a messageauthentication code, that a messagereceived (usually via a network) matchesthe message sent. (O’Reilly, 1992, ascited in the HISB draft Glossary of TermsRelated to Information Security In Healthcare Information Systems)

Part of mechanisms to preventunauthorized access to data that istransmitted over a communicationsnetwork on the matrix

Message authentication code:Data associated with an authenticated

message that allows a receiver to verifythe integrity of the message. (Glossary ofINFOSEC and INFOSEC Related Terms—Idaho State University)

Message integrity:The assurance of unaltered transmission

and receipt of a message from the senderto the intended recipient. (ABA DigitalSignature Guidelines)

Part of digital signature on the matrix.Multiple signatures:

It shall be possible for multiple parties tosign a document. Multiple signatures areconceptually, simply appended to thedocument. (ASTM E 1762–95)

Part of digital signature on the matrix.Need-to-know procedures for personnel

access:A security principle stating that a user

should have access only to the data heor she needs to perform a particularfunction. (O’Reilly, 1992, as cited in theHISB draft Glossary of Terms Related to

Information Security In Health careInformation Systems)


Nonrepudiation:Strong and substantial evidence of the

identity of the signer of a message andof message integrity, sufficient to preventa party from successfully denying theorigin, submission or delivery of themessage and the integrity of its contents.(ABA Digital Signature Guidelines)

Part of digital signature on the matrix.Operating, and in some cases, maintenance

personnel have proper accessauthorizations:

Formal, documented policies andprocedures to be followed indetermining the access level to begranted to individuals working on, or inthe vicinity of, health information.

Part of personnel security on the matrix.Password:

Confidential authentication informationcomposed of a string of characters. (ISO7498—2, as cited in the HISB draftGlossary of Terms Related to InformationSecurity In Health care InformationSystems)

Part of entity authentication on the matrix.Periodic security reminders:

Employees, agents and contractors shouldbe made aware of security concerns onan ongoing basis.

Part of training on the matrix.Personnel clearance procedure:

A protective measure applied to determinethat an individual’s access to sensitiveunclassified automated information isadmissible. The need for and extent of ascreening process is normally based onan assessment of risk, cost, benefit, andfeasibility as well as other protectivemeasures in place. Effective screeningprocesses are applied in such a way asto allow a range of implementation, fromminimal procedures to more stringentprocedures commensurate with thesensitivity of the data to be accessed andthe magnitude of harm or loss that couldbe caused by the individual (DOE1360.2A, as cited in Glossary ofINFOSEC and INFOSEC Related Terms—Idaho State University)

Part of personnel security on the matrix.Personnel security:

The procedures established to ensure thatall personnel who have access tosensitive information have the requiredauthority as well as appropriateclearances. (NCSC Glossary of ComputerSecurity Terms, October 21, 1988)

Part of administrative procedures to guarddata integrity, confidentiality andavailability on the matrix.

Personnel security policy/procedure:Formal, documentation of policies and

procedures established to ensure that allpersonnel who have access to sensitiveinformation have the required authorityas well as appropriate clearances.(Glossary of INFOSEC and INFOSECRelated Terms—Idaho State University)

Part of personnel security on the matrix.Physical access controls (limited access):

Those formal, documented policies andprocedures to be followed to limit


physical access to an entity whileensuring that properly authorized accessis allowed.


Physical safeguards:Protection of physical computer systems

and related buildings and equipmentfrom fire and other natural andenvironmental hazards, as well as fromintrusion. Also covers the use of locks,keys, and administrative measures usedto control access to computer systemsand facilities. (O’Reilly, 1992, as cited inHISB, draft Glossary of Terms Related toInformation Security in Health CareInformation Systems)

A section of the matrix covering physicalsecurity requirements.

PIN (Personal Identification Number):A number or code assigned to an

individual and used to provideverification of identity.

Part of entity authentication on the matrix.Policy/guideline on work station use:

Documented instructions/proceduresdelineating the proper functions to beperformed, the manner in which thosefunctions are to be performed, and thephysical attributes of the surroundings,of a specific computer terminal site ortype of site, dependant upon thesensitivity of the information accessedfrom that site.


Procedure for emergency access:Documented instructions for obtaining

necessary information during a crisis.Part of access control on the matrix.

Procedures for verifying accessauthorizations prior to physical access:

Formal, documented policies andinstructions for validating the accessprivileges of an entity prior to grantingthose privileges.


Provider:A supplier of services as defined in section

1861(u) of the HIPAA.A supplier of medical or other services as

defined in section 1861(s) of the HIPAA.Public key:

One of the two keys used in an asymmetricencryption system. The public key ismade public, to be used in conjunctionwith a corresponding private key.[Stallings, 1995]

Removal from access lists:The physical eradication of an entity’s

access privileges.Part of termination procedures on the

matrix.Removal of user account(s):

The termination or deletion of anindividual’s access privileges to theinformation, services, and resources forwhich they currently have clearance,authorization, and need-to-know whensuch clearance, authorization and need-to-know no longer exists.


Report procedures:

The documented formal mechanismemployed to document securityincidents.

Part of security incident procedures on thematrix.

Response procedures:The documented formal rules/instructions

for actions to be taken as a result of thereceipt of a security incident report.

Part of security incident procedures on thematrix.

Risk analysis:Risk analysis, a process whereby cost-

effective security/control measures maybe selected by balancing the costs ofvarious security/control measuresagainst the losses that would be expectedif these measures were not in place.

Part of the security management process onthe matrix.

Risk management:Risk is the possibility of something adverse

happening. Risk management is theprocess of assessing risk, taking steps toreduce risk to an acceptable level andmaintaining that level of risk. (NIST Pub.800–14)


Role-based access control:Role-based access control (RBAC) is an

alternative to traditional access controlmodels (e.g., discretionary or non-discretionary access control policies)that permits the specification andenforcement of enterprise-specificsecurity policies in a way that mapsmore naturally to an organization’sstructure and business activities. WithRBAC, rather than attempting to map anorganization’s security policy to arelatively low-level set of technicalcontrols (typically, access control lists),each user is assigned to one or morepredefined roles, each of which has beenassigned the various privileges needed toperform that role.

Part of access control on the matrix.Part of authorization control on the matrix.

Sanction policy:Organizations must have policies and

procedures regarding disciplinaryactions which are communicated to allemployees, agents and contractors, forexample, verbal warning, notice ofdisciplinary action placed in personnelfiles, removal of system privileges,termination of employment and contractpenalties (ASTM E 1869)

In addition to enterprise sanctions,employees, agents, and contractors mustbe advised of civil or criminal penaltiesfor misuse or misappropriation of healthinformation. Employees, agents andcontractors, must be made aware thatviolations may result in notification tolaw enforcement officials and regulatory,accreditation and licensureorganizations. (ASTM)


Secure work station location:Physical safeguards to eliminate or

minimize the possibility of unauthorizedaccess to information, for example,locating a terminal used to access

sensitive information in a locked roomand restricting access to that room toauthorized personnel, not placing aterminal used to access patientinformation in any area of a doctor’soffice where the screen contents can beviewed from the reception area.

Part of physical safeguards to guard dataintegrity, confidentiality, and availabilityon the matrix.

Security:Security encompasses all of the safeguards

in an information system, includinghardware, software, personnel policies,information practice policies, disasterpreparedness, and the oversight of allthese areas. The purpose of security is toprotect both the system and theinformation it contains fromunauthorized access from without andfrom misuse from within.

Through various security measures, ahealth information system can shieldconfidential information fromunauthorized access, disclosure andmisuse, thus protecting privacy of theindividuals who are the subjects of thestored data. (Privacy and HealthInformation Systems: A Guide toProtecting Patient Confidentiality)

Security awareness training:All employees, agents, and contractors

must participate in information securityawareness training programs. Based onjob responsibilities, individuals may berequired to attend customized educationprograms that focus on issues regardinguse of health information andresponsibilities regarding confidentialityand security. (ASTM)


Security configuration management:Measures, practices and procedures for the

security of information systems shouldbe coordinated and integrated with eachother and other measures, practices andprocedures of the organization so as tocreate a coherent system of security.(OECD Guidelines, as cited in NIST Pub800–14)


Security incident procedures:Formal, documented instructions for

reporting security breaches.Part of administrative procedures to guard

data integrity, confidentiality andavailability on the matrix.

Security management process:A security management process

encompasses the creation,administration and oversight of policiesto ensure the prevention, detection,containment, and correction of securitybreaches. It involves risk analysis andrisk management, including theestablishment of accountability,management controls (policies andeducation), electronic controls, physicalsecurity, and penalties for the abuse andmisuse of its assets, both physical andelectronic.



Security policy:The framework within which an

organization establishes needed levels ofinformation security to achieve thedesired confidentiality goals. A policy isa statement of information values,protection responsibilities, andorganization commitment for a system.(OTA, 1993) The American HealthInformation Management Associationrecommends that security policies applyto all employees, medical staff members,volunteers, students, faculty,independent contractors, and agents.(AHIMA, 1996c) (as cited in HISB,DRAFT GLOSSARY OF TERMSRELATED TO INFORMATIONSECURITY IN HEALTH CAREINFORMATION SYSTEMS draftGlossary of Terms Related to InformationSecurity in Health Care InformationSystems )

Part of the security management process onthe matrix

Security testing:A process used to determine that the

security features of a system areimplemented as designed and that theyare adequate for a proposed applicationsenvironment. This process includeshands-on functional testing, penetrationtesting, and verification. (Glossary ofINFOSEC and INFOSEC Related Terms—Idaho State University)


Sign-in for visitors and escort, if appropriate:Formal, documented procedure governing

the reception and hosting of visitors.Part of physical access controls (limited

access) on the matrix.Subject/object separation:

Access to a subject does not guaranteeaccess to the objects associated with thatsubject.

Subject is defined as an active entity,generally in the form of a person,process, or device that causesinformation to flow among objects orchanges the system state. Technically, aprocess/domain pair. (Glossary ofINFOSEC and INFOSEC Related Terms—Idaho State University)

Object is defined as a passive entity thatcontains or receives information. Accessto an object potentially implies access tothe information it contains. Examples ofobjects are: records blocks, pages,segments, files, directories, directorytrees, and programs, as well as bits,bytes, words, fields, processors, videodisplays, keyboards, clocks, printers,network nodes, etc. (Glossary ofINFOSEC and INFOSEC Related Terms—Idaho State University)

A type of access control.System users, including maintenance

personnel, trained in security:See Awareness training (including

management).Part of personnel security on the matrix.

Technical security mechanisms:The processes that are put in place to guard

against unauthorized access to data that

is transmitted over a communicationsnetwork,

A section of the matrix.Technical security services:

The processes that are put in place (1) toprotect information and (2) to controland monitor individual access toinformation.

A section of the matrix.Telephone callback:

A method of authenticating the identity ofthe receiver and sender of informationthrough a series of ‘‘questions’’ and‘‘answers’’ sent back and forthestablishing the identity of each. Forexample, when the communicatingsystems exchange a series ofidentification codes as part of theinitiation of a session to exchangeinformation, or when a host computerdisconnects the initial session before theauthentication is complete, and the hostcalls the user back to establish a sessionat a predetermined telephone number.

Part of Entity authentication on the matrix.Termination procedures:

Formal, documented instructions, whichinclude appropriate security measures,for the ending of an employee’semployment, or an internal/externaluser’s access.


Testing and revision:(1) Testing and revision of contingency

plans refers to the documented processof periodic testing to discoverweaknesses in such plans and thesubsequent process of revising thedocumentation if necessary.

Part of contingency plan on the matrix.(2) Testing and revision of programs

should be restricted to formallyauthorized personnel.


Time-of-day:Access to data is restricted to certain time

frames, e.g., Monday through Friday,8:00 a.m. to 6:00 p.m.

A type of access control on the matrix.Time-stamp:

To create a notation that indicates, at least,the correct date and time of an action,and the identity of the person thatcreated the notation.

Token:A physical item that’s used to provide

identity. Typically an electronic devicethat can be inserted in a door or acomputer system to obtain access.(O’Reilly, 1992) (as cited in HISB,DRAFT GLOSSARY OF TERMSRELATED TO INFORMATIONSECURITY IN HEALTH CAREINFORMATION SYSTEMS draftGlossary of Terms Related to InformationSecurity in Health Care InformationSystems)

Part of entity authentication on the matrixTraining:

Education concerning the vulnerabilities ofthe health information in an entity’spossession and ways to ensure theprotection of that information.


Transportability:A signed document can be transported

(over an insecure network) to anothersystem, while maintaining the integrityof the document.

Part of digital signature on the matrix.Turn in keys, token or cards that allow

access:Formal, documented procedure to ensure

all physical items that allow aterminated employee to access aproperty, building, or equipment areretrieved from that employee, preferablyprior to termination.


Unique user identification:The combination name/number assigned

and maintained in security proceduresfor identifying and tracking individualuser identity. (ASTM)

Part of Entity authentication on the matrix.User authentication:

The provision of assurance of the claimedidentity of an entity. (ASTM E1762–5)

Part of digital signature on the matrix.User-based access:

A security mechanism used to grant usersof a system access based upon theidentity of the user.

Part of access control on the matrix.Part of authorization control on the matrix.

User education in importance of monitoringlog in success/failure, and how to reportdiscrepancies:

Training in the user’s responsibility toensure the security of health careinformation.

Part of training on the matrix.User education concerning virus protection:

Training relative to user awareness of thepotential harm that can be caused by avirus, how to prevent the introduction ofa virus to a computer system, and whatto do if a virus is detected.

Part of training on the matrix.User education in password management:

A type of user training in the rules to befollowed in creating and changingpasswords and the need to keep themconfidential.

Part of training on the matrix.Virus checking:

A computer program that identifies anddisables:

(1) another ‘‘virus’’ computer program,typically hidden, that attaches itself toother programs and has the ability toreplicate. (Unchecked virus programsresult in undesired side effects generallyunanticipated by the user.)

(2) A type of programmed threat. A codefragment (not an independent program)that reproduces by attaching to anotherprogram. It may damage data directly, orit may degrade system performance bytaking over system resources which arethen not available to authorized users.(O’Reilly, 1992, as cited in HISB, DRAFTGLOSSARY OF TERMS RELATED TOINFORMATION SECURITY IN HEALTHCARE INFORMATION SYSTEMS draftGlossary of Terms Related to Information


Security in Health Care InformationSystems)

(3) Code embedded within a program thatcauses a copy of itself to be inserted inone or more other programs. In additionto propagation, the virus usuallyperforms some unwanted function.(Stallings, 1995, as cited in HISB,DRAFT GLOSSARY OF TERMSRELATED TO INFORMATIONSECURITY IN HEALTH CAREINFORMATION SYSTEMS draftGlossary of Terms Related to InformationSecurity in Health Care InformationSystems)


AcronymsABA American Bar AssociationADA American Dental AssociationANSI American National Standards

InstituteAHIMA American Health Information

Management AssociationASTM American Society for Testing and

MaterialsCDT Center for Democracy & TechnologyCEN Central European NationsCORBA Common Object Request BrokerCPRI Computer-based Patient Record

InstituteDAC Discretionary Access ControlDEA Data Encryption AlgorithmEDI Electronic Data InterchangeEHNAC Electronic Healthcare Network

Accreditation CommissionFDA Food and Drug AdministrationHISB Health Care Informatics Standards

Board

ISO International Organization forStandardization

MAC Mandatory Access ControlNCSC National Computer Security CenterNCQA National Council for Quality

AssuranceNCVHS National Committee on Vital and

Health StatisticsNUBC National Uniform Billing CommitteeNUCC National Uniform Claim CommitteePGP Pretty Good PrivacyPIN Personal Identification NumberNIST National Institutes of Standards and

TechnologySDO Standards Development OrganizationWEDI Workgroup for Electronic Data

Interchange

Bibliography

ABA, Digital Signature Guidelines.ANSI, ASC X12.58, Security Structures, June,

1997.ASTM, E1762–95, Standard Guide for

Electronic Authentication of Health CareInformation. ASTM Committee E–31 onComputerized Systems, SubcommitteeE31.20 on Authentication. WestConshohocken, PA, October 10, 1995.

ASTM, A Security Framework for HealthcareInformation. ASTM Committee E–31 onComputerized Systems, SubcommitteeE31.20 on Authentication. WestConshohocken, PA, February 11, 1997.

EDI Security, Control, and Audit, Marcells,Albert J. & Chan, Sally. Artech House,685 Canton Street, Norwood, MA 01602,1993.

FDA, Electronic Record; ElectronicSignatures; Final Rule.

For the Record—Protecting Electronic HealthInformation, Computer Science andTelecommunications Board, NRC,National Academy Press, 2102Constitution Avenue, NW, Box 285,Washington, DC, 20055, 1997.

Glossary of INFOSEC and INFOSEC RelatedTerms, Version 6. Schou, Corey D.,Center for Decision Support, Idaho StateUniversity. August, 1996

HISB, DRAFT GLOSSARY OF TERMSRELATED TO INFORMATIONSECURITY IN HEALTH CAREINFORMATION SYSTEMS Glossary ofTerms Related to Information Security inHealth Care Information Systems draft,1997

NCSC, Glossary of Computer Security Terms,October 21, 1988.

NIST Pub 800–14, ‘‘Generally AcceptedPrinciples and Practices for SecuringInformation Technology Systems’’,Swanson, Marianne, & Guttman, Barbara,September, 1996. PGP, Inc., CryptologyReference Chart, August, 1997

Privacy and Health Information Systems: AGuide to Protecting PatientConfidentiality, Goldman, Janlori &Mulligan, Deirdre, CDT, 1996.

Addendum 3

HIPAA SECURITY MATRIX—mapping

Please Note: While we have attempted tocategorize security requirements for ease ofunderstanding and reading clarity, there areoverlapping areas on the matrix in which thesame requirements are restated in a slightlydifferent context.


Requirement Implementation Mappedstandards

Certification ....................................................... ........................................................................... 47.Chain of trust partner agreement ..................... ........................................................................... 12, 47.Contingency plan (all listed implementation

features must be implemented).Applications and data criticality analysis ..........Data backup plan .............................................Disaster recovery plan ......................................Emergency mode operation plan .....................Testing and revision .........................................

17, 47, 53.12, 17, 47.12, 17, 47, 53.47, 53.12, 17, 47.

Formal mechanism for processing records ...... ........................................................................... 12, 17.Information access control (all listed implemen-

tation features must be implemented).Access authorization ........................................Access establishment .......................................Access modification ..........................................

12, 17, 47, 53.17, 47, 53.12, 17, 47, 53.

Internal audit ..................................................... ........................................................................... 12, 17, 43, 44, 47.Personnel security (all listed implementation

features must be implemented)Assure supervision of maintenance personnel

by authorized, knowledgeable person.17, 47.

Maintainance of record of access authoriza-tions.

12, 17, 47.

Operating, and in some cases, maintenancepersonnel have proper access authorization.

17, 47.

Personnel clearance procedure ....................... 17, 47.Personnel security policy/procedure ................. 17, 47, 53.System users, including maintenance person-

nel, trained in security.12, 17, 47, 53.

Security configuration mgmt. (all listed imple-mentation features must be implemented).

Documentation .................................................. 12, 17, 47, 53.

Hardware/software installation & maintenancereview and testing for security features.

12, 17, 47.

Inventory ........................................................... 12, 17.Security testing ................................................. 12, 17, 47.Virus checking .................................................. 12, 17, 47, 53.

Security incident procedures (all listed imple-mentation features must be implemented).

Report procedures ............................................Response procedures ......................................

12, 17, 47.17, 47.


ADMINISTRATIVE PROCEDURES TO GUARD DATA INTEGRITY, CONFIDENTIALITY, AND AVAILABILITY—Continued

Requirement Implementation Mappedstandards

Security management process (all listed imple-mentation features must be implemented).

Risk analysis .....................................................Risk management .............................................Sanction policy .................................................Security policy ..................................................

12, 17, 47, 53.17, 47.12, 17, 47, 53.17, 47, 53.

Termination procedures (all listed implementa-tion features must be implemented).

Combination locks changed .............................Removal from access lists ................................Removal of user account(s) .............................Turn in keys, token or cards that allow access

12, 17.12, 17, 47, 53.12, 17, 47.12, 17, 47.

Training (all listed implementation featuresmust be implemented).

Awareness training for all personnel (includingmgmt).

12, 17, 18, 47, 53.

Periodic security reminders .............................. 12, 18.User education concerning virus protection .....User education in importance of monitoring log

in success/failure, and how to report dis-crepancies.

12, 17, 18.

User education in password management ....... 12, 18, 47


Requirement Implementation Mapped standards

Assigned security responsibility ........................ ........................................................................... 47.Media controls (all listed implementation fea-

tures must be implemented).Access control ..................................................Accountability (tracking mechanism) ................Data backup .....................................................Data storage .....................................................Disposal ............................................................

17, 47, 53.17, 18, 47.12, 17, 47, 53.12, 17, 47.17, 47, 53.

Physical access controls (limited access) (alllisted implementation features must be im-plemented).

Disaster recovery ..............................................Emergency mode operation .............................Equipment control (into and out of site) ...........Facility security plan .........................................

17.17.17, 47.12, 17, 47.

Procedures for verifying access authorizationsprior to physical access.

17, 18, 47.

Maintenance records ........................................ 17Need-to-know procedures for personnel ac-

cess.12, 17, 47, 53

Sign-in for visitors and escort, if appropriate ... 17Testing and revision ......................................... 17, 47

Policy/guideline on work station use ................ ........................................................................... 18.Secure work station location ............................. ........................................................................... 17, 53.Security awareness training .............................. ........................................................................... 12, 17, 47.



Access control (The following implementationfeature must be implemented: Procedure foremergency access, In addition, at least oneof the following three implementation fea-tures must be implemented: Context-basedaccess, Roll-based access, User-based ac-cess. The use of Encryption is optional).

Context-based access, .....................................Encryption .........................................................

Procedure for emergency access .....................Roll-based access, ...........................................User-based access. ..........................................

5, 12, 14, 16, 17, 40, 47.1, 6, 12, 14, 17, 21, 22, 23, 24, 26, 36, 28, 29,

30, 31, 47, 49, 53, 54, 55.14, 17, 53.14, 16, 17, 40, 41, 47, 53.11, 12, 14, 16, 17, 40, 41, 47, 53.

Audit controls .................................................... ........................................................................... 12, 14, 18, 47, 53.Authorization control (At least one of the listed

implementation features must be imple-mented).

Role-based access ...........................................User-based access ...........................................

5, 14, 16, 17, 47, 53.14, 16, 47, 53.

Data authentication ........................................... ........................................................................... 11, 53.Entity Authentication (The following implemen-

tation features must be implemented: Auto-matic logoff, Unique user identification. Inaddition, at least one of the other listed im-plementation features must be implemented).

Automatic logoff ................................................Biometric ...........................................................Password ..........................................................PIN ....................................................................Telephone callback ...........................................Token ................................................................Unique user identification .................................

14, 16, 17, 18, 40, 5314, 16, 18, 40, 47, 53.14, 16, 17, 18, 19, 40, 47, 53.14, 16, 18, 19, 40, 47.14, 17, 18, 47, 53.14, 17, 47, 50, 53.14, 47, 53.


TECHNICAL SECURITY MECHANISMS TO GUARD DATA INTEGRITY, CONFIDENTIALITY, AND AVAILABILITY


Communications/network controls (If commu-nications or networking is employed, the fol-lowing implementation features must be im-plemented: Integrity controls, Message au-thentication. In addition, one of the followingimplementation features must be imple-mented: Access controls, Encryption. In ad-dition, if using a network, the following fourimplementation features must be imple-mented: Alarm, Audit trail, Entity authentica-tion, Event reporting).

Access controls ................................................Alarm, event reporting, and audit trail ..............Audit trailEncryption .........................................................

Entity authentication .........................................

Event reportingIntegrity controls ...............................................Message authentication ....................................

14, 17, 22, 23, 39, 47, 48, 53.14, 17, 18, 35, 36, 37, 38, 44.

1, 6, 12, 14, 17, 21, 22, 23, 24, 26, 27, 28, 29,30, 31, 47, 49, 52, 53.

12, 14, 17, 18, 20, 22, 23, 31, 32, 33, 34, 51,53.

14, 15, 17, 18, 22, 23, 45, 46.14, 15, 17, 18, 22, 23, 25, 45, 46, 52.



Digital signature (If digital signature is em-ployed, the following three implementationfeatures must be implemented: Message in-tegrity, Non-repudiation, User authentication.Other implementation features are optional).

Ability to add attributes .....................................Continuity of signature capability .....................Counter signatures ...........................................Independent verifiability ....................................Interoperability ..................................................Message integrity .............................................Multiple signatures ............................................Non-repudiation ................................................Transportability .................................................User authentication ...........................................

3, 4, 10, 11, 13, 203, 4, 11, 13, 14, 183, 4, 10, 11, 13, 14, 183, 4, 11, 13, 203, 4, 7, 8, 9, 13, 14, 483, 4, 10, 11, 13, 14, 183, 4, 10, 11, 13, 202, 3, 4, 10, 11, 13, 14, 423, 4, 11, 13, 14, 183, 4, 10, 11, 13, 20

Mapped Standards

1. ANSI X3.92—Data Encryption Standard2. ANSI X9.30—Part 1: Public Key

Cryptography Using IrreversibleAlgorithms: Digital Signature Algorithm

3. ANSI X9.30—Part 2: Public KeyCryptography Using IrreversibleAlgorithms: Secure Hash Algorithm (SHA–1)

4. ANSI X9.31—Reversible Digital SignatureAlgorithms

5. ANSI X9.45—Enhanced ManagementControls Using Digital Signatures andAttribute Certificates

6. ANSI X9.52—Triple DES Modes ofOperation

7. ANSI X9.55—Extensions to Public KeyCertificates and CRLs

8. ANSI X9.57—Certificate Management9. ANSI X9.62—Elliptic Curve Digital

Signature Algorithm (draft)10. ANSI X12.58—Security Structures

(version 2)11. ASTM E 1762—Standard Guide for

Authentication of Healthcare Information12. ASTM E 1869—Draft Standard for

Confidentiality, Privacy, Access and DataSecurity Principles

13. ASTM PS 100–97—StandardSpecification for Authentication ofHealthcare Information Using DigitalSignatures

14. ASTM PS 101–97—Security Frameworkfor Healthcare Information

15. ASTM PS 102–97—Standard Guide forInternet and Intranet Security

16. ASTM PS 103–97 Authentication &Authorization Guideline

17. CEN—European Pre-Standard18. FDA—Electronic Records—Electronic

Signatures—Final Rule

19. FIPS PUB 112—Password Usage20. FIPS PUB 196—Entity Authentication

Using Public Key Cryptography21. FIPS PUB 46–2—Data Encryption

Standard22. IEEE 802.10: Interoperable LAN/MAN

Security (SILS), 1992–1996 (multiple parts)23. IEEE 802.10c—LAN/WAN Security—Key

Management24. IETF ID—Combined SSL/PCT Transport

Layer Security Protocol25. IETF ID—FTP Authentication Using DSA26. IETF ID—Secure HyperText TP Protocol

(S–HTTP)27. IETF ID—SMIME Cert Handling28. IETF ID—SMIME Message Specification29. IETF RFC 1422—Privacy Enhanced Mail:

Part 1: Message Encryption andAuthentication Procedures

30. IETF RFC 1424—Privacy Enhanced Mail:Part 2: Certificate-Based Key Management

31. IETF RFC 1423—Privacy Enhanced Mail:Part 3: Algorithms, Modes, and Identifiers

32. ISO/IEC 9798–1: InformationTechnology—Security Techniques—EntityAuthentication Mechanisms—Part 1:General Model

33. ISO/IEC 9798–2: InformationTechnology—Security Techniques—EntityAuthentication Mechanisms—Part 2: EntityAuthentication Using AsymmetricTechniques

34. ISO/IEC 9798–2: InformationTechnology—Security Techniques—EntityAuthentication Mechanisms—Part 2: EntityAuthentication Using SymmetricTechniques

35. ISO/IEC 10164–4—InformationTechnology—Open Systems Connection—System Management: Alarm ReportingFunction

36. ISO/IEC 10164–5—InformationTechnology—Open Systems Connection—System Management: Event ReportManagement Function

37. ISO/IEC 10164–7—InformationTechnology—Open Systems Connection—System Management: Security AlarmReporting Function

38. ISO/IEC 10164–8—InformationTechnology—Open Systems Connection—System Management: Security Audit TrailFunction

39. ISO/IEC 10164–9—InformationTechnology—Open Systems Connection—System Management: Objects andAttributes for Access Control

40. ISO/IEC 10181–2—InformationTechnology—Security Frameworks inOpen Systems—Authentication Framework

41. ISO/IEC 10181–3—InformationTechnology—Security Frameworks inOpen Systems—Access Control Framework

42. ISO/IEC 10181–4—InformationTechnology—Security Frameworks inOpen Systems—Non-repudiationFramework

43. ISO/IEC 10181–5—InformationTechnology—Security Frameworks inOpen Systems—Confidentiality Framework

44. ISO/IEC 10181–7—InformationTechnology—Security Frameworks inOpen Systems—Security Audit Framework

45. ISO/IEC 10736—InformationTechnology—Telecommunications andInformation Exchange Between Systems—Transport Layer Security Protocol (TLSP)


46. ISO/IEC 11577—InformationTechnology—Telecommunications andInformation Exchange Between Systems—Network Layer Security Protocol (NLSP)

47. NIST—Generally Accepted Principlesand Practices for Secure InformationTechnology Systems

48. NIST MISPC—Minimum InteroperabilitySpecification for PKI Components Version1

49. PKCS #7—Cryptographic Message SyntaxStandard Version 1.5 or later

50. PKCS #11—Cryptoki B A CryptographicToken Interface

51. RFC 1510—Kerberos AuthenticationService

52. RFC 2104—HMAC:Keyed-Hashing forMessage Authentication

53. For the Record—Protecting ElectronicHealth Information

54. ANSI X9.42—Management of SymmetricKeys Using Diffie-Hellman

55. ANSI X9.44—Key Transport Using RSA

[FR Doc. 98–21601 Filed 8–7–98; 1:23 pm]BILLING CODE 4120–01–P