Administrative requirements: Security and electronic signature standards,

[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).

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

    1. 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))

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

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

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

    2. 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:

      1. ``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.

      2. ``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.

      3. ``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.

      4. Part A or Part B of the Medicare program (title XVIII of the Act).

      5. The Medicaid program (title XIX of the Act).

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

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

      8. An employee welfare benefit plan or any other arrangement that is established or maintained for the purpose of offering or providing health benefits to the employees of two or more employers. This includes plans that are referred to as multiple employer welfare arrangements (``MEWAs'').

      9. The health care program for active military personnel under title 10 of the United States Code.

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

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

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

      13. 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.)

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

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

      16. 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:

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

      18. 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).

      19. 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.''

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

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

      22. 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      20. 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.).

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

      22. 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, records are kept of everyone who is permitted to use the PC and what files they may access), and training all personnel in security. Again, we emphasize that these requirements are scalable. The requirement for Personnel Clearance Procedures could be met in a small office with standard personal and professional reference checks, while a large organization may employ more formal, rigorous background investigations.

        This same individual could also be charged with the responsibility for Security Configuration Management and Termination Procedures. For our small provider, the Security Configuration Management requirement would be relatively easy to satisfy; the necessary features could be part of a purchased hardware/software package (for example, a new PC might be equipped with virus checking software), or included as part of the support supplied with the purchase of equipment and software. Termination procedures would incorporate specific security actions to be taken as a result of an employee's termination, such as obtaining all keys and changing combinations or passwords. A ``position description'' document describing this person's duties could specify the level of detail necessary.

        The small or rural provider office would also need to ensure that they have activated the internal auditing capability of the software used to manage health data files so that it tracks who has accessed the data. (We expect that the capability of keeping audit trails will become standard in all health care software in the near future, spurred on by the health information privacy debates in the Congress and elsewhere.)

        A small or rural provider may document compliance with many of the

        [[Page 43256]]

        foregoing administrative security requirements by including them in an ``office procedures'' type of document that should be required reading by new employees and always available for reference. Requirements that would lend themselves to inclusion in an ``office procedures'' document include: contingency plans, formal records processing procedures, information access controls (rules for granting access, actual establishment of access, and procedures for modifying such access), security incident procedures (for example, who is to be notified if it appears that medical information has been accessed by an unauthorized party), and training. Periodic security reminders could include visual aids, such as posters and screen savers, and oral reminders in recurring meetings.

        Physical Access controls would be relatively straightforward for this small or rural office, using locked rooms and/or closets to secure equipment and media from unauthorized access. The ``office procedures/ policies'' manual should include directions for authorizing access and keeping records of authorized accesses. Media Controls and Workstation Use policy instructions would be developed by the office and would include additional instructions on such items as where to store backed- up data, how to dispose of data no longer needed, or logging off when leaving terminals unattended.

        Safeguards for the security of workstation location(s) would depend upon the physical surroundings in the small or rural office. Our small or rural provider may meet the requirements by locating equipment in areas that are generally populated by office staff and have some degree of physical separation from the public. Security Awareness Training would be part of the new employee orientation process and would be a periodic recurring discussion item in staff meetings.

        The Technical Security Services requirements for Access Control, Entity Authentication, and Authorization Control may be achieved simply by implementing a user-based data access model (assigning a user-name and password combination to each authorized employee). Other access models could be employed if desired, but would prove unwieldy for the small office. For example, the role-based access process groups users with similar data access needs, and context-based access is based upon the context of a transaction--not on the attributes of the initiator. By assigning full access rights to a minimum of two key individuals in the office, implementation of the Emergency Access feature could be satisfied. Audit control mechanisms, by necessity, would be provided by software featuring that capability. By establishing and using a message authentication code, Data Authentication would be achieved. Use of the password system mentioned above could also satisfy the Unique User Identification requirement.

        As our example provider contracts with a third party to handle claims processing, the claims processing contract would be the vehicle to provide for a chain of trust (requiring the contractor to implement the same security requirements and take responsibility for protecting the data it receives).

        If this provider chooses to use the Internet to transmit or receive health information, some form of encryption must be used. For example, the provider could procure and use commercial software to provide protection against unauthorized access to the data transmitted or received. (This decision must take into account what encryption system the message recipient uses.) On the other hand, health information when transmitted via other means such as VANs, private wires, or even dial- up connections may not require such absolute protection as is provided by encryption. This small or rural provider would likely not be part of a network configuration, therefore, only integrity controls and message authentication would be required and could be provided by currently available software products, most likely provided as part of their contract with their health care clearinghouse.

        Small providers may need guidance regarding the content of the documents required by this rule (for example, specifics of a chain of trust partner agreement). We would expect models of the documentation discussed in this example to be developed by industry associations and vendors. If this model documentation is not developed, DHHS would work with the industry to develop them.

    5. Electronic Signature Standard

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

      HIPAA directs the Secretary of the Department of Health and Human Services to coordinate with the Secretary of the Department of Commerce in adopting standards for the electronic transmission and authentication of signatures with respect to the transactions referred to in the law. This rule was developed in coordination with the Department of Commerce's National Institute of Standards and Technology. We propose to adopt a cryptographically based digital signature as the standard.

      Whenever a HIPAA specified transaction requires the use of an electronic signature, the standard must be used. It should be noted that an electronic signature is not required for any of the currently proposed standard transactions.

      In the electronic environment, the same legal weight associated with an original signature on a paper document may be needed for electronic data. Use of an electronic signature refers to the act of attaching a signature by electronic means. The electronic signature process involves authentication of the signer's identity, a signature process according to system design and software instructions, binding of the signature to the document and non-alterability after the signature has been affixed to the document. The generation of electronic signatures requires the successful identification and authentication of the signer at the time of the signature.

      The proposed standard for electronic signature is presented at Sec. 142.310 and would be digital.

      The following matrix depicts the requirement and implementation features for electronic signatures. Following the matrix is a discussion of the electronic signature requirement.

      [[Page 43257]]

      Electronic Signature

      Requirement

      Implementation

      Digital signature (If digital signature Ability to add attributes. is employed, the following three

      Continuity of signature

      implementation features must be

      capability.

      implemented: Message integrity,

      Countersignatures.

      Nonrepudiation, User authentication. Independent verifiability. Other implementation features are Interoperability.

      optional).

      Message integrity.

      Multiple Signatures.

      Nonrepudiation.

      Transportability.

      User authentication.

      Various technologies may fulfill one or more of the requirements specified in the matrix. Authentication systems (passwords, biometrics, physical feature authentication, behavioral actions and token-based authentication) can be combined with cryptographic techniques to form an electronic signature. However, a complete electronic signature system may require more than one of the technologies mentioned above. If electronic signatures would be used, certain implementation features must be included, specifically:

      ‹bullet› Message integrity.

      ‹bullet› Nonrepudiation.

      ‹bullet› User authentication.

      Currently there are no technically mature techniques that provide the security service of nonrepudiation in an open network environment, in the absence of trusted third parties, other than digital signature- based techniques. Therefore, if electronic signatures are employed, we would require that digital signature technology be used. A digital signature is formed by applying a mathematical function to the electronic document. This process yields a unique bit string, referred to as a message digest. The digest (only) is encrypted using the originator's private key and the resulting bit stream is appended to the electronic document. The recipient of the transmitted document decrypts the message digest with the originator's public key, applies the same message hash function to the document, then compares the resulting digest with the transmitted version. If they are identical, then the recipient is assured that the message is unaltered and the identity of the signer is proven. Since only the signatory authority can hold the Private Key used to digitally sign the document, the critical feature of nonrepudiation is enforced. Other electronic signature implementation features that may be used follow:

      ‹bullet› Ability to add attributes.

      ‹bullet› Continuity of signature capability.

      ‹bullet› Countersignatures capability.

      ‹bullet› Independent verifiability.

      ‹bullet› Interoperability.

      ‹bullet› Multiple signatures.

      ‹bullet› Transportability.

      This standard is described in greater detail in Sec. 142.310 of the regulation text and is depicted in tabular form along with the security standard in a combined matrix located at Addendum 1. We have not included the matrix in the proposed regulation text. We invite your comments concerning the appropriateness and usefulness of including the matrix in the final regulation text. We have also provided a glossary of terms to facilitate a common understanding of the matrix entries. The glossary can be found at Addendum 2. Finally, we have included currently existing standards and guidelines mapped to the proposed electronic signature standard. This mapping is not all inclusive and is located at Addendum 3.

    6. Selection Criteria

      Each individual implementation team weighted the criteria described in section I.B. above, Process for Developing National Standards, in terms of the standard it was addressing. As we assessed security and electronic signatures, it became apparent that while the security standard set forth in Sec. 142.308 and the electronic signature standard set forth in Sec. 142.310 satisfy all the criteria described above, they most strongly address criteria 1, 3, 7, 9, and 10. These criteria are described below in the specific context of these standards.

      1. Improve the efficiency and effectiveness of the health care system.

      The security and electronic signature standards would be integrated with the electronic transmission of health care information to improve the overall effectiveness of the health care system. This integration would assure that electronic health care information would not be accessible to any unauthorized person or organization, but would be both accurate and available to those who are authorized to receive it.

      3. Be consistent and uniform with the other HIPAA standards and, secondly, with other private and public sector health data standards.

      The security and electronic signature standards were developed after a comprehensive review of existing standards and guidelines, with significant input by a wide range of industry experts. As indicated in Addendum 3, the standards map well to existing standards and guidelines.

      7. Be technologically independent of computer platforms and transmission protocols.

      We have defined the security and electronic signature standards in terms of requirements that would allow businesses in the health care industry to select the technology that best meets their business requirements while still allowing them to comply with the standards.

      9. Keep data collection and paperwork burdens on users as low as is feasible.

      The security and electronic signature standards would allow individual health care industry businesses to ascertain the level of security information that would be needed. The confidentiality level associated with individual data elements concerning health care information would determine the appropriate security application to be used. The security standard would define the requirements to be met to achieve the privacy and confidentiality goal, but each business entity, driven by its business requirements, would decide what techniques and controls would provide appropriate and adequate electronic data protection. This would allow data collection and the paperwork burden to be as low as is feasible.

      10. Incorporate flexibility to adapt more easily to changes in the health care infrastructure and information technology.

      A technologically neutral security standard would be more adaptable to changes in infrastructure and information technology.

      [[Page 43258]]

    7. Consultations

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

      1. The NCVHS held two days of public hearings on security issues in August 1997, and made a recommendation to the Secretary of HHS, as required by the legislation. The NCVHS recommendation to the Secretary of HHS, as required by the legislation, was for a technologically neutral standard. It identified certain criteria to be established for a health information system to be secure. The proposed security standard complies with the NCVHS security recommendation.

      2. The ANSI Accredited Standards Committee (ASC) X12 subcommittees on communication and control, insurance and government were contacted. Their current standards development effort is focused on messaging rather than on security requirements.

      3. American Society for Testing and Materials (ASTM), Committee E31 on Computerized Systems participated in the security discussions.

      4. Association for Electronic Health Care Transactions (AFEHCT), the clearinghouse organization, provided information on its health care transaction process requirements and emphasized that the security standard must be adaptable to different business needs.

      5. Computer-based Patient Record Institute (CPRI) was consulted because the Work Group on Confidentiality, Privacy and Security is working on the establishment of guidelines, confidentiality agreements, security requirements, and frameworks. CPRI works closely with accredited standards development organizations.

      6. Health Level Seven (HL-7) has been contacted through its participation at the HISB meetings.

      7. NUCC and the NUBC were apprised of the different implementation teams' efforts. NUBC has not addressed security issues at any of the public meetings. NUCC identified a number of issues at its November 18- 19 meeting and provided written comments to us.

    8. Rules for Security Standards and Electronic Signature Standard

      1. Health Plans

      1. In Sec. 142.306(a), we would require health plans to accept and apply the security standard to all health care information pertaining to an individual that is electronically maintained or electronically transmitted. Federal agencies and States may place additional requirements on their health plans. In addition, trading partners may mutually agree to implement additional security measures.

      2. In Sec. 142.310(a), entities would not be required to use an electronic signature. However, if a plan elects to use an electronic signature in one of the transactions named in the law, it would be required to apply the electronic signature standard described in Sec. 142.310(b) to that transaction. In the future, we anticipate that the standards for other transactions may include requirements for signatures. In particular, the proposed standard for claims attachments, which will be issued in a separate regulations package later, may include signature requirements on some or all of the attachments. If the proposed attachments standard includes such signature requirements, we will address the issue of how to reconcile such requirements with existing State and Federal requirements for written signatures as part of the proposed rule. 2. Health Care Clearinghouses

      3. We would require in Sec. 142.306(b) that each health care clearinghouse comply with the security standard to ensure all health care information and activities are protected from unauthorized access. If the clearinghouse is part of a larger organization, then security must be imposed to prevent unauthorized access by the larger organization. The security standards apply to all health information pertaining to an individual that is electronically maintained or electronically transmitted.

      4. In Sec. 142.310(a), entities would not be required to use an electronic signature. However, if a plan elects to use an electronic signature in one of the transactions named in the law, it would be required to apply the electronic signature standard described in Sec. 142.310(b) to that transaction. In the future, we anticipate that the standards for other transactions may include requirements for signatures. In particular, the proposed standard for claims attachments, which will be issued in a separate regulations package later, may include signature requirements on some or all of the attachments. If the proposed attachments standard includes such signature requirements, we will address the issue of how to reconcile such requirements with existing State and Federal requirements for written signatures as part of the proposed rule. 3. Health Care Providers

      5. In Sec. 142.306(a), we would require each health care provider to apply the security standard to all health information pertaining to an individual that is electronically maintained or electronically transmitted.

      6. In Sec. 142.310(a), entities would not be required to use an electronic signature. However, if a plan elects to use an electronic signature in one of the transactions named in the law, it would be required to apply the electronic signature standard described in Sec. 142.310(b) to that transaction. In the future, we anticipate that the standards for other transactions may include requirements for signatures. In particular, the proposed standard for claims attachments, which will be issued in a separate regulations package later, may include signature requirements on some or all of the attachments. If the proposed attachments standard includes such signature requirements, we will address the issue of how to reconcile such requirements with existing State and Federal requirements for written signatures as part of the proposed rule.

  3. Effective Dates

    Health plans would be required to comply with the security and electronic signature standards as follows:

    1. Each health plan that is not a small health plan would have to comply with the requirements of Secs. 142.306, 142.308, and 142.310 no later than 24 months after publication of the final rule.

    2. Each small health plan would have to comply with the requirements of Secs. 142.306, 142.308, and 142.310 no later than 36 months after the date of publication of the final rule.

    3. If the effective date for the electronic transaction standards is later than the effective date for the security standard, implementation of the security standard would not be delayed until the standard transactions are in use. The security standard would still be effective with respect to electronically stored or maintained data. Security of health information would not be solely tied to the standard transactions but would apply to all individual health information electronically stored, maintained, or transmitted.

    4. Under this proposed rule, in some cases, a health plan could choose to convert from paper to standard EDI transactions prior to the effective date of the security standard. We would recommend that the security standard be implemented at that time in order to safeguard the data in those transactions. We invite comments on this issue.

    [[Page 43259]]

    Failure to comply with standards may result in monetary penalties. The Secretary is required by statute to impose penalties of not more than $100 per violation on any person who fails to comply with a standard, except that the total amount imposed on any one person in each calendar year may not exceed $25,000 for violations of one requirement.

    We are not proposing any enforcement procedures at this time, but we plan to do so in a future Federal Register document once the industry has some experience with using the standards. These procedures will be in place by the time the standards are implemented by industry. We envision the monitoring and enforcement process as a partnership between the Federal government and the private sector. Some private accreditation bodies have already exhibited interest in certifying compliance with the security requirements as part of their accreditation reviews. Small providers may be able to self-certify through industry-developed checklists. HHS would likely retain the final responsibility for determining violations and imposing the penalties specified by the statute. We welcome comments on this approach.

  4. Implementation

    If an entity elects to use an electronic signature in a transaction, or if an electronic signature is required by a transaction standard adopted by the Secretary, the entity must apply the electronic signature standard described in Sec. 142.310(b).

    How the security standard would be implemented is dependent upon industry trading partner agreements for electronic transmissions. The health care industry would be able to adapt the security matrix to meet its business needs. We propose that the requirements of the security standard be implemented over time. However, we would require implementation to be complete by the applicable effective date. We would encourage, but not require that entities comply with the security standard as soon as practicable, preferably before implementing the transactions standards.

    The security standard would supersede contrary provisions of State law including State law requiring medical or health plan records to be maintained or transmitted in other electronic formats. There are certain exceptions when the standards would not supersede contrary provisions of State law; section 1178 identifies those conditions and directs the Secretary to determine whether a particular State provision falls within one or more of the exceptions.

    The electronic signature standard (digital signature) would be deemed to satisfy Federal and State statutory requirements for written signatures with respect to the named transactions referred to in the legislation.

    Several accreditation organizations such as the Electronic Healthcare Network Accreditation Commission (EHNAC), the Joint Commission on Accreditation of Healthcare Organizations (JCAHO), and the National Committee for Quality Assurance (NCQA), indicate that one of their accreditation requirements will be compliance with the HIPAA security and electronic signature (if applicable) standards.

  5. New and Revised Standards

    To encourage innovation and promote development, we plan to establish a process to allow an organization to request a revision or replacement to any adopted standard or standards. An organization could request a revision or replacement to an adopted standard by requesting a waiver from the Secretary of Health and Human Services to test a revised or new standard. The organization would be required, at a minimum, to demonstrate that the revised or new standard offers a clear improvement over the adopted standard. If the organization presents sufficient documentation that supports testing of a revised or new standard, we want to be able to grant the organization a temporary waiver to test while remaining in compliance with the law. We do not intend to establish a process that would allow an organization to avoid using any adopted standard.

    We would welcome comments on the following: (1) How we should establish this process, (2) the length of time a proposed standard should be tested before we decide whether to adopt it, (3) whether we should solicit public comments before implementing a change in a standard, and (4) other issues and recommendations we should consider. Comments should be submitted to the addresses presented in the ADDRESSES section of this document.

    The following is one possible process:

    ‹bullet› Any organization that wishes to revise or replace an adopted standard would submit its waiver request to an HHS evaluation committee (to be established or defined). The organization would do the following for each standard it wishes to revise or replace:

    + Provide a detailed explanation, no more than 10 pages, of how the revision or replacement would be a clear improvement over the current standard.

    + Provide specifications and technical capabilities on the revised or new standard, including any additional system requirements.

    + Provide an explanation, no more than five pages, of how the organization intends to test the standard.

    ‹bullet› The committee's evaluation would, at a minimum, be based on the following:

    + A cost-benefit analysis.

    + An assessment of whether the proposed revision or replacement demonstrates a clear improvement to an existing standard.

    + The extent and length of time of the waiver.

    ‹bullet› The evaluation committee would inform the organization requesting the waiver within 30 working days of the committee's decision on the waiver request. If the committee decides to grant a waiver, the notification may include the following:

    + Committee comments such as the following:

    --The length of time for which the waiver applies if it differs from the waiver request. --The sites the committee believes are appropriate for testing if they differ from the waiver request. --Any pertinent information regarding the conditions of an approved waiver.

    ‹bullet› Any organization that receives a waiver would be required to submit a report containing the results of the study, no later than 3 months after the study is completed.

    ‹bullet› The committee would evaluate the report and determine whether the benefits of the proposed revision or new standard significantly outweigh the disadvantages of implementing it and make a recommendation to the Secretary.

  6. Response to Comments

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

  7. Impact Analysis

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

    [[Page 43260]]

    analysis on the total effect of all the standards in the proposed rule concerning the national provider identifier (HCFA-0045-P), which was published on May 7, 1998 (63 FR 25320).

    We intend to publish in each proposed rule an impact analysis that is specific to the standard or standards proposed in that rule, but the impact analysis will assess only the relative cost impact of implementing a given standard. Thus, the following discussion contains the impact analysis for the security standard and the electronic signature standard proposed in this rule. As stated in the general impact analysis in HCFA-0045-P, we do not intend to associate costs and savings to specific standards.

    Although we cannot determine the specific economic impact of the standards being proposed in this rule (and individually each standard may not have a significant impact), the overall impact analysis makes clear that, collectively, all the standards will have a significant impact of over $100 million on the economy. Also, while each standard may not have a significant impact on a substantial number of small entities, the combined effects of all the proposed standards may have a significant effect on a substantial number of small entities. Therefore, the following impact analysis should be read in conjunction with the overall impact analysis.

    The following describes the specific impacts that relate to the security and electronic signature standards. Security protection for health care information is not a ``stand-alone'' type requirement. Appropriate security protections will be a business enabler, encouraging the growth and use of electronic data interchange. The synergistic effect of the employment of the recommended security practices, procedures and technologies will enhance all aspects of HIPAA's Administrative Simplification requirements. In addition, it is important to recognize that security is not a product, but is an on- going, dynamic process.

    In accordance with the provisions of Executive Order 12866, this proposed rule was reviewed by the Office of Management and Budget.

    1. Security Standard

      HIPAA requires that all health plans, health care providers, and health care clearinghouses that maintain or transmit health information electronically establish and maintain reasonable and appropriate administrative, technical, and physical safeguards to ensure integrity, confidentiality, and availability of the information. The safeguards also protect the information against any reasonably anticipated threats or hazards to the security or integrity of the information and protect it against unauthorized use or disclosure. Recommendation 1 from the National Research Council's (NRC) report For the Record: Protecting Electronic Health Information (``All organizations that handle patient- identifiable health care information-- regardless of size--should adopt the set of technical and organization policies, practices, and procedures described * * * to protect such information.'') would apply to all health care providers regardless of size, health care clearinghouses, and health plans. We agree with the NRC's belief that implementation of the practices and technologies delineated in Recommendation 1 would be possible today, and at a reasonable cost.

      Health care providers that conduct electronic transactions with health plans would have to comply with the recommendation(s) for security protection. There is, however, no requirement to maintain health records electronically or transmit health care information by electronic means. There may also be health care providers that currently submit health care information on paper but archive records electronically. These entities will need to ensure that their existing electronic systems conform to security requirements for maintaining health information. Once they have done so, however, they may also take advantage of all the other benefits of electronic recordkeeping and transmittal. Therefore, no individual small entity is expected to experience direct costs that exceed benefits as a result of this rule. Furthermore, because almost all of the NRC recommendations reflect contemporary security measures and controls, most organizations that currently have security measures should have to make few, if any, modifications to their systems to meet the requirements proposed in the security standard.

      The singular exception to the above lies in the area of providing security for the electronic transmission of health care information over insecure, public media. Here, the choice of a method to use is driven by economic factors. If an organization wishes to use an insecure transmission media such as the Internet, and take advantage of the low costs involved, off-setting costs may need to be incurred to provide for an acceptable form of encryption so that health information will be protected from intercept and possible misuse.

      One alternative course of action to encrypting the information would be to use the services of a VAN. VANs do not manipulate data, but rather transmit data in its native form over telecommunication lines. We anticipate that VANs would be positively affected by administrative simplification, because use of the proposed transactions standards would eliminate the need for data to be reformatted. This would allow providers to purchase the services of a VAN directly, rather than as a service bundled with the functions of other clearinghouses. Another course of action might be to use private lines which would provide an appropriate level of protection for data in transmission.

    2. Electronic Signature Standard

      HIPAA does not require the use of electronic signatures. This particular capability, however, would be necessary for a completely paperless environment. Certain features of the digital signature type of electronic signature make this particular system the most desirable. Only digital signatures, using current technology, provide the combination of authenticity, message integrity, and nonrepudiation which is viewed as a desirable complement to the security standards required by the law.

      The use of digital signatures requires a certain infrastructure (Public Key Infrastructure) that may necessitate the expenditure of initial and recurring costs for users. We do not know what these costs are presently, due to the lack of maturity of digital signature technology, and minimal use in the marketplace today. It is noted that public key certificate management systems and services do exist today, and it is presumed more quantifiable information will be forthcoming, as to potential costs and savings that can be associated with the use of digital signature systems. Other forms of electronic signature were considered, such as biometric and digitized signatures. While they provide a useful capability in certain circumstances, we believe that digital signature technology is most appropriate for this particular application.

    3. Guiding Principles for Standard Selection

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

      [[Page 43261]]

      philosophy set forth in EO 12866 of September 30, 1993. In order to be designated as a standard, EO 12866 requires that a proposed standard:

      ‹bullet› Improve the efficiency and effectiveness of the health care system by leading to cost reductions for or improvements in benefits from electronic HIPAA health care transactions. This principle supports the regulatory goals of cost-effectiveness and avoidance of burden.

      ‹bullet› Meet the needs of the health data standards user community, particularly health care providers, health plans, and health care clearinghouses. This principle supports the regulatory goal of cost-effectiveness.

      ‹bullet› Be consistent and uniform with the other HIPAA standards (that is, their data element definitions and codes and their privacy and security requirements) and, secondarily, with other private and public sector health data standards. This principle supports the regulatory goals of consistency and avoidance of incompatibility, and it establishes a performance objective for the standard.

      ‹bullet› Have low additional development and implementation costs relative to the benefits of using the standard. This principle supports the regulatory goals of cost-effectiveness and avoidance of burden.

      ‹bullet› Be supported by an ANSI-accredited standards developing organization or other private or public organization that would ensure continuity and efficient updating of the standard over time. This principle supports the regulatory goal of predictability.

      ‹bullet› Have timely development, testing, implementation, and updating procedures to achieve administrative simplification benefits faster. This principle establishes a performance objective for the standard.

      ‹bullet› Be technologically independent of the computer platforms and transmission protocols used in HIPAA health transactions, except when they are explicitly part of the standard. This principle establishes a performance objective for the standard and supports the regulatory goal of flexibility.

      ‹bullet› Be precise and unambiguous but as simple as possible. This principle supports the regulatory goals of predictability and simplicity.

      ‹bullet› Keep data collection and paperwork burdens on users as low as is feasible. This principle supports the regulatory goals of cost- effectiveness and avoidance of duplication and burden.

      ‹bullet› Incorporate flexibility to adapt more easily to changes in the health care infrastructure (such as new services, organizations, and provider types) and information technology. This principle supports the regulatory goals of flexibility and encouragement of innovation.

      We assessed a wide variety of security standards, guidelines and electronic signature standards against the principles listed above, with the overall goal of achieving the maximum benefit for the least cost. We found that there exists no single standard for security or electronic signature that encompasses all the requirements that have been deemed necessary. However, in this particular area, technology is rapidly developing enhancements and better means for accomplishing the stated goals.

    4. Affected Entities

      1. Health Care Providers

      Health care providers that conduct business using electronic transactions with other health care participants (such as other health care providers, health plans, and employers) or maintain electronic health information are encouraged, but are not required to simultaneously implement the proposed security standard. However, if the effective date for the electronic transaction standards is later than the effective date for the security standard, the implementation of the security standard will not be delayed until the standard transactions are in use.

      Health care providers that transmit, receive, or maintain health information would incur implementation costs for establishing or updating their security systems. Any negative impact on these health care providers caused by implementing the proposed security standard would generally be related to the initial implementation period for the specific requirements of the security standard. Health care providers that are indirectly involved in electronic transactions (for example, those who submit a paper claim that the health plan transmits electronically to a secondary payer) and do not maintain electronic health information would not be affected. 2. Health Plans

      Health plans that engage in electronic health care transactions would have to modify their systems to use the security standard and the electronic signature standard, if used. Health plans that maintain electronic health information would also have to modify their systems to use the security standard. This conversion would have a one-time cost impact on Federal, State and private plans alike.

      We recognize that this conversion process has the potential to cause business disruption of some health plans. However, health plans would be able to schedule their implementation of the security standard and other standards in a way that best fits their needs, as long as they meet the deadlines specified in the law.

      Implementation of the security standard and the electronic signature standard, if used by the entities, would enhance payment safeguard activities and protect the integrity of the Medicare trust fund by reducing fraud and abuse that occurs when health care information is used by those who are not authorized to receive it. In addition these standards would assist the plans, providers, and clearinghouses to more effectively maintain the security of all health information in their databases. 3. Clearinghouses

      Health care clearinghouses would face impacts similar to those experienced by health care providers and health plans. Systems vendors, that provide computer software applications to health care providers and other billers of health care services, would likely be positively affected. These vendors would have to develop software solutions that would allow health care providers and other billers of health care transactions to protect the information in their databases from unwanted access to their systems. 4. Unfunded Mandates

      This proposed rule has been reviewed in accordance with the Unfunded Mandates Reform Act of 1995 (UMRA) (U.S.C. 1501 et seq.) and Executive Order 12875. As discussed in the combined impact analysis referenced above (see Federal Register, Volume 63, No. 88), DHHS estimates that implementation of the standards will require the expenditure of more than $100 million by the private sector. Therefore, the rule establishes a Federal private sector mandate and is a significant regulatory action within the meaning of section 202 of UMRA (2 U.S.C. 1532). DHHS has included this statement to address the anticipated effects of the proposed rules pursuant to section 202.

      These standards also apply to State and local governments in their roles as health plans or health care providers. Thus, the proposed rules impose unfunded mandates on these entities. While we do not have sufficient information to provide estimates of these impacts, several State Medicaid agencies have estimated that it would cost $1 million per State to implement

      [[Page 43262]]

      all of the HIPAA standards. However, the Congressional Budget Office analysis stated that ``States are already in the forefront in administering the Medicaid program electronically; the only costs-- which should not be significant--would involve bringing the software and computer systems for the Medicaid programs into compliance with the new standards.''

      The anticipated benefits and costs of this proposed standard, and other issues raised in section 202 of the UMRA, are addressed in the analysis below, and in the combined impact analysis. In addition, under section 205 of the UMRA (2 U.S.C. 1535), having considered a reasonable number of alternatives as outlined in the preamble to this rule and in the following analysis, the Department has concluded that the rule is the most cost-effective alternative for implementation of DHHS'' statutory objective of administrative simplification. 5. Regulatory Flexibility Act

      The Regulatory Flexibility Act (RFA) of 1980, Public Law 96-354, requires us to prepare a regulatory flexibility analysis if the Secretary certifies that a proposed regulation would have a significant economic impact on a substantial number of small entities. The security and electronic signature standards will affect small entities, such as providers. A more detailed analysis of the impact on small entities is part of the impact analysis we published on May 7, 1998 (63 FR 25320) for all the HIPAA standards. A detailed illustration of the potential impact of the security standard on a small health care provider can be found in the preamble in section D.

    5. Factors in Establishing the Security Standard

      1. Selection of Security Systems and Procedures

      Because there is no national security standard in widespread use throughout the industry, adopting any of the candidate standards would require most health care providers, health plans and health care clearinghouses to conform to the new standard. Implementation of the security standard would require all health plans, health care providers, and health care clearinghouses to establish or revise their security precautions because the proposed standard is not currently in use. The selection of the security standard does not impose a greater burden on the industry than the nonselected options, and presents significant advantages in terms of universality, uniqueness and flexibility.

      Only those plans, providers, and clearinghouses that decide to use the digital signature would be affected by the electronic signature standard. Some large health plans, health care providers, and health care clearinghouses that currently exchange health information among trading partners may have security systems and procedures in place to protect the information from unauthorized access. These entities may not incur significant costs to meet the proposed security standard and if they opt not to use the digital signature they would not incur costs to meet the electronic signature requirements. Also, some entities that currently use electronic signatures as an added security measure may also be using digital signature technology. At most, large entities that may have sophisticated security systems in place may only need to revise or update their systems to meet the proposed security standard and electronic signature standard. 2. Complexity of Conversion

      The complexity of the conversion would be significantly affected by the volume of claims health plans process electronically and the desire to transmit the claims themselves or to use the services of a VAN or a clearinghouse. If they chose to transmit themselves, they would need to convert to the proposed transaction standards. Specific technology limitations of existing systems could affect the complexity of the conversion. For example, some entities may only have a minimum level of security and procedures in place and therefore may require a full upgrade, while others may already have a very sophisticated system and procedures and require very little enhancement. 3. Cost of Conversion

      We expect that most providers, health plans, and clearinghouses that transmit or store data electronically have already implemented some security measures and will primarily need to assess existing security, identify areas of risk, and implement additional measures. We cannot estimate the per-entity cost of implementation because there is no information available regarding the extent to which providers', plans', and clearinghouses' current security practices are deficient. Moreover, some security solutions are almost cost-free to implement (e.g., reminding employees not to post passwords on their monitors) while others are not.

      Affected entities will have many choices regarding how they will implement security. Some may choose to assess security using in-house staff, while others will utilize consultants. Practice management software vendors may also provide security consultation services to their customers. Entities may also choose to implement security measures that require hardware or software purchases at the time they do routine equipment upgrades.

      The security requirements we are proposing were developed with considerable input from the health care industry, including providers, health plans, clearinghouses, vendors, and standards organizations. Industry members strongly advocated this flexible approach, which permits each affected entity to develop cost-effective security measures. We believe that this approach will yield the lowest implementation cost to industry while assuring that health information is safeguarded. We solicit input regarding implementation costs.

      We are unable to estimate, of the nation's 4 million-plus health plans and 1.2 million-plus providers, the number of entities that would require security systems and procedures because they conduct electronic transactions or maintain electronic health information. Nor are we able to estimate the number of entities that neither conduct electronic transactions nor maintain electronic health information but may choose to do so at some future time. (These would be entities that send and receive paper transactions and maintain paper records and thus would not be affected because they would have no need to implement security standards.) However, we are aware of the possibility that those small entities that currently process claims electronically or maintain electronic health information may not be able to continue to do so due to the cost of establishing security systems to meet the requirements of the proposed security standard. Those entities that are not able to bill and exchange health information electronically may use clearinghouses. We believe that the proposed security standard represents the minimum necessary for adequate protection of health information in an electronic format. As discussed earlier in this preamble, the security requirements are both scalable and technically flexible; and while the law requires each health plan that is not a small plan to comply with the security and electronic signature requirements no later than 24 months after the effective date of the final rule, small plans will be allowed an additional 12 months to comply.

      Since we are unable to estimate the number of entities, we are also unable to estimate the cost to the entities that will process electronic transactions.

      [[Page 43263]]

      However, we believe that the cost of establishing security systems and procedures is a portion of the costs associated with converting to the transaction standards that are required under HIPAA.

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

  8. Collection of Information Requirements

    Under the Paperwork Reduction Act of 1995, we are required to provide 60-day notice in the Federal Register and solicit public comment before a collection of information requirement is submitted to the Office of Management and Budget (OMB) for review and approval. In order to fairly evaluate whether an information collection should be approved by OMB, section 3506(c)(2)(A) of the Paperwork Reduction Act of 1995 requires that we solicit comment on the following issues:

    ‹bullet› The need for the information collection and its usefulness in carrying out the proper functions of our agency.

    ‹bullet› The accuracy of our estimate of the information collection burden.

    ‹bullet› The quality, utility, and clarity of the information to be collected.

    ‹bullet› Recommendations to minimize the information collection burden on the affected public, including automated collection techniques.

    As discussed below, we are soliciting comment on the recordkeeping requirements, as referenced in Sec. 142.308 of this document. In addition, we are soliciting comment on the applicability of the PRA as it may relate to the requirement to use the standard adopted in Sec. 142.310 of this regulation.

    Section 142.308 Security Standard

    In summary, each entity designated in Sec. 142.302 must maintain documentation demonstrating the development, implementation, and maintenance of appropriate security measures that include, at a minimum, the requirements and implementation features set forth in this section. In addition, entities must maintain necessary documentation to demonstrate that these measures have been periodically reviewed, validated, updated, and kept current.

    While we solicit comment on these recordkeeping requirements we explicitly solicit comment on the burden associated with maintaining documentation related to the implementation the requirements set forth in Sec. 142.308. Since the level of documentation necessary to demonstrate compliance with these requirements is dependent upon individual business needs and the fact that we do not prescribe the form, format, or degree of documentation necessary to demonstrate compliance, we are currently unable to accurately estimate the degree of recordkeeping burden that will be experienced by the varying entities. Therefore, commentors should provide an estimate of: (1) the initial recordkeeping burden associated with meeting these requirements and (2) the recordkeeping burden associated with maintaining documentation to demonstrate that the measures have been periodically reviewed, validated, updated, and kept current.

    Below is a discussion of the applicability of the PRA as it may relate to the adoption of the standard referenced in Sec. 142.310 of this regulation.

    Section 142.310 Electronic Signature Standard

    In summary, any entity electing to use an electronic signature in a transaction as defined in Sec. 142.103, or if an electronic signature is required by a transaction standard adopted by the Secretary, the entity must apply the electronic signature standard described in paragraph (b) of this section to that transaction. Discussion

    The emerging and increasing use of health care EDI standards and transactions raises the issue of the applicability of the PRA. The question arises whether a regulation that adopts an EDI standard used to exchange certain information constitutes an information collection subject to the PRA.

    In particular, we are still considering whether the use of any EDI transaction standard, such as the electronic signature described in this regulation, should be viewed or regarded as a standardized electronic collection of information. If it is a standardized electronic information collection, then the requirement by the Federal government on the industry to accept and transmit the information may be subject to OMB review and approval under the PRA.

    We invite public comment on the issues discussed above. If the requirements, as set forth in Sec. 142.310 are determined to be subject to the PRA, we will submit these requirements to OMB for PRA approval. If you comment on these information collection and recordkeeping requirements, please e-mail comments to JBurke1@hcfa.gov (Attn: HCFA- 0049) or mail copies directly to the following:

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

    List of Subjects in 45 CFR Part 142

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

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

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

    PART 142--ADMINISTRATIVE REQUIREMENTS

    Subpart A--General Provisions

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

    [[Page 43264]]

    Subpart B--Reserved

    Subpart C--Security and Electronic Signature Standards

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

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

    Subpart A--General Provisions

    Sec. 142.101 Statutory basis and purpose.

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

    Sec. 142.102 Applicability.

    (a) The standards adopted or designated under this part apply, in whole or in part, to the following:

    (1) A health plan.

    (2) A health care clearinghouse when doing the following:

    (i) Transmitting a standard transaction (as defined in Sec. 142.103) to a health care provider or health plan.

    (ii) Receiving a standard transaction from a health care provider or health plan.

    (iii) Transmitting and receiving the standard transactions when interacting with another health care clearinghouse.

    (3) A health care provider when transmitting an electronic transaction as defined in Sec. 142.103.

    (b) Means of compliance are stated in greater detail in Sec. 142.105.

    Sec. 142.103 Definitions.

    For purposes of this part, the following definitions apply:

    Code set means any set of codes used for encoding data elements, such as tables of terms, medical concepts, medical diagnostic codes, or medical procedure codes.

    Health care clearinghouse means a public or private entity that processes or facilitates the processing of nonstandard data elements of health information into standard data elements. The entity receives health care transactions from health care providers or other entities, translates the data from a given format into one acceptable to the intended payer or payers, and forwards the processed transaction to appropriate payers and clearinghouses. Billing services, repricing companies, community health management information systems, community health information systems, and ``value-added'' networks and switches are considered to be health care clearinghouses for purposes of this part.

    Health care provider means a provider of services as defined in section 1861(u) of the Social Security Act, 42 U.S.C. 1395x, a provider of medical or other health services as defined in section 1861(s) of the Social Security Act, and any other person who furnishes or bills and is paid for health care services or supplies in the normal course of business.

    Health information means any information, whether oral or recorded in any form or medium, that--

    (1) Is created or received by a health care provider, health plan, public health authority, employer, life insurer, school or university, or health care clearinghouse; and

    (2) Relates to the past, present, or future physical or mental health or condition of an individual, the provision of health care to an individual, or the past, present, or future payment for the provision of health care to an individual.

    Health plan means an individual or group plan that provides, or pays the cost of, medical care. Health plan includes the following, singly or in combination:

    (1) Group health plan. A group health plan is an employee welfare benefit plan (as currently defined in section 3(1) of the Employee Retirement Income and Security Act of 1974, 29 U.S.C. 1002(1)), including insured and self-insured plans, to the extent that the plan provides medical care, including items and services paid for as medical care, to employees or their dependents directly or through insurance, or otherwise, and--

    (i) Has 50 or more participants; or

    (ii) Is administered by an entity other than the employer that established and maintains the plan.

    (2) Health insurance issuer. A health insurance issuer is an insurance company, insurance service, or insurance organization that is licensed to engage in the business of insurance in a State and is subject to State law that regulates insurance.

    (3) Health maintenance organization. A health maintenance organization is a Federally qualified health maintenance organization, an organization recognized as a health maintenance organization under State law, or a similar organization regulated for solvency under State law in the same manner and to the same extent as such a health maintenance organization.

    (4) Part A or Part B of the Medicare program under title XVIII of the Social Security Act.

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

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

    (7) A long-term care policy, including a nursing home fixed- indemnity policy.

    (8) An employee welfare benefit plan or any other arrangement that is established or maintained for the purpose of offering or providing health benefits to the employees of two or more employers.

    (9) The health care program for active military personnel under title 10 of the United States Code.

    (10) The veterans health care program under 38 U.S.C. chapter 17.

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

    (12) The Indian Health Service program under the Indian Health Care Improvement Act (25 U.S.C. 1601 et seq.).

    (13) The Federal Employees Health Benefits Program under 5 U.S.C. chapter 89.

    (14) Any other individual or group health plan, or combination thereof, that provides or pays for the cost of medical care.

    Medical care means the diagnosis, cure, mitigation, treatment, or prevention of disease, or amounts paid for the purpose of affecting any body structure or function of the body; amounts paid for transportation primarily for and essential to these items; and amounts paid for insurance covering the items and the transportation specified in this definition.

    Participant means any employee or former employee of an employer, or any member or former member of an employee organization, who is or may become eligible to receive a benefit of any type from an employee benefit plan that covers employees of that employer or members of such an organization, or whose beneficiaries may be eligible to receive any of these benefits. ``Employee'' includes an individual who is treated as an employee under section 401(c)(1) of the Internal Revenue Code of 1986 (26 U.S.C. 401(c)(1)).

    Small health plan means a group health plan or individual health plan with fewer than 50 participants.

    [[Page 43265]]

    Standard means a set of rules for a set of codes, data elements, transactions, or identifiers promulgated either by an organization accredited by the American National Standards Institute or HHS for the electronic transmission of health information.

    Transaction means the exchange of information between two parties to carry out financial and administrative activities related to health care. It includes the following:

    (1) Health claims or equivalent encounter information.

    (2) Health care payment and remittance advice.

    (3) Coordination of benefits.

    (4) Health claims status.

    (5) Enrollment and disenrollment in a health plan.

    (6) Eligibility for a health plan.

    (7) Health plan premium payments.

    (8) Referral certification and authorization.

    (9) First report of injury.

    (10) Health claims attachments.

    (11) Other transactions as the Secretary may prescribe by regulation.

    Sec. 142.104 General requirements for health plans.

    If a person conducts a transaction (as defined in Sec. 142.103) with a health plan as a standard transaction, the following apply:

    (a) The health plan may not refuse to conduct the transaction as a standard transaction.

    (b) The health plan may not delay the transaction or otherwise adversely affect, or attempt to adversely affect, the person or the transaction on the ground that the transaction is a standard transaction.

    (c) The health information transmitted and received in connection with the transaction must be in the form of standard data elements of health information.

    (d) A health plan that conducts transactions through an agent must assure that the agent meets all the requirements of this part that apply to the health plan.

    Sec. 142.105 Compliance using a health care clearinghouse.

    (a) Any person or other entity subject to the requirements of this part may meet the requirements to accept and transmit standard transactions by either--

    (1) Transmitting and receiving standard data elements; or

    (2) Submitting nonstandard data elements to a health care clearinghouse for processing into standard data elements and transmission by the health care clearinghouse and receiving standard data elements through the health care clearinghouse.

    (b) The transmission, under contract, of nonstandard data elements between a health plan or a health care provider and its agent health care clearinghouse is not a violation of the requirements of this part.

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

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

    Subpart B--[Reserved]

    Subpart C--Security and Electronic Signature Standards

    Sec. 142.302 Applicability and scope.

    The standards adopted or designated under this subpart apply, in whole or in part, to the following:

    (a) A health plan.

    (b) A health care clearinghouse or health care provider that takes one of the following actions:

    (1) Processes any electronic transmission between any combination of health care entities listed in this section.

    (2) Electronically maintains any health information used in an electronic transmission that has been sent or received between any combination of health care entities listed in this section.

    Sec. 142.304 Definitions.

    For purposes of this subpart, the following definitions apply:

    Access refers to the ability or the means necessary to read, write, modify, or communicate data/information or otherwise make use of any system resource.

    Access control refers to a method of restricting access to resources, allowing only privileged entities access. Types of access control include, among others, mandatory access control, discretionary access control, time-of-day, and classification.

    Authentication refers to the corroboration that an entity is the one claimed.

    Contingency plan refers to a plan for responding to a system emergency. The plan includes performing backups, preparing critical facilities that can be used to facilitate continuity of operations in the event of an emergency, and recovering from a disaster.

    Encryption (or encipherment) refers to transforming confidential plaintext into ciphertext to protect it. An encryption algorithm combines plaintext with other values called keys, or ciphers, so the data becomes unintelligible. Once encrypted, data can be stored or transmitted over unsecured lines. Decrypting data reverses the encryption algorithm process and makes the plaintext available for further processing.

    Password refers to confidential authentication information composed of a string of characters.

    Role-based access control (RBAC) is an alternative to traditional access control models (e.g., discretionary or non-discretionary access control policies) that permits the specification and enforcement of enterprise-specific security policies in a way that maps more naturally to an organization's structure and business activities. With RBAC, rather than attempting to map an organization's security policy to a relatively low-level set of technical controls (typically, access control lists), each user is assigned to one or more predefined roles, each of which has been assigned the various privileges needed to perform that role.

    Token refers to a physical item necessary for user identification when used in the context of authentication. For example, an electronic device that can be inserted in a door or a computer system to obtain access.

    User-based access refers to a security mechanism used to grant users of a system access based upon the identity of the user.

    Sec. 142.306 Rules for the security standard.

    (a) An entity must apply the security standard described in Sec. 142.308 to all health information pertaining to an individual that is electronically maintained or electronically transmitted.

    (b) If a health care clearinghouse is part of a larger organization, it must assure that all health information pertaining to an individual is protected from unauthorized access by the larger organization.

    [[Page 43266]]

    Sec. 142.308 Security standard.

    Each entity designated in Sec. 142.302 must assess potential risks and vulnerabilities to the individual health data in its possession and develop, implement, and maintain appropriate security measures. These measures must be documented and kept current, and must include, at a minimum, the following requirements and implementation features:

    (a) Administrative procedures to guard data integrity, confidentiality, and availability (documented, formal practices to manage the selection and execution of security measures to protect data, and to manage the conduct of personnel in relation to the protection of data). These procedures include the following requirements:

    (1) Certification. (The technical evaluation performed as part of, and in support of, the accreditation process that establishes the extent to which a particular computer system or network design and implementation meet a pre-specified set of security requirements. This evaluation may be performed internally or by an external accrediting agency.)

    (2) A chain of trust partner agreement (a contract entered into by two business partners in which the partners agree to electronically exchange data and protect the integrity and confidentiality of the data exchanged).

    (3) A contingency plan, a routinely updated plan for responding to a system emergency, that includes performing backups, preparing critical facilities that can be used to facilitate continuity of operations in the event of an emergency, and recovering from a disaster. The plan must include all of the following implementation features:

    (i) An applications and data criticality analysis (an entity's formal assessment of the sensitivity, vulnerabilities, and security of its programs and information it receives, manipulates, stores, and/or transmits).

    (ii) Data backup plan (a documented and routinely updated plan to create and maintain, for a specific period of time, retrievable exact copies of information).

    (iii) A disaster recovery plan (the part of an overall contingency plan that contains a process enabling an enterprise to restore any loss of data in the event of fire, vandalism, natural disaster, or system failure).

    (iv) Emergency mode operation plan (the part of an overall contingency plan that contains a process enabling an enterprise to continue to operate in the event of fire, vandalism, natural disaster, or system failure).

    (v) Testing and revision procedures (the documented process of periodic testing of written contingency plans to discover weaknesses and the subsequent process of revising the documentation, if necessary).

    (4) Formal mechanism for processing records (documented policies and procedures for the routine, and nonroutine, receipt, manipulation, storage, dissemination, transmission, and/or disposal of health information).

    (5) Information access control (formal, documented policies and procedures for granting different levels of access to health care information) that includes all of the following implementation features:

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

    (ii) Access establishment (security policies and rules that determine an entity's initial right of access to a terminal, transaction, program, process or some other user).

    (iii) Access modification (security policies and rules that determine the types of, and reasons for, modification to an entity's established right of access, to a terminal, transaction, program, process, or some other user.)

    (6) Internal audit (in-house review of the records of system activity (such as logins, file accesses, and security incidents) maintained by an organization).

    (7) Personnel security (all personnel who have access to any sensitive information have the required authorities as well as all appropriate clearances) that includes all of the following implementation features:

    (i) Assuring supervision of maintenance personnel by an authorized, knowledgeable person. These procedures are documented formal procedures and instructions for the oversight of maintenance personnel when the personnel are near health information pertaining to an individual.

    (ii) Maintaining a record of access authorizations (ongoing documentation and review of the levels of access granted to a user, program, or procedure accessing health information).

    (iii) Assuring that operating and maintenance personnel have proper access authorization (formal documented policies and procedures for determining the access level to be granted to individuals working on, or near, health information).

    (iv) Establishing personnel clearance procedures (a protective measure applied to determine that an individual's access to sensitive unclassified automated information is admissible).

    (v) Establishing and maintaining personnel security policies and procedures (formal, documentation of procedures to ensure that all personnel who have access to sensitive information have the required authority as well as appropriate clearances).

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

    (8) Security configuration management (measures, practices, and procedures for the security of information systems that must be coordinated and integrated with each other and other measures, practices, and procedures of the organization established in order to create a coherent system of security) that includes all of the following implementation features:

    (i) Documentation (written security plans, rules, procedures, and instructions concerning all components of an entity's security).

    (ii) Hardware and software installation and maintenance review and testing for security features (formal, documented procedures for connecting and loading new equipment and programs, periodic review of the maintenance occurring on that equipment and programs, and periodic security testing of the security attributes of that hardware/software).

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

    (iv) Security testing (process used to determine that the security features of a system are implemented as designed and that they are adequate for a proposed applications environment; this process includes hands-on functional testing, penetration testing, and verification).

    (v) Virus checking. (The act of running a computer program that identifies and disables:

    (A) Another ``virus'' computer program, typically hidden, that attaches itself to other programs and has the ability to replicate.

    (B) A code fragment (not an independent program) that reproduces by attaching to another program.

    (C) A code embedded within a program that causes a copy of itself to be inserted in one or more other programs.)

    (9) Security incident procedures (formal documented instructions for reporting security breaches) that include all of the following implementation features:

    (i) Report procedures (documented formal mechanism employed to document security incidents).

    [[Page 43267]]

    (ii) Response procedures (documented formal rules or instructions for actions to be taken as a result of the receipt of a security incident report).

    (10) Security management process (creation, administration, and oversight of policies to ensure the prevention, detection, containment, and correction of security breaches involving risk analysis and risk management). It includes the establishment of accountability, management controls (policies and education), electronic controls, physical security, and penalties for the abuse and misuse of its assets (both physical and electronic) that includes all of the following implementation features:

    (i) Risk analysis, a process whereby cost-effective security/ control measures may be selected by balancing the costs of various security/control measures against the losses that would be expected if these measures were not in place.

    (ii) Risk management (process of assessing risk, taking steps to reduce risk to an acceptable level, and maintaining that level of risk).

    (iii) Sanction policies and procedures (statements regarding disciplinary actions that are communicated to all employees, agents, and contractors; for example, verbal warning, notice of disciplinary action placed in personnel files, removal of system privileges, termination of employment, and contract penalties). They must include employee, agent, and contractor notice of civil or criminal penalties for misuse or misappropriation of health information and must make employees, agents, and contractors aware that violations may result in notification to law enforcement officials and regulatory, accreditation, and licensure organizations.

    (iv) Security policy (statement(s) of information values, protection responsibilities, and organization commitment for a system). This is the framework within which an entity establishes needed levels of information security to achieve the desired confidentiality goals.

    (11) Termination procedures (formal documented instructions, which include appropriate security measures, for the ending of an employee's employment or an internal/external user's access) that include procedures for all of the following implementation features:

    (i) Changing locks (a documented procedure for changing combinations of locking mechanisms, both on a recurring basis and when personnel knowledgeable of combinations no longer have a need to know or require access to the protected facility or system).

    (ii) Removal from access lists (physical eradication of an entity's access privileges).

    (iii) Removal of user account(s) (termination or deletion of an individual's access privileges to the information, services, and resources for which they currently have clearance, authorization, and need-to-know when such clearance, authorization and need-to-know no longer exists).

    (iv) Turning in of keys, tokens, or cards that allow access (formal, documented procedure to ensure all physical items that allow a terminated employee to access a property, building, or equipment are retrieved from that employee, preferably before termination).

    (12) Training (education concerning the vulnerabilities of the health information in an entity's possession and ways to ensure the protection of that information) that includes all of the following implementation features:

    (i) Awareness training for all personnel, including management personnel (in security awareness, including, but not limited to, password maintenance, incident reporting, and viruses and other forms of malicious software).

    (ii) Periodic security reminders (employees, agents, and contractors are made aware of security concerns on an ongoing basis).

    (iii) User education concerning virus protection (training relative to user awareness of the potential harm that can be caused by a virus, how to prevent the introduction of a virus to a computer system, and what to do if a virus is detected).

    (iv) User education in importance of monitoring log-in success or failure and how to report discrepancies (training in the user's responsibility to ensure the security of health care information).

    (v) User education in password management (type of user training in the rules to be followed in creating and changing passwords and the need to keep them confidential).

    (b) Physical safeguards to guard data integrity, confidentiality, and availability. Protection of physical computer systems and related buildings and equipment from fire and other natural and environmental hazards, as well as from intrusion. It covers the use of locks, keys, and administrative measures used to control access to computer systems and facilities. Physical safeguards must include all of the following requirements and implementation features:

    (1) Assigned security responsibility (practices established by management to manage and supervise the execution and use of security measures to protect data and to manage and supervise the conduct of personnel in relation to the protection of data).

    (2) Media controls (formal, documented policies and procedures that govern the receipt and removal of hardware/software (such as diskettes and tapes) into and out of a facility) that include all of the following implementation features:

    (i) Access control.

    (ii) Accountability (the property that ensures that the actions of an entity can be traced uniquely to that entity).

    (iii) Data backup (a retrievable, exact copy of information).

    (iv) Data storage (the retention of health care information pertaining to an individual in an electronic format).

    (v) Disposal (final disposition of electronic data, and/or the hardware on which electronic data is stored).

    (3) Physical access controls (limited access) (formal, documented policies and procedures to be followed to limit physical access to an entity while ensuring that properly authorized access is allowed) that include all of the following implementation features:

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

    (ii) An emergency mode operation (access controls in place that enable an entity to continue to operate in the event of fire, vandalism, natural disaster, or system failure).

    (iii) Equipment control (into and out of site) (documented security procedures for bringing hardware and software into and out of a facility and for maintaining a record of that equipment. This includes, but is not limited to, the marking, handling, and disposal of hardware and storage media.)

    (iv) A facility security plan (a plan to safeguard the premises and building (exterior and interior) from unauthorized physical access and to safeguard the equipment therein from unauthorized physical access, tampering, and theft).

    (v) Procedures for verifying access authorizations before granting physical access (formal, documented policies and instructions for validating the access privileges of an entity before granting those privileges).

    (vi) Maintenance records (documentation of repairs and modifications to the physical components of a facility, such as

    [[Page 43268]]

    hardware, software, walls, doors, and locks).

    (vii) Need-to-know procedures for personnel access (a security principle stating that a user should have access only to the data he or she needs to perform a particular function).

    (viii) Procedures to sign in visitors and provide escorts, if appropriate (formal documented procedure governing the reception and hosting of visitors).

    (ix) Testing and revision (the restriction of program testing and revision to formally authorized personnel).

    (4) Policy and guidelines on work station use (documented instructions/procedures delineating the proper functions to be performed, the manner in which those functions are to be performed, and the physical attributes of the surroundings of a specific computer terminal site or type of site, dependent upon the sensitivity of the information accessed from that site).

    (5) A secure work station location (physical safeguards to eliminate or minimize the possibility of unauthorized access to information; for example, locating a terminal used to access sensitive information in a locked room and restricting access to that room to authorized personnel, not placing a terminal used to access patient information in any area of a doctor's office where the screen contents can be viewed from the reception area).

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

    (c) Technical security services to guard data integrity, confidentiality, and availability (the processes that are put in place to protect information and to control individual access to information). These services include the following requirements and implementation features:

    (1) The technical security services must include all of the following requirements and the specified implementation features:

    (i) Access control that includes:

    (A) A procedure for emergency access (documented instructions for obtaining necessary information during a crisis), and

    (B) At least one of the following implementation features:

    (1) Context-based access (an access control procedure based on the context of a transaction (as opposed to being based on attributes of the initiator or target)).

    (2) Role-based access.

    (3) User-based access.

    (C) The optional use of encryption.

    (ii) Audit controls (mechanisms employed to record and examine system activity).

    (iii) Authorization control (the mechanism for obtaining consent for the use and disclosure of health information) that includes at least one of the following implementation features:

    (A) Role-based access.

    (B) User-based access.

    (iv) Data authentication. (The corroboration that data has not been altered or destroyed in an unauthorized manner. Examples of how data corroboration may be assured include the use of a check sum, double keying, a message authentication code, or digital signature.)

    (v) Entity authentication (the corroboration that an entity is the one claimed) that includes:

    (A) Automatic logoff (a security procedure that causes an electronic session to terminate after a predetermined time of inactivity, such as 15 minutes), and

    (B) Unique user identifier (a combination name/number assigned and maintained in security procedures for identifying and tracking individual user identity).

    (C) At least one of the following implementation features:

    (1) Biometric identification (an identification system that identifies a human from a measurement of a physical feature or repeatable action of the individual (for example, hand geometry, retinal scan, iris scan, fingerprint patterns, facial characteristics, DNA sequence characteristics, voice prints, and hand written signature)).

    (2) Password.

    (3) Personal identification number (PIN) (a number or code assigned to an individual and used to provide verification of identity).

    (4) A telephone callback procedure (method of authenticating the identity of the receiver and sender of information through a series of ``questions'' and ``answers'' sent back and forth establishing the identity of each). For example, when the communicating systems exchange a series of identification codes as part of the initiation of a session to exchange information, or when a host computer disconnects the initial session before the authentication is complete, and the host calls the user back to establish a session at a predetermined telephone number.

    (5) Token.

    (2) [Reserved]

    (d) Technical security mechanisms (processes that are put in place to guard against unauthorized access to data that is transmitted over a communications network).

    (1) If an entity uses communications or network controls, its security standards for technical security mechanisms must include the following:

    (i) The following implementation features:

    (A) Integrity controls (a security mechanism employed to ensure the validity of the information being electronically transmitted or stored).

    (B) Message authentication (ensuring, typically with a message authentication code, that a message received (usually via a network) matches the message sent).

    (ii) One of the following implementation features:

    (A) Access controls (protection of sensitive communications transmissions over open or private networks so that they cannot be easily intercepted and interpreted by parties other than the intended recipient).

    (B) Encryption.

    (2) If an entity uses network controls (to protect sensitive communication that is transmitted electronically over open networks so that it cannot be easily intercepted and interpreted by parties other than the intended recipient), its technical security mechanisms must include all of the following implementation features:

    (i) Alarm. (In communication systems, any device that can sense an abnormal condition within the system and provide, either locally or remotely, a signal indicating the presence of the abnormality. The signal may be in any desired form ranging from a simple contact closure (or opening) to a time-phased automatic shutdown and restart cycle.)

    (ii) Audit trail (the data collected and potentially used to facilitate a security audit).

    (iii) Entity authentication (a communications or network mechanism to irrefutably identify authorized users, programs, and processes and to deny access to unauthorized users, programs, and processes).

    (iv) Event reporting (a network message indicating operational irregularities in physical elements of a network or a response to the occurrence of a significant task, typically the completion of a request for information).

    Sec. 142.310 Electronic signature standard.

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

    [[Page 43269]]

    transaction as defined in Sec. 142.103, or if an electronic signature is required by a transaction standard adopted by the Secretary, the entity must apply the electronic signature standard described in paragraph (b) of this section to that transaction.

    (b) Standard.

    (1) An electronic signature is the attribute affixed to an electronic document to bind it to a particular entity. An electronic signature secures the user authentication (proof of claimed identity) at the time the signature is generated; creates the logical manifestation of signature (including the possibility for multiple parties to sign a document and have the order of application recognized and proven); supplies additional information such as time stamp and signature purpose specific to that user; and ensures the integrity of the signed document to enable transportability of data, interoperability, independent verifiability, and continuity of signature capability. Verifying a signature on a document verifies the integrity of the document and associated attributes and verifies the identity of the signer.

    (2) The standard for electronic signature is a digital signature. A ``digital signature'' is an electronic signature based upon cryptographic methods of originator authentication, computed by using a set of rules and a set of parameters so that the identity of the signer and the integrity of the data can be verified.

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

    (1) Message integrity (the assurance of unaltered transmission and receipt of a message from the sender to the intended recipient).

    (2) Nonrepudiation (strong and substantial evidence of the identity of the signer of a message, and of message integrity, sufficient to prevent a party from successfully denying the origin, submission, or delivery of the message and the integrity of its contents).

    (3) User authentication (the provision of assurance of the claimed identity of an entity).

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

    (1) Ability to add attributes (one possible capability of a digital signature technology; for example, the ability to add a time stamp as part of a digital signature).

    (2) Continuity of signature capability (the concept that the public verification of a signature must not compromise the ability of the signer to apply additional secure signatures at a later date).

    (3) Countersignatures. (The capability to prove the order of application of signatures. This is analogous to the normal business practice of countersignatures, where a party signs a document that has already been signed by another party.)

    (4) Independent verifiability (the capability to verify the signature without the cooperation of the signer).

    (5) Interoperability (the applications used on either side of a communication, between trading partners and/or between internal components of an entity, are able to read and correctly interpret the information communicated from one to the other).

    (6) Multiple signatures. (With this feature, multiple parties are able to sign a document. Conceptually, multiple signatures are simply appended to the document.)

    (7) Transportability of data (the ability of a signed document to be transported over an insecure network to another system, while maintaining the integrity of the document, including content, signatures, signature attributes, and (if present) document attributes).

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

    (a) General rules.

    (1) Except for a small health plan (defined at Sec. 142.103), each entity designated in Sec. 142.302 must comply with the requirements of this subpart by [24 months after the effective date of the final rule in the Federal Register].

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

    (3) The requirements of the security standard may be implemented over time. Implementation must be completed by the applicable effective date.

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

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

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

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

    Addendum 1

    HIPAA Security Matrix

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

    Administrative Procedures To Guard Data Integrity, Confidentiality, and Availability

    Requirement

    Implementation

    Certification

    Chain of trust partner agreement

    Contingency plan (all listed

    Applications and data

    implementation features must be

    criticality analysis.

    implemented).

    Data backup plan.

    Disaster recovery plan.

    Emergency mode operation plan. Testing and revision.

    Formal mechanism for processing

    records.

    Information access control (all listed Access authorization.

    implementation features must be

    Access establishment.

    implemented).

    Access modification.

    Internal audit

    [[Page 43270]]

    Personnel security (all listed

    Assure supervision of

    implementation features must be

    maintenance personnel by implemented).

    authorized, knowledgeable person.

    Maintainance of record of access authorizations.

    Operating, and in some cases, maintenance personnel have

    proper access authorization. Personnel clearance procedure. Personnel security policy/ procedure.

    System users, including

    maintenance personnel, trained in security.

    Security configuration mgmt. (all

    Documentation.

    listed implementation features must be Hardware/software installation implemented).

    & maintenance review and testing for security features. Inventory.

    Security Testing.

    Virus checking.

    Security incident procedures (all

    Report procedures.

    listed implementation features must be Response procedures.

    implemented).

    Security management process (all listed Risk analysis.

    implementation features must be

    Risk management.

    implemented).

    Sanction policy.

    Security policy.

    Termination procedures (all listed Combination locks changed. implementation features must be

    Removal from access lists. implemented).

    Removal of user account(s).

    Turn in keys, token or cards that allow access.

    Training (all listed implementation Awareness training for all features must be implemented).

    personnel (including mgmt). Periodic security reminders. User education concerning virus protection.

    User education in importance of monitoring log in success/

    failure, and how to report

    discrepancies.

    User education in password management.

    Physical Safeguards To Guard Data Integrity, Confidentiality, and Availability

    Requirement

    Implementation

    Assigned security responsibility

    Media controls (all listed

    Access control.

    implementation features must be

    Accountability (tracking implemented).

    mechanism).

    Data backup.

    Data storage.

    Disposal.

    Physical access controls (limited

    Disaster recovery.

    access) (all listed implementation Emergency mode operation. features must be implemented).

    Equipment control (into and out of site).

    Facility security plan.

    Procedures for verifying access authorizations prior to physical access.

    Maintenance records.

    Need-to-know procedures for

    personnel access.

    Sign-in for visitors and escort, if appropriate. Testing and revision.

    Policy/guideline on work station use

    Secure work station location

    Security awareness training

    Technical Security Services To Guard Data Integrity, Confidentiality, and Availability

    Requirement

    Implementation

    Access control (The following

    Context-based access.

    implementation feature must be

    Encryption.

    implemented: Procedure for emergency Procedure for emergency access. access. In addition, at least one of Role-based access.

    the following three implementation User-based access.

    features must be implemented: Context-

    based access, Roll-based access, User-

    based access. The use of Encryption is

    optional).

    Audit controls

    Authorization Control (At least one of Role-based access.

    the listed implementation features User-based access

    must be implemented).

    Data Authentication

    [[Page 43271]]

    Entity Authentication (The following Automatic logoff.

    implementation features must be

    Biometric.

    implemented: Automatic logoff, Unique Password.

    user identification. In addition, at PIN.

    least one of the other listed

    Telephone callback.

    implementation features must be

    Token.

    implemented).

    Unique user identification.

    Technical Security Mechanisms To Guard Against Unauthorized Access to Data That Is Transmitted Over a Communications Network

    Requirement

    Implementation

    Communications/network controls (The

    Access controls.

    following implementation features must be Alarm.

    implemented: Integrity controls, Message Audit trail.

    authentication. If communications or

    Encryption.

    networking is employed, one of the following Entity authentication. implementation features must be implemented: Event reporting.

    Access controls, Encryption. In addition, if Integrity controls. using a network, the following four

    Message authentication. implementation features must be implemented:

    Alarm, Audit trail, Entity authentication,

    Event reporting).

    Electronic Signature

    Requirement

    Implementation

    Digital signature (If digital signature Ability to add attributes. is employed, the following three

    Continuity of signature

    implementation features must be

    capability.

    implemented: Message integrity, Non- Counter signatures.

    repudiation, User authentication. Independent verifiability. Other implementation features are Interoperability.

    optional).

    Message integrity.

    Multiple Signatures.

    Non-repudiation.

    Transportability.

    User authentication.

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

    Please Note:

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

    (2) While not appearing on the matrix, a number of terms listed below do appear in the glossary descriptions and have been supplied for additional clarity:

    (3) The definitions provided in this document have been obtained from multiple sources.

    Ability to add attributes:

    One possible capability of a digital signature technology, for example, the ability to add a time stamp as part of a digital signature.

    Part of digital signature on the matrix. Access:

    The ability or the means necessary to read, write, modify, or communicate data/information or otherwise make use of any system resource. Access authorization:

    Information-use policies/procedures that establish the rules for granting and/or restricting access to a user, terminal, transaction, program, or process.

    Part of information access control on the matrix. Access control:

    A method of restricting access to resources, allowing only privileged entities access. (PGP, Inc.)

    Types of access control include, among others, mandatory access control, discretionary access control, time-of-day, classification, and subject-object separation.

    Part of Media Controls on the matrix.

    Part of technical security services to control and monitor access to information on the matrix. Access controls:

    The protection of sensitive communications transmissions over open or private networks so that it cannot be easily intercepted and interpreted by parties other than the intended recipient.

    Part of mechanisms to prevent unauthorized access to data that is transmitted over a communications network on the matrix. Access establishment:

    The security policies, and the rules established therein, that determine an entity's initial right of access to a terminal, transaction, program, or process.

    Part of information access control on the matrix. Access Level:

    A level associated with an individual who may be accessing information (for example, a clearance level) or with the information which may be accessed (for example, a classification level). (NRC, 1991, as cited in HISB, DRAFT GLOSSARY OF TERMS RELATED TO INFORMATION SECURITY IN HEALTH CARE INFORMATION SYSTEMS draft Glossary of Terms Related to Information Security in Health Care Information Systems) Access modification:

    The security policies, and the rules established therein, that determine types of, and reasons for, modification to an entity's established right of access to a terminal, transaction, program, or process.

    Part of information access control on the matrix. Accountability:

    The property that ensures that the actions of an entity can be traced uniquely to that entity. (ASTM E1762--95)

    [[Page 43272]]

    Part of media controls on the matrix. Administrative procedures to guard data integrity, confidentiality and availability:

    Documented, formal practices to manage (1) the selection and execution of security measures to protect data, and (2) the conduct of personnel in relation to the protection of data.

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

    (1) Alarm: In communication systems, any device that can sense an abnormal condition within the system and provide, either locally or remotely, a signal indicating the presence of the abnormality. (188) NOTE: The signal may be in any desired form ranging from a simple contact closure (or opening) to a time-phased automatic shutdown and restart cycle. (Glossary of INFOSEC and INFOSEC Related Terms--Idaho State University)

    (2) Event reporting: Network message indicating operational irregularities in physical elements of a network or a response to the occurrence of a significant task, typically the completion of a request for information. (Glossary of INFOSEC and INFOSEC Related Terms--Idaho State University)

    (3) Audit trail: Data collected and potentially used to facilitate a security audit. (ISO 7498-2, as cited in HISB, DRAFT GLOSSARY OF TERMS RELATED TO INFORMATION SECURITY IN HEALTH CARE INFORMATION SYSTEMS draft Glossary of Terms Related to Information Security in Health Care Information Systems)

    Part of mechanisms to prevent unauthorized access to data that is transmitted over a communications network on the matrix. Applications and data criticality analysis:

    An entity's formal assessment of the sensitivity, vulnerabilities, and security of its programs and information it receives, manipulates, stores, and/or transmits.

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

    Practices put in place by management to manage and supervise (1) the execution and use of security measures to protect data, and (2) the conduct of personnel in relation to the protection of data.

    Part of Physical safeguards to guard data integrity, confidentiality, and availability on the matrix. Assure supervision of maintenance personnel by authorized, knowledgeable person:

    Documented formal procedures/instruction for the oversight of maintenance personnel when such personnel are in the vicinity of health information pertaining to an individual.

    Part of personnel security on the matrix. Asymmetric encryption:

    Encryption and decryption performed using two different keys, one of which is referred to as the public key and one of which is referred to as the private key.

    Also known as public-key encryption. (Stallings) Asymmetric key:

    One half of a key pair used in an asymmetric (``public-key'') encryption system. Asymmetric encryption systems have two important properties: (1) the key used for encryption is different from the one used for decryption (2) neither key can feasibly be derived from the other. (CORBA Security Services, 1997) Audit controls:

    The mechanisms employed to record and examine system activity.

    Part of technical security services to control and monitor access to information on the matrix. Authorization control:

    The mechanism for obtaining consent for the use and disclosure of health information.

    Part of technical security services to control and monitor access to information on the matrix. Automatic logoff:

    After a pre-determined time of inactivity (for example, 15 minutes), an electronic session is terminated.

    Part of entity authentication on the matrix. Availability:

    The property of being accessible and useable upon demand by an authorized entity. (ISO 7498-2, as cited in the HISB draft Glossary of Terms Related to Information Security In Health care Information Systems) Awareness training for all personnel (including management):

    All personnel in an organization should undergo security awareness training, including, but not limited to, password maintenance, incident reporting, and an education concerning viruses and other forms of malicious software.

    Part of Training on the matrix. Biometric:.

    A biometric identification system identifies a human from a measurement of a physical feature or repeatable action of the individual (for example, hand geometry, retinal scan, iris scan, fingerprint patterns, facial characteristics, DNA sequence characteristics, voice prints, and hand written signature). (ASTM E1762--95, as cited in the HISB draft Glossary of Terms Related to Information Security In Health care Information Systems)

    Part of entity authentication on the matrix. Certification:

    The technical evaluation performed as part of, and in support of, the accreditation process that establishes the extent to which a particular computer system or network design and implementation meet a pre-specified set of security requirements. This evaluation may be performed internally or by an external accrediting agency.

    Part of administrative procedures to guard data integrity, confidentiality, and availability. Chain of Trust Partner Agreement:

    Contract entered into by two business partners in which it is agreed to exchange data and that the first party will transmit information to the second party, where the data transmitted is agreed to be protected between the partners. The sender and receiver depend upon each other to maintain the integrity and confidentiality of the transmitted information. Multiple such two-party contracts may be involved in moving information from the originator to the ultimate recipient, for example, a provider may contract with a clearing house to transmit claims to the clearing house; the clearing house, in turn, may contract with another clearing house or with a payer for the further transmittal of those same claims.

    Part of administrative procedures to guard data integrity, confidentiality and availability on the matrix.. Classification:

    Protection of data from unauthorized access by the designation of multiple levels of access authorization clearances to be required for access, dependent upon the sensitivity of the information.

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

    * * * a public or private entity that processes or facilitates the processing of nonstandard data elements of health information into standard data elements. (HIPAA, Subtitle F, Section 262(a) Section 1171(2)) Combination locks changed:

    Documented procedure for changing combinations of locking mechanisms, both on a recurring basis and when personnel knowledgeable of combinations no longer have a need to know or a requirement for access to the protected facility/system.

    Part of termination procedures on the matrix. Confidentiality:

    The property that information is not made available or disclosed to unauthorized individuals, entities or processes. (ISO 7498-2, as cited in the HISB draft Glossary of Terms Related to Information Security In Health care Information Systems) . Context-based access:

    An access control based on the context of a transaction (as opposed to being based on attributes of the initiator or target). The ``external'' factors might include time of day, location of the user, strength of user authentication, etc.

    Part of access control on the matrix. Contingency Plan:

    A plan for responding to a system emergency. The plan includes performing backups, preparing critical facilities that can be used to facilitate continuity of operations in the event of an emergency, and recovering from a disaster. (O'Reilly, 1992, as cited in the HISB draft Glossary of Terms Related to Information Security In Health care Information Systems) Contingency plans should be updated routinely.

    Part of Administrative procedures to guard data integrity, confidentiality and availability on the matrix. Continuity of signature capability:

    The public verification of a signature shall not compromise the ability of the signer to apply additional secure signatures at a later date. (ASTM E 1762--95)

    [[Page 43273]]

    Part of digital signature on the matrix. Counter signatures:

    It shall be possible to prove the order of application of signatures. This is analogous to the normal business practice of countersignatures, where some party signs a document which has already been signed by another party. (ASTM E 1762 -95)

    Part of digital signature on the matrix. Data:

    A sequence of symbols to which meaning may be assigned. (NRC, 1991, as cited in the HISB draft Glossary of Terms Related to Information Security In Health care Information Systems) Data authentication:

    The corroboration that data has not been altered or destroyed in an unauthorized manner. Examples of how data corroboration may be assured include the use of a check sum, double keying, a message authentication code, or digital signature.

    Part of technical security services to control and monitor access to information on the matrix Data backup:

    A retrievable, exact copy of information.

    Part of media controls on the matrix. Data backup plan:

    A documented and routinely updated plan to create and maintain, for a specific period of time, retrievable exact copies of information.

    Part of contingency plans on the matrix. Data Integrity:

    The property that dat has [sic] not been altered or destroyed in an unauthorized manner. (ASTM E1762-95). Data storage:

    The retention of health care information pertaining to an individual in an electronic format.

    Part of media controls on the matrix. Digital signature:

    An electronic signature based upon cryptographic methods of originator authentication, computed by using a set of rules and a set of parameters such that the identity of the signer and the integrity of the data can be verified. (FDA Electronic Record; Electronic Signatures; Final Rule)

    Part of electronic signature on the matrix. Disaster recovery:

    The process whereby an enterprise would restore any loss of data in the event of fire, vandalism, natural disaster, or system failure. (CPRI, 1996c, as cited in HISB, DRAFT GLOSSARY OF TERMS RELATED TO INFORMATION SECURITY IN HEALTH CARE INFORMATION SYSTEMS draft Glossary of Terms Related to Information Security in Health Care Information Systems)

    Part of physical access controls (limited access) on the matrix. Disaster recovery plan:

    Part of an overall contingency plan. The plan for a process whereby an enterprise would restore any loss of data in the event of fire, vandalism, natural disaster, or system failure. (CPRI, 1996c, as cited in HISB, DRAFT GLOSSARY OF TERMS RELATED TO INFORMATION SECURITY IN HEALTH CARE INFORMATION SYSTEMS draft Glossary of Terms Related to Information Security in Health Care Information Systems)

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

    Discretionary Access Control (DAC) is used to control access by restricting a subject's access to an object. It is generally used to limit a user's access to a file. In this type of access control it is the owner of the file who controls other users' accesses to the file.

    A type of access control on the matrix. Disposal:

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

    Part of media controls on the matrix. Documentation:

    Written security plans, rules, procedures, and instructions concerning all components of an entity's security.

    Part of security configuration mgmt on the matrix. Electronic data interchange (EDI):

    Intercompany, computer-to-computer transmission of business information in a standard format. For EDI purists, ``computer-to- computer'' means direct transmission from the originating application program to the receiving, or processing, application program, and an EDI transmission consists only of business data, not any accompanying verbiage or free-form messages. Purists might also contend that a standard format is one that is approved by a national or international standards organization, as opposed to formats developed by industry groups or companies. (EDI Security, Control, and Audit) Electronic signature:

    The attribute that is affixed to an electronic document to bind it to a particular entity. An electronic signature process secures the user authentication (proof of claimed identity, such as by biometrics (fingerprints, retinal scans, hand written signature verification, etc.), tokens or passwords) at the time the signature is generated; creates the logical manifestation of signature (including the possibility for multiple parties to sign a document and have the order of application recognized and proven) and supplies additional information such as time stamp and signature purpose specific to that user; and ensures the integrity of the signed document to enable transportability, interoperability, independent verifiability, and continuity of signature capability. Verifying a signature on a document verifies the integrity of the document and associated attributes and verifies the identity of the signer. There are several technologies available for user authentication, including passwords, cryptography, and biometrics. (ASTM 1762-95, as cited in the HISB draft Glossary of Terms Related to Information Security In Health care Information Systems) Emergency mode operation:

    Access controls in place that enable an enterprise to continue to operate in the event of fire, vandalism, natural disaster, or system failure.

    Part of physical access controls (limited access) on the matrix. Emergency mode operation plan:

    Part of an overall contingency plan. The plan for a process whereby an enterprise would be able to continue to operate in the event of fire, vandalism, natural disaster, or system failure.

    Part of contingency plan on the matrix. Encryption:

    Transforming confidential plaintext into ciphertext to protect it. Also called encipherment. An encryption algorithm combines plaintext with other values called keys, or ciphers, so the data becomes unintelligible. Once encrypted, data can be stored or transmitted over unsecured lines. (EDI Security, Control, and Audit)

    Decrypting data reverses the encryption algorithm process and makes the plaintext available for further processing.

    Part of access control on the matrix. Entity authentication:

    1. The corroboration that an entity is the one claimed. (ISO 7498-2, as cited in the HISB draft Glossary of Terms Related to Information Security In Health care Information Systems)

    Part of technical security services to control and monitor access to information on the matrix.

    2. A communications/network mechanism to irrefutably identify authorized users, programs, and processes, and to deny access to unauthorized users, programs and processes.

    Part of mechanisms to prevent unauthorized access to data that is transmitted over a communications network on the matrix. Equipment control (into and out of site):

    Documented security procedures for bringing hardware and software into and out of a facility and for maintaining a record of that equipment. This includes, but is not limited to, the marking, handling, and disposal of hardware and storage media.

    Part of physical access controls (limited access) on the matrix. Facility security plan:

    A plan to safeguard the premises and building(s) (exterior and interior) from unauthorized physical access, and to safeguard the equipment therein from unauthorized physical access, tampering, and theft.

    Part of physical access controls (limited access) on the matrix. Formal mechanism for processing records:

    Documented policies and procedures for the routine, and non- routine, receipt, manipulation, storage, dissemination, transmission, and/or disposal of health information.

    [[Page 43274]]

    Part of administrative procedures to guard data integrity, confidentiality, and availability on the matrix. Hardware/software installation & maintenance review and testing for security features:

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

    Part of security configuration mgmt on the matrix. Independent verifiability:

    The capability to verify the signature without the cooperation of the signer. Technically, it is accomplished using the public key of the signatory, and it is a property of all digital signatures performed with asymmetric key encryption

    Part of digital signature on the matrix. Information:

    Data to which meaning is assigned, according to context and assumed conventions. (National Security Council, 1991, as cited in the HISB draft Glossary of Terms Related to Information Security In Health care Information Systems) Information access control:

    Formal, documented policies and procedures for granting different levels of access to health care information.

    Part of administrative procedures to ensure integrity and confidentiality on the matrix. Integrity controls:

    Security mechanism employed to ensure the validity of the information being electronically transmitted or stored.

    Part of mechanisms to prevent unauthorized access to data that is transmitted over a communications network on the matrix. Internal audit:

    The in-house review of the records of system activity (for example, logins, file accesses, security incidents) maintained by an organization.

    Part of administrative procedures to guard data integrity, confidentiality, and availability on the matrix. Interoperability:

    The applications used on either side of a communication, between trading partners and/or between internal components of an entity, being able to read and correctly interpret the information communicated from one to the other.

    Part of digital signature on the matrix. Inventory:

    Formal, documented identification of hardware and software assets.

    Part of security configuration mgmt on the matrix. Key:

    An input that controls the transformation of data by an encryption algorithm (NRC, 1991, as cited in the HISB draft Glossary of Terms Related to Information Security In Health care Information Systems) Maintenance of record of access authorizations:

    Ongoing documentation and review of the levels of access granted to a user, program, or procedure accessing health information.

    Part of personnel security on the matrix. Maintenance records:

    Documentation of repairs and modifications to the physical components of a facility, for example, hardware, software, walls, doors, locks.

    Part of physical access controls (limited access) on the matrix. Mandatory Access Control (MAC):

    A means of restricting access to objects that is based on fixed security attributes assigned to users and to files and other objects. The controls are mandatory in the sense that they cannot be modified by users or their programs. (Stallings, 1995) (as cited in the HISB draft Glossary of Terms Related to Information Security In Health care Information Systems)

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

    Formal, documented policies and procedures that govern the receipt and removal of hardware/software (for example, diskettes, tapes) into and out of a facility.

    Part of physical safeguards to guard data integrity, confidentiality, and availability on the matrix. Message:

    A digital representation of information. (ABA Digital Signatures Guidelines) Message authentication:

    Ensuring, typically with a message authentication code, that a message received (usually via a network) matches the message sent. (O'Reilly, 1992, as cited in the HISB draft Glossary of Terms Related to Information Security In Health care Information Systems)

    Part of mechanisms to prevent unauthorized access to data that is transmitted over a communications network on the matrix Message authentication code:

    Data associated with an authenticated message that allows a receiver to verify the integrity of the message. (Glossary of INFOSEC and INFOSEC Related Terms--Idaho State University) Message integrity:

    The assurance of unaltered transmission and receipt of a message from the sender to the intended recipient. (ABA Digital Signature Guidelines)

    Part of digital signature on the matrix. Multiple signatures:

    It shall be possible for multiple parties to sign a document. Multiple signatures are conceptually, simply appended to the document. (ASTM E 1762-95)

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

    A security principle stating that a user should have access only to the data he or she needs to perform a particular function. (O'Reilly, 1992, as cited in the HISB draft Glossary of Terms Related to Information Security In Health care Information Systems)

    Part of physical access controls (limited access) on the matrix. Nonrepudiation:

    Strong and substantial evidence of the identity of the signer of a message and of message integrity, sufficient to prevent a party from successfully denying the origin, submission or delivery of the message and the integrity of its contents. (ABA Digital Signature Guidelines)

    Part of digital signature on the matrix. Operating, and in some cases, maintenance personnel have proper access authorizations:

    Formal, documented policies and procedures to be followed in determining the access level to be granted to individuals working on, or in the vicinity of, health information.

    Part of personnel security on the matrix. Password:

    Confidential authentication information composed of a string of characters. (ISO 7498--2, as cited in the HISB draft Glossary of Terms Related to Information Security In Health care Information Systems)

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

    Employees, agents and contractors should be made aware of security concerns on an ongoing basis.

    Part of training on the matrix. Personnel clearance procedure:

    A protective measure applied to determine that an individual's access to sensitive unclassified automated information is admissible. The need for and extent of a screening process is normally based on an assessment of risk, cost, benefit, and feasibility as well as other protective measures in place. Effective screening processes are applied in such a way as to allow a range of implementation, from minimal procedures to more stringent procedures commensurate with the sensitivity of the data to be accessed and the magnitude of harm or loss that could be caused by the individual (DOE 1360.2A, as cited in Glossary of INFOSEC and INFOSEC Related Terms--Idaho State University)

    Part of personnel security on the matrix. Personnel security:

    The procedures established to ensure that all personnel who have access to sensitive information have the required authority as well as appropriate clearances. (NCSC Glossary of Computer Security Terms, October 21, 1988)

    Part of administrative procedures to guard data integrity, confidentiality and availability on the matrix. Personnel security policy/procedure:

    Formal, documentation of policies and procedures established to ensure that all personnel who have access to sensitive information have the required authority as well as appropriate clearances. (Glossary of INFOSEC and INFOSEC Related Terms--Idaho State University)

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

    Those formal, documented policies and procedures to be followed to limit

    [[Page 43275]]

    physical access to an entity while ensuring that properly authorized access is allowed.

    Part of Physical safeguards to guard data integrity, confidentiality, and availability on the matrix. Physical safeguards:

    Protection of physical computer systems and related buildings and equipment from fire and other natural and environmental hazards, as well as from intrusion. Also covers the use of locks, keys, and administrative measures used to control access to computer systems and facilities. (O'Reilly, 1992, as cited in HISB, draft Glossary of Terms Related to Information Security in Health Care Information Systems)

    A section of the matrix covering physical security requirements. PIN (Personal Identification Number):

    A number or code assigned to an individual and used to provide verification of identity.

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

    Documented instructions/procedures delineating the proper functions to be performed, the manner in which those functions are to be performed, and the physical attributes of the surroundings, of a specific computer terminal site or type of site, dependant upon the sensitivity of the information accessed from that site.

    Part of Physical safeguards to guard data integrity, confidentiality, and availability on the matrix. Procedure for emergency access:

    Documented instructions for obtaining necessary information during a crisis.

    Part of access control on the matrix. Procedures for verifying access authorizations prior to physical access:

    Formal, documented policies and instructions for validating the access privileges of an entity prior to granting those privileges.

    Part of physical access controls (limited access) on the matrix. Provider:

    A supplier of services as defined in section 1861(u) of the HIPAA.

    A supplier of medical or other services as defined in section 1861(s) of the HIPAA. Public key:

    One of the two keys used in an asymmetric encryption system. The public key is made public, to be used in conjunction with a corresponding private key. [Stallings, 1995] Removal from access lists:

    The physical eradication of an entity's access privileges.

    Part of termination procedures on the matrix. Removal of user account(s):

    The termination or deletion of an individual's access privileges to the information, services, and resources for which they currently have clearance, authorization, and need-to-know when such clearance, authorization and need-to-know no longer exists.

    Part of termination procedures on the matrix. Report procedures:

    The documented formal mechanism employed to document security incidents.

    Part of security incident procedures on the matrix. Response procedures:

    The documented formal rules/instructions for actions to be taken as a result of the receipt of a security incident report.

    Part of security incident procedures on the matrix. Risk analysis:

    Risk analysis, a process whereby cost-effective security/control measures may be selected by balancing the costs of various security/ control measures against the losses that would be expected if these measures were not in place.

    Part of the security management process on the matrix. Risk management:

    Risk is the possibility of something adverse happening. Risk management is the process of assessing risk, taking steps to reduce risk to an acceptable level and maintaining that level of risk. (NIST Pub. 800-14)

    Part of the security management process on the matrix. Role-based access control:

    Role-based access control (RBAC) is an alternative to traditional access control models (e.g., discretionary or non- discretionary access control policies) that permits the specification and enforcement of enterprise-specific security policies in a way that maps more naturally to an organization's structure and business activities. With RBAC, rather than attempting to map an organization's security policy to a relatively low-level set of technical controls (typically, access control lists), each user is assigned to one or more predefined roles, each of which has been assigned the various privileges needed to perform that role.

    Part of access control on the matrix.

    Part of authorization control on the matrix. Sanction policy:

    Organizations must have policies and procedures regarding disciplinary actions which are communicated to all employees, agents and contractors, for example, verbal warning, notice of disciplinary action placed in personnel files, removal of system privileges, termination of employment and contract penalties (ASTM E 1869)

    In addition to enterprise sanctions, employees, agents, and contractors must be advised of civil or criminal penalties for misuse or misappropriation of health information. Employees, agents and contractors, must be made aware that violations may result in notification to law enforcement officials and regulatory, accreditation and licensure organizations. (ASTM)

    Part of the security management process on the matrix. Secure work station location:

    Physical safeguards to eliminate or minimize the possibility of unauthorized access to information, for example, locating a terminal used to access sensitive information in a locked room and restricting access to that room to authorized personnel, not placing a terminal used to access patient information in any area of a doctor's office where the screen contents can be viewed from the reception area.

    Part of physical safeguards to guard data integrity, confidentiality, and availability on the matrix. Security:

    Security encompasses all of the safeguards in an information system, including hardware, software, personnel policies, information practice policies, disaster preparedness, and the oversight of all these areas. The purpose of security is to protect both the system and the information it contains from unauthorized access from without and from misuse from within.

    Through various security measures, a health information system can shield confidential information from unauthorized access, disclosure and misuse, thus protecting privacy of the individuals who are the subjects of the stored data. (Privacy and Health Information Systems: A Guide to Protecting Patient Confidentiality) Security awareness training:

    All employees, agents, and contractors must participate in information security awareness training programs. Based on job responsibilities, individuals may be required to attend customized education programs that focus on issues regarding use of health information and responsibilities regarding confidentiality and security. (ASTM)

    Part of Physical safeguards to guard data integrity, confidentiality, and availability on the matrix. Security configuration management:

    Measures, practices and procedures for the security of information systems should be coordinated and integrated with each other and other measures, practices and procedures of the organization so as to create a coherent system of security. (OECD Guidelines, as cited in NIST Pub 800-14)

    Part of administrative procedures to guard data integrity, confidentiality, and availability on the matrix. Security incident procedures:

    Formal, documented instructions for reporting security breaches.

    Part of administrative procedures to guard data integrity, confidentiality and availability on the matrix. Security management process:

    A security management process encompasses the creation, administration and oversight of policies to ensure the prevention, detection, containment, and correction of security breaches. It involves risk analysis and risk management, including the establishment of accountability, management controls (policies and education), electronic controls, physical security, and penalties for the abuse and misuse of its assets, both physical and electronic.

    [[Page 43276]]

    Part of administrative procedures to guard data integrity, confidentiality and availability on the matrix. Security policy:

    The framework within which an organization establishes needed levels of information security to achieve the desired confidentiality goals. A policy is a statement of information values, protection responsibilities, and organization commitment for a system. (OTA, 1993) The American Health Information Management Association recommends that security policies apply to all employees, medical staff members, volunteers, students, faculty, independent contractors, and agents. (AHIMA, 1996c) (as cited in HISB, DRAFT GLOSSARY OF TERMS RELATED TO INFORMATION SECURITY IN HEALTH CARE INFORMATION SYSTEMS draft Glossary of Terms Related to Information Security in Health Care Information Systems )

    Part of the security management process on the matrix Security testing:

    A process used to determine that the security features of a system are implemented as designed and that they are adequate for a proposed applications environment. This process includes hands-on functional testing, penetration testing, and verification. (Glossary of INFOSEC and INFOSEC Related Terms--Idaho State University)

    Part of security configuration mgmt on the matrix. Sign-in for visitors and escort, if appropriate:

    Formal, documented procedure governing the reception and hosting of visitors.

    Part of physical access controls (limited access) on the matrix. Subject/object separation:

    Access to a subject does not guarantee access to the objects associated with that subject.

    Subject is defined as an active entity, generally in the form of a person, process, or device that causes information to flow among objects or changes the system state. Technically, a process/domain pair. (Glossary of INFOSEC and INFOSEC Related Terms--Idaho State University)

    Object is defined as a passive entity that contains or receives information. Access to an object potentially implies access to the information it contains. Examples of objects are: records blocks, pages, segments, files, directories, directory trees, and programs, as well as bits, bytes, words, fields, processors, video displays, keyboards, clocks, printers, network nodes, etc. (Glossary of INFOSEC and INFOSEC Related Terms--Idaho State University)

    A type of access control. System users, including maintenance personnel, trained in security:

    See Awareness training (including management).

    Part of personnel security on the matrix. Technical security mechanisms:

    The processes that are put in place to guard against unauthorized access to data that is transmitted over a communications network,

    A section of the matrix. Technical security services:

    The processes that are put in place (1) to protect information and (2) to control and monitor individual access to information.

    A section of the matrix. Telephone callback:

    A method of authenticating the identity of the receiver and sender of information through a series of ``questions'' and ``answers'' sent back and forth establishing the identity of each. For example, when the communicating systems exchange a series of identification codes as part of the initiation of a session to exchange information, or when a host computer disconnects the initial session before the authentication is complete, and the host calls the user back to establish a session at a predetermined telephone number.

    Part of Entity authentication on the matrix. Termination procedures:

    Formal, documented instructions, which include appropriate security measures, for the ending of an employee's employment, or an internal/external user's access.

    Part of administrative procedures to guard data integrity, confidentiality and availability on the matrix. Testing and revision:

    (1) Testing and revision of contingency plans refers to the documented process of periodic testing to discover weaknesses in such plans and the subsequent process of revising the documentation if necessary.

    Part of contingency plan on the matrix.

    (2) Testing and revision of programs should be restricted to formally authorized personnel.

    Part of physical access controls (limited access) on the matrix. Time-of-day:

    Access to data is restricted to certain time frames, e.g., Monday through Friday, 8:00 a.m. to 6:00 p.m.

    A type of access control on the matrix. Time-stamp:

    To create a notation that indicates, at least, the correct date and time of an action, and the identity of the person that created the notation. Token:

    A physical item that's used to provide identity. Typically an electronic device that can be inserted in a door or a computer system to obtain access. (O'Reilly, 1992) (as cited in HISB, DRAFT GLOSSARY OF TERMS RELATED TO INFORMATION SECURITY IN HEALTH CARE INFORMATION SYSTEMS draft Glossary of Terms Related to Information Security in Health Care Information Systems)

    Part of entity authentication on the matrix Training:

    Education concerning the vulnerabilities of the health information in an entity's possession and ways to ensure the protection of that information.

    Part of administrative procedures to guard data integrity, confidentiality and availability on the matrix. Transportability:

    A signed document can be transported (over an insecure network) to another system, while maintaining the integrity of the document.

    Part of digital signature on the matrix. Turn in keys, token or cards that allow access:

    Formal, documented procedure to ensure all physical items that allow a terminated employee to access a property, building, or equipment are retrieved from that employee, preferably prior to termination.

    Part of termination procedures on the matrix. Unique user identification:

    The combination name/number assigned and maintained in security procedures for identifying and tracking individual user identity. (ASTM)

    Part of Entity authentication on the matrix. User authentication:

    The provision of assurance of the claimed identity of an entity. (ASTM E1762-5)

    Part of digital signature on the matrix. User-based access:

    A security mechanism used to grant users of a system access based upon the identity of the user.

    Part of access control on the matrix.

    Part of authorization control on the matrix. User education in importance of monitoring log in success/failure, and how to report discrepancies:

    Training in the user's responsibility to ensure the security of health care information.

    Part of training on the matrix. User education concerning virus protection:

    Training relative to user awareness of the potential harm that can be caused by a virus, how to prevent the introduction of a virus to a computer system, and what to do if a virus is detected.

    Part of training on the matrix. User education in password management:

    A type of user training in the rules to be followed in creating and changing passwords and the need to keep them confidential.

    Part of training on the matrix. Virus checking:

    A computer program that identifies and disables:

    (1) another ``virus'' computer program, typically hidden, that attaches itself to other programs and has the ability to replicate. (Unchecked virus programs result in undesired side effects generally unanticipated by the user.)

    (2) A type of programmed threat. A code fragment (not an independent program) that reproduces by attaching to another program. It may damage data directly, or it may degrade system performance by taking over system resources which are then not available to authorized users. (O'Reilly, 1992, as cited in HISB, DRAFT GLOSSARY OF TERMS RELATED TO INFORMATION SECURITY IN HEALTH CARE INFORMATION SYSTEMS draft Glossary of Terms Related to Information

    [[Page 43277]]

    Security in Health Care Information Systems)

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

    Part of security configuration mgmt on the matrix.

    Acronyms

    ABA American Bar Association ADA American Dental Association ANSI American National Standards Institute AHIMA American Health Information Management Association ASTM American Society for Testing and Materials CDT Center for Democracy & Technology CEN Central European Nations CORBA Common Object Request Broker CPRI Computer-based Patient Record Institute DAC Discretionary Access Control DEA Data Encryption Algorithm EDI Electronic Data Interchange EHNAC Electronic Healthcare Network Accreditation Commission FDA Food and Drug Administration HISB Health Care Informatics Standards Board ISO International Organization for Standardization MAC Mandatory Access Control NCSC National Computer Security Center NCQA National Council for Quality Assurance NCVHS National Committee on Vital and Health Statistics NUBC National Uniform Billing Committee NUCC National Uniform Claim Committee PGP Pretty Good Privacy PIN Personal Identification Number NIST National Institutes of Standards and Technology SDO Standards Development Organization WEDI Workgroup for Electronic Data Interchange

    Bibliography

    ABA, Digital Signature Guidelines. ANSI, ASC X12.58, Security Structures, June, 1997. ASTM, E1762-95, Standard Guide for Electronic Authentication of Health Care Information. ASTM Committee E-31 on Computerized Systems, Subcommittee E31.20 on Authentication. West Conshohocken, PA, October 10, 1995. ASTM, A Security Framework for Healthcare Information. ASTM Committee E-31 on Computerized Systems, Subcommittee E31.20 on Authentication. West Conshohocken, PA, February 11, 1997. EDI Security, Control, and Audit, Marcells, Albert J. & Chan, Sally. Artech House, 685 Canton Street, Norwood, MA 01602, 1993. FDA, Electronic Record; Electronic Signatures; Final Rule. For the Record--Protecting Electronic Health Information, Computer Science and Telecommunications Board, NRC, National Academy Press, 2102 Constitution Avenue, NW, Box 285, Washington, DC, 20055, 1997. Glossary of INFOSEC and INFOSEC Related Terms, Version 6. Schou, Corey D., Center for Decision Support, Idaho State University. August, 1996 HISB, DRAFT GLOSSARY OF TERMS RELATED TO INFORMATION SECURITY IN HEALTH CARE INFORMATION SYSTEMS Glossary of Terms Related to Information Security in Health Care Information Systems draft, 1997 NCSC, Glossary of Computer Security Terms, October 21, 1988. NIST Pub 800-14, ``Generally Accepted Principles and Practices for Securing Information Technology Systems'', Swanson, Marianne, & Guttman, Barbara, September, 1996. PGP, Inc., Cryptology Reference Chart, August, 1997 Privacy and Health Information Systems: A Guide to Protecting Patient Confidentiality, Goldman, Janlori & Mulligan, Deirdre, CDT, 1996.

    Addendum 3

    HIPAA SECURITY MATRIX--mapping

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

    Administrative Procedures To Guard Data Integrity, Confidentiality, and Availability

    Requirement

    Implementation Mapped standards

    Certification............... .................... 47.

    Chain of trust partner

    .................... 12, 47.

    agreement.

    Contingency plan (all listed Applications and 17, 47, 53.

    implementation features data criticality 12, 17, 47.

    must be implemented).

    analysis.

    12, 17, 47, 53. Data backup plan.... 47, 53.

    Disaster recovery 12, 17, 47.

    plan.

    Emergency mode

    operation plan.

    Testing and revision

    Formal mechanism for

    .................... 12, 17.

    processing records.

    Information access control Access authorization 12, 17, 47, 53. (all listed implementation Access establishment 17, 47, 53.

    features must be

    Access modification. 12, 17, 47, 53. implemented).

    Internal audit.............. .................... 12, 17, 43, 44, 47. Personnel security (all Assure supervision 17, 47.

    listed implementation of maintenance

    features must be

    personnel by

    implemented)

    authorized,

    knowledgeable

    person.

    Maintainance of 12, 17, 47.

    record of access

    authorizations.

    Operating, and in 17, 47.

    some cases,

    maintenance

    personnel have

    proper access

    authorization.

    Personnel clearance 17, 47.

    procedure.

    Personnel security 17, 47, 53.

    policy/procedure.

    System users,

    12, 17, 47, 53. including

    maintenance

    personnel, trained

    in security.

    Security configuration mgmt. Documentation....... 12, 17, 47, 53. (all listed implementation

    features must be

    implemented).

    Hardware/software 12, 17, 47.

    installation &

    maintenance review

    and testing for

    security features.

    Inventory........... 12, 17.

    Security testing.... 12, 17, 47.

    Virus checking...... 12, 17, 47, 53. Security incident procedures Report procedures... 12, 17, 47.

    (all listed implementation Response procedures. 17, 47.

    features must be

    implemented).

    [[Page 43278]]

    Security management process Risk analysis....... 12, 17, 47, 53. (all listed implementation Risk management..... 17, 47.

    features must be

    Sanction policy..... 12, 17, 47, 53. implemented).

    Security policy..... 17, 47, 53.

    Termination procedures (all Combination locks 12, 17.

    listed implementation

    changed.

    12, 17, 47, 53. features must be

    Removal from access 12, 17, 47.

    implemented).

    lists.

    12, 17, 47.

    Removal of user

    account(s).

    Turn in keys, token

    or cards that allow

    access.

    Training (all listed

    Awareness training 12, 17, 18, 47, 53. implementation features for all personnel

    must be implemented).

    (including mgmt).

    Periodic security 12, 18.

    reminders.

    User education

    .................... concerning virus

    protection.

    User education in 12, 17, 18.

    importance of

    monitoring log in

    success/failure,

    and how to report

    discrepancies.

    User education in 12, 18, 47

    password management.

    Physical Safeguards To Guard Data Integrity, Confidentiality, and Availability

    Requirement

    Implementation Mapped standards

    Assigned security

    .................... 47.

    responsibility.

    Media controls (all listed Access control...... 17, 47, 53.

    implementation features Accountability

    17, 18, 47.

    must be implemented).

    (tracking

    12, 17, 47, 53. mechanism).

    12, 17, 47.

    Data backup......... 17, 47, 53.

    Data storage........

    Disposal............

    Physical access controls Disaster recovery... 17.

    (limited access) (all

    Emergency mode

    17.

    listed implementation

    operation.

    17, 47.

    features must be

    Equipment control 12, 17, 47.

    implemented).

    (into and out of

    site).

    Facility security

    plan.

    Procedures for

    17, 18, 47.

    verifying access

    authorizations

    prior to physical

    access.

    Maintenance records. 17

    Need-to-know

    12, 17, 47, 53 procedures for

    personnel access.

    Sign-in for visitors 17

    and escort, if

    appropriate.

    Testing and revision 17, 47

    Policy/guideline on work .................... 18.

    station use.

    Secure work station location .................... 17, 53.

    Security awareness training. .................... 12, 17, 47.

    Technical Security Services To Guard Data Integrity, Confidentiality, and Availability

    Requirement

    Implementation Mapped standards

    Access control (The

    Context-based

    5, 12, 14, 16, 17, following implementation access,.

    40, 47.

    feature must be

    Encryption.......... 1, 6, 12, 14, 17, implemented: Procedure for

    21, 22, 23, 24, 26, emergency access, In

    Procedure for

    36, 28, 29, 30, 31, addition, at least one of emergency access. 47, 49, 53, 54, 55. the following three

    Roll-based access,.. 14, 17, 53.

    implementation features User-based access... 14, 16, 17, 40, 41, must be implemented:

    47, 53.

    Context-based access, Roll-

    11, 12, 14, 16, 17, based access, User-based

    40, 41, 47, 53.

    access. The use of

    Encryption is optional).

    Audit controls.............. .................... 12, 14, 18, 47, 53. Authorization control (At Role-based access... 5, 14, 16, 17, 47, least one of the listed User-based access... 53.

    implementation features

    14, 16, 47, 53. must be implemented).

    Data authentication......... .................... 11, 53.

    Entity Authentication (The Automatic logoff.... 14, 16, 17, 18, 40, following implementation Biometric........... 53

    features must be

    Password............ 14, 16, 18, 40, 47, implemented: Automatic PIN................. 53.

    logoff, Unique user

    Telephone callback.. 14, 16, 17, 18, 19, identification. In

    Token............... 40, 47, 53.

    addition, at least one of Unique user

    14, 16, 18, 19, 40, the other listed

    identification. 47.

    implementation features

    14, 17, 18, 47, 53. must be implemented).

    14, 17, 47, 50, 53. 14, 47, 53.

    [[Page 43279]]

    Technical Security Mechanisms To Guard Data Integrity, Confidentiality, and Availability

    Requirement

    Implementation Mapped standards

    Communications/network

    Access controls..... 14, 17, 22, 23, 39, controls (If communications Alarm, event

    47, 48, 53.

    or networking is employed, reporting, and 14, 17, 18, 35, 36, the following

    audit trail.

    37, 38, 44.

    implementation features Audit trail

    must be implemented:

    Encryption.......... 1, 6, 12, 14, 17, Integrity controls, Message

    21, 22, 23, 24, 26, authentication. In

    Entity

    27, 28, 29, 30, 31, addition, one of the

    authentication. 47, 49, 52, 53.

    following implementation

    12, 14, 17, 18, 20, features must be

    Event reporting

    22, 23, 31, 32, 33, implemented: Access

    Integrity controls.. 34, 51, 53.

    controls, Encryption. In Message

    addition, if using a

    authentication. 14, 15, 17, 18, 22, network, the following four

    23, 45, 46.

    implementation features

    14, 15, 17, 18, 22, must be implemented: Alarm,

    23, 25, 45, 46, 52. Audit trail, Entity

    authentication, Event

    reporting).

    Electronic Signature

    Requirement

    Implementation Mapped standards

    Digital signature (If

    Ability to add

    3, 4, 10, 11, 13, 20 digital signature is

    attributes.

    3, 4, 11, 13, 14, 18 employed, the following Continuity of

    3, 4, 10, 11, 13, three implementation

    signature

    14, 18

    features must be

    capability.

    3, 4, 11, 13, 20

    implemented: Message

    Counter signatures.. 3, 4, 7, 8, 9, 13, integrity, Non-repudiation, Independent

    14, 48

    User authentication. Other verifiability. 3, 4, 10, 11, 13, implementation features are Interoperability.... 14, 18

    optional).

    Message integrity... 3, 4, 10, 11, 13, 20 Multiple signatures. 2, 3, 4, 10, 11, 13, Non-repudiation..... 14, 42

    Transportability.... 3, 4, 11, 13, 14, 18 User authentication. 3, 4, 10, 11, 13, 20

    Mapped Standards

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

    [[Page 43280]]

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

    [FR Doc. 98-21601Filed8-7-98; 1:23 pm]

    BILLING CODE 4120-01-P

VLEX uses login cookies to provide you with a better browsing experience. If you click on 'Accept' or continue browsing this site we consider that you accept our cookie policy. ACCEPT