In this proposed rule, the requirements and implementation features for technical security mechanisms are presented at § 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.
|Communications/network controls (If communications or networking is employed, the following implementation features must be implemented: Integrity controls, Message authentication. In addition, one of the following implementation features must be implemented: Access controls, Encryption. In addition, if using a network, the following four implementation features must be implemented: Alarm, Audit trail, Entity authentication, Event reporting).||Access controls.
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:
One of the following implementation features would be in place:
In addition, if using a network for communications, the following implementation features would be in place:
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 offices 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 persons 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 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.