NRPM: Security and Electronic Signature Standards. Security Standard


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

Section 142.308 would set forth the security standard. There is no recognized single standard that integrates all the components of security (administrative procedures, physical safeguards, technical security services, and technical mechanisms) that must be in place to preserve health information confidentiality and privacy as defined in the law. Therefore, we are designating a new, comprehensive standard, which defines the security requirements to be fulfilled.

In fact, there are numerous security guidelines and standards in existence today, focusing on the different techniques available for implementing the various aspects of security. We thoroughly researched the existing guidelines and standards, and consulted extensively with the organizations that developed them. A list of the organizations with which we consulted can be found in section G. below. As a result of these consultations and our research, we identified several high-level concepts on which the standard is based:

  • The standard must be comprehensive.
  • Consultation with standards development organizations, such as ANSI-accredited organizations, as well as business interest organizations, revealed the need for a standard that addressed all aspects of security in a concerted fashion. The HISB noted in its report to the Secretary that:

"Comprehensive adoption of security standards in health care, not piecemeal implementation, is advocated to provide security to data that is exchanged between health care entities.

By definition, if a system or communications between two systems, were implemented with technology(s) meeting standards in a general system security framework (Identification and Authentication; Authorization and Access Control; Accountability; Integrity and Availability; Security of Communication; and Security Administration.) that system would be essentially secure.

* * * no single standards development organization (SDO) is addressing all aspects of health care information security and confidentiality, and specifically, no single SDO is developing standards that cover every category of the security framework." [Page 189]

  • The standard must be technology-neutral.

Our proposed standard does not reference or advocate specific technology because security technology is changing quickly. We want to give providers/plans/clearinghouses flexibility to choose their own technical solutions. A standard that is dependent on a specific technology or technologies would not be flexible enough to use future advances.

  • The standard must be scalable.

The standard must be able to be implemented by all the affected entities, from the smallest provider to the largest clearinghouse. A single approach would be neither economically feasible nor effective in safeguarding health data. For example, in a small physician practice, a contingency plan for system emergencies might be only a few pages long, and cover issues such as where backup diskettes must be stored, and the location of a backup personal computer (PC). At a large health plan, the contingency plan might consist of multiple volumes and cover issues such as remote hot site operations and secure off-site storage of electronic media. The physician office solution would not protect the large plan’s data, and the plan’s solution would not be economically feasible (or necessary) for the physician office. Moreover, the statute specifically directed the Secretary to take into account the needs and capabilities of small and rural health care providers, as those terms are defined by the Secretary. The scalability of our approach addresses this direction. We are not proposing specific definitions of "small" and "rural" health care providers because the statute provides no exemptions or special benefits for these two groups. However, we solicit comments on the necessity to define these terms.

General Approach

We would define the security standard as a set of requirements with implementation features that providers, plans, and clearinghouses must include in their operations to assure that electronic health information pertaining to an individual remains secure. The implementation features address specific aspects of the requirements. The standard does not reference or advocate specific technology. This would allow the security standard to be stable, yet flexible enough to take advantage of state-of-the-art technology. The standard does not address the extent to which a particular entity should implement the specific features. Instead, we would require that each affected entity assess its own security needs and risks and devise, implement, and maintain appropriate security to address its business requirements. How individual security requirements would be satisfied and which technology to use would be business decisions that each organization would have to make.

The recommendations contained in the National Research Council's 1997 report For The Record: Protecting Electronic Health Information support our approach to the development of a security standard. This report presents findings and recommendations related to health data security, and is widely viewed as an authoritative and comprehensive source on the subject. The report concludes that appropriate security practices are highly dependent on individual circumstances, but goes on to suggest that:

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

The specific requirements and supporting implementation features detailed in the next section represent this general set of practices. Many health care entities have already implemented some or all of these practices. We believe they represent those practices that are necessary in order to conduct business electronically in the health care industry today and, therefore, are normal business costs.

Inherent in this approach is a balance between the need to secure health data against risk and the economic cost of doing so. Health care entities must consider both aspects in devising their security solutions.

Specific Requirements

The proposed standard requires that each health care entity engaged in electronic maintenance or transmission of health information assess potential risks and vulnerabilities to the individual health data in its possession in electronic form, and develop, implement, and maintain appropriate security measures. Most importantly, these measures must be documented and kept current.

The proposed security standard consists of the requirements that a health care entity must address in order to safeguard the integrity, confidentiality, and availability of its electronic data. It also describes the implementation features that must be present in order to satisfy each requirement. The proposed requirements and implementation features were developed by the implementation team based on knowledge of security procedures and existing standards and guidelines described above. This was an iterative process that involved extensive outreach with a number of health care industry and Department of Commerce security experts. We also drew upon Recommendations 1 and 3 in the National Research Council’s 1997 report, For The Record, that were recommended for immediate implementation.

"Recommendation 1: All organizations that handle patient-identifiable health care information--regardless of size--should adopt the set of technical and organizational policies, practices, and procedures described below to protect such information."

The proposed security standard addresses the following policies, practices, and procedures that were listed under Recommendation 1:

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

"Recommendation 3: The federal government should work with industry to promote and encourage an informed public debate to determine an appropriate balance between the primary concerns of patients and the information needs of various users of health care information."

This proposed security standard was developed in the spirit of Recommendation 3. The security standard development process has been an open one with invitations to a number of organizations to participate in the security discussions. Although implementation team membership was limited to government employees, nongovernmental organizations; business organizations; individuals knowledgeable in security; and educational institutions have been encouraged to express their views.

As a result of the collaborative security regulation development process, the implementation team has chosen to divide the proposed security requirements, for purposes of presentation only, into the following four categories:

  • Administrative procedures to guard data integrity, confidentiality, and availability - these are documented, formal practices to manage the selection and execution of security measures to protect data and the conduct of personnel in relation to the protection of data.
  • Physical safeguards to guard data integrity, confidentiality, and availability - these relate to the protection of physical computer systems and related buildings and equipment from fire and other natural and environmental hazards, as well as from intrusion. Physical safeguards also cover the use of locks, keys, and administrative measures used to control access to computer systems and facilities.
  • Technical security services to guard data integrity, confidentiality, and availability - these include the processes that are put in place to protect and to control and monitor information access, and
  • Technical security mechanisms - these include the processes that are put in place to prevent unauthorized access to data that is transmitted over a communications network.

It should be noted that the only necessity is that the requirements would be met, not that they be presented in these four categories. Under this proposed rule, a business entity could choose to order the requirements in any manner that suits its business.

We then determined the requirements and implementation features that health plans, providers, and clearinghouses would implement. The implementation features describe the requirements in greater detail. Some requirements do not require this additional level of detail. Within the four categories, the requirements and implementation features are presented in alphabetical order to ensure that no one item is considered to be more important than another. The relative importance of the requirements and implementation features would depend on the characteristics of each organization.

The four categories of the matrix are described in greater detail in § 142.308 and are depicted in tabular form along with the electronic signature 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 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.