[Federal Register: August 12, 1998 (Volume 63, Number 155)]
[Proposed Rules]
[Page 43241-43280]
From the Federal Register Online via GPO Access [wais.access.gpo.gov]
[DOCID:fr12au98-28]
[[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
[[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: security@osaspe.dhhs.gov. 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:
.
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