[Federal Register Volume 63, Number 155 (Wednesday, August 12, 1998)]
[Proposed Rules]
[Pages 43242-43280]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 98-21601]



[[Page 43241]]

_______________________________________________________________________

Part III





Department of Health and Human Services





_______________________________________________________________________



Office of the Secretary



_______________________________________________________________________



45 CFR Part 142



Security and Electronic Signature Standards; Proposed Rule

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

[[Page 43242]]


-----------------------------------------------------------------------

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Part 142

[HCFA-0049-P]
RIN 0938-AI57


Security and Electronic Signature Standards

AGENCY: Health Care Financing Administration (HCFA), HHS.

ACTION: Proposed rule.

-----------------------------------------------------------------------

SUMMARY: This rule proposes standards for the security of individual 
health information and electronic signature use by health plans, health 
care clearinghouses, and health care providers. The health plans, 
health care clearinghouses, and health care providers would use the 
security standards to develop and maintain the security of all 
electronic individual health information. The electronic signature 
standard is applicable only with respect to use with the specific 
transactions defined in the Health Insurance Portability and 
Accountability Act of 1996, and when it has been determined that an 
electronic signature must be used.
    The use of these standards would improve the Medicare and Medicaid 
programs, and other Federal health programs and private health 
programs, and the effectiveness and efficiency of the health care 
industry in general. This rule would implement some of the requirements 
of the Administrative Simplification subtitle of the Health Insurance 
Portability and Accountability Act of 1996.

DATES: Comments will be considered if we receive them at the 
appropriate address, as provided below, no later than 5 p.m. on October 
13, 1998.

ADDRESSES: Mail written comments (1 original and 3 copies) to the 
following address: Health Care Financing Administration, Department of 
Health and Human Services, Attention: HCFA-0049-P, P.O. Box 26585, 
Baltimore, MD 21207-0519.
    If you prefer, you may deliver your written comments (1 original 
and 3 copies) to one of the following addresses:

Room 309-G, Hubert H. Humphrey Building, 200 Independence Avenue, SW., 
Washington, DC 20201, or
Room C5-09-26, 7500 Security Boulevard, Baltimore, MD 21244-1850.

    Comments may also be submitted electronically to the following e-
mail address: [email protected]. For e-mail comment procedures, 
see the beginning of SUPPLEMENTARY INFORMATION. For further information 
on ordering copies of the Federal Register containing this document and 
on electronic access, see the beginning of
SUPPLEMENTARY information.

FOR FURTHER INFORMATION CONTACT: John Parmigiani, (410) 786-2976.

SUPPLEMENTARY INFORMATION:

E-Mail, Comments, Procedures, Availability of Copies, and Electronic 
Access

    E-mail comments should include the full name, postal address, and 
affiliation (if applicable) of the sender and must be submitted to the 
referenced address to be considered. All comments should be 
incorporated in the e-mail message because we may not be able to access 
attachments.
    Because of staffing and resource limitations, we cannot accept 
comments by facsimile (FAX) transmission. In commenting, please refer 
to file code HCFA-0049-P and the specific section or sections of the 
proposed rule. Both electronic and written comments received by the 
time and date indicated above will be available for public inspection 
as they are received, generally beginning approximately 3 weeks after 
publication of a document, in Room 309-G of the Department's offices at 
200 Independence Avenue, SW., Washington, DC, on Monday through Friday 
of each week from 8:30 a.m. to 5 p.m. (phone: (202) 690-7890). 
Electronic and legible written comments will also be posted, along with 
this proposed rule, at the following web site: http://aspe.os.dhhs.gov/
admnsimp/.
    Copies: To order copies of the Federal Register containing this 
document, send your request to: New Orders, Superintendent of 
Documents, P.O. Box 371954, Pittsburgh, PA 15250-7954. Specify the date 
of the issue requested and enclose a check or money order payable to 
the Superintendent of Documents, or enclose your Visa or Master Card 
number and expiration date. Credit card orders can also be placed by 
calling the order desk at (202) 512-1800 or by faxing to (202) 512-
2250. The cost for each copy is $8. As an alternative, you can view and 
photocopy the Federal Register document at most libraries designated as 
Federal Depository Libraries and at many other public and academic 
libraries throughout the country that receive the Federal Register.
    This Federal Register document is also available from the Federal 
Register online database through GPO Access, a service of the U.S. 
Government Printing Office. Free public access is available on a Wide 
Area Information Server (WAIS) through the Internet and via 
asynchronous dial-in. Internet users can access the database by using 
the World Wide Web, http://www.access.gpo.gov/nara/, by using local 
WAIS client software, or by telnet to swais.access.gpo.gov, then login 
as guest (no password required). Dial-in users should use 
communications software and modem to call (202) 512-1661; type swais, 
then login as guest (no password required).

I. Background

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

    In order to administer their programs, the Department of Health and 
Human Services, other Federal agencies, State Medicaid agencies, 
private health plans, health care providers, and health care 
clearinghouses must assure their customers (such as patients, insured, 
providers, and health care plans) that the confidentiality and privacy 
of health care information they electronically collect, maintain, use, 
or transmit is secure. Security of health information is especially 
important when health information can be directly linked to an 
individual.
    Confidentiality is threatened not only by the risk of improper 
access to electronically stored information, but also by the risk of 
interception during electronic transmission of the information.
    In addition to the need to ensure electronic health care 
information is secure and confidential, there is a potential need to 
associate signature capability with information being electronically 
stored or transmitted. Today, there are numerous forms of electronic 
signatures, ranging from biometric devices to digital signature. To 
satisfy the legal and time-tested characteristics of a written 
signature, however, an electronic signature must do 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 will make it difficult for the signer to 
claim that the electronic representation is not valid. Currently, the 
only technically mature electronic signature meeting the above criteria 
is the digital signature. There is no national standard for security or 
electronic signatures. Of necessity, each health care provider, health 
care plan, and health care entity

[[Page 43243]]

has defined its own security requirements.

A. Legislation

    The Congress included provisions to address the need for security 
and electronic signature standards and other administrative 
simplification issues in the Health Insurance Portability and 
Accountability Act of 1996 (HIPAA), Public Law 104-191, which was 
enacted on August 21, 1996. Through subtitle F of title II of that law, 
the Congress added to title XI of the Social Security Act a new part C, 
entitled ``Administrative Simplification.'' (Public Law 104-191 affects 
several titles in the United States Code. Hereafter, we refer to the 
Social Security Act as the Act; we refer to the other laws cited in 
this document by their names.) The purpose of this part C is to improve 
the Medicare and Medicaid programs, in particular, and the efficiency 
and effectiveness of the health care system, in general, by encouraging 
the development of a health information system through the 
establishment of standards and requirements to facilitate the 
electronic maintenance and transmission of certain health information.
    Part C of title XI of the Act consists of sections 1171 through 
1179. These sections define various terms and impose several 
requirements on HHS, health plans, health care clearinghouses, and 
certain health care providers concerning electronic transmission of 
health information.
    The first section, section 1171 of the Act, establishes definitions 
for purposes of part C of title XI for the following terms: code set, 
health care clearinghouse, health care provider, health information, 
health plan, individually identifiable health information, standard, 
and standard setting organization.
    Section 1172 of the Act makes any standard adopted under part C 
applicable to: (1) Health plans, (2) health care clearinghouses, and 
(3) health care providers that transmit any health information in 
electronic form in connection with the transactions referred to in 
section 1173(a)(1) of the Act. The security standard to be adopted 
under Part C is not restricted to the transactions referred to in 
section 1173(a)(1) of the Act, but is applicable to any health 
information pertaining to an individual that is electronically 
maintained or transmitted. This section also contains the following 
requirements concerning standard setting:
     The Secretary may adopt a standard developed, adopted, or 
modified by a standard setting organization (that is, an organization 
accredited by the American National Standards Institute (ANSI)) that 
has consulted with the National Uniform Billing Committee (NUBC), the 
National Uniform Claim Committee (NUCC), Workgroup for Electronic Data 
Interchange (WEDI), and the American Dental Association (ADA).
     The Secretary may also adopt a standard other than one 
established by a standard setting organization, if the different 
standard will reduce costs for health care providers and health plans, 
the different standard is promulgated through negotiated rulemaking 
procedures, and the Secretary consults with each of the above-named 
groups.
     If no standard has been adopted by any standard setting 
organization, the Secretary must rely on the recommendations of the 
National Committee on Vital and Health Statistics (NCVHS) and consult 
with each of the above-named groups.
    In complying with the requirements of part C of title XI, the 
Secretary must rely on the recommendations of the NCVHS, consult with 
appropriate State, Federal, and private agencies or organizations, and 
publish the NCVHS recommendations in the Federal Register.
    Paragraph (a) of section 1173 of the Act requires that the 
Secretary adopt standards for financial and administrative 
transactions, and data elements for those transactions, to enable 
health information to be exchanged electronically. Standards are 
required for the following transactions: health claims, health 
encounter information, health claims attachments, health plan 
enrollments and disenrollments, health plan eligibility, health care 
payment and remittance advice, health plan premium payments, first 
report of injury, health claim status, and referral certification and 
authorization. In addition, the Secretary is required to adopt 
standards for any other financial and administrative transactions that 
are determined to be appropriate by the Secretary.
    Paragraph (b) of section 1173 of the Act requires the Secretary to 
adopt standards for unique health identifiers for all individuals, 
employers, health plans, and health care providers and requires further 
that the adopted standards specify for what purposes unique health 
identifiers may be used.
    Paragraphs (c) through (f) of section 1173 of the Act require the 
Secretary to establish standards for code sets for each data element 
for each health care transaction listed above, security standards for 
health care information systems, standards for electronic signatures 
(established together with the Secretary of Commerce), and standards 
for the transmission of data elements needed for the coordination of 
benefits and sequential processing of claims. Compliance with 
electronic signature standards will be deemed to satisfy both State and 
Federal requirements for written signatures with respect to the 
transactions listed in paragraph (a) of section 1173 of the Act.
    In section 1174 of the Act, the Secretary is required to establish 
standards for all of the above transactions, except claims attachments, 
by February 21, 1998. The standards for claims attachments must be 
established by February 21, 1999. Generally, after a standard is 
established, it cannot be changed during the first year after adoption 
except for changes that are necessary to permit compliance with the 
standard. Modifications to any of these standards may be made after the 
first year, but not more frequently than once every 12 months. The 
Secretary must also ensure that procedures exist for the routine 
maintenance, testing, enhancement, and expansion of code sets and that 
there are crosswalks from prior versions.
    Section 1175 of the Act prohibits health plans from refusing to 
process or delaying the processing of a transaction that is presented 
in standard format. The Act's requirements are not limited to health 
plans; however, each person to whom a standard or implementation 
specification applies is required to comply with the standard within 24 
months (or 36 months for small health plans) of its adoption. A health 
plan or other entity may, of course, comply voluntarily before the 
effective date. A person may comply by using a health care 
clearinghouse to transmit or receive the standard transactions. 
Compliance with modifications to standards or implementation 
specifications must be accomplished by a date designated by the 
Secretary. This date may not be earlier than 180 days from the notice 
of change.
    Section 1176 of the Act establishes a civil monetary penalty for 
violation of the provisions in part C of title XI of the Act, subject 
to several limitations. Penalties may not be more than $100 per person 
per violation and not more than $25,000 per person for violations of a 
single standard for a calendar year. The procedural provisions in 
section 1128A of the Act, ``Civil Monetary Penalties,'' are applicable.
    Section 1177 of the Act establishes penalties for a knowing misuse 
of unique health identifiers and individually identifiable health 
information: (1) A fine of not more than $50,000 and/or imprisonment of 
not

[[Page 43244]]

more than 1 year; (2) if misuse is ``under false pretenses,'' a fine of 
not more than $100,000 and/or imprisonment of not more than 5 years; 
and (3) if misuse is with intent to sell, transfer, or use individually 
identifiable health information for commercial advantage, personal 
gain, or malicious harm, a fine of not more than $250,000 and/or 
imprisonment of not more than 10 years. Note that these penalties do 
not affect any other penalties which may be imposed by other Federal 
programs, including ERISA.
    Under section 1178 of the Act, the provisions of part C of title XI 
of the Act, as well as any standards established under them, supersede 
any State law that is contrary to them. However, the Secretary may, for 
statutorily-specified reasons, waive this provision.
    Finally, section 1179 of the Act makes the above provisions 
inapplicable to financial institutions or anyone acting on behalf of a 
financial institution when ``authorizing, processing, clearing, 
settling, billing, transferring, reconciling, or collecting payments 
for a financial institution.''

    (Concerning this last provision, the conference report, in its 
discussion on section 1178, states:
    ``The conferees do not intend to exclude the activities of 
financial institutions or their contractors from compliance with the 
standards adopted under this part if such activities would be 
subject to this part. However, conferees intend that this part does 
not apply to use or disclosure of information when an individual 
utilizes a payment system to make a payment for, or related to, 
health plan premiums or health care. For example, the exchange of 
information between participants in a credit card system in 
connection with processing a credit card payment for health care 
would not be covered by this part. Similarly sending a checking 
account statement to an account holder who uses a credit or debit 
card to pay for health care services, would not be covered by this 
part. However, this part does apply if a company clears health care 
claims, the health care claims activities remain subject to the 
requirements of this part.'') (H.R. Rep. No. 736, 104th Cong., 2nd 
Sess. 268-269 (1996))

B. Process for Developing National Standards

    The Secretary has formulated a five-part strategy for developing 
and implementing the standards mandated under part C of title XI of the 
Act:
    1. To ensure necessary interagency coordination and required 
interaction with other Federal departments and the private sector, 
establish interdepartmental implementation teams to identify and assess 
potential standards for adoption. The subject matter of the teams 
includes claims/encounters, identifiers, enrollment/eligibility, 
systems security and electronic signature, and medical coding 
classification. Another team addresses cross-cutting issues and 
coordinates the subject matter teams. The teams consult with external 
groups such as the NCVHS' Workgroup on Data Standards, WEDI, the ANSI's 
Healthcare Informatics Standards Board (HISB), the NUCC, the NUBC, and 
the ADA. The teams are charged with developing regulations and other 
necessary documents and making recommendations for the various 
standards to the HHS Data Council through its Committee on Health Data 
Standards. (The HHS Data Council is the focal point for consideration 
of data policy issues. It reports directly to the Secretary and advises 
the Secretary on data standards and privacy issues.)
    2. Develop recommendations for standards to be adopted.
    3. Publish proposed rules in the Federal Register describing the 
standards. Each proposed rule provides the public with a 60-day comment 
period.
    4. Analyze public comments and publish the final rules in the 
Federal Register.
    5. Distribute standards and coordinate preparation and distribution 
of implementation guides.
    This strategy affords many opportunities for involvement of 
interested and affected parties in standards development and adoption 
by enabling them to:
     Participate with standards setting organizations.
     Provide written input to the NCVHS.
     Provide written input to the Secretary of HHS.
     Provide testimony at NCVHS'' public meetings.
     Comment on the proposed rules for each of the proposed 
standards.
     Invite HHS staff to meetings with public and private 
sector organizations or meet directly with senior HHS staff involved in 
the implementation process.
    The implementation teams charged with reviewing standards for 
designation as required national standards under the statute have 
defined, with significant input from the health care industry, a set of 
principles for guiding choices for the standards to be adopted by the 
Secretary. These principles are based on direct specifications in 
HIPAA, the purpose of the law, and generally desirable principles. To 
be designated as an HIPAA standard, each standard should:
    1. Improve the efficiency and effectiveness of the health care 
system by leading to cost reductions for or improvements in benefits 
from electronic health care transactions.
    2. Meet the needs of the health data standards user community, 
particularly health care providers, health plans, and health care 
clearinghouses.
    3. Be consistent and uniform with the other HIPAA standards--their 
data element definitions and codes and their privacy and security 
requirements--and, secondarily, with other private and public sector 
health data standards.
    4. Have low additional development and implementation costs 
relative to the benefits of using the standard.
    5. Be supported by an ANSI-accredited standards developing 
organization or other private or public organization that will ensure 
continuity and efficient updating of the standard over time.
    6. Have timely development, testing, implementation, and updating 
procedures to achieve administrative simplification benefits faster.
    7. Be technologically independent of the computer platforms and 
transmission protocols used in electronic health transactions, except 
when they are explicitly part of the standard.
    8. Be precise and unambiguous, but as simple as possible.
    9. Keep data collection and paperwork burdens on users as low as is 
feasible.
    10. Incorporate flexibility to adapt more easily to changes in the 
health care infrastructure (such as new services, organizations, and 
provider types) and information technology.
    A master data dictionary providing for common data definitions 
across the standards selected for implementation under HIPAA will be 
developed and maintained. We intend for the data element definitions to 
be precise, unambiguous, and consistently applied. The transaction-
specific reports and general reports from the master data dictionary 
will be readily available to the public. At a minimum, the information 
presented will include data element names, definitions, and appropriate 
references to the transactions where they are used.
    This proposed rule would establish the security standard and 
electronic signature standard for health care information and 
individually identifiable health care information maintained or 
transmitted electronically. The remaining standards are grouped, to the 
extent possible, by subject matter and audience in other regulations. 
We anticipate publishing

[[Page 43245]]

several separate regulation documents to promulgate the remaining 
standards required under HIPAA.

II. Provisions of this Proposed Rule

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

    We propose to add a new part to title 45 of the Code of Federal 
Regulations for health plans, health care providers, and health care 
clearinghouses in general. The new part would be part 142 of title 45 
and would be titled ``Administrative Requirements.'' Subpart A would 
contain the general provisions for this part, including the general 
definitions and general requirements for health plans. Subpart C would 
contain provisions specific to securing health information used in any 
electronic transmission or stored format.
    In this proposed rule, we propose a standard for security of health 
information. This rule would establish that health plans, health care 
clearinghouses, and health care providers must have the security 
standard in place to comply with the statutory requirement that health 
care information and individually identifiable health care information 
be protected to ensure privacy and confidentiality when health 
information is electronically stored, maintained, or transmitted. The 
Congress mandated a separate standard for electronic signature, 
therefore, this proposed security standard also addresses the selected 
standard for electronic signature. The proposed security standard does 
not require the use of an electronic signature, but specifies the 
standard for an electronic signature that must be followed if such a 
signature is used. If an entity elects to use an electronic signature, 
it must comply with the electronic signature standard.

A. Applicability

    With the exception of the security provisions, section 262 of HIPAA 
applies to any health plan, any health care clearinghouse, and any 
health care provider that transmits any health information in 
electronic form in connection with transactions referred to in section 
1173(a)(1) of the Act. The security provisions of section 262 of HIPAA 
apply to any health plan, any health care clearinghouse, and any health 
care provider that electronically maintains or transmits any health 
information relating to an individual.
    Our proposed rules (at 45 CFR 142.102) would apply to the health 
plans and health care clearinghouses as well, but we would clarify the 
statutory language in our regulations for health care providers. With 
the exception of the security regulation, we would have the regulations 
apply to any health care provider only when electronically transmitting 
any of the transactions to which section 1173(a)(1) of the Act refers.
    Electronic transmissions would include transactions using all 
media, even when the information is physically moved from one location 
to another using magnetic tape, disk, or compact disc (cd) media. 
Transmissions over the Internet (wide-open), Extranet (using Internet 
technology to link a business with information only accessible to 
collaborating parties), leased lines, dial-up lines, and private 
networks are all included. Telephone voice response and ``faxback'' (a 
request for information made via voice using a fax machine and 
requested information returned via that same machine as a fax) systems 
would not be included. We solicit comments concerning any adverse 
impact the above statement concerning voice response or faxback may 
have upon the security of the health information in the commenter's 
care.
    With the exception of the security regulation, our regulations 
would apply to health care clearinghouses when transmitting 
transactions to, and receiving transactions from, a health care 
provider or health plan that transmits and receives standard 
transactions (as defined under ``transaction'') and at all times when 
transmitting to or receiving electronic transactions from another 
health care clearinghouse. The security regulation would apply to 
health care clearing houses electronically maintaining or transmitting 
any health information pertaining to an individual.
    Entities that offer on-line interactive transmission must comply 
with the standards. The Hypertext Markup Language (HTML) interaction 
between a server and a browser by which the data elements of a 
transaction are solicited from a user would not have to use the 
standards (with the exception of the security standard), although the 
data content must be equal to that required for the standard. Once the 
data elements are assembled into a transaction by the server, the 
transmitted transaction would have to comply with the standards.
    With the exception of the security portion, the law would apply to 
each health care provider when transmitting or receiving any of the 
specified electronic transactions. The security regulation would apply 
to each health care provider electronically maintaining or transmitting 
any health information pertaining to an individual.
    The law applies to health plans for all transactions. Section 
142.104 would contain the following provisions (from section 1175 of 
the Act):
    If a person desires to conduct a transaction (as defined in 
Sec. 142.103) with a health plan as a standard transaction, the 
following apply:
    (1) The health plan may not refuse to conduct the transaction as a 
standard transaction.
    (2) The health plan may not delay the transaction or otherwise 
adversely affect, or attempt to adversely affect, the person or the 
transaction on the basis that the transaction is a standard 
transaction.
    (3) The information transmitted and received in connection with the 
transaction must be in the form of standard data elements of health 
information.
    As a further requirement, we would provide that a health plan that 
conducts transactions through an agent assure that the agent meets all 
the requirements of part 142 that apply to the health plan.
    Section 142.105 would state that a person or other entity may meet 
the transaction requirements of Sec. 142.104 by either--
    (1) Transmitting and receiving standard data elements, or
    (2) Submitting nonstandard data elements to a health care 
clearinghouse for processing into standard data elements and 
transmission by the health care clearinghouse and receiving standard 
data elements through the clearinghouse.
    Health care clearinghouses would be able to accept nonstandard 
transactions for the sole purpose of translating them into standard 
transactions for sending customers and would be able to accept standard 
transactions and translate them into nonstandard formats for receiving 
customers. We would state in Sec. 142.105 that the transmission of 
nonstandard transactions, under contract, between a health plan or a 
health care provider and a health care clearinghouse would not violate 
the law.
    With the exception of the security standard, transmissions within a 
corporate entity would not be required to comply with the standards. A 
hospital that is wholly owned by a managed care company would not have 
to use the transaction standards to pass encounter information back to 
the home office, but it would have to use the standard claims 
transaction to submit a claim to another payer. Another example might 
be transactions within Federal agencies and their contractors and 
between State agencies within the same State. For example, Medicare 
enters into contracts with insurance

[[Page 43246]]

companies and common working file sites that process Medicare claims 
using government furnished software. There is constant communication, 
on a private network, between HCFA Central Office and the Medicare 
carriers, intermediaries, and common working file sites. This 
communication may continue in nonstandard mode. However, these 
contractors would be required to comply with the transaction standards 
when exchanging any of the transactions covered by HIPAA with an entity 
outside these ``corporate'' boundaries.
    The security standard is applicable to all health care information 
electronically maintained or used in an electronic transmission, 
regardless of format (standard transaction or a proprietary format); no 
distinction is made between internal corporate entity communication or 
communication external to the corporate entity.
    Although there are situations in which the use of the standards is 
not required (for example, health care providers may continue to submit 
paper claims and employers are not required to use any of the standard 
transactions), we stress that a standard may be used voluntarily in any 
situation in which it is not required.
    This proposed regulation would not mandate the use of electronic 
signatures with any specific transaction at this time. Instead, the 
regulation proposes that whenever an electronic signature is required 
for an electronic transaction by law, regulation, or contract, the 
signature must meet the standard established in the regulation at 
Sec. 142.310. Use of this standard would satisfy any Federal or State 
requirement for a signature, either electronic or on paper.
    We note that the ANSI X12N standards for individual transactions 
which have been proposed for adoption as national standards in a 
separate proposed rule do not require the use of electronic signatures. 
Standards for additional transactions that the Secretary may propose 
for adoption in the future, including one for claims attachments, may 
contain such requirements. We solicit comments on whether electronic 
signatures should be required for any specific transactions or under 
specific circumstances and what effect such requirements would have on 
electronic health care transactions.
    We also note that the NCVHS is required by HIPAA to report to the 
Secretary recommendations and legislative proposals for uniform data 
standards for patient medical record information and the electronic 
exchange of such information, with the implication that HHS should rely 
on such recommendations to adopt such standards or propose the passage 
of such legislation by the Congress. We solicit comments on whether the 
standard proposed below for electronic signatures would be appropriate 
for consideration as part of such standards.

B. Definitions

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

    Section 1171 of the Act defines several terms and our proposed 
rules would, for the most part, simply restate the law. The terms that 
we are defining in this proposed rule follow:
1. Code Set
    We would define ``code set'' as section 1171(1) of the Act does: 
``code set'' means any set of codes used for encoding data elements, 
such as tables of terms, medical concepts, medical diagnostic codes, or 
medical procedure codes.
2. Health Care Clearinghouse
    We would define ``health care clearinghouse'' as section 1171(2) of 
the Act does, but we are adding a further, clarifying sentence. The 
statute defines a ``health care clearinghouse'' as a public or private 
entity that processes or facilitates the processing of nonstandard data 
elements of health information into standard data elements. We would 
further explain that such an entity is one that currently receives 
health care transactions from health care providers or other entities, 
translates the data from a given format into one acceptable to the 
intended recipient and forwards the processed transaction to 
appropriate payers and clearinghouses, as necessary, for further 
action.
    There are currently a number of private clearinghouses that perform 
this function for health care providers. For purposes of this rule, we 
would consider billing services, repricing companies, community health 
management information systems or community health information systems, 
value-added networks, and switches that perform this function to be 
health care clearinghouses.
3. Health Care Provider
    As defined by section 1171(3) of the Act, a ``health care 
provider'' is a provider of services as defined in section 1861(u) of 
the Act, a provider of medical or other health services as defined in 
section 1861(s) of the Act, and any other person who furnishes health 
care services or supplies. Our regulations would define ``health care 
provider'' as the statute does and clarify that the definition of a 
health care provider is limited to those entities that furnish, or bill 
and are paid for, health care services in the normal course of 
business.
    For a more detailed discussion of the definition of health care 
provider, we refer the reader to our proposed rule, HCFA-0045-P, 
Standard Health Care Provider, 63 FR 25320, published May 7, 1998.
4. Health Information
    ``Health information,'' as defined in section 1171 of the Act, 
means any information, whether oral or recorded in any form or medium, 
that--
     Is created or received by a health care provider, health 
plan, public health authority, employer, life insurer, school or 
university, or health care clearinghouse; and
     Relates to the past, present, or future physical or mental 
health or condition of an individual; the provision of health care to 
an individual; or the past, present, or future payment for the 
provision of health care to an individual.
    We propose the same definition for our regulations.
5. Health Plan
    We propose that a ``health plan'' be defined essentially as section 
1171 of the Act defines it. Section 1171 of the Act cross refers to 
definitions in section 2791 of the Public Health Service Act (as added 
by Public Law 104-191, 42 U.S.C. 300gg-91); we would incorporate those 
definitions as currently stated into our proposed definitions for the 
convenience of the public. We note that the term ``health plan'' is 
also defined in other statutes, such as the Employee Retirement Income 
Security Act of 1974 (ERISA). Our definitions are based on the roles of 
plans in conducting administrative transactions, and any differences 
should not be construed to affect other statutes.
    For purposes of implementing the provisions of administrative 
simplification, a ``health plan'' would be an individual or group 
health plan that provides, or pays the cost of, medical care. This 
definition includes, but is not limited to, the 13 types of plans 
listed in the statute. On the other hand, plans such as property and 
casualty insurance plans and workers compensation plans, which may pay 
health care costs in the course of administering nonhealth care 
benefits, are not considered to be health plans in the proposed 
definition of health plan. Of course, these plans may voluntarily adopt 
these standards for their own business needs. At some

[[Page 43247]]

future time, the Congress may choose to expressly include some or all 
of these plans in the list of health plans that must comply with the 
standards.
    Health plans often carry out their business functions through 
agents, such as plan administrators (including third party 
administrators), entities that are under ``administrative services 
only'' (ASO) contracts, claims processors, and fiscal agents. These 
agents may or may not be health plans in their own right; for example, 
a health plan acting as another health plan's agent as another line of 
business. As stated earlier, a health plan that conducts HIPAA 
transactions through an agent is required to assure that the agent 
meets all HIPAA requirements that apply to the plan itself.
    ``Health plan'' includes the following, singly or in combination:
    a. ``Group health plan'' (as currently defined by section 2791(a) 
of the Public Health Service Act). A group health plan is a plan that 
has 50 or more participants (as the term ``participant'' is currently 
defined by section 3(7) of ERISA) or is administered by an entity other 
than the employer that established and maintains the plan. This 
definition includes both insured and self-insured plans. We define 
``participant'' separately below.
    Section 2791(a)(1) of the Public Health Service Act defines ``group 
health plan'' as an employee welfare benefit plan (as defined in 
current section 3(1) of ERISA) to the extent that the plan provides 
medical care, including items and services paid for as medical care, to 
employees or their dependents directly or through insurance, or 
otherwise.
    b. ``Health insurance issuer'' (as currently defined by section 
2791(b) of the Public Health Service Act).
    Section 2791(b) of the Public Health Service Act currently defines 
a ``health insurance issuer'' as an insurance company, insurance 
service, or insurance organization that is licensed to engage in the 
business of insurance in a State and is subject to State law that 
regulates insurance.
    c. ``Health maintenance organization'' (as currently defined by 
section 2791(b) of the Public Health Service Act).
    Section 2791(b) of the Public Health Service Act currently defines 
a ``health maintenance organization'' as a Federally qualified health 
maintenance organization, an organization recognized as such under 
State law, or a similar organization regulated for solvency under State 
law in the same manner and to the same extent as such a health 
maintenance organization. These organizations may include preferred 
provider organizations, provider sponsored organizations, independent 
practice associations, competitive medical plans, exclusive provider 
organizations, and foundations for medical care.
    d. Part A or Part B of the Medicare program (title XVIII of the 
Act).
    e. The Medicaid program (title XIX of the Act).
    f. A ``Medicare supplemental policy'' as defined under section 
1882(g)(1) of the Act.
    Section 1882(g)(1) of the Act defines a ``Medicare supplemental 
policy'' as a health insurance policy that a private entity offers a 
Medicare beneficiary to provide payment for expenses incurred for 
services and items that are not reimbursed by Medicare because of 
deductible, coinsurance, or other limitations under Medicare. The 
statutory definition of a Medicare supplemental policy excludes a 
number of plans that are generally considered to be Medicare 
supplemental plans, such as health plans for employees and former 
employees and for members and former members of trade associations and 
unions. A number of these health plans may be included under the 
definitions of ``group health plan'' or ``health insurance issuer'', as 
defined in paragraphs a. and b. above.
    g. A ``long-term care policy,'' including a nursing home fixed-
indemnity policy. A ``long-term care policy'' is considered to be a 
health plan regardless of how comprehensive it is. We recognize the 
long-term care insurance segment of the industry is largely unautomated 
and we welcome comments regarding the impact of HIPAA on the long-term 
care segment.
    h. An employee welfare benefit plan or any other arrangement that 
is established or maintained for the purpose of offering or providing 
health benefits to the employees of two or more employers. This 
includes plans that are referred to as multiple employer welfare 
arrangements (``MEWAs'').
    i. The health care program for active military personnel under 
title 10 of the United States Code.
    j. The veterans health care program under chapter 17 of title 38 of 
the United States Code.
    This health plan primarily furnishes medical care through hospitals 
and clinics administered by the Department of Veterans Affairs for 
veterans with a service-connected disability that is compensable. 
Veterans with nonservice-connected disabilities (and no other health 
benefit plan) may receive health care under this health plan to the 
extent resources and facilities are available.
    k. The Civilian Health and Medical Program of the Uniformed 
Services (CHAMPUS), as defined in 10 U.S.C. 1072(4).
    CHAMPUS primarily covers services furnished by civilian medical 
providers to dependents of active duty members of the uniformed 
services and retirees and their dependents under age 65.
    l. The Indian Health Service program under the Indian Health Care 
Improvement Act (25 U.S.C. 1601 et seq.).
    This program furnishes services, generally through its own health 
care providers, primarily to persons who are eligible to receive 
services because they are of American Indian or Alaskan Native descent.
    m. The Federal Employees Health Benefits Program under 5 U.S.C. 
chapter 89.
    This program consists of health insurance plans offered to active 
and retired Federal employees and their dependents. Depending on the 
health plan, the services may be furnished on a fee-for-service basis 
or through a health maintenance organization.

    (Note: Although section 1171(5)(M) of the Act refers to the 
``Federal Employees Health Benefit Plan,'' this and any other rules 
adopting administrative simplification standards will use the 
correct name, the Federal Employees Health Benefits Program. One 
health plan does not cover all Federal employees; there are over 350 
health plans that provide health benefits coverage to Federal 
employees, retirees, and their eligible family members. Therefore, 
we will use the correct name, the Federal Employees Health Benefits 
Program, to make clear that the administrative simplification 
standards apply to all health plans that participate in the 
Program.)

    n. Any other individual or group health plan, or combination 
thereof, that provides or pays for the cost of medical care.
    We would include a fourteenth category of health plan in addition 
to those specifically named in HIPAA, as there are health plans that do 
not readily fit into the other categories but whose major purpose is 
providing health benefits. The Secretary would determine which of these 
plans are health plans for purposes of title II of HIPAA. This category 
would include the Medicare Plus Choice plans that will become available 
as a result of section 1855 of the Act as amended by section 4001 of 
the Balanced Budget Act of 1997 (Public Law 105-33) to the extent that 
these health plans do not fall under any other category.

[[Page 43248]]

6. Small Health Plan
    We would define a ``small health plan'' as a group health plan with 
fewer than 50 participants.
    The HIPAA does not define a ``small health plan'' but instead 
leaves the definition to be determined by the Secretary. The Conference 
Report suggests that the appropriate definition of a ``small health 
plan'' is found in current section 2791(a) of the Public Health Service 
Act, which is a group health plan with fewer than 50 participants. We 
would also define small individual health plans as those with fewer 
than 50 participants.
7. Individually Identifiable Health Information
    Section 1171(6) states the term ``individually identifiable health 
information'' means any information, including demographic information 
collected from an individual, that--
    a. Is created or received by a health care provider, health plan, 
employer, or health care clearinghouse; and
    b. Relates to the past, present or future physical or mental health 
or condition of an individual, the provision of health care to an 
individual, or the past, present, or future payment for the provision 
of health care to an individual, and
    (i) Identifies the individual, or
    (ii) With respect to which there is a reasonable basis to believe 
that the information can be used to identify the individual.
8. Standard
    Section 1171 of the Act defines ``standard,'' when used with 
reference to a data element of health information or a transaction 
referred to in section 1173(a)(1) of the Act, as any such data element 
or transaction that meets each of the standards and implementation 
specifications adopted or established by the Secretary with respect to 
the data element or transaction under sections 1172 through 1174 of the 
Act.
    Under our definition, the security standard would be a set of 
requirements adopted or established to preserve and maintain the 
confidentiality and privacy of electronically stored, maintained, or 
transmitted health information promulgated either by an organization 
accredited by the ANSI or HHS.
9. Transaction
    ``Transaction'' would mean the exchange of information between two 
parties to carry out financial and administrative activities related to 
health care. A transaction would be (a) any of the transactions listed 
in section 1173(a)(2) of the Act, and (b) any determined appropriate by 
the Secretary in accordance with section 1173(a)(1)(B) of the Act. We 
present them below in the order in which we propose to list them in the 
regulations text.
    A ``transaction'' would mean any of the following:
    a. Health claims or equivalent encounter information. This 
transaction may be used to submit health care claim billing 
information, encounter information, or both, from health care providers 
to payers, either directly or via intermediary billers and claims 
clearinghouses.
    b. Health care payment and remittance advice. This transaction may 
be used by a health plan to make a payment to a financial institution 
for a health care provider (sending payment only), to send an 
explanation of benefits remittance advice directly to a health care 
provider (sending data only), or to make payment and send an 
explanation of benefits remittance advice to a health care provider via 
a financial institution (sending both payment and data).
    c. Coordination of benefits. This transaction set can be used to 
transmit health care claims and billing payment information between 
payers with different payment responsibilities where coordination of 
benefits is required or between payers and regulatory agencies to 
monitor the furnishing, billing, and/or payment of health care services 
within a specific health care/insurance industry segment.
    In addition to the nine electronic transactions specified in 
section 1173(a)(2) of the Act, section 1173(f) directs the Secretary to 
adopt standards for transferring standard data elements among health 
plans for coordination of benefits. This particular provision does not 
state that these should be standards for electronic transfer of 
standard data elements among health plans. However, we believe that the 
Congress, when writing this provision, intended for these standards to 
be an electronic form of transactions for coordination of benefits and 
sequential processing of claims. The Congress expressed its intent on 
these matters generally in section 1173(a)(1)(B) of the Act, where the 
Secretary is directed to adopt ``other financial and administrative 
transactions * * * consistent with the goals of improving the operation 
of the health care system and reducing administrative costs.''
    d. Health claim status. This transaction may be used by health care 
providers and recipients of health care products or services (or their 
authorized agents) to request the status of a health care claim or 
encounter from a health plan.
    e. Enrollment and disenrollment in a health plan. This transaction 
may be used to establish communication between the sponsor of a health 
benefit and the payer. It provides enrollment data, such as subscriber 
and dependents, employer information, and primary care health care 
provider information. A sponsor is the backer of the coverage, benefit, 
or product. A sponsor can be an employer, union, government agency, 
association, or insurance company. The health plan refers to an entity 
that pays claims, administers the insurance product or benefit, or 
both.
    f. Eligibility for a health plan. This transaction may be used to 
inquire about the eligibility, coverage, or benefits associated with a 
benefit plan, employer, plan sponsor, subscriber, or a dependent under 
the subscriber's policy. It also can be used to communicate information 
about or changes to eligibility, coverage, or benefits from information 
sources (such as insurers, sponsors, and payers) to information 
receivers (such as physicians, hospitals, third party administrators, 
and government agencies).
    g. Health plan premium payments. This transaction may be used by, 
for example, employers, employees, unions, and associations to make and 
keep track of payments of health plan premiums to their health 
insurers. This transaction may also be used by a health care provider, 
acting as liaison for the beneficiary, to make payment to a health 
insurer for coinsurance, copayments, and deductibles.
    h. Referral certification and authorization. This transaction may 
be used to transmit health care service referral information between 
health care providers, health care providers furnishing services, and 
payers. It can also be used to obtain authorization for certain health 
care services from a health plan.
    i. First report of injury. This transaction may be used to report 
information pertaining to an injury, illness, or incident to entities 
interested in the information for statistical, legal, claims, and risk 
management processing requirements.
    j. Health claims attachments. This transaction may be used to 
transmit health care service information, such as subscriber, patient, 
demographic, diagnosis, or treatment data for the purpose of a request 
for review, certification, notification, or reporting the outcome of a 
health care services review.
    k. Other transactions as the Secretary may prescribe by regulation.

[[Page 43249]]

    Under section 1173(a)(1)(B) of the Act, the Secretary may adopt 
standards, and data elements for those standards, and for other 
financial and administrative transactions deemed appropriate by the 
Secretary. These transactions would be consistent with the goals of 
improving the operation of the health care system and reducing 
administrative costs.

C. Effective Dates--General

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

    In general, any given standard would be effective 24 months after 
the effective date (36 months for small health plans) of the final rule 
for that standard. Because there are other standards to be established 
than those in this proposed rule, we specify the date for a given 
standard under the subpart for that standard.
    Health plans would be required by part 142 to comply with our 
requirements as follows:
    1. Each health plan that is not a small plan would have to comply 
with the requirements of part 142 no later than 24 months after the 
effective date of the final rule.
    2. Each small health plan would have to comply with the 
requirements of part 142 no later than 36 months after the effective 
date of the final rule.
    Health care providers and health care clearinghouses would be 
required to begin using the standard by 24 months after the effective 
date of the final rule.

(The effective date of the final rule will be 60 days after the final 
rule is published in the Federal Register.)
    Provisions of trading partner agreements that stipulate data 
content, format definitions, or conditions that conflict with the 
adopted standard would be invalid beginning 36 months from the 
effective date of the final rule for small health plans, and 24 months 
from the effective date of the final rule for all other health plans.
    If the HHS adopts a modification to an implementation specification 
or a standard, the implementation date of the modification would be no 
earlier than the 180th day following the adoption of the modification. 
HHS would determine the actual date, taking into account the time 
needed to comply due to the nature and extent of the modification. HHS 
would be able to extend the time for compliance for small health plans. 
This provision would be at Sec. 142.106.
    Any of the health plans, health care clearinghouses, and health 
care providers may implement a given standard earlier than the date 
specified in the subpart created for that standard. We realize that 
this may create some problems temporarily, as early implementers would 
have to be able to continue using old standards until the new one must, 
by law, be in place.

D. Security Standard

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

    Section 142.308 would set forth the security standard. There is no 
recognized single standard that integrates all the components of 
security (administrative procedures, physical safeguards, technical 
security services, and technical mechanisms) that must be in place to 
preserve health information confidentiality and privacy as defined in 
the law. Therefore, we are designating a new, comprehensive standard, 
which defines the security requirements to be fulfilled.
    In fact, there are numerous security guidelines and standards in 
existence today, focusing on the different techniques available for 
implementing the various aspects of security. We thoroughly researched 
the existing guidelines and standards, and consulted extensively with 
the organizations that developed them. A list of the organizations with 
which we consulted can be found in section G. below. As a result of 
these consultations and our research, we identified several high-level 
concepts on which the standard is based:
     The standard must be comprehensive.
     Consultation with standards development organizations, 
such as ANSI-accredited organizations, as well as business interest 
organizations, revealed the need for a standard that addressed all 
aspects of security in a concerted fashion. The HISB noted in its 
report to the Secretary that:
    ``Comprehensive adoption of security standards in health care, not 
piecemeal implementation, is advocated to provide security to data that 
is exchanged between health care entities.
    By definition, if a system or communications between two systems, 
were implemented with technology(s) meeting standards in a general 
system security framework (Identification and Authentication; 
Authorization and Access Control; Accountability; Integrity and 
Availability; Security of Communication; and Security Administration.) 
that system would be essentially secure.
    * * * no single standards development organization (SDO) is 
addressing all aspects of health care information security and 
confidentiality, and specifically, no single SDO is developing 
standards that cover every category of the security framework.'' [Page 
189]
     The standard must be technology-neutral.
    Our proposed standard does not reference or advocate specific 
technology because security technology is changing quickly. We want to 
give providers/plans/clearinghouses flexibility to choose their own 
technical solutions. A standard that is dependent on a specific 
technology or technologies would not be flexible enough to use future 
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 largest clearinghouse. A 
single approach would be neither economically feasible nor effective in 
safeguarding health data. For example, in a small physician practice, a 
contingency plan for system emergencies might be only a few pages long, 
and cover issues such as where backup diskettes must be stored, and the 
location of a backup personal computer (PC). At a large health plan, 
the contingency plan might consist of multiple volumes and cover issues 
such as remote hot site operations and secure off-site storage of 
electronic media. The physician office solution would not protect the 
large plan's data, and the plan's solution would not be economically 
feasible (or necessary) for the physician office. Moreover, the statute 
specifically directed the Secretary to take into account the needs and 
capabilities of small and rural health care providers, as those terms 
are defined by the Secretary. The scalability of our approach addresses 
this direction. We are not proposing specific definitions of ``small'' 
and ``rural'' health care providers because the statute provides no 
exemptions or special benefits for these two groups. However, we 
solicit comments on the necessity to define these terms.
General Approach
    We would define the security standard as a set of requirements with 
implementation features that providers, plans, and clearinghouses must 
include in their operations to assure that electronic health 
information pertaining to an individual remains secure. The 
implementation features address specific aspects of the requirements. 
The standard does not reference or advocate specific technology. This 
would allow the security standard to be stable, yet flexible enough to 
take advantage of state-of-the-art technology.

[[Page 43250]]

The standard does not address the extent to which a particular entity 
should implement the specific features. Instead, we would require that 
each affected entity assess its own security needs and risks and 
devise, implement, and maintain appropriate security to address its 
business requirements. How individual security requirements would be 
satisfied and which technology to use would be business decisions that 
each organization would have to make.
    The recommendations contained in the National Research Council's 
1997 report For The Record: Protecting Electronic Health Information 
support our approach to the development of a security standard. This 
report presents findings and recommendations related to health data 
security, and is widely viewed as an authoritative and comprehensive 
source on the subject. The report concludes that appropriate security 
practices are highly dependent on individual circumstances, but goes on 
to suggest that:

    ``It is therefore not possible to prescribe in detail specific 
practices for all organizations; rather, each organization must 
analyze its systems, vulnerabilities, risks, and resources to 
determine optimal security measures. Nevertheless, the committee 
believes that a set of practices can be articulated in a 
sufficiently general way that they can be adopted by all health care 
organizations in one form or another.'' (Page 168)

    The specific requirements and supporting implementation features 
detailed in the next section represent this general set of practices. 
Many health care entities have already implemented some or all of these 
practices. We believe they represent those practices that are necessary 
in order to conduct business electronically in the health care industry 
today and, therefore, are normal business costs.
    Inherent in this approach is a balance between the need to secure 
health data against risk and the economic cost of doing so. Health care 
entities must consider both aspects in devising their security 
solutions.
Specific Requirements
    The proposed standard requires that each health care entity engaged 
in electronic maintenance or transmission of health information assess 
potential risks and vulnerabilities to the individual health data in 
its possession in electronic form, and develop, implement, and maintain 
appropriate security measures. Most importantly, these measures must be 
documented and kept current.
    The proposed security standard consists of the requirements that a 
health care entity must address in order to safeguard the integrity, 
confidentiality, and availability of its electronic data. It also 
describes the implementation features that must be present in order to 
satisfy each requirement. The proposed requirements and implementation 
features were developed by the implementation team based on knowledge 
of security procedures and existing standards and guidelines described 
above. This was an iterative process that involved extensive outreach 
with a number of health care industry and Department of Commerce 
security experts. We also drew upon Recommendations 1 and 3 in the 
National Research Council's 1997 report, For The Record, that were 
recommended for immediate implementation.
    ``Recommendation 1: All organizations that handle patient-
identifiable health care information--regardless of size--should adopt 
the set of technical and organizational policies, practices, and 
procedures described below to protect such information.''
    The proposed security standard addresses the following policies, 
practices, and procedures that were listed under Recommendation 1:

 Organizational Practices
    1. Security and confidentiality policies
    2. Information security officers
    3. Education and training programs, and
    4. Sanctions
 Technical Practices and Procedures
    1. Individual authentication of users
    2. Access controls
    3. Audit trails
    4. Physical security and disaster recovery
    5. Protection of remote access points
    6. Protection of external electronic communications
    7. Software discipline, and
    8. System assessment

    ``Recommendation 3: The federal government should work with 
industry to promote and encourage an informed public debate to 
determine an appropriate balance between the primary concerns of 
patients and the information needs of various users of health care 
information.''
    This proposed security standard was developed in the spirit of 
Recommendation 3. The security standard development process has been an 
open one with invitations to a number of organizations to participate 
in the security discussions. Although implementation team membership 
was limited to government employees, nongovernmental organizations; 
business organizations; individuals knowledgeable in security; and 
educational institutions have been encouraged to express their views.
    As a result of the collaborative security regulation development 
process, the implementation team has chosen to divide the proposed 
security requirements, for purposes of presentation only, into the 
following four categories:
     Administrative procedures to guard data integrity, 
confidentiality, and availability--these are documented, formal 
practices to manage the selection and execution of security measures to 
protect data and the conduct of personnel in relation to the protection 
of data.
     Physical safeguards to guard data integrity, 
confidentiality, and availability--these relate to the protection of 
physical computer systems and related buildings and equipment from fire 
and other natural and environmental hazards, as well as from intrusion. 
Physical safeguards also cover the use of locks, keys, and 
administrative measures used to control access to computer systems and 
facilities.
     Technical security services to guard data integrity, 
confidentiality, and availability--these include the processes that are 
put in place to protect and to control and monitor information access, 
and
     Technical security mechanisms--these include the processes 
that are put in place to prevent unauthorized access to data that is 
transmitted over a communications network.
    It should be noted that the only necessity is that the requirements 
would be met, not that they be presented in these four categories. 
Under this proposed rule, a business entity could choose to order the 
requirements in any manner that suits its business.
    We then determined the requirements and implementation features 
that health plans, providers, and clearinghouses would implement. The 
implementation features describe the requirements in greater detail. 
Some requirements do not require this additional level of detail. 
Within the four categories, the requirements and implementation 
features are presented in alphabetical order to ensure that no one item 
is considered to be more important than another. The relative 
importance of the requirements and implementation features would depend 
on the characteristics of each organization.
    The four categories of the matrix are described in greater detail 
in Sec. 142.308 and are depicted in tabular form along with the 
electronic signature standard in

[[Page 43251]]

a combined matrix located at Addendum 1. We have not included the 
matrix in the proposed regulation text. We invite your comments 
concerning the appropriateness and usefulness of including the matrix 
in the final regulation text. We also solicit comments as to the level 
of detail expressed in requirement implementation features; i.e., do 
any represent a level of detail that goes beyond what is necessary or 
appropriate. We have also provided a glossary of terms to facilitate a 
common understanding of the matrix entries. The glossary can be found 
at Addendum 2. Finally, we have included currently existing standards 
and guidelines mapped to the proposed security standard. This mapping 
is not all inclusive and is located at Addendum 3.
1. Administrative Procedures
[Please label written comments or e-mailed comments about this 
section with the subject: administrative procedures]

    In this proposed rule, the administrative requirements and 
supporting implementation features are presented at Sec. 142.308(a). We 
would require each to be documented. We would require the documentation 
to be made available to those individuals responsible for implementing 
the procedures and would require it to be reviewed and updated 
periodically. The following matrix depicts the requirements and 
supporting implementation features for the Administrative Procedures 
category. Following the matrix is a discussion of each of the 
requirements under that category.

 Administrative Procedures To Guard Data Integrity, Confidentiality, and
                              Availability                              
------------------------------------------------------------------------
              Requirement                         Implementation        
------------------------------------------------------------------------
Certification                                                           
Chain of trust partner agreement                                        
Contingency plan (all listed             Applications and data          
 implementation features must be          criticality analysis.         
 implemented).                           Data backup plan.              
                                         Disaster recovery plan.        
                                         Emergency mode operation plan. 
                                         Testing and revision.          
Formal mechanism for processing records                                 
Information access control (all listed   Access authorization.          
 implementation features must be         Access establishment.          
 implemented).                           Access modification.           
Internal audit                                                          
Personnel security (all listed           Assure supervision of          
 implementation features must be          maintenance personnel by      
 implemented).                            authorized, knowledgeable     
                                          person.                       
                                         Maintenance of record of access
                                          authorizations.               
                                         Operating, and in some cases,  
                                          maintenance personnel have    
                                          proper access authorization.  
                                         Personnel clearance procedure. 
                                         Personnel security policy/     
                                          procedure.                    
                                         System users, including        
                                          maintenance personnel, trained
                                          in security.                  
Security configuration mgmt. (all        Documentation.                 
 listed implementation features must be  Hardware/software installation 
 implemented).                            & maintenance review and      
                                          testing for security features.
                                         Inventory.                     
                                         Security Testing.              
                                         Virus checking.                
Security incident procedures (all        Report procedures.             
 listed implementation features must be  Response procedures.           
 implemented).                                                          
Security management process (all listed  Risk analysis.                 
 implementation features must be         Risk management.               
 implemented).                           Sanction policy.               
                                         Security policy.               
Termination procedures (all listed       Combination locks changed.     
 implementation features must be         Removal from access lists.     
 implemented).                           Removal of user account(s).    
                                         Turn in keys, token or cards   
                                          that allow access.            
Training (all listed implementation      Awareness training for all     
 features must be implemented).           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 organization would be required to evaluate 
its computer system(s) or network design(s) to certify that the 
appropriate security has been implemented. This evaluation could be 
performed internally or by an external accrediting agency.
    We are, at this time, soliciting input on appropriate mechanisms to 
permit independent assessment of compliance. We would be particularly 
interested in input from those engaging in health care electronic data 
interchange (EDI), as well as independent certification and auditing 
organizations addressing issues of documentary evidence of steps taken 
for compliance; need for, or desirability of, independent verification, 
validation, and testing of system changes; and certifications required 
for off-the-shelf products used to meet the requirements of this 
regulation.

[[Page 43252]]

    We also solicit comments on the extent to which obtaining external 
certification would create an undue burden on small or rural providers.
    b. Chain of Trust Partner Agreement. If data are processed through 
a third party, the parties would be required to enter into a chain of 
trust partner agreement. This is a contract in which the parties agree 
to electronically exchange data and to protect the transmitted data. 
The sender and receiver are required and depend upon each other to 
maintain the integrity and confidentiality of the transmitted 
information. Multiple two-party contracts may be involved in moving 
information from the originating party to the ultimate receiving party. 
For example, a provider may contract with a clearinghouse to transmit 
claims to the clearinghouse; the clearinghouse, in turn, may contract 
with another clearinghouse or with a payer for the further transmittal 
of those claims. These agreements are important so that the same level 
of security will be maintained at all links in the chain when 
information moves from one organization to another.
    c. Contingency Plan. We would require a contingency plan to be in 
effect for responding to system emergencies. The organization would be 
required to perform periodic backups of data, have available critical 
facilities for continuing operations in the event of an emergency, and 
have disaster recovery procedures in place. To satisfy the requirement, 
the plan would include the following:
     Applications and data criticality analysis,
     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 formal 
mechanism for processing records, that is, documented policies and 
procedures for the routine and nonroutine receipt, manipulation, 
storage, dissemination, transmission, and/or disposal of health 
information. This is important to limit the inadvertent loss or 
disclosure of secure information because of process issues.
    e. Information Access Control. An entity would be required to 
establish and maintain formal, documented policies and procedures for 
granting different levels of access to health care information. To 
satisfy this requirement, the following features would be provided:
     Access authorization policies and procedures.
     Access establishment policies and procedures.
     Access modification policies and procedures.
    Access control is also discussed later in this document in the 
personnel security requirement and under the physical safeguards, 
technical security services, and technical security mechanisms 
categories.
    f. Internal Audit. There would be a requirement for an ongoing 
internal audit process, which is the in-house review of the records of 
system activity (for example, logins, file accesses, security 
incidents) maintained by an entity. This is important to enable the 
organization to identify potential security violations.
    g. Personnel Security. There would be a requirement that all 
personnel with access to health information must be authorized to do so 
after receiving appropriate clearances. This is important to prevent 
unnecessary or inadvertent access to secure information. The personnel 
security requirement would require entities to meet the following 
conditions:
     Assure supervision of personnel performing technical 
systems maintenance activities by authorized, knowledgeable persons.
     Maintain access authorization records.
     Insure that operating, and in some cases, maintenance 
personnel have proper access.
     Employ personnel clearance procedures
     Employ personnel security policy/procedures.
     Ensure that system users, including technical maintenance 
personnel are trained in system security.
    h. Security Configuration Management. The organization would be 
required to implement measures, practices, and procedures for the 
security of information systems. These would be coordinated and 
integrated with other system configuration management practices in 
order to create and manage system integrity. This integration process 
is important to ensure that routine changes to system hardware and/or 
software do not contribute to or create security weaknesses. This 
requirement would include the following:
     Documentation.
     Hardware/software installation and maintenance review and 
testing for security features.
     Inventory procedures.
     Security testing.
     Virus checking.
    i. Security Incident Procedures. There would be a requirement to 
implement accurate and current security incident procedures. These are 
formal, documented instructions for reporting security breaches, so 
that security violations are reported and handled promptly. These 
instructions would include the following:
     Report procedures.
     Response procedures.
    j. Security Management Process. A process for security management 
would be required. This involves creating, administering, and 
overseeing policies to ensure the prevention, detection, containment, 
and correction of security breaches. We would require the organization 
to have a formal security management process in place to address the 
full range of security issues. Security management includes the 
following mandatory implementation features:
     Risk analysis.
     Risk management.
     A sanction policy.
     A security policy.
    k. Termination Procedures. There would be a requirement to 
implement termination procedures, which are formal, documented 
instructions, including appropriate security measures, for the ending 
of an employee's employment or an internal/external user's access. 
These procedures are important to prevent the possibility of 
unauthorized access to secure data by those who are no longer 
authorized to access the data. Termination procedures would include the 
following mandatory implementation 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 staff regarding the vulnerabilities of the health information in an 
entity's possession and procedures which must be followed to ensure the 
protection of that information. This is important because employees 
need to understand their security responsibilities and make security a 
part of their day-to-day activities. The implementation features that 
would be required to be incorporated follow:
     Awareness training for all personnel, including 
management, (this is also included as a requirement under physical 
safeguards).
     Periodic security reminders.
     User education concerning virus protection.
     User education in importance of monitoring login success/
failure, and how to report discrepancies.
     User education in password management.

[[Page 43253]]

2. Physical Safeguards To Guard Data Integrity, Confidentiality, and 
Availability
[Please label written comments or e-mailed comments about this 
section with the subject: Physical Safeguards]

    The requirements and implementation features for physical 
safeguards are presented at Sec. 142.308(b) of this proposed rule. We 
would require each of these safeguards to be documented. We would 
require this documentation to be made available to those individuals 
responsible for implementing the safeguards and to be reviewed and 
updated periodically. The following matrix depicts the requirements and 
implementation features for the Physical Safeguards category. Following 
the matrix is a discussion of each of the requirements under that 
category.

    Physical Safeguards To Guard Data Integrity, Confidentiality, and   
                              Availability                              
------------------------------------------------------------------------
              Requirement                         Implementation        
------------------------------------------------------------------------
Assigned security responsibility                                        
Media controls (all listed               Access control.                
 implementation features must be         Accountability (tracking       
 implemented).                            mechanism).                   
                                         Data backup.                   
                                         Data storage.                  
                                         Disposal.                      
Physical access controls (limited        Disaster recovery.             
 access) (all listed implementation      Emergency mode operation.      
 features must be implemented).          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 use                                    
Secure work station location                                            
Security awareness training.                                            
------------------------------------------------------------------------

    a. Assigned Security Responsibility. We would require the security 
responsibility to be assigned to a specific individual or organization, 
and the assignment be documented. These responsibilities would include 
the management and supervision of (1) the use of security measures to 
protect data, and (2) the conduct of personnel in relation to the 
protection of data. This assignment is important to provide an 
organizational focus and importance to security and to pinpoint 
responsibility.
    b. Media Controls. Media controls would be required in the form of 
formal, documented policies and procedures that govern the receipt and 
removal of hardware/software (for example, diskettes, tapes) into and 
out of a facility. They are important to ensure total control of media 
containing health information. These controls would include the 
following mandatory implementation features:
     Controlled access to media.
     Accountability (tracking mechanism).
     Data backup.
     Data storage.
     Disposal.
    c. Physical Access Controls. Physical access controls (limited 
access) would be required. These would be formal, documented policies 
and procedures for limiting physical access to an entity while ensuring 
that properly authorized access is allowed. These controls would be 
extremely important to the security of health information by preventing 
unauthorized physical access to information and ensuring that 
authorized personnel have proper access. These controls would include 
the following mandatory implementation 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 be 
required to have a policy/guideline on workstation use. These 
documented instructions/procedures would delineate the proper functions 
to be performed and the manner in which those functions are to be 
performed (for example, logging off before leaving a terminal 
unattended). This would be important so that employees will understand 
the manner in which workstations must be used to maximize the security 
of health information.
    e. Secure Workstation Location. Each organization would be required 
to put in place physical safeguards to eliminate or minimize the 
possibility of unauthorized access to information. This would be 
important especially in public buildings, provider locations, and in 
areas where there is heavy pedestrian traffic.
    f. Security Awareness Training. Security awareness training would 
be required for all employees, agents, and contractors. This would be 
important because employees would need to understand their security 
responsibilities based on their job responsibilities in the 
organization and make security a part of their daily activities.
3. Technical Security Services To Guard Data Integrity, 
Confidentiality, and Availability
[Please label written comments or e-mailed comments about this 
section with the subject: Technical Security Services]

    The proposed requirements and implementation features for technical 
security services are presented at Sec. 142.308(c). We would require 
each of these services to be implemented and documented. The 
documentation would be made available to those individuals responsible 
for implementing the services and would be reviewed and updated 
periodically. The following matrix depicts the requirements and 
implementation features for the Technical Security Services category. 
Following the matrix is a discussion of

[[Page 43254]]

each of the requirements under that category.

  Technical Security Services To Guard Data Integrity, Confidentiality, 
                            and Availability                            
------------------------------------------------------------------------
              Requirement                         Implementation        
------------------------------------------------------------------------
Access control (The following            Context-based access.          
 implementation feature must be          Encryption.                    
 implemented: Procedure for emergency    Procedure for emergency access.
 access. In addition, at least one of    Role-based access.             
 the following three implementation      User-based access.             
 features must be implemented: Context-                                 
 based access, Role-based access, User-                                 
 based access. The use of Encryption is                                 
 optional).                                                             
Audit controls                                                          
Authorization control (At least one of   Role-based access.             
 the listed implementation features      User-based access.             
 must be implemented).                                                  
Data Authentication                                                     
Entity authentication (The following     Automatic logoff.              
 implementation features must be         Biometric.                     
 implemented: Automatic logoff, Unique   Password.                      
 user identification. In addition, at    PIN.                           
 least one of the other listed           Telephone callback.            
 implementation features must be         Token.                         
 implemented).                           Unique user identification.    
------------------------------------------------------------------------

    a. Access Control. There would be a requirement for access control 
which would restrict access to resources and allow access only by 
privileged entities. It would be important to limit access to health 
information to those employees who have a business need to access it. 
Types of access control include, among others, mandatory access 
control, discretionary access control, time-of-day, classification, and 
subject-object separation. The following implementation feature would 
be used:
     Procedure for emergency access.
    In addition, at least one of the following three implementation 
features would be used:
     Context-based access.
     Role-based access.
     User-based access.
    The use of the encryption implementation feature would be optional.
    b. Audit Controls. Each organization would be required to put in 
place audit control mechanisms to record and examine system activity. 
They would be important so that the organization can identify suspect 
data access activities, assess its security program, and respond to 
potential weaknesses.
    c. Authorization Control. There would be a requirement to put in 
place a mechanism for obtaining consent for the use and disclosure of 
health information. These controls would be necessary to ensure that 
health information is used only by properly authorized individuals. 
Either of the following implementation features may be used:
     Role-based access.
     User-based access (see access control, above.).
    d. Data Authentication. Each organization would be required to be 
able to provide corroboration that data in its possession has not been 
altered or destroyed in an unauthorized manner. Examples of how data 
corroboration may be assured include the use of a check sum, double 
keying, a message authentication code, or digital signature.
    e. Entity Authentication. Each organization would be required to 
implement entity authentication, which is the corroboration that an 
entity is who it claims to be. Authentication would be important to 
prevent the improper identification of an entity who is accessing 
secure data. The following implementation features would be used:
     Automatic log off.
     Unique user identification.
    In addition, at least one of the following implementation features 
would be used:
     A biometric identification system.
     A password system.
     A personal identification number (PIN).
     Telephone callback.
     A token system which uses a physical device for user 
identification.
4. Technical Security Mechanisms To Guard Against Unauthorized Access 
to Data That Is Transmitted Over a Communications Network
[Please label written comments or e-mailed comments about this 
section with the subject: Technical Security Mechanisms]

    In this proposed rule, the requirements and implementation features 
for technical security mechanisms are presented at Sec. 142.308(d). 
Each of these mechanisms would need to be documented. The documentation 
would be made available to those individuals responsible for 
implementing the mechanisms and would be reviewed and updated 
periodically. The following matrix depicts the requirement and 
implementation features for the Technical Security Mechanisms category. 
Following the matrix is a discussion of the requirement under that 
category.

[[Page 43255]]



  Technical Security Mechanisms To Guard Against Unauthorized Access to 
         Data That Is Transmitted Over a Communications Network         
------------------------------------------------------------------------
              Requirement                         Implementation        
------------------------------------------------------------------------
Communications/network controls (If      Access controls.               
 communications or networking is         Alarm.                         
 employed, the following implementation  Audit trail.                   
 features must be implemented:           Encryption.                    
 Integrity controls, Message             Entity authentication.         
 authentication. In addition, one of     Event reporting.               
 the following implementation features   Integrity controls.            
 must be implemented: Access controls,   Message authentication.        
 Encryption. In addition, if using a                                    
 network, the following four                                            
 implementation features must be                                        
 implemented: Alarm, Audit trail,                                       
 Entity authentication, Event                                           
 reporting).                                                            
------------------------------------------------------------------------

    Each organization that uses communications or networks would be 
required to protect communications containing health information that 
are transmitted electronically over open networks so that they cannot 
be easily intercepted and interpreted by parties other than the 
intended recipient, and to protect their information systems from 
intruders trying to access systems through external communication 
points. When using open networks, some form of encryption should be 
employed. The utilization of less open systems/networks such as those 
provided by a value-added network (VAN) or private-wire arrangement 
provides sufficient access controls to allow encryption to be an 
optional feature. These controls would be important because of the 
potential for compromise of information over open systems such as the 
Internet or dial-in lines.
    The following implementation features 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 following 
implementation features would be in place:
     Alarm.
     Audit trail.
     Entity authentication.
     Event reporting.
    Small or Rural Provider Example. The size and organizational 
structure of the entities that would be required to implement this 
standard vary tremendously. Therefore, it would be impossible to 
provide examples that would cover every possible implementation of 
security in the health care industry. Nevertheless, we have included an 
example describing the manner in which a small or rural provider might 
choose to implement the requirements of the standard. (For purposes of 
this example, we would describe a small or rural provider as a one to 
four physician office, with two to five additional employees. The 
office uses a PC-based practice management system, which is used to 
communicate intermittently with a clearinghouse for submission of 
electronic claims. The number of providers is of less importance for 
this example than the relatively simple technology in use and the fact 
that there is insufficient volume or revenue to justify employment of a 
computer system administrator.) We want to emphasize that there are 
numerous ways in which an entity could implement these requirements and 
features. This example does not necessarily represent the best way or 
the only way in which an entity could choose to implement security.
    We anticipate that the small or rural provider office, as described 
above, would normally evaluate and self-certify that the appropriate 
security is in place for its computer system and office procedures. 
This evaluation could be done by a knowledgeable person on the staff, 
or more likely, by a consultant or by the vendor of the practice 
management system as a service to its customers. First, the office 
might assess actual and potential risks to its information assets. 
Then, to establish appropriate security, the office would develop 
policies and procedures to mitigate and manage those risks. These would 
include an overall framework outlining information security activities 
and responsibilities, and repercussions for failure to meet those 
responsibilities.
    Next, this office might develop contingency plans to reduce or 
negate the damage resulting from processing anomalies; for example, 
establish a routine process for maintaining back up floppy disks at a 
second location, obtain a PC maintenance contract, and arrange for use 
of a backup PC should the need arise. This office would need to 
periodically review its plan to determine whether it still met the 
office's needs.
    The office would need to create and document a personnel security 
policy and procedures to be followed. A key individual on the office 
staff should be charged with the responsibility for assuring the 
Personnel Security requirement is met. This responsibility would 
include seeing that the access authorization levels granted are 
documented and kept current (for example, records are kept of everyone 
who is permitted to use the PC and what files they may access), and 
training all personnel in security. Again, we emphasize that these 
requirements are scalable. The requirement for Personnel Clearance 
Procedures could be met in a small office with standard personal and 
professional reference checks, while a large organization may employ 
more formal, rigorous background investigations.
    This same individual could also be charged with the responsibility 
for Security Configuration Management and Termination Procedures. For 
our small provider, the Security Configuration Management requirement 
would be relatively easy to satisfy; the necessary features could be 
part of a purchased hardware/software package (for example, a new PC 
might be equipped with virus checking software), or included as part of 
the support supplied with the purchase of equipment and software. 
Termination procedures would incorporate specific security actions to 
be taken as a result of an employee's termination, such as obtaining 
all keys and changing combinations or passwords. A ``position 
description'' document describing this person's duties could specify 
the level of detail necessary.
    The small or rural provider office would also need to ensure that 
they have activated the internal auditing capability of the software 
used to manage health data files so that it tracks who has accessed the 
data. (We expect that the capability of keeping audit trails will 
become standard in all health care software in the near future, spurred 
on by the health information privacy debates in the Congress and 
elsewhere.)
    A small or rural provider may document compliance with many of the

[[Page 43256]]

foregoing administrative security requirements by including them in an 
``office procedures'' type of document that should be required reading 
by new employees and always available for reference. Requirements that 
would lend themselves to inclusion in an ``office procedures'' document 
include: contingency plans, formal records processing procedures, 
information access controls (rules for granting access, actual 
establishment of access, and procedures for modifying such access), 
security incident procedures (for example, who is to be notified if it 
appears that medical information has been accessed by an unauthorized 
party), and training. Periodic security reminders could include visual 
aids, such as posters and screen savers, and oral reminders in 
recurring meetings.
    Physical Access controls would be relatively straightforward for 
this small or rural office, using locked rooms and/or closets to secure 
equipment and media from unauthorized access. The ``office procedures/
policies'' manual should include directions for authorizing access and 
keeping records of authorized accesses. Media Controls and Workstation 
Use policy instructions would be developed by the office and would 
include additional instructions on such items as where to store backed-
up data, how to dispose of data no longer needed, or logging off when 
leaving terminals unattended.
    Safeguards for the security of workstation location(s) would depend 
upon the physical surroundings in the small or rural office. Our small 
or rural provider may meet the requirements by locating equipment in 
areas that are generally populated by office staff and have some degree 
of physical separation from the public. Security Awareness Training 
would be part of the new employee orientation process and would be a 
periodic recurring discussion item in staff meetings.
    The Technical Security Services requirements for Access Control, 
Entity Authentication, and Authorization Control may be achieved simply 
by implementing a user-based data access model (assigning a user-name 
and password combination to each authorized employee). Other access 
models could be employed if desired, but would prove unwieldy for the 
small office. For example, the role-based access process groups users 
with similar data access needs, and context-based access is based upon 
the context of a transaction--not on the attributes of the initiator. 
By assigning full access rights to a minimum of two key individuals in 
the office, implementation of the Emergency Access feature could be 
satisfied. Audit control mechanisms, by necessity, would be provided by 
software featuring that capability. By establishing and using a message 
authentication code, Data Authentication would be achieved. Use of the 
password system mentioned above could also satisfy the Unique User 
Identification requirement.
    As our example provider contracts with a third party to handle 
claims processing, the claims processing contract would be the vehicle 
to provide for a chain of trust (requiring the contractor to implement 
the same security requirements and take responsibility for protecting 
the data it receives).
    If this provider chooses to use the Internet to transmit or receive 
health information, some form of encryption must be used. For example, 
the provider could procure and use commercial software to provide 
protection against unauthorized access to the data transmitted or 
received. (This decision must take into account what encryption system 
the message recipient uses.) On the other hand, health information when 
transmitted via other means such as VANs, private wires, or even dial-
up connections may not require such absolute protection as is provided 
by encryption. This small or rural provider would likely not be part of 
a network configuration, therefore, only integrity controls and message 
authentication would be required and could be provided by currently 
available software products, most likely provided as part of their 
contract with their health care clearinghouse.
    Small providers may need guidance regarding the content of the 
documents required by this rule (for example, specifics of a chain of 
trust partner agreement). We would expect models of the documentation 
discussed in this example to be developed by industry associations and 
vendors. If this model documentation is not developed, DHHS would work 
with the industry to develop them.

E. Electronic Signature Standard

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

    HIPAA directs the Secretary of the Department of Health and Human 
Services to coordinate with the Secretary of the Department of Commerce 
in adopting standards for the electronic transmission and 
authentication of signatures with respect to the transactions referred 
to in the law. This rule was developed in coordination with the 
Department of Commerce's National Institute of Standards and 
Technology. We propose to adopt a cryptographically based digital 
signature as the standard.
    Whenever a HIPAA specified transaction requires the use of an 
electronic signature, the standard must be used. It should be noted 
that an electronic signature is not required for any of the currently 
proposed standard transactions.
    In the electronic environment, the same legal weight associated 
with an original signature on a paper document may be needed for 
electronic data. Use of an electronic signature refers to the act of 
attaching a signature by electronic means. The electronic signature 
process involves authentication of the signer's identity, a signature 
process according to system design and software instructions, binding 
of the signature to the document and non-alterability after the 
signature has been affixed to the document. The generation of 
electronic signatures requires the successful identification and 
authentication of the signer at the time of the signature.
    The proposed standard for electronic signature is presented at 
Sec. 142.310 and would be digital.
    The following matrix depicts the requirement and implementation 
features for electronic signatures. Following the matrix is a 
discussion of the electronic signature requirement.

[[Page 43257]]



                          Electronic Signature                          
------------------------------------------------------------------------
              Requirement                         Implementation        
------------------------------------------------------------------------
Digital signature (If digital signature  Ability to add attributes.     
 is employed, the following three        Continuity of signature        
 implementation features must be          capability.                   
 implemented: Message integrity,         Countersignatures.             
 Nonrepudiation, User authentication.    Independent verifiability.     
 Other implementation features are       Interoperability.              
 optional).                              Message integrity.             
                                         Multiple Signatures.           
                                         Nonrepudiation.                
                                         Transportability.              
                                         User authentication.           
------------------------------------------------------------------------

    Various technologies may fulfill one or more of the requirements 
specified in the matrix. Authentication systems (passwords, biometrics, 
physical feature authentication, behavioral actions and token-based 
authentication) can be combined with cryptographic techniques to form 
an electronic signature. However, a complete electronic signature 
system may require more than one of the technologies mentioned above. 
If electronic signatures would be used, certain implementation features 
must be included, specifically:
     Message integrity.
     Nonrepudiation.
     User authentication.
    Currently there are no technically mature techniques that provide 
the security service of nonrepudiation in an open network environment, 
in the absence of trusted third parties, other than digital signature-
based techniques. Therefore, if electronic signatures are employed, we 
would require that digital signature technology be used. A digital 
signature is formed by applying a mathematical function to the 
electronic document. This process yields a unique bit string, referred 
to as a message digest. The digest (only) is encrypted using the 
originator's private key and the resulting bit stream is appended to 
the electronic document. The recipient of the transmitted document 
decrypts the message digest with the originator's public key, applies 
the same message hash function to the document, then compares the 
resulting digest with the transmitted version. If they are identical, 
then the recipient is assured that the message is unaltered and the 
identity of the signer is proven. Since only the signatory authority 
can hold the Private Key used to digitally sign the document, the 
critical feature of nonrepudiation is enforced. Other electronic 
signature implementation features 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 Sec. 142.310 of the 
regulation text and is depicted in tabular form along with the security 
standard in a combined matrix located at Addendum 1. We have not 
included the matrix in the proposed regulation text. We invite your 
comments concerning the appropriateness and usefulness of including the 
matrix in the final regulation text. We have also provided a glossary 
of terms to facilitate a common understanding of the matrix entries. 
The glossary can be found at Addendum 2. Finally, we have included 
currently existing standards and guidelines mapped to the proposed 
electronic signature standard. This mapping is not all inclusive and is 
located at Addendum 3.

F. Selection Criteria

    Each individual implementation team weighted the criteria described 
in section I.B. above, Process for Developing National Standards, in 
terms of the standard it was addressing. As we assessed security and 
electronic signatures, it became apparent that while the security 
standard set forth in Sec. 142.308 and the electronic signature 
standard set forth in Sec. 142.310 satisfy all the criteria described 
above, they most strongly address criteria 1, 3, 7, 9, and 10. These 
criteria are described below in the specific context of these 
standards.
    1. Improve the efficiency and effectiveness of the health care 
system.
    The security and electronic signature standards would be integrated 
with the electronic transmission of health care information to improve 
the overall effectiveness of the health care system. This integration 
would assure that electronic health care information would not be 
accessible to any unauthorized person or organization, but would be 
both accurate and available to those who are authorized to receive it.
    3. Be consistent and uniform with the other HIPAA standards and, 
secondly, with other private and public sector health data standards.
    The security and electronic signature standards were developed 
after a comprehensive review of existing standards and guidelines, with 
significant input by a wide range of industry experts. As indicated in 
Addendum 3, the standards map well to existing standards and 
guidelines.
    7. Be technologically independent of computer platforms and 
transmission protocols.
    We have defined the security and electronic signature standards in 
terms of requirements that would allow businesses in the health care 
industry to select the technology that best meets their business 
requirements while still allowing them to comply with the standards.
    9. Keep data collection and paperwork burdens on users as low as is 
feasible.
    The security and electronic signature standards would allow 
individual health care industry businesses to ascertain the level of 
security information that would be needed. The confidentiality level 
associated with individual data elements concerning health care 
information would determine the appropriate security application to be 
used. The security standard would define the requirements to be met to 
achieve the privacy and confidentiality goal, but each business entity, 
driven by its business requirements, would decide what techniques and 
controls would provide appropriate and adequate electronic data 
protection. This would allow data collection and the paperwork burden 
to be as low as is feasible.
    10. Incorporate flexibility to adapt more easily to changes in the 
health care infrastructure and information technology.
    A technologically neutral security standard would be more adaptable 
to changes in infrastructure and information technology.

[[Page 43258]]

G. Consultations

    In the development of the security and electronic signature 
standards, we consulted with many organizations, including those the 
legislation requires (section 1172(c)(3)(B) of the Act):
    1. The NCVHS held two days of public hearings on security issues in 
August 1997, and made a recommendation to the Secretary of HHS, as 
required by the legislation. The NCVHS recommendation to the Secretary 
of HHS, as required by the legislation, was for a technologically 
neutral standard. It identified certain criteria to be established for 
a health information system to be secure. The proposed security 
standard complies with the NCVHS security recommendation.
    2. The ANSI Accredited Standards Committee (ASC) X12 subcommittees 
on communication and control, insurance and government were contacted. 
Their current standards development effort is focused on messaging 
rather than on security requirements.
    3. American Society for Testing and Materials (ASTM), Committee E31 
on Computerized Systems participated in the security discussions.
    4. Association for Electronic Health Care Transactions (AFEHCT), 
the clearinghouse organization, provided information on its health care 
transaction process requirements and emphasized that the security 
standard must be adaptable to different business needs.
    5. Computer-based Patient Record Institute (CPRI) was consulted 
because the Work Group on Confidentiality, Privacy and Security is 
working on the establishment of guidelines, confidentiality agreements, 
security requirements, and frameworks. CPRI works closely with 
accredited standards development organizations.
    6. Health Level Seven (HL-7) has been contacted through its 
participation at the HISB meetings.
    7. NUCC and the NUBC were apprised of the different implementation 
teams' efforts. NUBC has not addressed security issues at any of the 
public meetings. NUCC identified a number of issues at its November 18-
19 meeting and provided written comments to us.

H. Rules for Security Standards and Electronic Signature Standard

    1. Health Plans
    a. In Sec. 142.306(a), we would require health plans to accept and 
apply the security standard to all health care information pertaining 
to an individual that is electronically maintained or electronically 
transmitted. Federal agencies and States may place additional 
requirements on their health plans. In addition, trading partners may 
mutually agree to implement additional security measures.
    b. In Sec. 142.310(a), entities would not be required to use an 
electronic signature. However, if a plan elects to use an electronic 
signature in one of the transactions named in the law, it would be 
required to apply the electronic signature standard described in 
Sec. 142.310(b) to that transaction. In the future, we anticipate that 
the standards for other transactions may include requirements for 
signatures. In particular, the proposed standard for claims 
attachments, which will be issued in a separate regulations package 
later, may include signature requirements on some or all of the 
attachments. If the proposed attachments standard includes such 
signature requirements, we will address the issue of how to reconcile 
such requirements with existing State and Federal requirements for 
written signatures as part of the proposed rule.
2. Health Care Clearinghouses
    a. We would require in Sec. 142.306(b) that each health care 
clearinghouse comply with the security standard to ensure all health 
care information and activities are protected from unauthorized access. 
If the clearinghouse is part of a larger organization, then security 
must be imposed to prevent unauthorized access by the larger 
organization. The security standards apply to all health information 
pertaining to an individual that is electronically maintained or 
electronically transmitted.
    b. In Sec. 142.310(a), entities would not be required to use an 
electronic signature. However, if a plan elects to use an electronic 
signature in one of the transactions named in the law, it would be 
required to apply the electronic signature standard described in 
Sec. 142.310(b) to that transaction. In the future, we anticipate that 
the standards for other transactions may include requirements for 
signatures. In particular, the proposed standard for claims 
attachments, which will be issued in a separate regulations package 
later, may include signature requirements on some or all of the 
attachments. If the proposed attachments standard includes such 
signature requirements, we will address the issue of how to reconcile 
such requirements with existing State and Federal requirements for 
written signatures as part of the proposed rule.
3. Health Care Providers
    a. In Sec. 142.306(a), we would require each health care provider 
to apply the security standard to all health information pertaining to 
an individual that is electronically maintained or electronically 
transmitted.
    b. In Sec. 142.310(a), entities would not be required to use an 
electronic signature. However, if a plan elects to use an electronic 
signature in one of the transactions named in the law, it would be 
required to apply the electronic signature standard described in 
Sec. 142.310(b) to that transaction. In the future, we anticipate that 
the standards for other transactions may include requirements for 
signatures. In particular, the proposed standard for claims 
attachments, which will be issued in a separate regulations package 
later, may include signature requirements on some or all of the 
attachments. If the proposed attachments standard includes such 
signature requirements, we will address the issue of how to reconcile 
such requirements with existing State and Federal requirements for 
written signatures as part of the proposed rule.

I. Effective Dates

    Health plans would be required to comply with the security and 
electronic signature standards as follows:
    1. Each health plan that is not a small health plan would have to 
comply with the requirements of Secs. 142.306, 142.308, and 142.310 no 
later than 24 months after publication of the final rule.
    2. Each small health plan would have to comply with the 
requirements of Secs. 142.306, 142.308, and 142.310 no later than 36 
months after the date of publication of the final rule.
    3. If the effective date for the electronic transaction standards 
is later than the effective date for the security standard, 
implementation of the security standard would not be delayed until the 
standard transactions are in use. The security standard would still be 
effective with respect to electronically stored or maintained data. 
Security of health information would not be solely tied to the standard 
transactions but would apply to all individual health information 
electronically stored, maintained, or transmitted.
    4. Under this proposed rule, in some cases, a health plan could 
choose to convert from paper to standard EDI transactions prior to the 
effective date of the security standard. We would recommend that the 
security standard be implemented at that time in order to safeguard the 
data in those transactions. We invite comments on this issue.

[[Page 43259]]

    Failure to comply with standards may result in monetary penalties. 
The Secretary is required by statute to impose penalties of not more 
than $100 per violation on any person who fails to comply with a 
standard, except that the total amount imposed on any one person in 
each calendar year may not exceed $25,000 for violations of one 
requirement.
    We are not proposing any enforcement procedures at this time, but 
we plan to do so in a future Federal Register document once the 
industry has some experience with using the standards. These procedures 
will be in place by the time the standards are implemented by industry. 
We envision the monitoring and enforcement process as a partnership 
between the Federal government and the private sector. Some private 
accreditation bodies have already exhibited interest in certifying 
compliance with the security requirements as part of their 
accreditation reviews. Small providers may be able to self-certify 
through industry-developed checklists. HHS would likely retain the 
final responsibility for determining violations and imposing the 
penalties specified by the statute. We welcome comments on this 
approach.

III. Implementation

    If an entity elects to use an electronic signature in a 
transaction, or if an electronic signature is required by a transaction 
standard adopted by the Secretary, the entity must apply the electronic 
signature standard described in Sec. 142.310(b).
    How the security standard would be implemented is dependent upon 
industry trading partner agreements for electronic transmissions. The 
health care industry would be able to adapt the security matrix to meet 
its business needs. We propose that the requirements of the security 
standard be implemented over time. However, we would require 
implementation to be complete by the applicable effective date. We 
would encourage, but not require that entities comply with the security 
standard as soon as practicable, preferably before implementing the 
transactions standards.
    The security standard would supersede contrary provisions of State 
law including State law requiring medical or health plan records to be 
maintained or transmitted in other electronic formats. There are 
certain exceptions when the standards would not supersede contrary 
provisions of State law; section 1178 identifies those conditions and 
directs the Secretary to determine whether a particular State provision 
falls within one or more of the exceptions.
    The electronic signature standard (digital signature) would be 
deemed to satisfy Federal and State statutory requirements for written 
signatures with respect to the named transactions referred to in the 
legislation.
    Several accreditation organizations such as the Electronic 
Healthcare Network Accreditation Commission (EHNAC), the Joint 
Commission on Accreditation of Healthcare Organizations (JCAHO), and 
the National Committee for Quality Assurance (NCQA), indicate that one 
of their accreditation requirements will be compliance with the HIPAA 
security and electronic signature (if applicable) standards.

IV. New and Revised Standards

    To encourage innovation and promote development, we plan to 
establish a process to allow an organization to request a revision or 
replacement to any adopted standard or standards. An organization could 
request a revision or replacement to an adopted standard by requesting 
a waiver from the Secretary of Health and Human Services to test a 
revised or new standard. The organization would be required, at a 
minimum, to demonstrate that the revised or new standard offers a clear 
improvement over the adopted standard. If the organization presents 
sufficient documentation that supports testing of a revised or new 
standard, we want to be able to grant the organization a temporary 
waiver to test while remaining in compliance with the law. We do not 
intend to establish a process that would allow an organization to avoid 
using any adopted standard.
    We would welcome comments on the following: (1) How we should 
establish this process, (2) the length of time a proposed standard 
should be tested before we decide whether to adopt it, (3) whether we 
should solicit public comments before implementing a change in a 
standard, and (4) other issues and recommendations we should consider. 
Comments should be submitted to the addresses presented in the 
ADDRESSES section of this document.
    The following is one possible process:
     Any organization that wishes to revise or replace an 
adopted standard would submit its waiver request to an HHS evaluation 
committee (to be established or defined). The organization would do the 
following for each standard it wishes to revise or replace:
    + Provide a detailed explanation, no more than 10 pages, of how the 
revision or replacement would be a clear improvement over the current 
standard.
    + Provide specifications and technical capabilities on the revised 
or new standard, including any additional system requirements.
    + Provide an explanation, no more than five pages, of how the 
organization intends to test the standard.
     The committee's evaluation would, at a minimum, be based 
on the following:
    + A cost-benefit analysis.
    + An assessment of whether the proposed revision or replacement 
demonstrates a clear improvement to an existing standard.
    + The extent and length of time of the waiver.
     The evaluation committee would inform the organization 
requesting the waiver within 30 working days of the committee's 
decision on the waiver request. If the committee decides to grant a 
waiver, the notification may include the following:
    + Committee comments such as the following:

--The length of time for which the waiver applies if it differs from 
the waiver request.
--The sites the committee believes are appropriate for testing if they 
differ from the waiver request.
--Any pertinent information regarding the conditions of an approved 
waiver.
     Any organization that receives a waiver would be required 
to submit a report containing the results of the study, no later than 3 
months after the study is completed.
     The committee would evaluate the report and determine 
whether the benefits of the proposed revision or new standard 
significantly outweigh the disadvantages of implementing it and make a 
recommendation to the Secretary.

V. Response to Comments

    Because of the large number of items of correspondence we normally 
receive on Federal Register documents published for comment, we are not 
able to acknowledge or respond to them individually. We will consider 
all comments we receive by the date and time specified in the DATES 
section of this preamble, and, if we proceed with a subsequent 
document, we will respond to the major comments in the preamble of that 
document.

VI. Impact Analysis

    As the effect of any one standard is affected by the implementation 
of other standards, it can be misleading to discuss the impact of one 
standard by itself. Therefore, we did an impact

[[Page 43260]]

analysis on the total effect of all the standards in the proposed rule 
concerning the national provider identifier (HCFA-0045-P), which was 
published on May 7, 1998 (63 FR 25320).
    We intend to publish in each proposed rule an impact analysis that 
is specific to the standard or standards proposed in that rule, but the 
impact analysis will assess only the relative cost impact of 
implementing a given standard. Thus, the following discussion contains 
the impact analysis for the security standard and the electronic 
signature standard proposed in this rule. As stated in the general 
impact analysis in HCFA-0045-P, we do not intend to associate costs and 
savings to specific standards.
    Although we cannot determine the specific economic impact of the 
standards being proposed in this rule (and individually each standard 
may not have a significant impact), the overall impact analysis makes 
clear that, collectively, all the standards will have a significant 
impact of over $100 million on the economy. Also, while each standard 
may not have a significant impact on a substantial number of small 
entities, the combined effects of all the proposed standards may have a 
significant effect on a substantial number of small entities. 
Therefore, the following impact analysis should be read in conjunction 
with the overall impact analysis.
    The following describes the specific impacts that relate to the 
security and electronic signature standards. Security protection for 
health care information is not a ``stand-alone'' type requirement. 
Appropriate security protections will be a business enabler, 
encouraging the growth and use of electronic data interchange. The 
synergistic effect of the employment of the recommended security 
practices, procedures and technologies will enhance all aspects of 
HIPAA's Administrative Simplification requirements. In addition, it is 
important to recognize that security is not a product, but is an on-
going, dynamic process.
    In accordance with the provisions of Executive Order 12866, this 
proposed rule was reviewed by the Office of Management and Budget.

A. Security Standard

    HIPAA requires that all health plans, health care providers, and 
health care clearinghouses that maintain or transmit health information 
electronically establish and maintain reasonable and appropriate 
administrative, technical, and physical safeguards to ensure integrity, 
confidentiality, and availability of the information. The safeguards 
also protect the information against any reasonably anticipated threats 
or hazards to the security or integrity of the information and protect 
it against unauthorized use or disclosure. Recommendation 1 from the 
National Research Council's (NRC) report For the Record: Protecting 
Electronic Health Information (``All organizations that handle patient-
identifiable health care information-- regardless of size--should adopt 
the set of technical and organization policies, practices, and 
procedures described * * * to protect such information.'') would apply 
to all health care providers regardless of size, health care 
clearinghouses, and health plans. We agree with the NRC's belief that 
implementation of the practices and technologies delineated in 
Recommendation 1 would be possible today, and at a reasonable cost.
    Health care providers that conduct electronic transactions with 
health plans would have to comply with the recommendation(s) for 
security protection. There is, however, no requirement to maintain 
health records electronically or transmit health care information by 
electronic means. There may also be health care providers that 
currently submit health care information on paper but archive records 
electronically. These entities will need to ensure that their existing 
electronic systems conform to security requirements for maintaining 
health information. Once they have done so, however, they may also take 
advantage of all the other benefits of electronic recordkeeping and 
transmittal. Therefore, no individual small entity is expected to 
experience direct costs that exceed benefits as a result of this rule. 
Furthermore, because almost all of the NRC recommendations reflect 
contemporary security measures and controls, most organizations that 
currently have security measures should have to make few, if any, 
modifications to their systems to meet the requirements proposed in the 
security standard.
    The singular exception to the above lies in the area of providing 
security for the electronic transmission of health care information 
over insecure, public media. Here, the choice of a method to use is 
driven by economic factors. If an organization wishes to use an 
insecure transmission media such as the Internet, and take advantage of 
the low costs involved, off-setting costs may need to be incurred to 
provide for an acceptable form of encryption so that health information 
will be protected from intercept and possible misuse.
    One alternative course of action to encrypting the information 
would be to use the services of a VAN. VANs do not manipulate data, but 
rather transmit data in its native form over telecommunication lines. 
We anticipate that VANs would be positively affected by administrative 
simplification, because use of the proposed transactions standards 
would eliminate the need for data to be reformatted. This would allow 
providers to purchase the services of a VAN directly, rather than as a 
service bundled with the functions of other clearinghouses. Another 
course of action might be to use private lines which would provide an 
appropriate level of protection for data in transmission.

B. Electronic Signature Standard

    HIPAA does not require the use of electronic signatures. This 
particular capability, however, would be necessary for a completely 
paperless environment. Certain features of the digital signature type 
of electronic signature make this particular system the most desirable. 
Only digital signatures, using current technology, provide the 
combination of authenticity, message integrity, and nonrepudiation 
which is viewed as a desirable complement to the security standards 
required by the law.
    The use of digital signatures requires a certain infrastructure 
(Public Key Infrastructure) that may necessitate the expenditure of 
initial and recurring costs for users. We do not know what these costs 
are presently, due to the lack of maturity of digital signature 
technology, and minimal use in the marketplace today. It is noted that 
public key certificate management systems and services do exist today, 
and it is presumed more quantifiable information will be forthcoming, 
as to potential costs and savings that can be associated with the use 
of digital signature systems. Other forms of electronic signature were 
considered, such as biometric and digitized signatures. While they 
provide a useful capability in certain circumstances, we believe that 
digital signature technology is most appropriate for this particular 
application.

C. Guiding Principles for Standard Selection

    The implementation teams charged with designating standards under 
the statute have defined, with significant input from the health care 
industry, a set of common criteria for evaluating potential standards. 
These criteria are based on direct specifications in the HIPAA, the 
purpose of the law, and principles that support the regulatory

[[Page 43261]]

philosophy set forth in EO 12866 of September 30, 1993. In order to be 
designated as a standard, EO 12866 requires that a proposed standard:
     Improve the efficiency and effectiveness of the health 
care system by leading to cost reductions for or improvements in 
benefits from electronic HIPAA health care transactions. This principle 
supports the regulatory goals of cost-effectiveness and avoidance of 
burden.
     Meet the needs of the health data standards user 
community, particularly health care providers, health plans, and health 
care clearinghouses. This principle supports the regulatory goal of 
cost-effectiveness.
     Be consistent and uniform with the other HIPAA standards 
(that is, their data element definitions and codes and their privacy 
and security requirements) and, secondarily, with other private and 
public sector health data standards. This principle supports the 
regulatory goals of consistency and avoidance of incompatibility, and 
it establishes a performance objective for the standard.
     Have low additional development and implementation costs 
relative to the benefits of using the standard. This principle supports 
the regulatory goals of cost-effectiveness and avoidance of burden.
     Be supported by an ANSI-accredited standards developing 
organization or other private or public organization that would ensure 
continuity and efficient updating of the standard over time. This 
principle supports the regulatory goal of predictability.
     Have timely development, testing, implementation, and 
updating procedures to achieve administrative simplification benefits 
faster. This principle establishes a performance objective for the 
standard.
     Be technologically independent of the computer platforms 
and transmission protocols used in HIPAA health transactions, except 
when they are explicitly part of the standard. This principle 
establishes a performance objective for the standard and supports the 
regulatory goal of flexibility.
     Be precise and unambiguous but as simple as possible. This 
principle supports the regulatory goals of predictability and 
simplicity.
     Keep data collection and paperwork burdens on users as low 
as is feasible. This principle supports the regulatory goals of cost-
effectiveness and avoidance of duplication and burden.
     Incorporate flexibility to adapt more easily to changes in 
the health care infrastructure (such as new services, organizations, 
and provider types) and information technology. This principle supports 
the regulatory goals of flexibility and encouragement of innovation.
    We assessed a wide variety of security standards, guidelines and 
electronic signature standards against the principles listed above, 
with the overall goal of achieving the maximum benefit for the least 
cost. We found that there exists no single standard for security or 
electronic signature that encompasses all the requirements that have 
been deemed necessary. However, in this particular area, technology is 
rapidly developing enhancements and better means for accomplishing the 
stated goals.

D. Affected Entities

1. Health Care Providers
    Health care providers that conduct business using electronic 
transactions with other health care participants (such as other health 
care providers, health plans, and employers) or maintain electronic 
health information are encouraged, but are not required to 
simultaneously implement the proposed security standard. However, if 
the effective date for the electronic transaction standards is later 
than the effective date for the security standard, the implementation 
of the security standard will not be delayed until the standard 
transactions are in use.
    Health care providers that transmit, receive, or maintain health 
information would incur implementation costs for establishing or 
updating their security systems. Any negative impact on these health 
care providers caused by implementing the proposed security standard 
would generally be related to the initial implementation period for the 
specific requirements of the security standard. Health care providers 
that are indirectly involved in electronic transactions (for example, 
those who submit a paper claim that the health plan transmits 
electronically to a secondary payer) and do not maintain electronic 
health information would not be affected.
2. Health Plans
    Health plans that engage in electronic health care transactions 
would have to modify their systems to use the security standard and the 
electronic signature standard, if used. Health plans that maintain 
electronic health information would also have to modify their systems 
to use the security standard. This conversion would have a one-time 
cost impact on Federal, State and private plans alike.
    We recognize that this conversion process has the potential to 
cause business disruption of some health plans. However, health plans 
would be able to schedule their implementation of the security standard 
and other standards in a way that best fits their needs, as long as 
they meet the deadlines specified in the law.
    Implementation of the security standard and the electronic 
signature standard, if used by the entities, would enhance payment 
safeguard activities and protect the integrity of the Medicare trust 
fund by reducing fraud and abuse that occurs when health care 
information is used by those who are not authorized to receive it. In 
addition these standards would assist the plans, providers, and 
clearinghouses to more effectively maintain the security of all health 
information in their databases.
3. Clearinghouses
    Health care clearinghouses would face impacts similar to those 
experienced by health care providers and health plans. Systems vendors, 
that provide computer software applications to health care providers 
and other billers of health care services, would likely be positively 
affected. These vendors would have to develop software solutions that 
would allow health care providers and other billers of health care 
transactions to protect the information in their databases from 
unwanted access to their systems.
4. Unfunded Mandates
    This proposed rule has been reviewed in accordance with the 
Unfunded Mandates Reform Act of 1995 (UMRA) (U.S.C. 1501 et seq.) and 
Executive Order 12875. As discussed in the combined impact analysis 
referenced above (see Federal Register, Volume 63, No. 88), DHHS 
estimates that implementation of the standards will require the 
expenditure of more than $100 million by the private sector. Therefore, 
the rule establishes a Federal private sector mandate and is a 
significant regulatory action within the meaning of section 202 of UMRA 
(2 U.S.C. 1532). DHHS has included this statement to address the 
anticipated effects of the proposed rules pursuant to section 202.
    These standards also apply to State and local governments in their 
roles as health plans or health care providers. Thus, the proposed 
rules impose unfunded mandates on these entities. While we do not have 
sufficient information to provide estimates of these impacts, several 
State Medicaid agencies have estimated that it would cost $1 million 
per State to implement

[[Page 43262]]

all of the HIPAA standards. However, the Congressional Budget Office 
analysis stated that ``States are already in the forefront in 
administering the Medicaid program electronically; the only costs--
which should not be significant--would involve bringing the software 
and computer systems for the Medicaid programs into compliance with the 
new standards.''
    The anticipated benefits and costs of this proposed standard, and 
other issues raised in section 202 of the UMRA, are addressed in the 
analysis below, and in the combined impact analysis. In addition, under 
section 205 of the UMRA (2 U.S.C. 1535), having considered a reasonable 
number of alternatives as outlined in the preamble to this rule and in 
the following analysis, the Department has concluded that the rule is 
the most cost-effective alternative for implementation of DHHS'' 
statutory objective of administrative simplification.
5. Regulatory Flexibility Act
    The Regulatory Flexibility Act (RFA) of 1980, Public Law 96-354, 
requires us to prepare a regulatory flexibility analysis if the 
Secretary certifies that a proposed regulation would have a significant 
economic impact on a substantial number of small entities. The security 
and electronic signature standards will affect small entities, such as 
providers. A more detailed analysis of the impact on small entities is 
part of the impact analysis we published on May 7, 1998 (63 FR 25320) 
for all the HIPAA standards. A detailed illustration of the potential 
impact of the security standard on a small health care provider can be 
found in the preamble in section D.

E. Factors in Establishing the Security Standard

1. Selection of Security Systems and Procedures
    Because there is no national security standard in widespread use 
throughout the industry, adopting any of the candidate standards would 
require most health care providers, health plans and health care 
clearinghouses to conform to the new standard. Implementation of the 
security standard would require all health plans, health care 
providers, and health care clearinghouses to establish or revise their 
security precautions because the proposed standard is not currently in 
use. The selection of the security standard does not impose a greater 
burden on the industry than the nonselected options, and presents 
significant advantages in terms of universality, uniqueness and 
flexibility.
    Only those plans, providers, and clearinghouses that decide to use 
the digital signature would be affected by the electronic signature 
standard. Some large health plans, health care providers, and health 
care clearinghouses that currently exchange health information among 
trading partners may have security systems and procedures in place to 
protect the information from unauthorized access. These entities may 
not incur significant costs to meet the proposed security standard and 
if they opt not to use the digital signature they would not incur costs 
to meet the electronic signature requirements. Also, some entities that 
currently use electronic signatures as an added security measure may 
also be using digital signature technology. At most, large entities 
that may have sophisticated security systems in place may only need to 
revise or update their systems to meet the proposed security standard 
and electronic signature standard.
2. Complexity of Conversion
    The complexity of the conversion would be significantly affected by 
the volume of claims health plans process electronically and the desire 
to transmit the claims themselves or to use the services of a VAN or a 
clearinghouse. If they chose to transmit themselves, they would need to 
convert to the proposed transaction standards. Specific technology 
limitations of existing systems could affect the complexity of the 
conversion. For example, some entities may only have a minimum level of 
security and procedures in place and therefore may require a full 
upgrade, while others may already have a very sophisticated system and 
procedures and require very little enhancement.
3. Cost of Conversion
    We expect that most providers, health plans, and clearinghouses 
that transmit or store data electronically have already implemented 
some security measures and will primarily need to assess existing 
security, identify areas of risk, and implement additional measures. We 
cannot estimate the per-entity cost of implementation because there is 
no information available regarding the extent to which providers', 
plans', and clearinghouses' current security practices are deficient. 
Moreover, some security solutions are almost cost-free to implement 
(e.g., reminding employees not to post passwords on their monitors) 
while others are not.
    Affected entities will have many choices regarding how they will 
implement security. Some may choose to assess security using in-house 
staff, while others will utilize consultants. Practice management 
software vendors may also provide security consultation services to 
their customers. Entities may also choose to implement security 
measures that require hardware or software purchases at the time they 
do routine equipment upgrades.
    The security requirements we are proposing were developed with 
considerable input from the health care industry, including providers, 
health plans, clearinghouses, vendors, and standards organizations. 
Industry members strongly advocated this flexible approach, which 
permits each affected entity to develop cost-effective security 
measures. We believe that this approach will yield the lowest 
implementation cost to industry while assuring that health information 
is safeguarded. We solicit input regarding implementation costs.
    We are unable to estimate, of the nation's 4 million-plus health 
plans and 1.2 million-plus providers, the number of entities that would 
require security systems and procedures because they conduct electronic 
transactions or maintain electronic health information. Nor are we able 
to estimate the number of entities that neither conduct electronic 
transactions nor maintain electronic health information but may choose 
to do so at some future time. (These would be entities that send and 
receive paper transactions and maintain paper records and thus would 
not be affected because they would have no need to implement security 
standards.) However, we are aware of the possibility that those small 
entities that currently process claims electronically or maintain 
electronic health information may not be able to continue to do so due 
to the cost of establishing security systems to meet the requirements 
of the proposed security standard. Those entities that are not able to 
bill and exchange health information electronically may use 
clearinghouses. We believe that the proposed security standard 
represents the minimum necessary for adequate protection of health 
information in an electronic format. As discussed earlier in this 
preamble, the security requirements are both scalable and technically 
flexible; and while the law requires each health plan that is not a 
small plan to comply with the security and electronic signature 
requirements no later than 24 months after the effective date of the 
final rule, small plans will be allowed an additional 12 months to 
comply.
    Since we are unable to estimate the number of entities, we are also 
unable to estimate the cost to the entities that will process 
electronic transactions.

[[Page 43263]]

However, we believe that the cost of establishing security systems and 
procedures is a portion of the costs associated with converting to the 
transaction standards that are required under HIPAA.
    This discussion on conversion costs relates only to health plans, 
health care providers, and health care clearinghouses that are required 
to follow the security standard to maintain, transmit or receive 
electronic health information. Other entities would not be required to 
follow the security standard and procedures until they choose to 
maintain, transmit, or receive electronic health information. The cost 
of establishing security systems and procedures for entities that do 
not transmit, receive or maintain health information electronically is 
not included in our estimates.

VII. Collection of Information Requirements

    Under the Paperwork Reduction Act of 1995, we are required to 
provide 60-day notice in the Federal Register and solicit public 
comment before a collection of information requirement is submitted to 
the Office of Management and Budget (OMB) for review and approval. In 
order to fairly evaluate whether an information collection should be 
approved by OMB, section 3506(c)(2)(A) of the Paperwork Reduction Act 
of 1995 requires that we solicit comment on the following issues:
     The need for the information collection and its usefulness 
in carrying out the proper functions of our agency.
     The accuracy of our estimate of the information collection 
burden.
     The quality, utility, and clarity of the information to be 
collected.
     Recommendations to minimize the information collection 
burden on the affected public, including automated collection 
techniques.
    As discussed below, we are soliciting comment on the recordkeeping 
requirements, as referenced in Sec. 142.308 of this document. In 
addition, we are soliciting comment on the applicability of the PRA as 
it may relate to the requirement to use the standard adopted in 
Sec. 142.310 of this regulation.

Section 142.308  Security Standard

    In summary, each entity designated in Sec. 142.302 must maintain 
documentation demonstrating the development, implementation, and 
maintenance of appropriate security measures that include, at a 
minimum, the requirements and implementation features set forth in this 
section. In addition, entities must maintain necessary documentation to 
demonstrate that these measures have been periodically reviewed, 
validated, updated, and kept current.
    While we solicit comment on these recordkeeping requirements we 
explicitly solicit comment on the burden associated with maintaining 
documentation related to the implementation the requirements set forth 
in Sec. 142.308. Since the level of documentation necessary to 
demonstrate compliance with these requirements is dependent upon 
individual business needs and the fact that we do not prescribe the 
form, format, or degree of documentation necessary to demonstrate 
compliance, we are currently unable to accurately estimate the degree 
of recordkeeping burden that will be experienced by the varying 
entities. Therefore, commentors should provide an estimate of: (1) the 
initial recordkeeping burden associated with meeting these requirements 
and (2) the recordkeeping burden associated with maintaining 
documentation to demonstrate that the measures have been periodically 
reviewed, validated, updated, and kept current.
    Below is a discussion of the applicability of the PRA as it may 
relate to the adoption of the standard referenced in Sec. 142.310 of 
this regulation.

Section 142.310  Electronic Signature Standard

    In summary, any entity electing to use an electronic signature in a 
transaction as defined in Sec. 142.103, or if an electronic signature 
is required by a transaction standard adopted by the Secretary, the 
entity must apply the electronic signature standard described in 
paragraph (b) of this section to that transaction.
Discussion
    The emerging and increasing use of health care EDI standards and 
transactions raises the issue of the applicability of the PRA. The 
question arises whether a regulation that adopts an EDI standard used 
to exchange certain information constitutes an information collection 
subject to the PRA.
    In particular, we are still considering whether the use of any EDI 
transaction standard, such as the electronic signature described in 
this regulation, should be viewed or regarded as a standardized 
electronic collection of information. If it is a standardized 
electronic information collection, then the requirement by the Federal 
government on the industry to accept and transmit the information may 
be subject to OMB review and approval under the PRA.
    We invite public comment on the issues discussed above. If the 
requirements, as set forth in Sec. 142.310 are determined to be subject 
to the PRA, we will submit these requirements to OMB for PRA approval. 
If you comment on these information collection and recordkeeping 
requirements, please e-mail comments to JB[email protected] (Attn: HCFA-
0049) or mail copies directly to the following:

Health Care Financing Administration, Office of Information Services, 
Security and Standards Group, Division of HCFA Enterprise Standards, 
Room N2-14-26, 7500 Security Boulevard, Baltimore, MD 21244-1850. Attn: 
John Burke HCFA-0049, HCFA Reports Clearance Officer
And
Office of Information and Regulatory Affairs, Office of Management and 
Budget, Room 10235, New Executive Office Building, Washington, DC 
20503, Attn: Allison Herron Eydt, HCFA Desk Officer

List of Subjects in 45 CFR Part 142

    Administrative practice and procedure, Health facilities, Health 
insurance, Hospitals, Medicaid, Medicare, Report and recordkeeping 
requirement.

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

    Note to Reader: This proposed rule is one of several proposed 
rules that are being published to implement the administrative 
simplification provisions of the Health Insurance Portability and 
Accountability Act of 1996. We propose to establish a new 45 CFR 
Part 142. Proposed Subpart A--General Provisions is exactly the same 
in each rule unless we have added new sections or definitions to 
incorporate additional general information. The subparts that follow 
relate to the specific provisions announced separately in each 
proposed rule. When we publish the first final rule, each subsequent 
final rule will revise or add to the text that is set out in the 
first final rule.

PART 142--ADMINISTRATIVE REQUIREMENTS

Subpart A--General Provisions

Sec.
142.101  Statutory basis and purpose.
142.102  Applicability.
142.103  Definitions.
142.104  General requirements for health plans.
142.105  Compliance using a health care clearinghouse.
142.106  Effective dates of a modification to a standard or 
implementation specification.

[[Page 43264]]

Subpart B--Reserved

Subpart C--Security and Electronic Signature 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 and electronic standards.

    Authority: Sections 1173 and 1175 of the Social Security Act (42 
U.S.C. 1320d-2 and 1320d-4).

Subpart A--General Provisions


Sec. 142.101  Statutory basis and purpose.

    Sections 1171 through 1179 of the Social Security Act, 42 U.S.C. 
1320d, as added by section 262 of the Health Insurance Portability and 
Accountability Act of 1996, require HHS to adopt national standards for 
the electronic exchange of health information in the health care 
system. The purpose of the sections of this part is to promote 
administrative simplification.


Sec. 142.102  Applicability.

    (a) The standards adopted or designated under this part apply, in 
whole or in part, to the following:
    (1) A health plan.
    (2) A health care clearinghouse when doing the following:
    (i) Transmitting a standard transaction (as defined in 
Sec. 142.103) to a health care provider or health plan.
    (ii) Receiving a standard transaction from a health care provider 
or health plan.
    (iii) Transmitting and receiving the standard transactions when 
interacting with another health care clearinghouse.
    (3) A health care provider when transmitting an electronic 
transaction as defined in Sec. 142.103.
    (b) Means of compliance are stated in greater detail in 
Sec. 142.105.


Sec. 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 as tables of terms, medical concepts, medical diagnostic codes, or 
medical procedure codes.
    Health care clearinghouse means a public or private entity that 
processes or facilitates the processing of nonstandard data elements of 
health information into standard data elements. The entity receives 
health care transactions from health care providers or other entities, 
translates the data from a given format into one acceptable to the 
intended payer or payers, and forwards the processed transaction to 
appropriate payers and clearinghouses. Billing services, repricing 
companies, community health management information systems, community 
health information systems, and ``value-added'' networks and switches 
are considered to be health care clearinghouses for purposes of this 
part.
    Health care provider means a provider of services as defined in 
section 1861(u) of the Social Security Act, 42 U.S.C. 1395x, a provider 
of medical or other health services as defined in section 1861(s) of 
the Social Security Act, and any other person who furnishes or bills 
and is paid for health care services or supplies in the normal course 
of business.
    Health information means any information, whether oral or recorded 
in any form or medium, that--
    (1) Is created or received by a health care provider, health plan, 
public health authority, employer, life insurer, school or university, 
or health care clearinghouse; and
    (2) Relates to the past, present, or future physical or mental 
health or condition of an individual, the provision of health care to 
an individual, or the past, present, or future payment for the 
provision of health care to an individual.
    Health plan means an individual or group plan that provides, or 
pays the cost of, medical care. Health plan includes the following, 
singly or in combination:
    (1) Group health plan. A group health plan is an employee welfare 
benefit plan (as currently defined in section 3(1) of the Employee 
Retirement Income and Security Act of 1974, 29 U.S.C. 1002(1)), 
including insured and self-insured plans, to the extent that the plan 
provides medical care, including items and services paid for as medical 
care, to employees or their dependents directly or through insurance, 
or otherwise, and--
    (i) Has 50 or more participants; or
    (ii) Is administered by an entity other than the employer that 
established and maintains the plan.
    (2) Health insurance issuer. A health insurance issuer is an 
insurance company, insurance service, or insurance organization that is 
licensed to engage in the business of insurance in a State and is 
subject to State law that regulates insurance.
    (3) Health maintenance organization. A health maintenance 
organization is a Federally qualified health maintenance organization, 
an organization recognized as a health maintenance organization under 
State law, or a similar organization regulated for solvency under State 
law in the same manner and to the same extent as such a health 
maintenance organization.
    (4) Part A or Part B of the Medicare program under title XVIII of 
the Social Security Act.
    (5) The Medicaid program under title XIX of the Social Security 
Act.
    (6) A Medicare supplemental policy (as defined in section 
1882(g)(1) of the Social Security Act, 42 U.S.C. 1395ss).
    (7) A long-term care policy, including a nursing home fixed-
indemnity policy.
    (8) An employee welfare benefit plan or any other arrangement that 
is established or maintained for the purpose of offering or providing 
health benefits to the employees of two or more employers.
    (9) The health care program for active military personnel under 
title 10 of the United States Code.
    (10) The veterans health care program under 38 U.S.C. chapter 17.
    (11) The Civilian Health and Medical Program of the Uniformed 
Services (CHAMPUS), as defined in 10 U.S.C. 1072(4).
    (12) The Indian Health Service program under the Indian Health Care 
Improvement Act (25 U.S.C. 1601 et seq.).
    (13) The Federal Employees Health Benefits Program under 5 U.S.C. 
chapter 89.
    (14) Any other individual or group health plan, or combination 
thereof, that provides or pays for the cost of medical care.
    Medical care means the diagnosis, cure, mitigation, treatment, or 
prevention of disease, or amounts paid for the purpose of affecting any 
body structure or function of the body; amounts paid for transportation 
primarily for and essential to these items; and amounts paid for 
insurance covering the items and the transportation specified in this 
definition.
    Participant means any employee or former employee of an employer, 
or any member or former member of an employee organization, who is or 
may become eligible to receive a benefit of any type from an employee 
benefit plan that covers employees of that employer or members of such 
an organization, or whose beneficiaries may be eligible to receive any 
of these benefits. ``Employee'' includes an individual who is treated 
as an employee under section 401(c)(1) of the Internal Revenue Code of 
1986 (26 U.S.C. 401(c)(1)).
    Small health plan means a group health plan or individual health 
plan with fewer than 50 participants.

[[Page 43265]]

    Standard means a set of rules for a set of codes, data elements, 
transactions, or identifiers promulgated either by an organization 
accredited by the American National Standards Institute or HHS for the 
electronic transmission of health information.
    Transaction means the exchange of information between two parties 
to carry out financial and administrative activities related to health 
care. It includes the following:
    (1) Health claims or equivalent encounter information.
    (2) Health care payment and remittance 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.


Sec. 142.104  General requirements for health plans.

    If a person conducts a transaction (as defined in Sec. 142.103) 
with a health plan as a standard transaction, the following apply:
    (a) The health plan may not refuse to conduct the transaction as a 
standard transaction.
    (b) The health plan may not delay the transaction or otherwise 
adversely affect, or attempt to adversely affect, the person or the 
transaction on the ground that the transaction is a standard 
transaction.
    (c) The health information transmitted and received in connection 
with the transaction must be in the form of standard data elements of 
health information.
    (d) A health plan that conducts transactions through an agent must 
assure that the agent meets all the requirements of this part that 
apply to the health plan.


Sec. 142.105  Compliance using a health care clearinghouse.

    (a) Any person or other entity subject to the requirements of this 
part may meet the requirements to accept and transmit standard 
transactions by either--
    (1) Transmitting and receiving standard data elements; or
    (2) Submitting nonstandard data elements to a health care 
clearinghouse for processing into standard data elements and 
transmission by the health care clearinghouse and receiving standard 
data elements through the health care clearinghouse.
    (b) The transmission, under contract, of nonstandard data elements 
between a health plan or a health care provider and its agent health 
care clearinghouse is not a violation of the requirements of this part.


Sec. 142.106  Effective dates of a modification to a standard or 
implementation specification.

    HHS may modify a standard or implementation specification after the 
first year in which HHS requires the standard or implementation 
specification to be used, but not more frequently than once every 12 
months. If HHS adopts a modification to a standard or implementation 
specification, the implementation date of the modified standard or 
implementation specification may be no earlier than 180 days following 
the adoption of the modification. HHS determines the actual date, 
taking into account the time needed to comply due to the nature and 
extent of the modification. HHS may extend the time for compliance for 
small health plans.

Subpart B--[Reserved]

Subpart C--Security and Electronic Signature Standards


Sec. 142.302  Applicability and scope.

    The standards adopted or designated under this subpart apply, in 
whole or in part, to the following:
    (a) A health plan.
    (b) A health care clearinghouse or health care provider that takes 
one of the following actions:
    (1) Processes any electronic transmission between any combination 
of health care entities listed in this section.
    (2) Electronically maintains any health information used in an 
electronic transmission that has been sent or received between any 
combination of health care entities listed in this section.


Sec. 142.304  Definitions.

    For purposes of this subpart, the following definitions apply:
    Access refers to the ability or the means necessary to read, write, 
modify, or communicate data/information or otherwise make use of any 
system resource.
    Access control refers to a method of restricting access to 
resources, allowing only privileged entities access. Types of access 
control include, among others, mandatory access control, discretionary 
access control, time-of-day, and classification.
    Authentication refers to the corroboration that an entity is the 
one claimed.
    Contingency plan refers to a plan for responding to a system 
emergency. The plan includes performing backups, preparing critical 
facilities that can be used to facilitate continuity of operations in 
the event of an emergency, and recovering from a disaster.
    Encryption (or encipherment) refers to transforming confidential 
plaintext into ciphertext to protect it. An encryption algorithm 
combines plaintext with other values called keys, or ciphers, so the 
data becomes unintelligible. Once encrypted, data can be stored or 
transmitted over unsecured lines. Decrypting data reverses the 
encryption algorithm process and makes the plaintext available for 
further processing.
    Password refers to confidential authentication information composed 
of a string of characters.
    Role-based access control (RBAC) is an alternative to traditional 
access control models (e.g., discretionary or non-discretionary access 
control policies) that permits the specification and enforcement of 
enterprise-specific security policies in a way that maps more naturally 
to an organization's structure and business activities. With RBAC, 
rather than attempting to map an organization's security policy to a 
relatively low-level set of technical controls (typically, access 
control lists), each user is assigned to one or more predefined roles, 
each of which has been assigned the various privileges needed to 
perform that role.
    Token refers to a physical item necessary for user identification 
when used in the context of authentication. For example, an electronic 
device that can be inserted in a door or a computer system to obtain 
access.
    User-based access refers to a security mechanism used to grant 
users of a system access based upon the identity of the user.


Sec. 142.306  Rules for the security standard.

    (a) An entity must apply the security standard described in 
Sec. 142.308 to all health information pertaining to an individual that 
is electronically maintained or electronically transmitted.
    (b) If a health care clearinghouse is part of a larger 
organization, it must assure that all health information pertaining to 
an individual is protected from unauthorized access by the larger 
organization.

[[Page 43266]]

Sec. 142.308  Security standard.

    Each entity designated in Sec. 142.302 must assess potential risks 
and vulnerabilities to the individual health data in its possession and 
develop, implement, and maintain appropriate security measures. These 
measures must be documented and kept current, and must include, at a 
minimum, the following requirements and implementation features:
    (a) Administrative procedures to guard data integrity, 
confidentiality, and availability (documented, formal practices to 
manage the selection and execution of security measures to protect 
data, and to manage the conduct of personnel in relation to the 
protection of data). These procedures include the following 
requirements:
    (1) Certification. (The technical evaluation performed as part of, 
and in support of, the accreditation process that establishes the 
extent to which a particular computer system or network design and 
implementation meet a pre-specified set of security requirements. This 
evaluation may be performed internally or by an external accrediting 
agency.)
    (2) A chain of trust partner agreement (a contract entered into by 
two business partners in which the partners agree to electronically 
exchange data and protect the integrity and confidentiality of the data 
exchanged).
    (3) A contingency plan, a routinely updated plan for responding to 
a system emergency, that includes performing backups, preparing 
critical facilities that can be used to facilitate continuity of 
operations in the event of an emergency, and recovering from a 
disaster. The plan must include all of the following implementation 
features:
    (i) An applications and data criticality analysis (an entity's 
formal assessment of the sensitivity, vulnerabilities, and security of 
its programs and information it receives, manipulates, stores, and/or 
transmits).
    (ii) Data backup plan (a documented and routinely updated plan to 
create and maintain, for a specific period of time, retrievable exact 
copies of information).
    (iii) A disaster recovery plan (the part of an overall contingency 
plan that contains a process enabling an enterprise to restore any loss 
of data in the event of fire, vandalism, natural disaster, or system 
failure).
    (iv) Emergency mode operation plan (the part of an overall 
contingency plan that contains a process enabling an enterprise to 
continue to operate in the event of fire, vandalism, natural disaster, 
or system failure).
    (v) Testing and revision procedures (the documented process of 
periodic testing of written contingency plans to discover weaknesses 
and the subsequent process of revising the documentation, if 
necessary).
    (4) Formal mechanism for processing records (documented policies 
and procedures for the routine, and nonroutine, receipt, manipulation, 
storage, dissemination, transmission, and/or disposal of health 
information).
    (5) Information access control (formal, documented policies and 
procedures for granting different levels of access to health care 
information) that includes all of the following implementation 
features:
    (i) Access authorization (information-use policies and procedures 
that establish the rules for granting access, (for example, to a 
terminal, transaction, program, process, or some other user.)
    (ii) Access establishment (security policies and rules that 
determine an entity's initial right of access to a terminal, 
transaction, program, process or some other user).
    (iii) Access modification (security policies and rules that 
determine the types of, and reasons for, modification to an entity's 
established right of access, to a terminal, transaction, program, 
process, or some other user.)
    (6) Internal audit (in-house review of the records of system 
activity (such as logins, file accesses, and security incidents) 
maintained by an organization).
    (7) Personnel security (all personnel who have access to any 
sensitive information have the required authorities as well as all 
appropriate clearances) that includes all of the following 
implementation features:
    (i) Assuring supervision of maintenance personnel by an authorized, 
knowledgeable person. These procedures are documented formal procedures 
and instructions for the oversight of maintenance personnel when the 
personnel are near health information pertaining to an individual.
    (ii) Maintaining a record of access authorizations (ongoing 
documentation and review of the levels of access granted to a user, 
program, or procedure accessing health information).
    (iii) Assuring that operating and maintenance personnel have proper 
access authorization (formal documented policies and procedures for 
determining the access level to be granted to individuals working on, 
or near, health information).
    (iv) Establishing personnel clearance procedures (a protective 
measure applied to determine that an individual's access to sensitive 
unclassified automated information is admissible).
    (v) Establishing and maintaining personnel security policies and 
procedures (formal, documentation of procedures to ensure that all 
personnel who have access to sensitive information have the required 
authority as well as appropriate clearances).
    (vi) Assuring that system users, including maintenance personnel, 
receive security awareness training.
    (8) Security configuration management (measures, practices, and 
procedures for the security of information systems that must be 
coordinated and integrated with each other and other measures, 
practices, and procedures of the organization established in order to 
create a coherent system of security) that includes all of the 
following implementation features:
    (i) Documentation (written security plans, rules, procedures, and 
instructions concerning all components of an entity's security).
    (ii) Hardware and software installation and maintenance review and 
testing for security features (formal, documented procedures for 
connecting and loading new equipment and programs, periodic review of 
the maintenance occurring on that equipment and programs, and periodic 
security testing of the security attributes of that hardware/software).
    (iii) Inventory (the formal, documented identification of hardware 
and software assets).
    (iv) Security testing (process used to determine that the security 
features of a system are implemented as designed and that they are 
adequate for a proposed applications environment; this process includes 
hands-on functional testing, penetration testing, and verification).
    (v) Virus checking. (The act of running a computer program that 
identifies and disables:
    (A) Another ``virus'' computer program, typically hidden, that 
attaches itself to other programs and has the ability to replicate.
    (B) A code fragment (not an independent program) that reproduces by 
attaching to another program.
    (C) A code embedded within a program that causes a copy of itself 
to be inserted in one or more other programs.)
    (9) Security incident procedures (formal documented instructions 
for reporting security breaches) that include all of the following 
implementation features:
    (i) Report procedures (documented formal mechanism employed to 
document security incidents).

[[Page 43267]]

    (ii) Response procedures (documented formal rules or instructions 
for actions to be taken as a result of the receipt of a security 
incident report).
    (10) Security management process (creation, administration, and 
oversight of policies to ensure the prevention, detection, containment, 
and correction of security breaches involving risk analysis and risk 
management). It includes the establishment of accountability, 
management controls (policies and education), electronic controls, 
physical security, and penalties for the abuse and misuse of its assets 
(both physical and electronic) that includes all of the following 
implementation features:
    (i) Risk analysis, a process whereby cost-effective security/
control measures may be selected by balancing the costs of various 
security/control measures against the losses that would be expected if 
these measures were not in place.
    (ii) Risk management (process of assessing risk, taking steps to 
reduce risk to an acceptable level, and maintaining that level of 
risk).
    (iii) Sanction policies and procedures (statements regarding 
disciplinary actions that are communicated to all employees, agents, 
and contractors; for example, verbal warning, notice of disciplinary 
action placed in personnel files, removal of system privileges, 
termination of employment, and contract penalties). They must include 
employee, agent, and contractor notice of civil or criminal penalties 
for misuse or misappropriation of health information and must make 
employees, agents, and contractors aware that violations may result in 
notification to law enforcement officials and regulatory, 
accreditation, and licensure organizations.
    (iv) Security policy (statement(s) of information values, 
protection responsibilities, and organization commitment for a system). 
This is the framework within which an entity establishes needed levels 
of information security to achieve the desired confidentiality goals.
    (11) Termination procedures (formal documented instructions, which 
include appropriate security measures, for the ending of an employee's 
employment or an internal/external user's access) that include 
procedures for all of the following implementation features:
    (i) Changing locks (a documented procedure for changing 
combinations of locking mechanisms, both on a recurring basis and when 
personnel knowledgeable of combinations no longer have a need to know 
or require access to the protected facility or system).
    (ii) Removal from access lists (physical eradication of an entity's 
access privileges).
    (iii) Removal of user account(s) (termination or deletion of an 
individual's access privileges to the information, services, and 
resources for which they currently have clearance, authorization, and 
need-to-know when such clearance, authorization and need-to-know no 
longer exists).
    (iv) Turning in of keys, tokens, or cards that allow access 
(formal, documented procedure to ensure all physical items that allow a 
terminated employee to access a property, building, or equipment are 
retrieved from that employee, preferably before termination).
    (12) Training (education concerning the vulnerabilities of the 
health information in an entity's possession and ways to ensure the 
protection of that information) that includes all of the following 
implementation features:
    (i) Awareness training for all personnel, including management 
personnel (in security awareness, including, but not limited to, 
password maintenance, incident reporting, and viruses and other forms 
of malicious software).
    (ii) Periodic security reminders (employees, agents, and 
contractors are made aware of security concerns on an ongoing basis).
    (iii) User education concerning virus protection (training relative 
to user awareness of the potential harm that can be caused by a virus, 
how to prevent the introduction of a virus to a computer system, and 
what to do if a virus is detected).
    (iv) User education in importance of monitoring log-in success or 
failure and how to report discrepancies (training in the user's 
responsibility to ensure the security of health care information).
    (v) User education in password management (type of user training in 
the rules to be followed in creating and changing passwords and the 
need to keep them confidential).
    (b) Physical safeguards to guard data integrity, confidentiality, 
and availability. Protection of physical computer systems and related 
buildings and equipment from fire and other natural and environmental 
hazards, as well as from intrusion. It covers the use of locks, keys, 
and administrative measures used to control access to computer systems 
and facilities. Physical safeguards must include all of the following 
requirements and implementation features:
    (1) Assigned security responsibility (practices established by 
management to manage and supervise the execution and use of security 
measures to protect data and to manage and supervise the conduct of 
personnel in relation to the protection of data).
    (2) Media controls (formal, documented policies and procedures that 
govern the receipt and removal of hardware/software (such as diskettes 
and tapes) into and out of a facility) that include all of the 
following implementation features:
    (i) Access control.
    (ii) Accountability (the property that ensures that the actions of 
an entity can be traced uniquely to that entity).
    (iii) Data backup (a retrievable, exact copy of information).
    (iv) Data storage (the retention of health care information 
pertaining to an individual in an electronic format).
    (v) Disposal (final disposition of electronic data, and/or the 
hardware on which electronic data is stored).
    (3) Physical access controls (limited access) (formal, documented 
policies and procedures to be followed to limit physical access to an 
entity while ensuring that properly authorized access is allowed) that 
include all of the following implementation features:
    (i) Disaster recovery (the process enabling an entity to restore 
any loss of data in the event of fire, vandalism, natural disaster, or 
system failure).
    (ii) An emergency mode operation (access controls in place that 
enable an entity to continue to operate in the event of fire, 
vandalism, natural disaster, or system failure).
    (iii) Equipment control (into and out of site) (documented security 
procedures for bringing hardware and software into and out of a 
facility and for maintaining a record of that equipment. This includes, 
but is not limited to, the marking, handling, and disposal of hardware 
and storage media.)
    (iv) A facility security plan (a plan to safeguard the premises and 
building (exterior and interior) from unauthorized physical access and 
to safeguard the equipment therein from unauthorized physical access, 
tampering, and theft).
    (v) Procedures for verifying access authorizations before granting 
physical access (formal, documented policies and instructions for 
validating the access privileges of an entity before granting those 
privileges).
    (vi) Maintenance records (documentation of repairs and 
modifications to the physical components of a facility, such as

[[Page 43268]]

hardware, software, walls, doors, and locks).
    (vii) Need-to-know procedures for personnel access (a security 
principle stating that a user should have access only to the data he or 
she needs to perform a particular function).
    (viii) Procedures to sign in visitors and provide escorts, if 
appropriate (formal documented procedure governing the reception and 
hosting of visitors).
    (ix) Testing and revision (the restriction of program testing and 
revision to formally authorized personnel).
    (4) Policy and guidelines on work station use (documented 
instructions/procedures delineating the proper functions to be 
performed, the manner in which those functions are to be performed, and 
the physical attributes of the surroundings of a specific computer 
terminal site or type of site, dependent upon the sensitivity of the 
information accessed from that site).
    (5) A secure work station location (physical safeguards to 
eliminate or minimize the possibility of unauthorized access to 
information; for example, locating a terminal used to access sensitive 
information in a locked room and restricting access to that room to 
authorized personnel, not placing a terminal used to access patient 
information in any area of a doctor's office where the screen contents 
can be viewed from the reception area).
    (6) Security awareness training (information security awareness 
training programs in which all employees, agents, and contractors must 
participate, including, based on job responsibilities, customized 
education programs that focus on issues regarding use of health 
information and responsibilities regarding confidentiality and 
security).
    (c) Technical security services to guard data integrity, 
confidentiality, and availability (the processes that are put in place 
to protect information and to control individual access to 
information). These services include the following requirements and 
implementation features:
    (1) The technical security services must include all of the 
following requirements and the specified implementation features:
    (i) Access control that includes:
    (A) A procedure for emergency access (documented instructions for 
obtaining necessary information during a crisis), and
    (B) At least one of the following implementation features:
    (1) Context-based access (an access control procedure based on the 
context of a transaction (as opposed to being based on attributes of 
the initiator or target)).
    (2) Role-based access.
    (3) User-based access.
    (C) The optional use of encryption.
    (ii) Audit controls (mechanisms employed to record and examine 
system activity).
    (iii) Authorization control (the mechanism for obtaining consent 
for the use and disclosure of health information) that includes at 
least one of the following implementation features:
    (A) Role-based access.
    (B) User-based access.
    (iv) Data authentication. (The corroboration that data has not been 
altered or destroyed in an unauthorized manner. Examples of how data 
corroboration may be assured include the use of a check sum, double 
keying, a message authentication code, or digital signature.)
    (v) Entity authentication (the corroboration that an entity is the 
one claimed) that includes:
    (A) Automatic logoff (a security procedure that causes an 
electronic session to terminate after a predetermined time of 
inactivity, such as 15 minutes), and
    (B) Unique user identifier (a combination name/number assigned and 
maintained in security procedures for identifying and tracking 
individual user identity).
    (C) At least one of the following implementation features:
    (1) Biometric identification (an identification system that 
identifies a human from a measurement of a physical feature or 
repeatable action of the individual (for example, hand geometry, 
retinal scan, iris scan, fingerprint patterns, facial characteristics, 
DNA sequence characteristics, voice prints, and hand written 
signature)).
    (2) Password.
    (3) Personal identification number (PIN) (a number or code assigned 
to an individual and used to provide verification of identity).
    (4) A telephone callback procedure (method of authenticating the 
identity of the receiver and sender of information through a series of 
``questions'' and ``answers'' sent back and forth establishing the 
identity of each). For example, when the communicating systems exchange 
a series of identification codes as part of the initiation of a session 
to exchange information, or when a host computer disconnects the 
initial session before the authentication is complete, and the host 
calls the user back to establish a session at a predetermined telephone 
number.
    (5) Token.
    (2) [Reserved]
    (d) Technical security mechanisms (processes that are put in place 
to guard against unauthorized access to data that is transmitted over a 
communications network).
    (1) If an entity uses communications or network controls, its 
security standards for technical security mechanisms must include the 
following:
    (i) The following implementation features:
    (A) Integrity controls (a security mechanism employed to ensure the 
validity of the information being electronically transmitted or 
stored).
    (B) Message authentication (ensuring, typically with a message 
authentication code, that a message received (usually via a network) 
matches the message sent).
    (ii) One of the following implementation features:
    (A) Access controls (protection of sensitive communications 
transmissions over open or private networks so that they cannot be 
easily intercepted and interpreted by parties other than the intended 
recipient).
    (B) Encryption.
    (2) If an entity uses network controls (to protect sensitive 
communication that is transmitted electronically over open networks so 
that it cannot be easily intercepted and interpreted by parties other 
than the intended recipient), its technical security mechanisms must 
include all of the following implementation features:
    (i) Alarm. (In communication systems, any device that can sense an 
abnormal condition within the system and provide, either locally or 
remotely, a signal indicating the presence of the abnormality. The 
signal may be in any desired form ranging from a simple contact closure 
(or opening) to a time-phased automatic shutdown and restart cycle.)
    (ii) Audit trail (the data collected and potentially used to 
facilitate a security audit).
    (iii) Entity authentication (a communications or network mechanism 
to irrefutably identify authorized users, programs, and processes and 
to deny access to unauthorized users, programs, and processes).
    (iv) Event reporting (a network message indicating operational 
irregularities in physical elements of a network or a response to the 
occurrence of a significant task, typically the completion of a request 
for information).


Sec. 142.310  Electronic signature standard.

    (a) General rule. If an entity elects to use an electronic 
signature in a

[[Page 43269]]

transaction as defined in Sec. 142.103, or if an electronic signature 
is required by a transaction standard adopted by the Secretary, the 
entity must apply the electronic signature standard described in 
paragraph (b) of this section to that transaction.
    (b) Standard.
    (1) An electronic signature is the attribute affixed to an 
electronic document to bind it to a particular entity. An electronic 
signature secures the user authentication (proof of claimed identity) 
at the time the signature is generated; creates the logical 
manifestation of signature (including the possibility for multiple 
parties to sign a document and have the order of application recognized 
and proven); supplies additional information such as time stamp and 
signature purpose specific to that user; and ensures the integrity of 
the signed document to enable transportability of data, 
interoperability, independent verifiability, and continuity of 
signature capability. Verifying a signature on a document verifies the 
integrity of the document and associated attributes and verifies the 
identity of the signer.
    (2) The standard for electronic signature is a digital signature. A 
``digital signature'' is an electronic signature based upon 
cryptographic methods of originator authentication, computed by using a 
set of rules and a set of parameters so that the identity of the signer 
and the integrity of the data can be verified.
    (c) Required implementation features. If an entity uses electronic 
signatures, the signature method must assure all of the following 
features:
    (1) Message integrity (the assurance of unaltered transmission and 
receipt of a message from the sender to the intended recipient).
    (2) Nonrepudiation (strong and substantial evidence of the identity 
of the signer of a message, and of message integrity, sufficient to 
prevent a party from successfully denying the origin, submission, or 
delivery of the message and the integrity of its contents).
    (3) User authentication (the provision of assurance of the claimed 
identity of an entity).
    (d) Optional implementation features. If an entity uses electronic 
signatures, the entity may also use, among others, any of the following 
implementation features:
    (1) Ability to add attributes (one possible capability of a digital 
signature technology; for example, the ability to add a time stamp as 
part of a digital signature).
    (2) Continuity of signature capability (the concept that the public 
verification of a signature must not compromise the ability of the 
signer to apply additional secure signatures at a later date).
    (3) Countersignatures. (The capability to prove the order of 
application of signatures. This is analogous to the normal business 
practice of countersignatures, where a party signs a document that has 
already been signed by another party.)
    (4) Independent verifiability (the capability to verify the 
signature without the cooperation of the signer).
    (5) Interoperability (the applications used on either side of a 
communication, between trading partners and/or between internal 
components of an entity, are able to read and correctly interpret the 
information communicated from one to the other).
    (6) Multiple signatures. (With this feature, multiple parties are 
able to sign a document. Conceptually, multiple signatures are simply 
appended to the document.)
    (7) Transportability of data (the ability of a signed document to 
be transported over an insecure network to another system, while 
maintaining the integrity of the document, including content, 
signatures, signature attributes, and (if present) document 
attributes).


Sec. 142.312  Effective date of the initial implementation of the 
security and electronic signature standards.

    (a) General rules.
    (1) Except for a small health plan (defined at Sec. 142.103), each 
entity designated in Sec. 142.302 must comply with the requirements of 
this subpart by [24 months after the effective date of the final rule 
in the Federal Register].
    (2) A delay in an effective date for using a standard transaction 
described in this part does not delay the effective dates described in 
paragraphs (a)(1) and (b) of this section.
    (3) The requirements of the security standard may be implemented 
over time. Implementation must be completed by the applicable effective 
date.
    (b) Small health plans. A small health plan must comply with the 
requirements of this subpart by [36 months after the effective date of 
the final rule in the Federal Register].

    Authority: Sections 1173 and 1175 of the Social Security Act (42 
U.S.C. 1320d-2 and 1320d-4).

    Dated: July 15, 1998.
Donna E. Shalala,
Secretary.
    Note: The following appendix will not appear in the Code of 
Federal Regulations.

Addendum 1

HIPAA Security Matrix

    Please Note: (1) While we have attempted to categorize security 
requirements for ease of understanding and reading clarity, there 
are overlapping areas on the matrix in which the same requirements 
are restated in a slightly different context. (2) To ensure that no 
Requirement or Implementation feature is considered more important 
than another, this matrix has been presented, within each subject 
area, in alphabetical order.

 Administrative Procedures To Guard Data Integrity, Confidentiality, and
                              Availability                              
------------------------------------------------------------------------
              Requirement                         Implementation        
------------------------------------------------------------------------
Certification                                                           
Chain of trust partner agreement                                        
Contingency plan (all listed             Applications and data          
 implementation features must be          criticality analysis.         
 implemented).                           Data backup plan.              
                                         Disaster recovery plan.        
                                         Emergency mode operation plan. 
                                         Testing and revision.          
Formal mechanism for processing                                         
 records.                                                               
Information access control (all listed   Access authorization.          
 implementation features must be         Access establishment.          
 implemented).                           Access modification.           
Internal audit                                                          

[[Page 43270]]

                                                                        
Personnel security (all listed           Assure supervision of          
 implementation features must be          maintenance personnel by      
 implemented).                            authorized, knowledgeable     
                                          person.                       
                                         Maintainance of record of      
                                          access authorizations.        
                                         Operating, and in some cases,  
                                          maintenance personnel have    
                                          proper access authorization.  
                                         Personnel clearance procedure. 
                                         Personnel security policy/     
                                          procedure.                    
                                         System users, including        
                                          maintenance personnel, trained
                                          in security.                  
Security configuration mgmt. (all        Documentation.                 
 listed implementation features must be  Hardware/software installation 
 implemented).                            & maintenance review and      
                                          testing for security features.
                                         Inventory.                     
                                         Security Testing.              
                                         Virus checking.                
Security incident procedures (all        Report procedures.             
 listed implementation features must be  Response procedures.           
 implemented).                                                          
Security management process (all listed  Risk analysis.                 
 implementation features must be         Risk management.               
 implemented).                           Sanction policy.               
                                         Security policy.               
Termination procedures (all listed       Combination locks changed.     
 implementation features must be         Removal from access lists.     
 implemented).                           Removal of user account(s).    
                                         Turn in keys, token or cards   
                                          that allow access.            
Training (all listed implementation      Awareness training for all     
 features must be implemented).           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.                   
------------------------------------------------------------------------


    Physical Safeguards To Guard Data Integrity, Confidentiality, and   
                              Availability                              
------------------------------------------------------------------------
              Requirement                         Implementation        
------------------------------------------------------------------------
Assigned security responsibility                                        
Media controls (all listed               Access control.                
 implementation features must be         Accountability (tracking       
 implemented).                            mechanism).                   
                                         Data backup.                   
                                         Data storage.                  
                                         Disposal.                      
Physical access controls (limited        Disaster recovery.             
 access) (all listed implementation      Emergency mode operation.      
 features must be implemented).          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 use                                    
Secure work station location                                            
Security awareness training                                             
------------------------------------------------------------------------


  Technical Security Services To Guard Data Integrity, Confidentiality, 
                            and Availability                            
------------------------------------------------------------------------
              Requirement                         Implementation        
------------------------------------------------------------------------
Access control (The following            Context-based access.          
 implementation feature must be          Encryption.                    
 implemented: Procedure for emergency    Procedure for emergency access.
 access. In addition, at least one of    Role-based access.             
 the following three implementation      User-based access.             
 features must be implemented: Context-                                 
 based access, Roll-based access, User-                                 
 based access. The use of Encryption is                                 
 optional).                                                             
Audit controls                                                          
Authorization Control (At least one of   Role-based access.             
 the listed implementation features      User-based access              
 must be implemented).                                                  
Data Authentication                                                     

[[Page 43271]]

                                                                        
Entity Authentication (The following     Automatic logoff.              
 implementation features must be         Biometric.                     
 implemented: Automatic logoff, Unique   Password.                      
 user identification. In addition, at    PIN.                           
 least one of the other listed           Telephone callback.            
 implementation features must be         Token.                         
 implemented).                           Unique user identification.    
------------------------------------------------------------------------


  Technical Security Mechanisms To Guard Against Unauthorized Access to 
         Data That Is Transmitted Over a Communications Network         
------------------------------------------------------------------------
                 Requirement                         Implementation     
------------------------------------------------------------------------
Communications/network controls (The           Access controls.         
 following implementation features must be     Alarm.                   
 implemented: Integrity controls, Message      Audit trail.             
 authentication. If communications or          Encryption.              
 networking is employed, one of the following  Entity authentication.   
 implementation features must be implemented:  Event reporting.         
 Access controls, Encryption. In addition, if  Integrity controls.      
 using a network, the following four           Message authentication.  
 implementation features must be implemented:                           
 Alarm, Audit trail, Entity authentication,                             
 Event reporting).                                                      
------------------------------------------------------------------------


                          Electronic Signature                          
------------------------------------------------------------------------
              Requirement                         Implementation        
------------------------------------------------------------------------
Digital signature (If digital signature  Ability to add attributes.     
 is employed, the following three        Continuity of signature        
 implementation features must be          capability.                   
 implemented: Message integrity, Non-    Counter signatures.            
 repudiation, User authentication.       Independent verifiability.     
 Other implementation features are       Interoperability.              
 optional).                              Message integrity.             
                                         Multiple Signatures.           
                                         Non-repudiation.               
                                         Transportability.              
                                         User authentication.           
------------------------------------------------------------------------

Addendum 2--HIPAA Security and Electronic Signature Standards Glossary 
of Terms

    Please Note:
    (1) While we have attempted to categorize security requirements 
for ease of understanding and reading clarity, there are overlapping 
areas on the matrix in which the same requirements are restated in a 
slightly different context.
    (2) While not appearing on the matrix, a number of terms listed 
below do appear in the glossary descriptions and have been supplied 
for additional clarity:
    (3) The definitions provided in this document have been obtained 
from multiple sources.

Ability to add attributes:
    One possible capability of a digital signature technology, for 
example, the ability to add a time stamp as part of a digital 
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 of any 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 the matrix.
Access control:
    A method of restricting access to resources, allowing only 
privileged entities access. (PGP, Inc.)
    Types of access control include, among others, mandatory access 
control, discretionary access control, time-of-day, classification, 
and subject-object separation.
    Part of Media Controls on the matrix.
    Part of technical security services to control and monitor 
access to information on the matrix.
Access controls:
    The protection of sensitive communications transmissions over 
open or private networks so that it cannot be easily intercepted and 
interpreted by parties other than the intended recipient.
    Part of mechanisms to prevent unauthorized access to data that 
is transmitted over a communications network on the matrix.
Access establishment:
    The security policies, and the rules established therein, that 
determine an entity's initial right of access to a terminal, 
transaction, program, or process.
    Part of information access control on the matrix.
Access Level:
    A level associated with an individual who may be accessing 
information (for example, a clearance level) or with the information 
which may be accessed (for example, a classification level). (NRC, 
1991, as cited in HISB, DRAFT GLOSSARY OF TERMS RELATED TO 
INFORMATION SECURITY IN HEALTH CARE INFORMATION SYSTEMS draft 
Glossary of Terms Related to Information Security in Health Care 
Information Systems)
Access modification:
    The security policies, and the rules established therein, that 
determine types of, and reasons for, modification to an entity's 
established right of access to a terminal, transaction, program, or 
process.
    Part of information access control on the matrix.
Accountability:
    The property that ensures that the actions of an entity can be 
traced uniquely to that entity. (ASTM E1762--95)

[[Page 43272]]

    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 of security measures to protect data, and (2) the conduct 
of personnel in relation to the protection of data.
    A section of the matrix.
Alarm, event reporting, and audit trail:
    (1) Alarm: In communication systems, any device that can sense 
an abnormal condition within the system and provide, either locally 
or remotely, a signal indicating the presence of the abnormality. 
(188) NOTE: The signal may be in any desired form ranging from a 
simple contact closure (or opening) to a time-phased automatic 
shutdown and restart cycle. (Glossary of INFOSEC and INFOSEC Related 
Terms--Idaho State University)
    (2) Event reporting: Network message indicating operational 
irregularities in physical elements of a network or a response to 
the occurrence of a significant task, typically the completion of a 
request for information. (Glossary of INFOSEC and INFOSEC Related 
Terms--Idaho State University)
    (3) Audit trail: Data collected and potentially used to 
facilitate a security audit. (ISO 7498-2, as cited in HISB, DRAFT 
GLOSSARY OF TERMS RELATED TO INFORMATION SECURITY IN HEALTH CARE 
INFORMATION SYSTEMS draft Glossary of Terms Related to Information 
Security in Health Care Information Systems)
    Part of mechanisms to prevent unauthorized access to data that 
is transmitted over a communications network on the matrix.
Applications and data criticality analysis:
    An entity's formal assessment of the sensitivity, 
vulnerabilities, and security of its programs and information it 
receives, manipulates, stores, and/or transmits.
    Part of contingency plan on the matrix.
Assigned security responsibility:
    Practices put in place by management to manage and supervise (1) 
the execution and use of security measures to protect data, and (2) 
the conduct of personnel in relation to the protection of data.
    Part of Physical safeguards to guard data integrity, 
confidentiality, and availability on the matrix.
Assure supervision of maintenance personnel by authorized, 
knowledgeable person:
    Documented formal procedures/instruction for the oversight of 
maintenance personnel when such personnel are in the vicinity of 
health information pertaining to an individual.
    Part of personnel security on the matrix.
Asymmetric encryption:
    Encryption and decryption performed using two different keys, 
one of which is referred to as the public key and one of which is 
referred to as the private key.
    Also known as public-key encryption. (Stallings)
Asymmetric key:
    One half of a key pair used in an asymmetric (``public-key'') 
encryption system. Asymmetric encryption systems have two important 
properties: (1) the key used for encryption is different from the 
one used for decryption (2) neither key can feasibly be derived from 
the other. (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 to information on the matrix.
Authorization control:
    The mechanism for obtaining consent for the use and disclosure 
of health information.
    Part of technical security services to control and monitor 
access to information on the matrix.
Automatic logoff:
    After a pre-determined time of inactivity (for example, 15 
minutes), an electronic session is terminated.
    Part of entity authentication on the matrix.
Availability:
    The property of being accessible and useable upon demand by an 
authorized entity. (ISO 7498-2, as cited in the HISB draft Glossary 
of Terms Related to Information Security In Health care Information 
Systems)
Awareness training for all personnel (including management):
    All personnel in an organization should undergo security 
awareness training, including, but not limited to, password 
maintenance, incident reporting, and an education concerning viruses 
and other forms of malicious software.
    Part of Training on the matrix.
Biometric:.
    A biometric identification system identifies a human from a 
measurement of a physical feature or repeatable action of the 
individual (for example, hand geometry, retinal scan, iris scan, 
fingerprint patterns, facial characteristics, DNA sequence 
characteristics, voice prints, and hand written signature). (ASTM 
E1762--95, as cited in the HISB draft Glossary of Terms Related to 
Information Security In Health care Information Systems)
    Part of entity authentication on the matrix.
Certification:
    The technical evaluation performed as part of, and in support 
of, the accreditation process that establishes the extent to which a 
particular computer system or network design and implementation meet 
a pre-specified set of security requirements. This evaluation may be 
performed internally or by an external accrediting agency.
    Part of administrative procedures to guard data integrity, 
confidentiality, and availability.
Chain of Trust Partner Agreement:
    Contract entered into by two business partners in which it is 
agreed to exchange data and that the first party will transmit 
information to the second party, where the data transmitted is 
agreed to be protected between the partners. The sender and receiver 
depend upon each other to maintain the integrity and confidentiality 
of the transmitted information. Multiple such two-party contracts 
may be involved in moving information from the originator to the 
ultimate recipient, for example, a provider may contract with a 
clearing house to transmit claims to the clearing house; the 
clearing house, in turn, may contract with another clearing house or 
with a payer for the further transmittal of those same claims.
    Part of administrative procedures to guard data integrity, 
confidentiality and availability on the matrix..
Classification:
    Protection of data from unauthorized access by the designation 
of multiple levels of access authorization clearances to be required 
for access, dependent upon the sensitivity of the information.
    A type of access control on the matrix.
Clearing House:
    * * * a public or private entity that processes or facilitates 
the processing of nonstandard data elements of health information 
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 when personnel 
knowledgeable of combinations no longer have a need to know or a 
requirement for access to the protected facility/system.
    Part of termination procedures on the matrix.
Confidentiality:
    The property that information is not made available or disclosed 
to unauthorized individuals, entities or processes. (ISO 7498-2, as 
cited in the HISB draft Glossary of Terms Related to Information 
Security In Health care Information Systems) .
Context-based access:
    An access control based on the context of a transaction (as 
opposed to being based on attributes of the initiator or target). 
The ``external'' factors might include time of day, location of the 
user, strength of user authentication, etc.
    Part of access control on the matrix.
Contingency Plan:
    A plan for responding to a system emergency. The plan includes 
performing backups, preparing critical facilities that can be used 
to facilitate continuity of operations in the event of an emergency, 
and recovering from a disaster. (O'Reilly, 1992, as cited in the 
HISB draft Glossary of Terms Related to Information Security In 
Health care Information Systems) Contingency plans should be updated 
routinely.
    Part of Administrative procedures to guard data integrity, 
confidentiality and availability on the matrix.
Continuity of signature capability:
    The public verification of a signature shall not compromise the 
ability of the signer to apply additional secure signatures at a 
later date. (ASTM E 1762--95)

[[Page 43273]]

    Part of digital signature on the matrix.
Counter signatures:
    It shall be possible to prove the order of application of 
signatures. This is analogous to the normal business practice of 
countersignatures, where some party signs a document which has 
already been signed by another party. (ASTM E 1762 -95)
    Part of digital signature on the matrix.
Data:
    A sequence of symbols to which meaning may be assigned. (NRC, 
1991, as cited in the HISB draft Glossary of Terms Related to 
Information Security In Health care Information Systems)
Data authentication:
    The corroboration that data has not been altered or destroyed in 
an unauthorized manner. Examples of how data corroboration may be 
assured include the use of a check sum, double keying, a message 
authentication code, or digital signature.
    Part of technical security services to control and monitor 
access to information 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 specific period of time, retrievable exact copies of 
information.
    Part of contingency plans on the matrix.
Data Integrity:
    The property that dat has [sic] not been altered or destroyed in 
an unauthorized manner. (ASTM E1762-95).
Data storage:
    The retention of health care information pertaining to an 
individual in an electronic format.
    Part of media controls on the matrix.
Digital signature:
    An electronic signature based upon cryptographic methods of 
originator authentication, computed by using a set of rules and a 
set of parameters such that the identity of the signer and the 
integrity of the data can be verified. (FDA Electronic Record; 
Electronic Signatures; Final Rule)
    Part of electronic signature on the matrix.
Disaster recovery:
    The process whereby an enterprise would restore any loss of data 
in the event of fire, vandalism, natural disaster, or system 
failure. (CPRI, 1996c, as cited in HISB, DRAFT GLOSSARY OF TERMS 
RELATED TO INFORMATION SECURITY IN HEALTH CARE INFORMATION SYSTEMS 
draft Glossary of Terms Related to Information Security in Health 
Care Information Systems)
    Part of physical access controls (limited access) on the matrix.
Disaster recovery plan:
    Part of an overall contingency plan. The plan for a process 
whereby an enterprise would restore any loss of data in the event of 
fire, vandalism, natural disaster, or system failure. (CPRI, 1996c, 
as cited in HISB, DRAFT GLOSSARY OF TERMS RELATED TO INFORMATION 
SECURITY IN HEALTH CARE INFORMATION SYSTEMS draft Glossary of Terms 
Related to Information Security in Health Care Information Systems)
    Part of contingency plan on the matrix.
Discretionary access control:
    Discretionary Access Control (DAC) is used to control access by 
restricting a subject's access to an object. It is generally used to 
limit a user's access to a file. In this type of access control it 
is the owner of the 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 electronic data is stored.
    Part of media controls on the matrix.
Documentation:
    Written security plans, rules, procedures, and instructions 
concerning all components of an entity's security.
    Part of security configuration mgmt on the matrix.
Electronic data interchange (EDI):
    Intercompany, computer-to-computer transmission of business 
information in a standard format. For EDI purists, ``computer-to-
computer'' means direct transmission from the originating 
application program to the receiving, or processing, application 
program, and an EDI transmission consists only of business data, not 
any accompanying verbiage or free-form messages. Purists might also 
contend that a standard format is one that is approved by a national 
or international standards organization, as opposed to formats 
developed by industry groups or companies. (EDI Security, Control, 
and Audit)
Electronic signature:
    The attribute that is affixed to an electronic document to bind 
it to a particular entity. An electronic signature process secures 
the user authentication (proof of claimed identity, such as by 
biometrics (fingerprints, retinal scans, hand written signature 
verification, etc.), tokens or passwords) at the time the signature 
is generated; creates the logical manifestation of signature 
(including the possibility for multiple parties to sign a document 
and have the order of application recognized and proven) and 
supplies additional information such as time stamp and signature 
purpose specific to that user; and ensures the integrity of the 
signed document to enable transportability, interoperability, 
independent verifiability, and continuity of signature capability. 
Verifying a signature on a document verifies the integrity of the 
document and associated attributes and verifies the identity of the 
signer. There are several technologies available for user 
authentication, including passwords, cryptography, and biometrics. 
(ASTM 1762-95, as cited in the HISB draft Glossary of Terms Related 
to Information Security In Health care Information Systems)
Emergency mode operation:
    Access controls in place that enable an enterprise to continue 
to operate in the event of fire, vandalism, natural disaster, or 
system failure.
    Part of physical access controls (limited access) on the matrix.
Emergency mode operation plan:
    Part of an overall contingency plan. The plan for a process 
whereby an enterprise would be able to continue to operate in the 
event of fire, vandalism, natural disaster, or system failure.
    Part of contingency plan on the matrix.
Encryption:
    Transforming confidential plaintext into ciphertext to protect 
it. Also called encipherment. An encryption algorithm combines 
plaintext with other values called keys, or ciphers, so the data 
becomes unintelligible. Once encrypted, data can be stored or 
transmitted over unsecured lines. (EDI Security, Control, and Audit)
    Decrypting data reverses the encryption algorithm process and 
makes the plaintext available for further processing.
    Part of access control on the matrix.
Entity authentication:
    1. The corroboration that an entity is the one claimed. (ISO 
7498-2, as cited in the HISB draft Glossary of Terms Related to 
Information Security In Health care Information Systems)
    Part of technical security services to control and monitor 
access to information on the matrix.
    2. A communications/network mechanism to irrefutably identify 
authorized users, programs, and processes, and to deny access to 
unauthorized users, programs and processes.
    Part of mechanisms to prevent unauthorized access to data that 
is transmitted over a communications network on the matrix.
Equipment control (into and out of site):
    Documented security procedures for bringing hardware and 
software into and out of a facility and for maintaining a record of 
that equipment. This includes, but is not limited to, the marking, 
handling, and disposal of hardware and storage media.
    Part of physical access controls (limited access) on the matrix.
Facility security plan:
    A plan to safeguard the premises and building(s) (exterior and 
interior) from unauthorized physical access, and to safeguard the 
equipment therein from unauthorized physical access, tampering, and 
theft.
    Part of physical access controls (limited access) on the matrix.
Formal mechanism for processing records:
    Documented policies and procedures for the routine, and non-
routine, receipt, manipulation, storage, dissemination, 
transmission, and/or disposal of health information.

[[Page 43274]]

    Part of administrative procedures to guard data integrity, 
confidentiality, and availability on the matrix.
Hardware/software installation & maintenance review and testing for 
security features:
    Formal, documented procedures for (1) connecting and loading new 
equipment and programs, (2) periodic review of the maintenance 
occurring on that equipment and programs, and (3) periodic security 
testing of the security attributes of that hardware/software.
    Part of security configuration mgmt on the matrix.
Independent verifiability:
    The capability to verify the signature without the cooperation 
of the signer. Technically, it is accomplished using the public key 
of the signatory, and it is a property of all digital signatures 
performed with asymmetric key encryption
    Part of digital signature on the matrix.
Information:
    Data to which meaning is assigned, according to context and 
assumed conventions. (National Security Council, 1991, as cited in 
the HISB draft Glossary of Terms Related to Information Security In 
Health care Information Systems)
Information access control:
    Formal, documented policies and procedures for granting 
different levels of access to health care information.
    Part of administrative procedures to ensure integrity and 
confidentiality on the matrix.
Integrity controls:
    Security mechanism employed to ensure the validity of the 
information being electronically transmitted or stored.
    Part of mechanisms to prevent unauthorized access to data that 
is transmitted over a communications network on the matrix.
Internal audit:
    The in-house review of the records of system activity (for 
example, logins, file accesses, security incidents) maintained by an 
organization.
    Part of administrative procedures to guard data integrity, 
confidentiality, and availability on the matrix.
Interoperability:
    The applications used on either side of a communication, between 
trading partners and/or between internal components of an entity, 
being able to read and correctly interpret the information 
communicated from one to the other.
    Part of digital signature on the matrix.
Inventory:
    Formal, documented identification of hardware and software 
assets.
    Part of security configuration mgmt on the matrix.
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 Security In Health care Information 
Systems)
Maintenance of record of access authorizations:
    Ongoing documentation and review of the levels of access granted 
to a user, program, or procedure accessing health information.
    Part of personnel security on the matrix.
Maintenance records:
    Documentation of repairs and modifications to the physical 
components of a facility, for example, hardware, software, walls, 
doors, locks.
    Part of physical access controls (limited access) on the matrix.
Mandatory Access Control (MAC):
    A means of restricting access to objects that is based on fixed 
security attributes assigned to users and to files and other 
objects. The controls are mandatory in the sense that they cannot be 
modified by users or their programs. (Stallings, 1995) (as cited in 
the HISB draft Glossary of Terms Related to Information Security In 
Health care Information Systems)
    A type of access control on the matrix.
Media controls:
    Formal, documented policies and procedures that govern the 
receipt and removal of hardware/software (for example, diskettes, 
tapes) into and out of a facility.
    Part of physical safeguards to guard data integrity, 
confidentiality, and availability on the matrix.
Message:
    A digital representation of information. (ABA Digital Signatures 
Guidelines)
Message authentication:
    Ensuring, typically with a message authentication code, that a 
message received (usually via a network) matches the message sent. 
(O'Reilly, 1992, as cited in the HISB draft Glossary of Terms 
Related to Information Security In Health care Information Systems)
    Part of mechanisms to prevent unauthorized access to data that 
is transmitted over a communications network on the matrix
Message authentication code:
    Data associated with an authenticated message that allows a 
receiver to verify the integrity of the message. (Glossary of 
INFOSEC and INFOSEC Related Terms--Idaho State University)
Message integrity:
    The assurance of unaltered transmission and receipt of a message 
from the sender to the intended recipient. (ABA Digital Signature 
Guidelines)
    Part of digital signature on the matrix.
Multiple signatures:
    It shall be possible for multiple parties to sign a document. 
Multiple signatures are conceptually, simply appended to the 
document. (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 he or she needs to perform a particular function. 
(O'Reilly, 1992, as cited in the HISB draft Glossary of Terms 
Related to Information Security In Health care Information Systems)
    Part of physical access controls (limited access) on the matrix.
Nonrepudiation:
    Strong and substantial evidence of the identity of the signer of 
a message and of message integrity, sufficient to prevent a party 
from successfully denying the origin, submission or delivery of the 
message 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 
access authorizations:
    Formal, documented policies and procedures to be followed in 
determining the access level to be granted to individuals working 
on, or in the vicinity of, health information.
    Part of personnel security on the matrix.
Password:
    Confidential authentication information composed of a string of 
characters. (ISO 7498--2, as cited in the HISB draft Glossary of 
Terms Related to Information Security In Health care Information 
Systems)
    Part of entity authentication on the matrix.
Periodic security reminders:
    Employees, agents and contractors should be made aware of 
security concerns on an ongoing basis.
    Part of training on the matrix.
Personnel clearance procedure:
    A protective measure applied to determine that an individual's 
access to sensitive unclassified automated information is 
admissible. The need for and extent of a screening process is 
normally based on an assessment of risk, cost, benefit, and 
feasibility as well as other protective measures in place. Effective 
screening processes are applied in such a way as to allow a range of 
implementation, from minimal procedures to more stringent procedures 
commensurate with the sensitivity of the data to be accessed and the 
magnitude of harm or loss that could be caused by the individual 
(DOE 1360.2A, as cited in Glossary of INFOSEC and INFOSEC Related 
Terms--Idaho State University)
    Part of personnel security on the matrix.
Personnel security:
    The procedures established to ensure that all personnel who have 
access to sensitive information have the required authority as well 
as appropriate clearances. (NCSC Glossary of Computer Security 
Terms, October 21, 1988)
    Part of administrative procedures to guard data integrity, 
confidentiality and availability on the matrix.
Personnel security policy/procedure:
    Formal, documentation of policies and procedures established to 
ensure that all personnel who have access to sensitive information 
have the required authority as well as appropriate clearances. 
(Glossary of INFOSEC and INFOSEC Related Terms--Idaho State 
University)
    Part of personnel security on the matrix.
Physical access controls (limited access):
    Those formal, documented policies and procedures to be followed 
to limit

[[Page 43275]]

physical access to an entity while ensuring that properly authorized 
access is allowed.
    Part of Physical safeguards to guard data integrity, 
confidentiality, and availability on the matrix.
Physical safeguards:
    Protection of physical computer systems and related buildings 
and equipment from fire and other natural and environmental hazards, 
as well as from intrusion. Also covers the use of locks, keys, and 
administrative measures used to control access to computer systems 
and facilities. (O'Reilly, 1992, as cited in HISB, draft Glossary of 
Terms Related to Information Security in Health Care Information 
Systems)
    A section of the matrix covering physical security requirements.
PIN (Personal Identification Number):
    A number or code assigned to an individual and used to provide 
verification of identity.
    Part of entity authentication on the matrix.
Policy/guideline on work station use:
    Documented instructions/procedures delineating the proper 
functions to be performed, the manner in which those functions are 
to be performed, and the physical attributes of the surroundings, of 
a specific computer terminal site or type of site, dependant upon 
the sensitivity of the information accessed from that site.
    Part of Physical safeguards to guard data integrity, 
confidentiality, and availability on the matrix.
Procedure for emergency access:
    Documented instructions for obtaining necessary information 
during a crisis.
    Part of access control on the matrix.
Procedures for verifying access authorizations prior to physical 
access:
    Formal, documented policies and instructions for validating the 
access privileges of an entity prior to granting those privileges.
    Part of physical access controls (limited access) on the matrix.
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 asymmetric encryption system. The 
public key is made public, to be used in conjunction with 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 an individual's access privileges 
to the information, services, and resources for which they currently 
have clearance, authorization, and need-to-know when such clearance, 
authorization and need-to-know no longer exists.
    Part of termination procedures on the matrix.
Report procedures:
    The documented formal mechanism employed to document security 
incidents.
    Part of security incident procedures on the matrix.
Response procedures:
    The documented formal rules/instructions for actions to be taken 
as a result of the receipt of a security incident report.
    Part of security incident procedures on the matrix.
Risk analysis:
    Risk analysis, a process whereby cost-effective security/control 
measures may be selected by balancing the costs of various security/
control measures against the losses that would be expected if these 
measures were not in place.
    Part of the security management process on the matrix.
Risk management:
    Risk is the possibility of something adverse happening. Risk 
management is the process of assessing risk, taking steps to reduce 
risk to an acceptable level and maintaining that level of risk. 
(NIST Pub. 800-14)
    Part of the security management process on the matrix.
Role-based access control:
    Role-based access control (RBAC) is an alternative to 
traditional access control models (e.g., discretionary or non-
discretionary access control policies) that permits the 
specification and enforcement of enterprise-specific security 
policies in a way that maps more naturally to an organization's 
structure and business activities. With RBAC, rather than attempting 
to map an organization's security policy to a relatively low-level 
set of technical controls (typically, access control lists), each 
user is assigned to one or more predefined roles, each of which has 
been assigned the various privileges needed to perform 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 
disciplinary actions which are communicated to all employees, agents 
and contractors, for example, verbal warning, notice of disciplinary 
action placed in personnel files, removal of system privileges, 
termination of employment and contract penalties (ASTM E 1869)
    In addition to enterprise sanctions, employees, agents, and 
contractors must be advised of civil or criminal penalties for 
misuse or misappropriation of health information. Employees, agents 
and contractors, must be made aware that violations may result in 
notification to law enforcement officials and regulatory, 
accreditation and licensure organizations. (ASTM)
    Part of the security management process on the matrix.
Secure work station location:
    Physical safeguards to eliminate or minimize the possibility of 
unauthorized access to information, for example, locating a terminal 
used to access sensitive information in a locked room and 
restricting access to that room to authorized personnel, not placing 
a terminal used to access patient information in any area of a 
doctor's office where the screen contents can be viewed from the 
reception area.
    Part of physical safeguards to guard data integrity, 
confidentiality, and availability on the matrix.
Security:
    Security encompasses all of the safeguards in an information 
system, including hardware, software, personnel policies, 
information practice policies, disaster preparedness, and the 
oversight of all these areas. The purpose of security is to protect 
both the system and the information it contains from unauthorized 
access from without and from misuse from within.
    Through various security measures, a health information system 
can shield confidential information from unauthorized access, 
disclosure and misuse, thus protecting privacy of the individuals 
who are the subjects of the stored data. (Privacy and Health 
Information Systems: A Guide to Protecting Patient Confidentiality)
Security awareness training:
    All employees, agents, and contractors must participate in 
information security awareness training programs. Based on job 
responsibilities, individuals may be required to attend customized 
education programs that focus on issues regarding use of health 
information and responsibilities regarding confidentiality and 
security. (ASTM)
    Part of Physical safeguards to guard data integrity, 
confidentiality, and availability on the matrix.
Security configuration management:
    Measures, practices and procedures for the security of 
information systems should be coordinated and integrated with each 
other and other measures, practices and procedures of the 
organization so as to create a coherent system of security. (OECD 
Guidelines, as cited in NIST Pub 800-14)
    Part of administrative procedures to guard data integrity, 
confidentiality, and availability on the matrix.
Security incident procedures:
    Formal, documented instructions for reporting security breaches.
    Part of administrative procedures to guard data integrity, 
confidentiality and availability on the matrix.
Security management process:
    A security management process encompasses the creation, 
administration and oversight of policies to ensure the prevention, 
detection, containment, and correction of security breaches. It 
involves risk analysis and risk management, including the 
establishment of accountability, management controls (policies and 
education), electronic controls, physical security, and penalties 
for the abuse and misuse of its assets, both physical and 
electronic.

[[Page 43276]]

    Part of administrative procedures to guard data integrity, 
confidentiality and availability on the matrix.
Security policy:
    The framework within which an organization establishes needed 
levels of information security to achieve the desired 
confidentiality goals. A policy is a statement of information 
values, protection responsibilities, and organization commitment for 
a system. (OTA, 1993) The American Health Information Management 
Association recommends that security policies apply to all 
employees, medical staff members, volunteers, students, faculty, 
independent contractors, and agents. (AHIMA, 1996c) (as cited in 
HISB, DRAFT GLOSSARY OF TERMS RELATED TO INFORMATION SECURITY IN 
HEALTH CARE INFORMATION SYSTEMS draft Glossary of Terms Related to 
Information Security in Health Care Information Systems )
    Part of the security management process on the matrix
Security testing:
    A process used to determine that the security features of a 
system are implemented as designed and that they are adequate for a 
proposed applications environment. This process includes hands-on 
functional testing, penetration testing, and verification. (Glossary 
of INFOSEC and INFOSEC Related Terms--Idaho State University)
    Part of security configuration mgmt on the matrix.
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 guarantee access to the objects 
associated with that subject.
    Subject is defined as an active entity, generally in the form of 
a person, process, or device that causes information to flow among 
objects or changes the system state. Technically, a process/domain 
pair. (Glossary of INFOSEC and INFOSEC Related Terms--Idaho State 
University)
    Object is defined as a passive entity that contains or receives 
information. Access to an object potentially implies access to the 
information it contains. Examples of objects are: records blocks, 
pages, segments, files, directories, directory trees, and programs, 
as well as bits, bytes, words, fields, processors, video displays, 
keyboards, clocks, printers, network nodes, etc. (Glossary of 
INFOSEC 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 
communications network,
    A section of the matrix.
Technical security services:
    The processes that are put in place (1) to protect information 
and (2) to control and monitor individual access to information.
    A section of the matrix.
Telephone callback:
    A method of authenticating the identity of the receiver and 
sender of information through a series of ``questions'' and 
``answers'' sent back and forth establishing the identity of each. 
For example, when the communicating systems exchange a series of 
identification codes as part of the initiation of a session to 
exchange information, or when a host computer disconnects the 
initial session before the authentication is complete, and the host 
calls the user back to establish a session at a predetermined 
telephone number.
    Part of Entity authentication on the matrix.
Termination procedures:
    Formal, documented instructions, which include appropriate 
security measures, for the ending of an employee's employment, or an 
internal/external user's access.
    Part of administrative procedures to guard data integrity, 
confidentiality and availability on the matrix.
Testing and revision:
    (1) Testing and revision of contingency plans refers to the 
documented process of periodic testing to discover weaknesses in 
such plans and the subsequent process of revising the documentation 
if necessary.
    Part of contingency plan on the matrix.
    (2) Testing and revision of programs should be restricted to 
formally authorized personnel.
    Part of physical access controls (limited access) on the matrix.
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 that created 
the notation.
Token:
    A physical item that's used to provide identity. Typically an 
electronic device that can be inserted in a door or a computer 
system to obtain access. (O'Reilly, 1992) (as cited in HISB, DRAFT 
GLOSSARY OF TERMS RELATED TO INFORMATION SECURITY IN HEALTH CARE 
INFORMATION SYSTEMS draft Glossary of Terms Related to Information 
Security in Health Care Information Systems)
    Part of entity authentication on the matrix
Training:
    Education concerning the vulnerabilities of the health 
information in an entity's possession and ways to ensure the 
protection of that information.
    Part of administrative procedures to guard data integrity, 
confidentiality and availability on the matrix.
Transportability:
    A signed document can be transported (over an insecure network) 
to another system, while maintaining the integrity of 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 a terminated employee to access a property, building, or 
equipment are retrieved from that employee, preferably prior to 
termination.
    Part of termination procedures on the matrix.
Unique user identification:
    The combination name/number assigned and maintained in security 
procedures for identifying and tracking individual user identity. 
(ASTM)
    Part of Entity authentication on the matrix.
User authentication:
    The provision of assurance of the claimed identity of an entity. 
(ASTM E1762-5)
    Part of digital signature on the matrix.
User-based access:
    A security mechanism used to grant users of a system access 
based upon the identity of the user.
    Part of access control on the matrix.
    Part of authorization control on the matrix.
User education in importance of monitoring log in success/failure, 
and how to report discrepancies:
    Training in the user's responsibility to ensure the security of 
health care information.
    Part of training on the matrix.
User education concerning virus protection:
    Training relative to user awareness of the potential harm that 
can be caused by a virus, how to prevent the introduction of a virus 
to a computer system, and what to 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 be followed in creating 
and changing passwords and the need to keep them confidential.
    Part of training on the matrix.
Virus checking:
    A computer program that identifies and disables:
    (1) another ``virus'' computer program, typically hidden, that 
attaches itself to other programs and has the ability to replicate. 
(Unchecked virus programs result in undesired side effects generally 
unanticipated by the user.)
    (2) A type of programmed threat. A code fragment (not an 
independent program) that reproduces by attaching to another 
program. It may damage data directly, or it may degrade system 
performance by taking over system resources which are then not 
available to authorized users. (O'Reilly, 1992, as cited in HISB, 
DRAFT GLOSSARY OF TERMS RELATED TO INFORMATION SECURITY IN HEALTH 
CARE INFORMATION SYSTEMS draft Glossary of Terms Related to 
Information

[[Page 43277]]

Security in Health Care Information Systems)
    (3) Code embedded within a program that causes a copy of itself 
to be inserted in one or more other programs. In addition to 
propagation, the virus usually performs some unwanted function. 
(Stallings, 1995, as cited in HISB, DRAFT GLOSSARY OF TERMS RELATED 
TO INFORMATION SECURITY IN HEALTH CARE INFORMATION SYSTEMS draft 
Glossary of Terms Related to Information Security in Health Care 
Information Systems)
    Part of security configuration mgmt on the matrix.

Acronyms

ABA  American Bar Association
ADA  American Dental Association
ANSI  American National Standards Institute
AHIMA  American Health Information Management Association
ASTM  American Society for Testing and Materials
CDT  Center for Democracy & Technology
CEN  Central European Nations
CORBA  Common Object Request Broker
CPRI  Computer-based Patient Record Institute
DAC  Discretionary Access Control
DEA  Data Encryption Algorithm
EDI  Electronic Data Interchange
EHNAC  Electronic Healthcare Network Accreditation Commission
FDA  Food and Drug Administration
HISB  Health Care Informatics Standards Board
ISO  International Organization for Standardization
MAC  Mandatory Access Control
NCSC  National Computer Security Center
NCQA  National Council for Quality Assurance
NCVHS  National Committee on Vital and Health Statistics
NUBC  National Uniform Billing Committee
NUCC  National Uniform Claim Committee
PGP  Pretty Good Privacy
PIN  Personal Identification Number
NIST  National Institutes of Standards and Technology
SDO  Standards Development Organization
WEDI  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 Care Information. ASTM Committee E-31 on Computerized 
Systems, Subcommittee E31.20 on Authentication. West Conshohocken, 
PA, October 10, 1995.
ASTM, A Security Framework for Healthcare Information. ASTM 
Committee E-31 on Computerized Systems, Subcommittee E31.20 on 
Authentication. West Conshohocken, 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; Electronic Signatures; Final Rule.
For the Record--Protecting Electronic Health Information, Computer 
Science and Telecommunications Board, NRC, National Academy Press, 
2102 Constitution Avenue, NW, Box 285, Washington, DC, 20055, 1997.
Glossary of INFOSEC and INFOSEC Related Terms, Version 6. Schou, 
Corey D., Center for Decision Support, Idaho State University. 
August, 1996
HISB, DRAFT GLOSSARY OF TERMS RELATED TO INFORMATION SECURITY IN 
HEALTH CARE INFORMATION SYSTEMS Glossary of Terms Related to 
Information Security in Health Care Information Systems draft, 1997
NCSC, Glossary of Computer Security Terms, October 21, 1988.
NIST Pub 800-14, ``Generally Accepted Principles and Practices for 
Securing Information Technology Systems'', Swanson, Marianne, & 
Guttman, Barbara, September, 1996. PGP, Inc., Cryptology Reference 
Chart, August, 1997
Privacy and Health Information Systems: A Guide to Protecting 
Patient Confidentiality, Goldman, Janlori & Mulligan, Deirdre, CDT, 
1996.

Addendum 3

HIPAA SECURITY MATRIX--mapping

    Please Note: While we have attempted to categorize security 
requirements for ease of understanding and reading clarity, there 
are overlapping areas on the matrix in which the same requirements 
are restated in a slightly different context.

 Administrative Procedures To Guard Data Integrity, Confidentiality, and
                              Availability                              
------------------------------------------------------------------------
         Requirement             Implementation       Mapped  standards 
------------------------------------------------------------------------
Certification...............  ....................  47.                 
Chain of trust partner        ....................  12, 47.             
 agreement.                                                             
Contingency plan (all listed  Applications and      17, 47, 53.         
 implementation features       data criticality     12, 17, 47.         
 must be implemented).         analysis.            12, 17, 47, 53.     
                              Data backup plan....  47, 53.             
                              Disaster recovery     12, 17, 47.         
                               plan.                                    
                              Emergency mode                            
                               operation plan.                          
                              Testing and revision                      
Formal mechanism for          ....................  12, 17.             
 processing records.                                                    
Information access control    Access authorization  12, 17, 47, 53.     
 (all listed implementation   Access establishment  17, 47, 53.         
 features must be             Access modification.  12, 17, 47, 53.     
 implemented).                                                          
Internal audit..............  ....................  12, 17, 43, 44, 47. 
   Personnel security (all    Assure supervision    17, 47.             
    listed implementation      of maintenance                           
      features must be         personnel by                             
        implemented)           authorized,                              
                               knowledgeable                            
                               person.                                  
                              Maintainance of       12, 17, 47.         
                               record of access                         
                               authorizations.                          
                              Operating, and in     17, 47.             
                               some cases,                              
                               maintenance                              
                               personnel have                           
                               proper access                            
                               authorization.                           
                              Personnel clearance   17, 47.             
                               procedure.                               
                              Personnel security    17, 47, 53.         
                               policy/procedure.                        
                              System users,         12, 17, 47, 53.     
                               including                                
                               maintenance                              
                               personnel, trained                       
                               in security.                             
Security configuration mgmt.  Documentation.......  12, 17, 47, 53.     
 (all listed implementation                                             
 features must be                                                       
 implemented).                                                          
                              Hardware/software     12, 17, 47.         
                               installation &                           
                               maintenance review                       
                               and testing for                          
                               security features.                       
                              Inventory...........  12, 17.             
                              Security testing....  12, 17, 47.         
                              Virus checking......  12, 17, 47, 53.     
Security incident procedures  Report procedures...  12, 17, 47.         
 (all listed implementation   Response procedures.  17, 47.             
 features must be                                                       
 implemented).                                                          

[[Page 43278]]

                                                                        
Security management process   Risk analysis.......  12, 17, 47, 53.     
 (all listed implementation   Risk management.....  17, 47.             
 features must be             Sanction policy.....  12, 17, 47, 53.     
 implemented).                Security policy.....  17, 47, 53.         
Termination procedures (all   Combination locks     12, 17.             
 listed implementation         changed.             12, 17, 47, 53.     
 features must be             Removal from access   12, 17, 47.         
 implemented).                 lists.               12, 17, 47.         
                              Removal of user                           
                               account(s).                              
                              Turn in keys, token                       
                               or cards that allow                      
                               access.                                  
Training (all listed          Awareness training    12, 17, 18, 47, 53. 
 implementation features       for all personnel                        
 must be implemented).         (including mgmt).                        
                              Periodic security     12, 18.             
                               reminders.                               
                              User education        ....................
                               concerning virus                         
                               protection.                              
                              User education in     12, 17, 18.         
                               importance of                            
                               monitoring log in                        
                               success/failure,                         
                               and how to report                        
                               discrepancies.                           
                              User education in     12, 18, 47          
                               password management.                     
------------------------------------------------------------------------


    Physical Safeguards To Guard Data Integrity, Confidentiality, and   
                              Availability                              
------------------------------------------------------------------------
         Requirement             Implementation       Mapped standards  
------------------------------------------------------------------------
Assigned security             ....................  47.                 
 responsibility.                                                        
Media controls (all listed    Access control......  17, 47, 53.         
 implementation features      Accountability        17, 18, 47.         
 must be implemented).         (tracking            12, 17, 47, 53.     
                               mechanism).          12, 17, 47.         
                              Data backup.........  17, 47, 53.         
                              Data storage........                      
                              Disposal............                      
Physical access controls      Disaster recovery...  17.                 
 (limited access) (all        Emergency mode        17.                 
 listed implementation         operation.           17, 47.             
 features must be             Equipment control     12, 17, 47.         
 implemented).                 (into and out of                         
                               site).                                   
                              Facility security                         
                               plan.                                    
                              Procedures for        17, 18, 47.         
                               verifying access                         
                               authorizations                           
                               prior to physical                        
                               access.                                  
                              Maintenance records.  17                  
                              Need-to-know          12, 17, 47, 53      
                               procedures for                           
                               personnel access.                        
                              Sign-in for visitors  17                  
                               and escort, if                           
                               appropriate.                             
                              Testing and revision  17, 47              
Policy/guideline on work      ....................  18.                 
 station use.                                                           
Secure work station location  ....................  17, 53.             
Security awareness training.  ....................  12, 17, 47.         
------------------------------------------------------------------------


  Technical Security Services To Guard Data Integrity, Confidentiality, 
                            and Availability                            
------------------------------------------------------------------------
         Requirement             Implementation       Mapped standards  
------------------------------------------------------------------------
Access control (The           Context-based         5, 12, 14, 16, 17,  
 following implementation      access,.              40, 47.            
 feature must be              Encryption..........  1, 6, 12, 14, 17,   
 implemented: Procedure for                          21, 22, 23, 24, 26,
 emergency access, In         Procedure for          36, 28, 29, 30, 31,
 addition, at least one of     emergency access.     47, 49, 53, 54, 55.
 the following three          Roll-based access,..  14, 17, 53.         
 implementation features      User-based access...  14, 16, 17, 40, 41, 
 must be implemented:                                47, 53.            
 Context-based access, Roll-                        11, 12, 14, 16, 17, 
 based access, User-based                            40, 41, 47, 53.    
 access. The use of                                                     
 Encryption is optional).                                               
Audit controls..............  ....................  12, 14, 18, 47, 53. 
Authorization control (At     Role-based access...  5, 14, 16, 17, 47,  
 least one of the listed      User-based access...   53.                
 implementation features                            14, 16, 47, 53.     
 must be implemented).                                                  
Data authentication.........  ....................  11, 53.             
Entity Authentication (The    Automatic logoff....  14, 16, 17, 18, 40, 
 following implementation     Biometric...........   53                 
 features must be             Password............  14, 16, 18, 40, 47, 
 implemented: Automatic       PIN.................   53.                
 logoff, Unique user          Telephone callback..  14, 16, 17, 18, 19, 
 identification. In           Token...............   40, 47, 53.        
 addition, at least one of    Unique user           14, 16, 18, 19, 40, 
 the other listed              identification.       47.                
 implementation features                            14, 17, 18, 47, 53. 
 must be implemented).                              14, 17, 47, 50, 53. 
                                                    14, 47, 53.         
------------------------------------------------------------------------


[[Page 43279]]


 Technical Security Mechanisms To Guard Data Integrity, Confidentiality,
                            and Availability                            
------------------------------------------------------------------------
         Requirement             Implementation       Mapped standards  
------------------------------------------------------------------------
Communications/network        Access controls.....  14, 17, 22, 23, 39, 
 controls (If communications  Alarm, event           47, 48, 53.        
 or networking is employed,    reporting, and       14, 17, 18, 35, 36, 
 the following                 audit trail.          37, 38, 44.        
 implementation features      Audit trail                               
 must be implemented:         Encryption..........  1, 6, 12, 14, 17,   
 Integrity controls, Message                         21, 22, 23, 24, 26,
 authentication. In           Entity                 27, 28, 29, 30, 31,
 addition, one of the          authentication.       47, 49, 52, 53.    
 following implementation                           12, 14, 17, 18, 20, 
 features must be             Event reporting        22, 23, 31, 32, 33,
 implemented: Access          Integrity controls..   34, 51, 53.        
 controls, Encryption. In     Message                                   
 addition, if using a          authentication.      14, 15, 17, 18, 22, 
 network, the following four                         23, 45, 46.        
 implementation features                            14, 15, 17, 18, 22, 
 must be implemented: Alarm,                         23, 25, 45, 46, 52.
 Audit trail, Entity                                                    
 authentication, Event                                                  
 reporting).                                                            
------------------------------------------------------------------------


                          Electronic Signature                          
------------------------------------------------------------------------
         Requirement             Implementation       Mapped standards  
------------------------------------------------------------------------
Digital signature (If         Ability to add        3, 4, 10, 11, 13, 20
 digital signature is          attributes.          3, 4, 11, 13, 14, 18
 employed, the following      Continuity of         3, 4, 10, 11, 13,   
 three implementation          signature             14, 18             
 features must be              capability.          3, 4, 11, 13, 20    
 implemented: Message         Counter signatures..  3, 4, 7, 8, 9, 13,  
 integrity, Non-repudiation,  Independent            14, 48             
 User authentication. Other    verifiability.       3, 4, 10, 11, 13,   
 implementation features are  Interoperability....   14, 18             
 optional).                   Message integrity...  3, 4, 10, 11, 13, 20
                              Multiple signatures.  2, 3, 4, 10, 11, 13,
                              Non-repudiation.....   14, 42             
                              Transportability....  3, 4, 11, 13, 14, 18
                              User authentication.  3, 4, 10, 11, 13, 20
------------------------------------------------------------------------

Mapped Standards

1. ANSI X3.92--Data Encryption Standard
2. ANSI X9.30--Part 1: Public Key Cryptography Using Irreversible 
Algorithms: Digital Signature Algorithm
3. ANSI X9.30--Part 2: Public Key Cryptography Using Irreversible 
Algorithms: Secure Hash Algorithm (SHA-1)
4. ANSI X9.31--Reversible Digital Signature Algorithms
5. ANSI X9.45--Enhanced Management Controls Using Digital Signatures 
and Attribute Certificates
6. ANSI X9.52--Triple DES Modes of Operation
7. ANSI X9.55--Extensions to Public Key Certificates and CRLs
8. ANSI X9.57--Certificate Management
9. 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 
Information
12. ASTM E 1869--Draft Standard for Confidentiality, Privacy, Access 
and Data Security Principles
13. ASTM PS 100-97--Standard Specification for Authentication of 
Healthcare Information Using Digital Signatures
14. ASTM PS 101-97--Security Framework for Healthcare Information
15. ASTM PS 102-97--Standard Guide for Internet and Intranet 
Security
16. ASTM PS 103-97 Authentication & Authorization Guideline
17. CEN--European Pre-Standard
18. FDA--Electronic Records--Electronic Signatures--Final Rule
19. FIPS PUB 112--Password Usage
20. FIPS PUB 196--Entity Authentication Using Public Key 
Cryptography
21. FIPS PUB 46-2--Data Encryption Standard
22. IEEE 802.10: Interoperable LAN/MAN Security (SILS), 1992-1996 
(multiple parts)
23. IEEE 802.10c--LAN/WAN Security--Key Management
24. IETF ID--Combined SSL/PCT Transport Layer Security Protocol
25. IETF ID--FTP Authentication Using DSA
26. IETF ID--Secure HyperText TP Protocol (S-HTTP)
27. IETF ID--SMIME Cert Handling
28. IETF ID--SMIME Message Specification
29. IETF RFC 1422--Privacy Enhanced Mail: Part 1: Message Encryption 
and Authentication 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: Information Technology--Security Techniques--
Entity Authentication Mechanisms--Part 1: General Model
33. ISO/IEC 9798-2: Information Technology--Security Techniques--
Entity Authentication Mechanisms--Part 2: Entity Authentication 
Using Asymmetric Techniques
34. ISO/IEC 9798-2: Information Technology--Security Techniques--
Entity Authentication Mechanisms--Part 2: Entity Authentication 
Using Symmetric Techniques
35. ISO/IEC 10164-4--Information Technology--Open Systems 
Connection--System Management: Alarm Reporting Function
36. ISO/IEC 10164-5--Information Technology--Open Systems 
Connection--System Management: Event Report Management Function
37. ISO/IEC 10164-7--Information Technology--Open Systems 
Connection--System Management: Security Alarm Reporting Function
38. ISO/IEC 10164-8--Information Technology--Open Systems 
Connection--System Management: Security Audit Trail Function
39. ISO/IEC 10164-9--Information Technology--Open Systems 
Connection--System Management: Objects and Attributes for Access 
Control
40. ISO/IEC 10181-2--Information Technology--Security Frameworks in 
Open Systems--Authentication Framework
41. ISO/IEC 10181-3--Information Technology--Security Frameworks in 
Open Systems--Access Control Framework
42. ISO/IEC 10181-4--Information Technology--Security Frameworks in 
Open Systems--Non-repudiation Framework
43. ISO/IEC 10181-5--Information Technology--Security Frameworks in 
Open Systems--Confidentiality Framework
44. ISO/IEC 10181-7--Information Technology--Security Frameworks in 
Open Systems--Security Audit Framework
45. ISO/IEC 10736--Information Technology--Telecommunications and 
Information Exchange Between Systems--Transport Layer Security 
Protocol (TLSP)

[[Page 43280]]

46. ISO/IEC 11577--Information Technology--Telecommunications and 
Information Exchange Between Systems--Network Layer Security 
Protocol (NLSP)
47. NIST--Generally Accepted Principles and Practices for Secure 
Information Technology Systems
48. NIST MISPC--Minimum Interoperability Specification for PKI 
Components Version 1
49. PKCS #7--Cryptographic Message Syntax Standard Version 1.5 or 
later
50. PKCS #11--Cryptoki B A Cryptographic Token Interface
51. RFC 1510--Kerberos Authentication Service
52. RFC 2104--HMAC:Keyed-Hashing for Message Authentication
53. For the Record--Protecting Electronic Health Information
54. ANSI X9.42--Management of Symmetric Keys 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