| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
HIPAA Online |
|
|
 |
|
|
Schedule In Person Training |
|
|
|
|
|
|
|
|
|
|
|
|
|
Security - HIPAA : WAIS Document Retrieval
[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: http://aspe.os.dhhs.gov/
admnsimp/.
Copies: To order copies of the Federal Register containing this
document, send your request to: New Orders, Superintendent of
Documents, P.O. Box 371954, Pittsburgh, PA 15250-7954. Specify the date
of the issue requested and enclose a check or money order payable to
the Superintendent of Documents, or enclose your Visa or Master Card
number and expiration date. Credit card orders can also be placed by
calling the order desk at (202) 512-1800 or by faxing to (202) 512-
2250. The cost for each copy is $8. As an alternative, you can view and
photocopy the Federal Register document at most libraries designated as
Federal Depository Libraries and at many other public and academic
libraries throughout the country that receive the Federal Register.
This Federal Register document is also available from the Federal
Register online database through GPO Access, a service of the U.S.
Government Printing Office. Free public access is available on a Wide
Area Information Server (WAIS) through the Internet and via
asynchronous dial-in. Internet users can access the database by using
the World Wide Web, http://www.access.gpo.gov/nara/, by using local
WAIS client software, or by telnet to swais.access.gpo.gov, then login
as guest (no password required). Dial-in users should use
communications software and modem to call (202) 512-1661; type swais,
then login as guest (no password required).
I. Background
[Please label written or e-mailed comments about this section with
the subject: Background]
In order to administer their programs, the Department of Health and
Human Services, other Federal agencies, State Medicaid agencies,
private health plans, health care providers, and health care
clearinghouses must assure their customers (such as patients, insured,
providers, and health care plans) that the confidentiality and privacy
of health care information they electronically collect, maintain, use,
or transmit is secure. Security of health information is especially
important when health information can be directly linked to an
individual.
Confidentiality is threatened not only by the risk of improper
access to electronically stored information, but also by the risk of
interception during electronic transmission of the information.
In addition to the need to ensure electronic health care
information is secure and confidential, there is a potential need to
associate signature capability with information being electronically
stored or transmitted. Today, there are numerous forms of electronic
signatures, ranging from biometric devices to digital signature. To
satisfy the legal and time-tested characteristics of a written
signature, however, an electronic signature must do the following:
<bullet> Identify the signatory individual,
<bullet> Assure the integrity of a document's content, and
<bullet> 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:
<bullet> 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).
<bullet> 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.
<bullet> 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:
<bullet> Participate with standards setting organizations.
<bullet> Provide written input to the NCVHS.
<bullet> Provide written input to the Secretary of HHS.
<bullet> Provide testimony at NCVHS'' public meetings.
<bullet> Comment on the proposed rules for each of the proposed
standards.
<bullet> 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--
<bullet> 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
<bullet> 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:
<bullet> The standard must be comprehensive.
<bullet> 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]
<bullet> 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.
<bullet> 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:
<bullet> Organizational Practices
1. Security and confidentiality policies
2. Information security officers
3. Education and training programs, and
4. Sanctions
<bullet> 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:
<bullet> 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.
<bullet> 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.
<bullet> 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
<bullet> 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:
<bullet> Applications and data criticality analysis,
<bullet> A data backup plan,
<bullet> A disaster recovery plan,
<bullet> An emergency mode operation plan, and
<bullet> 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:
<bullet> Access authorization policies and procedures.
<bullet> Access establishment policies and procedures.
<bullet> 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:
<bullet> Assure supervision of personnel performing technical
systems maintenance activities by authorized, knowledgeable persons.
<bullet> Maintain access authorization records.
<bullet> Insure that operating, and in some cases, maintenance
personnel have proper access.
<bullet> Employ personnel clearance procedures
<bullet> Employ personnel security policy/procedures.
<bullet> 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:
<bullet> Documentation.
<bullet> Hardware/software installation and maintenance review
and testing for security features.
<bullet> Inventory procedures.
<bullet> Security testing.
<bullet> 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:
<bullet> Report procedures.
<bullet> 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:
<bullet> Risk analysis.
<bullet> Risk management.
<bullet> A sanction policy.
<bullet> 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:
<bullet> Changing combination locks.
<bullet> Removal from access lists.
<bullet> Removal of user account(s).
<bullet> 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:
<bullet> Awareness training for all personnel, including
management, (this is also included as a requirement under physical
safeguards).
<bullet> Periodic security reminders.
<bullet> User education concerning virus protection.
<bullet> User education in importance of monitoring login
success/failure, and how to report discrepancies.
<bullet> 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:
<bullet> Controlled access to media.
<bullet> Accountability (tracking mechanism).
<bullet> Data backup.
<bullet> Data storage.
<bullet> 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:
<bullet> Disaster recovery.
<bullet> Emergency mode operation.
<bullet> Equipment control (into and out of site).
<bullet> A facility security plan.
<bullet> Procedures for verifying access authorizations prior
to physical access.
<bullet> Maintenance records.
<bullet> Need-to-know procedures for personnel access.
<bullet> Sign-in for visitors and escort, if appropriate.
<bullet> 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:
<bullet> Procedure for emergency access.
In addition, at least one of the following three implementation
features would be used:
<bullet> Context-based access.
<bullet> Role-based access.
<bullet> 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:
<bullet> Role-based access.
<bullet> 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:
<bullet> Automatic log off.
<bullet> Unique user identification.
In addition, at least one of the following implementation features
would be used:
<bullet> A biometric identification system.
<bullet> A password system.
<bullet> A personal identification number (PIN).
<bullet> Telephone callback.
<bullet> 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:
<bullet> Integrity controls.
<bullet> Message authentication.
One of the following implementation features would be in place:
<bullet> Access controls.
<bullet> Encryption.
In addition, if using a network for communications, the following
implementation features would be in place:
<bullet> Alarm.
<bullet> Audit trail.
<bullet> Entity authentication.
<bullet> 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, reco |
