Electronic Record Keeping: Achieving and Maintaining Compliance with 21 CFR Part 11 and 45 CFR Parts 160, 162, and 164

Electronic Record Keeping Achieving and Maintaining Compliance with 21 CFR Part 11 and 45 CFR Parts 160, 162 and 164 Da...

Author: David Nettleton Janet Gough

338 downloads 1015 Views 10MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Electronic Record Keeping Achieving and Maintaining Compliance with 21 CFR Part 11 and 45 CFR Parts 160, 162 and 164

David Nettleton Janet Gough

Interpharm /CRC Boca Raton London New York Washington, D.C.

Copyright © 2004 CRC Press, LLC

PH2164_C00.fm Page 2 Wednesday, November 19, 2003 2:52 PM

Library of Congress Cataloging-in-Publication Data Nettleton, David, 1963– Electronic record keeping: achieving and maintaining compliance wih 21 CFR Part 11 and 45 CFR parts 160, 162, and 164 / David Nettleton, Janet Gough. p. cm. Includes bibliographical references and index. ISBN 0-8493-2164-6 (alk. paper) 1. Medical records--Law and legislation--United States. 2. Medical records--Automation. 3. Medical records--Data processing. I. Gough, Janet. II. Title. KF3827.R4N48 2003 070.5’797--dc22 2003055694

This book contains information obtained from authentic and highly regarded sources. Reprinted material is quoted with permission, and sources are indicated. A wide variety of references are listed. Reasonable efforts have been made to publish reliable data and information, but the author and the publisher cannot assume responsibility for the validity of all materials or for the consequences of their use. Neither this book nor any part may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, microÞlming, and recording, or by any information storage or retrieval system, without prior permission in writing from the publisher. The consent of CRC Press LLC does not extend to copying for general distribution, for promotion, for creating new works, or for resale. SpeciÞc permission must be obtained in writing from CRC Press LLC for such copying. Direct all inquiries to CRC Press LLC, 2000 N.W. Corporate Blvd., Boca Raton, Florida 33431. Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identiÞcation and explanation, without intent to infringe.

Visit the CRC Press Web site at www.crcpress.com © 2004 by CRC Press LLC No claim to original U.S. Government works International Standard Book Number 0-8493-2164-6 Library of Congress Card Number 2003055694 Printed in the United States of America 1 2 3 4 5 6 7 8 9 0 Printed on acid-free paper



Introduction It has been said that the only static element is change. So it is in business. Technology becomes available and industry seeks to embrace it. The rules and regulations evolve commensurately. Proposed regulations and Þnal rules about electronic record keeping that apply to food, drug, medical devices and biologic businesses and healthcare management require companies to achieve and maintain compliance. This is a formidable task, but it need not be onerous. This book provides guidance for purchasing, installing, validating and managing commercial off-the-shelf (COTS) software for data collection and retention. Title 21 of the Code of Federal Regulations (CFR) Part 11, Electronic records; electronic signatures and the new Health Insurance Portability and Accountability Act (HIPAA) regulations 45 CFR Parts 160, 162 and 164 that were signed into law in early 2003 spell out essentially the same requirements, and, in fact, 21 CFR Part 11, which was signed into law in 1997, provides the paradigm for the new HIPAA regulations. Companies already familiar with the 21 CFR Part 11 requirements can build on that knowledge to comply with HIPAA requirements. We are currently experiencing a revolution in software, and the regulations have evolved to address the increasingly sophisticated software on the market worldwide. More and more, companies are turning to off-the-shelf software for electronic record keeping. Electronic record keeping, also known as electronic data capture (EDC), entails collecting or acquiring data as a permanent electronic record with or without a human interface, such as using data collection systems or applications that are modem based or Web based, use optical mark/character recognition or employ audio text, interactive voice response, graphical interfaces, clinical laboratory interfaces or touch screens. The word “permanent” here means that changes made to electronic data are recorded in an audit trail. To maintain the integrity of the record, an audit trail and controlled security are imperative. The bottom line is this: people using data from computerized systems must have conÞdence in the integrity of their data, and data entered into electronic systems must be as reliable, if not more so, than data captured in paper form. Security and accountability are big factors in data integrity, and this book discusses security measures and how to manage passwords. Finally, since the audit function has long been a part of FDA regulations but can be new to many facilities that are subject to the newer HIPAA regulations, the book presents a summary of an effective audit function. It also offers guidance in training people in the electronic systems and preparing supporting documentation. Note that the HIPAA regulations that have been in place since 1996 are extensive. These regulations are related to healthcare, labor and beneÞts, and reside in the CFR, Titles 26, 29, 42 and 45. This book addresses only those regulations recently passed into Þnal rule related to electronic record keeping. A primary purpose of 45 CFR



Parts 160, 162 and 164 is to reduce paperwork — and the projection is that the new regulations will do so by 25 percent. Accomplishing this should signiÞcantly reduce costs.

UPPER MANAGEMENT COMMITMENT Once a company determines to employ electronic record keeping, it is important that upper management understand what is involved in going electronic. Management may not fully understand what installing electronic record keeping systems entails and therefore may not allocate the appropriate resources for all the activities that must occur to make and keep a company compliant. Thus, those folks who actually plan to purchase, install, validate and document an electronic record keeping system and conduct user training for it must be adept at conveying what’s involved, so that the system can receive proper support both in terms of capital and time allotment, and ultimately do the job for which it is intended. To be overly frugal with resources at this stage will surely prove costly going forward. Further, electronic record keeping requires top-down support because electronic record keeping systems are tools that serve to drive the operation forward. To avoid going down the electronic path is akin to setting limits on the operation. Without electronic record keeping, a company can fall far behind its competitors and lose the cutting edge. Embracing it now will keep the operation poised to grow effectively. And ultimately, electronic record keeping will translate into better records, fewer problems and cost-effective operation — provided it’s put in place correctly.



Authors David Nettleton is a 21 CFR Part 11, HIPAA, and Computer System Validation consultant involved with the development, purchase, installation, operation and maintenance of computerized systems used in regulated applications. Services include gap analysis, remediation plans, SOP development, vendor audits, training, and project management. He has completed more than 120 computer system validation projects for mission critical applications involving blood bank, clinical trial, corrective action, document control, electronic data capture, Excel spreadsheets developed for regulated applications, Internet billing, laboratory instruments, laboratory information management, manufacturing, enterprise resource planning, medical device software, MRI software, nuclear power plant maintenance, pharmaceutical, retail software including Visio and MS Windows operating systems, server room moves and toxicology systems. He is on the faculties of several professional training organizations. He is also the co-author of Commercial Off-the-Shelf (COTS) Software Validation for 21 CFR Part 11 Compliance (Davis Horwood International [DHI] and the Parenteral Drug Association [PDA]). 916-928-1470 phone 916-928-1470 fax dnettleton@ computersystemvalidation.com www.computersystemvalidation.com Janet Gough, an English language expert and consultant to the pharmaceutical, biotech and device industries, assists companies in developing compliant systems and preparing documentation, including research and development reports, procedures, clinical documents and regulatory Þlings. She also trains staff in systems and procedures and in English as a second language and technical writing. She has been a director of technical communications for a biotech company, has taught English in university graduate and undergraduate programs and is currently on the faculties of several professional training organizations. She is the author of Write It Down: Guidance for Preparing Documentation that Meets Regulatory Requirements (CRC Press) and Hosting A Compliance Inspection (Davis Horwood International [DHI] and the Parenteral Drug Association [PDA]); and the co-author of The Internal Quality Audit, The External Quality Audit and Commercial Off-the-Shelf (COTS) Software Validation for 21 CFR Part 11 Compliance (Davis Horwood International and PDA). 973-252-3731 phone 973-252-6910 fax [email protected]



Table of Contents Chapter 1

Electronic Record Keeping: The Big Picture..................................... 1

Regulatory Evolution................................................................................................ 2 The Electronic Revolution .............................................................................. 4 Compliance Requirements .............................................................................. 7 General Basis for Electronic Records ................................................ 8 Security .............................................................................................. 9 Data Transfer..................................................................................... 14 Operation Checks.............................................................................. 15 Archiving........................................................................................... 15 Audit Trails ....................................................................................... 16 Computer System Validation, Training and Documentation ................................. 17 Chapter 2

The Regulations: Not Just What They Say, But What They Mean........................................................................ 19

45 CFR Parts 160, 162 and 164 and Industry Standards ...................................... 160.103 DeÞnitions....................................................................................... 164.304 DeÞnitions....................................................................................... 164.306 Security Standards: General Rules ................................................. 164.308 Administrative Safeguards .............................................................. 164.310 Physical Safeguards ........................................................................ 164.312 Technical Safeguards ...................................................................... 164.314 Organizational Requirements.......................................................... 164.316 Policies, Procedures and Documentation Requirements................ Chapter 3

31 31 32 33 34 37 38 39 41

Going Electronic: What You Need to Know and Do....................... 43

Software Development and Use: From Then till Now .......................................... The COTS Software Development Life Cycle............................................. Purchasing COTS Software .............................................................. Choosing a Vendor ............................................................................ Escrow Accounts........................................................................................... Developer and User Validation ......................................................... Developer Validation ......................................................................... User Validation.............................................................................................. Ten Steps to Computer System User Validation .......................................... User and Developer Combined Validation ................................................... Operating Environments ................................................................... Computer System Validation ............................................................


43 45 46 47 50 51 53 56 58 59 60 61


Validation Models for System Components...................................... 62 Retrospective Validation................................................................................ 64 Chapter 4

Documentation and Training ............................................................ 65

The Validation Packet ............................................................................................. Validation Documents............................................................................................. User Requirements........................................................................................ Project Plan ....................................................................................... Installation Protocol .......................................................................... Installation Report............................................................................. Functional SpeciÞcations .................................................................. Hazard Analysis ................................................................................ User Testing Protocol........................................................................ User Testing Report .......................................................................... System Release Report ..................................................................... System Review Report...................................................................... System Support Documents.......................................................................... Standard Operating Procedures .................................................................... Document Management .................................................................... Training ............................................................................................ Facilities Security.............................................................................. Network Security .............................................................................. Workplace Security Awareness Program .......................................... Computer System Back-up ............................................................... Data Archiving .................................................................................. Computer System Maintenance Event Recording............................ Computer System Disaster Recovery ............................................... Information System Monitoring and Review ................................... Security Incident Procedure.............................................................. Electronic Signatures ........................................................................ Electronic Record Retention............................................................. Control of Electronic Mail................................................................ Computer Software Procurement...................................................... Software Vendor Auditing................................................................. Computer System Change Control ................................................... Computer System Validation ............................................................ Computer System Retirement........................................................... Signature Log/Look-Up Table SOP.................................................. Human Resources ......................................................................................... Additional Records ....................................................................................... Electronic Signature NotiÞcation...................................................... Minimum Required Signatures List ................................................. System User Training.................................................................................... 21 CFR Part 211 — Current Good Manufacturing Practice for Finished Pharmaceuticals.................................................................. Copyright © 2004 CRC Press, LLC

66 68 68 68 69 69 69 70 70 70 71 71 71 72 73 73 73 74 74 74 74 74 75 75 75 75 76 76 76 77 77 77 77 78 78 78 78 79 79 79


Subpart B — Organization and Personnel........................................ 21 CFR Part 606 — Current Good Manufacturing Practice for Blood and Blood Components.......................................................... Subpart B — Organization and Personnel........................................ 21 CFR Part 820 — Quality System Regulations........................................ Subpart B — Quality System Requirements .................................... Subpart G — Production and Process Controls ............................... ICH Q7A Good Manufacturing Practice Guide for Active Pharmaceutical Ingredients................................................ Chapter 5

80 80 80 80 80 81

Security, Accountability and Change Management ......................... 83

Managing the System ............................................................................................. Security ................................................................................................................... The People Factor ......................................................................................... Fraud ........................................................................................................... Vandalism ...................................................................................................... Terrorism ....................................................................................................... Theft ........................................................................................................... Security Defenses.......................................................................................... Commitment to Security............................................................................... The Security Mindset........................................................................ Ongoing Communication ....................................................................................... Managing Passwords: A Keychain......................................................................... Biometric Keychains ..................................................................................... Change Management..................................................................................... Maintaining a Robust System....................................................................... Remaining Compliant ................................................................................... Chapter 6

79

84 84 84 85 85 85 86 86 87 87 89 90 90 93 94 95

Auditing Electronic Record Keeping Systems ................................. 97

Establishing an Audit Function .................................................................... 99 The Scope of the Audit............................................................................... 100 Preparing to Audit....................................................................................... 101 The Binding Regulations ............................................................................ 101 Document Review ....................................................................................... 102 Scheduling the Audit................................................................................... 102 Audit Measurements ................................................................................... 103 The Audit Plan ............................................................................................ 104 Checklists and Notebooks........................................................................... 104 Conducting the Actual Audit ...................................................................... 105 Interviewing Users ...................................................................................... 105 Observing System Operation ...................................................................... 107 Training .......................................................................................... 107 Building Security ............................................................................ 107 Computer Security .......................................................................... 107 Copyright © 2004 CRC Press, LLC


Backup .......................................................................................... Archiving Data ................................................................................ System Maintenance Event Recording........................................... Change Control ............................................................................... Disaster Recovery ........................................................................... Electronic Signature Policy ............................................................ Electronic Record Retention........................................................... Computer System Validation .......................................................... Nonconformances............................................................................ Information Exchange................................................................................. Evaluating and Reporting Results .............................................................. Reporting Audit Results.............................................................................. Future Audits............................................................................................... Keeping the Audit Function Vital............................................................... Auditing and the Regulatory Inspection..................................................... The Mock Inspection .................................................................................. Chapter 7

Moving Forward.............................................................................. 113

Computer System Validation Committee ............................................................. Changing Company Cultures...................................................................... Gap Analysis ............................................................................................... Computer System Inventory ....................................................................... Software Inventory Elements.......................................................... Revalidation................................................................................................. Remaining Vigilant ..................................................................................... Chapter 8

108 108 108 108 108 108 108 108 109 109 109 110 110 110 111 111

113 114 115 116 117 117 118

Frequently Asked Questions ........................................................... 121

Binding Regulations.................................................................................... Software Vendors ........................................................................................ Computer System Validation ...................................................................... Electronic Records ...................................................................................... Electronic Signatures and Accountability................................................... Security........................................................................................................ Systems........................................................................................................ Audit Trails ................................................................................................. Staying Informed.........................................................................................

121 123 126 128 130 132 134 136 137

Appendix I ........................................................................................................... 139 Appendix II ......................................................................................................... 235 Appendix III ........................................................................................................ 247



References ............................................................................................................ 357


PH2164_C01.fm Page 1 Wednesday, November 19, 2003 9:40 AM

Record 1 Electronic Keeping: The Big Picture The law must be stable, but it must not stand still. Roscoe Pound

In February of 2003, United States Public Welfare and Human Services enacted Title 45 of the Code of Federal Regulations (CFR) Parts 160, 162 and 164. This regulation evolved from the Health Insurance Portability and Accountability Act (HIPAA), enacted into law in August of 1996. What it means for the healthcare industry that must manage medical data is that there will be increased scrutiny on record keeping. This regulation is a parallel to Title 21 of the CFR Part 11 Electronic Records; Electronic Signatures, enacted in 1997, which mandates tight controls on electronic data and electronically signed documents. HIPAA is intended to improve efficiency, reduce administrative burden, lower operating costs and improve quality by creating national standards for electronic data exchange (EDI) across the industry. Further, HIPAA is designed to protect the security, integrity and privacy of healthcare data, just as 21 CFR Part 11 is designed to protect records generated in the design, development, manufacture and distribution of food, pharmaceuticals, medical devices and biologics for humans and animals under the mandates of the Food and Drug Administration (FDA). HIPAA will impact FDA-regulated businesses as well, because these manage patient data in clinical trials and prepare products with information for human and animal treatment. 21 CFR Part 11 spells out how to manage records electronically as well as what is required to employ electronic signatures. Issued in August of 1998, the 45 CFR Part 142 Security and Electronic Signature Standards Proposed Rule, which addresses healthcare records electronically, is based directly on the concepts of 21 CFR Part 11. In February of 2003, 45 CFR Parts 160, 162 and 164 Health Insurance Reform: Security Standards; Final Rule was enacted. It becomes effective in 2005. Compliance with these CFR laws is mandatory. Because they are mandatory is reason enough to comply, but compliance does more than meet the letter of the law. Compliance ensures good business because it promotes good record keeping and has the potential to reduce costs significantly. So how do companies become compliant and remain so over time? The key lies in understanding the regulations and industry standards for addressing those regulations. When a law is promulgated, industry responds, and dialogueue between the agency that issues the law and individual companies serves to determine just how

1 Copyright © 2004 CRC Press, LLC


2

Achieving and Maintaining Compliance

companies can comply. Industry standards evolve over time, and companies must keep abreast of these standards. The new HIPAA regulations have not been in place long enough for industry standards to be fully developed. 21 CFR Part 11, however, has. The two regulations have parallel elements, and it is likely that the industry standards established for Part 11 will serve as the paradigm for HIPAA industry standards. The regulations come into place often because technology precedes them and companies gain the ability to improve their systems. The regulatory bodies then respond with rules to ensure that the practices have integrity, and industry standards evolve accordingly.

REGULATORY EVOLUTION The first US federal regulation dates back to 1884, when American soldiers died after ingesting adulterated quinine. As a result of these deaths, the government passed the Drug Importation Act, which required customs inspections on drugs coming from overseas. Then in 1901, The Biologic Control Act became law after 13 children died from a contaminated antitoxin for diphtheria. This act gave the government regulatory power over antitoxin and vaccine development. Shortly after, in 1906, the government passed the Food and Drugs Act to authorize the government to monitor food purity and safety of medicines. In 1931, the Food and Drugs Act was renamed the Food and Drug Administration. Several other events were significant in developing binding regulations designed to protect humans and animals. The 1932 Tuskegee Study of Untreated Syphilis in the Negro Male, conducted under the auspices of the U.S. Public Health Service, deprived infected men of effective treatment to not interrupt the project. Then, in 1937, 107 people died after taking “elixir of sulfanilamide,” which turned out to be an antifreeze solution. The FDA removed the product from the market, not because it caused fatalities, but because it was mislabeled. In 1938, the government passed the Food, Drug and Cosmetic Act, which expanded the role of the FDA to control of cosmetics and devices. It was during World War II, however, that experiments were done on a large scale on unconsenting humans. The Nuremberg War Crimes Trials brought these atrocities to light and resulted in the Nuremberg Code, which cited ten standards for ethical human research. A wake-up call for even better monitoring came in 1962, when thousands of babies were born with defects after their mothers took thalidomide while pregnant. The drug had never been approved for marketing in the U.S., but was undergoing research in American women. Of these women, nine gave birth to defective infants. This event induced the FDA to require notification of investigational use of drugs, which up until this time had not been required. The result was the Kefauver-Harris Amendment to the Food, Drug and Cosmetic Act. At about the same time, President John F. Kennedy announced the Consumer Bill of Rights in a message to Congress. This bill said the people have the right to safety, the right to be informed, the right to choose and the right to be heard. In the same period, in 1964, the World Medical Association issued the Declaration of Copyright © 2004 CRC Press, LLC


Electronic Record Keeping: The Big Picture

3

Helsinki, and physicians were tasked with embracing this statement: “The health of my patients will be my first consideration.” The declaration has been amended four times, and the Code of Federal Regulations has incorporated the basic elements. In 1972, the National Institutes of Health transferred the regulation of biologics to the FDA. This was followed by the National Research Act, which created the National Commission for the Protection of Human Subjects of Biomedical and Behavioral Research. Additional legislation has continued to promote ethical treatment of healthcare recipients. In 1978, the FDA published the current Good Manufacturing Practices, 21 CFR Parts 210 and 211. In 1988, the FDA became an agency of the Department of Health and Human Services. Since that time, the International Conference on Harmonisation (ICH) has been formed. A significant ICH goal is to maintain safeguards on quality, safety, efficacy and regulatory obligation for the protection of the public. The 1997 Food and Drug Administration Modernization Act reauthorized the Prescription Drug User Fee Act of 1992 and instituted reforms in agency practices. In 1996, medical devices became subject to Quality System Regulation (QSR) 21 CFR Part 820. Also in 1996, The Department of Health and Human Services enacted the Health Insurance Portability and Accountability Act (HIPAA) into law. This provided the forward momentum for broad changes in the healthcare industry, but the specifics of the regulation were still being written. Shortly thereafter, in 1997, 21 CFR Part 11, Electronic Records; Electronic Signatures; Final Rule was issued. The government does not issue laws blindly and without thought. The Office of the Federal Register issues the Federal Register (FR), a weekly disclosure publication that informs citizens of their rights and obligations by providing access to the official text of approved regulations and descriptions of federal organizations, programs and activities. It also publishes texts of proposed regulations and changes to existing regulations. This gives industry the opportunity to react and share dialogueue with the government agency that has ownership of the proposal. Reviewers can comment on content and wording, the date the regulation goes into effect and the penalties for noncompliance. Comments are reviewed in a government forum, and the final regulation becomes the “final rule.” Once enacted, laws are published in the Code of Federal Regulations (CFR), which is issued annually on April 1. Laws are enforceable by the respective divisions within the Department of Health and Human Services. It is important to note, however, that once a final rule appears in the FR, companies are responsible for instituting compliance. Thus, keeping abreast of the regulation requires constant vigilance. The CFR contains regulations of specific government departments and agencies. The CFR has 50 “titles,” each assigned to a different unit of government. Title 21, Food and Drugs, contains regulations mandated by the FDA. Title 45, Public Welfare, falls under the auspices of the National Institutes of Health (NIH). Each title is then divided into chapters and each chapter is divided into parts and subparts. The new HIPAA regulations are thus 45 CFR Parts 160, 162 and 164, while the FDA’s somewhat older Electronic Records; Electronic Signatures Regulation, is 21 CFR Part 11. These regulations share commonality. Systems that companies and organizations use to manage data are subject to tight controls. Even more demanding is Copyright © 2004 CRC Press, LLC


4


that electronic filing of healthcare claims is mandatory under the new HIPAA regulations. One thing is important to note: when 21 CFR Part 11 was enacted, industry was already complying with a multitude of regulations. The new law did not replace these regulations; rather it is an adjunct to them. Companies must adhere to predicate rules as well as Part 11. The same is true for the HIPAA regulations: predicate rules for healthcare management still apply. (Note: The rules already in place and those issued after Part 11 became effective are predicate rules.)

THE ELECTRONIC REVOLUTION Pharmaceutical companies started using electronic equipment to generate data as early as the 1980s. Members of the pharmaceutical industry approached the FDA in the early 1990s to develop new ways of dealing with the ever-increasing volume of regulatory paperwork. Companies must keep detailed records involving all aspects of product development, clinical trials, manufacturing, testing, release, labeling and distribution. Record requirements are defined in a plethora of existing FDA regulations. The use of computers for managing and tracking data has increased dramatically and continues to do so steadily. Typewriters were initially replaced with word processing computers, and instruments were attached to computers to provide new, more complex functionalities. Guidelines for managing paper records were in place, and industry complied with those guidelines, producing paper records with electronic equipment. Before 1997, no guidelines were in place for dealing with electronic records, yet companies were rapidly embracing computerized systems to generate data. Electronic data was being printed, signed and dated manually and retained in paper files. The cost of storing the files was growing steeply, and the ability to locate data in the files was becoming unmanageable. As electronic records increased in size, sorting through them to find the appropriate supporting information became difficult for the companies themselves and virtually impossible for the FDA. The process was slowing the rate of regulatory review of products and therefore delaying FDA approval. When industry first approached the FDA with the intention of working together to make the paper system more manageable, the long-range goal was in line with what the computer industry was touting as the “paperless office.” In 1991, members of the pharmaceutical industry and the FDA met to determine how they could accommodate paperless record systems under the current good manufacturing practice (cGMP) regulations in 21 CFR Parts 210 and 211. Both industry and the FDA embraced this goal because it would ultimately lead to paperless regulatory submissions. Paper regulatory submissions for a single product can total several million pages, from the initial Investigational New Drug (IND) application to conduct clinical trials for the product to the New Drug Application (NDA) for final approval to produce and market it. And, the agency demands multiple copies. The first evolution of the paperless system was the hybrid paper and electronic record system. In a hybrid system, the electronic data remains electronic, and the paper documents reference the electronic files. Electronic data from the original media are copied to tape and other forms of mobile, removable media for retention. Copyright © 2004 CRC Press, LLC



5

Documents that need approval, that is a hand written signature, are printed and signed. Together the electronic records and paper documents provide the complete set of data. In some ways, managing a hybrid system to manage electronic records in compliance with FDA mandates is more difficult than the full paper system. In many cases, companies printed electronic data and retained it so that all of the data was available in a tangible format that was familiar and trusted. the FDA saw that companies could not demonstrate that the electronic data accurately reflected supporting data for the approved paper documents. Indeed, the FDA had difficulty dealing with hybrid systems within the agency. One of the advantages of electronic records is they can be quickly and easily changed by a computer. When a decision about a set of data is made, that specific data must be retained to support the documentation that sets forth the decision. In a hybrid system, the decision is documented on paper, and is then approved with a handwritten signature. When the electronic data is updated, there is no longer a record that reflects the set of data to support the approved decision. With electronic data changing so readily, companies again found that the only way to be sure what the supporting data was at any given time was to print the electronic data and manually initial and date the pages. It was clear that guidelines for electronic data needed to be redefined. Paper records can be immediately out of date because once they are printed, if the computer system updates the data, there is no way for the static paper record to reflect the change. With this understanding, the industry and FDA together decided that the electronic record was really the better choice for tracking data. The electronic data thus becomes the official record. To allow a record that is constantly able to change to be known at every time point of interest, electronic records would need to be tracked with automatic date and time stamps. This gave rise to the automated audit trail, which is a chronological history of an electronic record. With the audit trail the electronic data can be re-created to reflect what it was at any given historical time point. This new conceptual approach meant that software would need to be updated, and therefore all electronic records would be significantly changed. This would necessitate a considerable amount of time and money on the part of software vendors and the regulated industry. At that time, most companies employed custom software and maintained large software development and information technology (IT) departments. The improved electronic records worked well for data collected on instruments, but did not provide a means to capture the handwritten approvals that were present on the paper records. While the change in electronic records would be substantially better than the previous electronic records, it did not much change the hybrid system. If all of the effort was to be made to enhance electronic records but the resulting hybrid system was to be about the same, there was insufficient economic incentive to move forward. Industry proposed that, instead of having paper documents to support decisions made from electronic records, the electronic records and the decisions could be integrated into the existing computer systems. The FDA was open to this idea but was concerned with how decisions could be made without the legally Copyright © 2004 CRC Press, LLC


6


required handwritten signature that demonstrates identity of the individuals making the decision and the non-repudiation associated with their handwritten signature. Industry proposed attaching an electronic representation of the handwritten signature to electronic records, but this approach could be easily used in a fraudulent manner and the proposal was thus rejected on legal grounds. A new conceptual approach was needed to allow a handwritten signature to be replaced with an electronic form. At the time, most software did not have security components, but some systems used a user name and password as a means to grant access to the software like a key to a door. Those with the key could open the door and those without the key could not enter. As with any key, if the key is stolen, someone without authorization can gain access. To use an electronic key, computer systems would need redesigning to accommodate user names and passwords so that every key was unique. This would allow the electronic key to become the electronic signature. Software processes would also have to be redesigned to include steps that could capture decisions previously made on paper. In short, electronic signatures would replace handwritten signatures. This was a big change in software and processes. The conservative pharmaceutical industry liked the idea of the paperless environment, but when it came down to making radical changes, industry made it clear that it wasn’t ready to give up conventional handwritten signatures. The use of electronic signatures was added to the Part 11 regulation as optional. 21 CFR Part 11 was going to make significant changes to the regulated environment. Its title includes the terms “electronic records” and “electronic signatures” to underscore the major changes. The new regulation was written to ensure existing guidelines and predicate rules were understood as they relate to the new electronic record and signature constructs. 21 CFR Part 11 is the first regulation to make the requirement for computer system validation the law. It repeats predicate rules for staff training by specifically stating that training is required for users of computer systems and sets requirements for users of electronic signatures. Drafts of the new regulation were publicly circulated for more than a year before the regulation was promulgated on May 19, 1997. The regulation became effective in the standard 90-day period. On August 20, 1997, 21 CFR Part 11 became effective with no grandfather clause, meaning full compliance for all electronic record keeping, new or already in place (legacy), was required. The regulation made significant changes to the regulated industry. One of the major changes was consolidation of software systems. Companies worked with software vendors to develop off-the-shelf (OTS) software. OTS is cost effective in terms of development and maintenance and reduces the in-house software development requirements. These internal resources changed the focus from custom development to system administrators and developers of interfaces between OTS systems. This in turn provided the next generation of system integration and automation that propelled gains in worker productivity for the next decade. When the regulation became effective in 1997, virtually no companies were compliant, and the FDA was unable to audit companies for compliance because its inspectors were untrained. Over the next few years, industry and the FDA matured Copyright © 2004 CRC Press, LLC



7

and FDA inspections resulted in the agency’s citing companies for gross violations. These years solidified the understanding of what needed to be in place for effective electronic record keeping. As with many FDA regulations, the text is vague. It provides direction from the standpoint of concepts, but it does not provide detailed instructions that describe how to be compliant. 21 CFR Part 11 is an interpreted regulation, meaning that industry and inspectors must explain the meaning based on the current industry standards. This is why this book addresses what 21 CFR Part 11 means, not just what it says. Companies comprising the food, pharmaceutical, biotechnology, biologic and medical device industries work together in associations to provide a unified front for dealing with the FDA. In 2001, several associations explained to the FDA that companies do not have the resources required to be fully compliant with 21 CFR Part 11. Larger organizations have more systems to redesign or replace than smaller, newer companies. Thus, while larger companies have substantially more resources, they mostly have not managed to be fully compliant. Compliance tends to focus first on new computer systems and second on legacy systems. By the time Part 11 had been in effect for five years, the FDA had made an effort to establish enforcement criteria based on risk. This means that without ever making a statement to this effect, the FDA is enforcing compliance for highrisk businesses, computer systems and components of the regulation. Note that highrisk businesses and high-risk computer systems are two separate things. A business that makes a heart medication, for instance, is more risky than a business that makes aspirin. A computer system that calculates potency is more risky than a computer system that keeps track of clinical supplies. The FDA, in effect, is ensuring compliance with the components of the regulation for the high-risk systems. How systems are determined to be high risk is not clearly defined. The company itself has to do this with a software inventory, gap analysis and remediation plan. Companies that demonstrate sufficient compliance in these high-risk areas and show a plan for continued compliance are granted time to continue their compliance activities without full-scale inspection. The text of the regulation is short, but its impact has been dramatic. While the regulation text is only the last three pages, it includes a 35-page preamble that provides background information and a discussion of the comments. The fundamentals of 21 CFR Part 11 have been included in regulations for many other industries. More than 40 federal regulations have been updated to address electronic data. In addition, new legislation designed to modernize specific industries has been passed: HIPAA for medical records as well as Gramm-Leach Bliley for finance are examples.

COMPLIANCE REQUIREMENTS The 21 CFR Part 11 regulation identifies a number of requirements related to computer systems, electronic data, electronic signatures and supporting documentation. 45 CFR Parts 160, 162 and 164 have parallel requirements. Understanding of the industry standards that are implied by the Part 11 regulation is essential to putting electronic record keeping in place. But, as noted earlier, while industry standards are in place Copyright © 2004 CRC Press, LLC



8

for Part 11, they have not yet been established for the new HIPAA regulations. Both regulations contain elements related to the following topics: • • • • • • • •

General basis for electronic records Security Data transfer Audit trails Electronic signatures Computer system validation Training Supporting procedural infrastructure

General Basis for Electronic Records The general basis for electronic records encompasses the concept of moving from a paper system to an electronic system. More important, the regulation allows electronic records to be used in place of paper records, provided they are trustworthy and reliable. Clearly, companies need to have a working knowledge of industry standards to understand the current requirements that constitute the definition of “trustworthy” and “reliable.” Electronic records include all data directly reported to the FDA. These include regulatory submissions for product approval and any correspondence related to FDA regulations. The requirements for electronic records go well beyond data that is submitted to the FDA in any form, however. The regulation applies to all electronic data that supports data submitted. Supporting data has such a wide scope that most data is affected by the regulation. Upon FDA request, copies of electronic records must be made available for inspections. Companies typically print electronic records so inspectors can easily read them. The regulation requires that exact copies of data are reproducible from the electronic records. While this may seem simple today, older systems frequently did not employ the “what you see is what you get” that is virtually a standard with modern software. Printed copies of electronic records are often subsets of the total electronic record. To complicate matters further, the electronic record may have been updated several times since it was submitted to the FDA, or the data was used to support a decision that was issued to the FDA in another form. Printing all elements of an electronic record as it sits today does not fulfill the meaning of the requirement to print exact copies of electronic records. The exact copy must be available for all time points, specifically those tied to an approved decision. The definition of an electronic record was written in the mid-1990s. The definition has evolved over time, but the regulation remains as stated in the Federal Register. Subpart A section 11.3 states, “Electronic record means any combination of text, graphics, data, audio, pictorial, or other information representation in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system.” One FDA employee who worked on the definition stated that if he could have used more nouns and verbs in the definition he would have. To put it simply, an electronic record is any type of computerized data related to the Copyright © 2004 CRC Press, LLC



9

company’s product development, production, distribution and sales. For HIPAA, it means patient records — complete and unadulterated. The regulation makes a distinction between open and closed systems. This classification is based on whether the people who have responsibility for the data control have access to the system. With modern security standards, it’s easy to think that all systems containing regulated data are closed. Computer systems are no longer contained in a single building, and the use of the Internet and other methods of physical and logical access have blurred the demarcation between “open” and “closed.” Regardless of the classification, the objective is to have a safe system with controlled access. If a system is classified as open, the emphasis must be on making it secure. These additional security features do not change the classification to closed, but they should make the system as safe and secure as a closed system. The regulation also defines the characteristics of software for electronic record keeping. The vendor, in-house development staff, or a third party must build these characteristics into the software. The requirement for features means the software itself must have basic functionality that cannot be replaced with manual workarounds or other indirect methods. Prior to use of electronic signatures, a company must notify the FDA that electronic signatures are intended to be the legally binding equivalent of traditional handwritten signatures. This notification needs to be done only once. The notification is sufficient for all systems and all users, and there is no need to specify systems or users. The FDA provides example text and a specific FDA address in the preamble of the regulation. A simple statement, signed by an individual with the authority to make the statement, is sufficient to notify the FDA. The notification should come before the company uses the first electronic signature, not in response to an FDA request. The last general requirement of the regulation addresses the timeframe for compliance of all systems. The regulation specifically does not provide a grace period. This is the bottom line: all newly installed systems and existing legacy systems must be compliant. The FDA has provided industry with more than a year of lead time. It seems, however, that the FDA and industry failed to estimate the magnitude of resources required for compliance. Five years after the regulation went into effect, virtually no companies are completely compliant. Approximately half of the OTS software is compliant with the required feature set, and the remaining half is still undergoing version upgrades to add features. Security More than any other requirement in the regulation, computer security has generated the greatest change to industry standards. New technologies in computer hardware, operating systems, the Internet and software have been met with an evolving set of computer viruses, cyber-criminals and high-technology implementations of fraud and theft of intellectual property. Major changes in the way people work have resulted from wide-scale use of the Internet and the increased threat of terrorism. The regulation provides little guidance with respect to data security. The current Copyright © 2004 CRC Press, LLC



10

industry standard defines computer security with respect to user access as having the following characteristics: •

•

•

•

Authentication: The computer system must be able to determine whether users are who they say they are. Typically, a user enters a user name and password that is authenticated against a previously defined user name and password. Authorization: The computer system must be able to determine which users are allowed access to individual features. Typically, a system administrator with access to security controls grants authorization access to all other users. Users are granted access on a need-to-know basis. By default, users should not have access to everything on the system. Access starts with the ability to log on to the system and involves each individual feature available on the system. Privacy: Security must be in place to prevent the observation and snooping that results in a breach of confidentiality or people becoming aware of more than what they need to know. Today, the number one form of snooping results from someone looking over another person’s shoulder. Computer system features cannot control this problem. Systems classified as open have to deal with privacy issues to a greater extent than closed systems. The Internet, electronic mail and staff’s being able to access the corporate network while away from work make privacy difficult to secure. Encryption is an evolving technology that is being employed to ensure privacy. 128-bit encryption, which is a standard feature of Internet browsers, is readily available for use in software applications. Data integrity: The ability to determine whether data have been altered, by whom and when, and whether the person was authorized is what data integrity means. A combination of the previous security characteristics and an audit trail is necessary to secure data. If the data cannot be secured, no decision made from that data is trustworthy.

Security characteristics are evolving; therefore industry standards change accordingly. HIPAA, for example, contains a proposed standard for secure transactions. 45 CFR Part 142 Security and Electronic Signature Standards; Proposed Rule August 12, 1998, calls for electronic signatures in the form of digital signatures. A digital signature is an electronic signature based on 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. Digital signatures require development of a trusted third party, similar to the agency that distributes passports. This will require significant federal support and new laws. The use of electronic signatures in the context of 21 CFR Part 11 requires the user to be established as part of the security system in which the electronic data resides. HIPAA, however, deals with systems and users that are widely dispersed, so all users can’t be part of a single system. This is why HIPAA is looking to digital signatures, which use a trusted third party, like the Department of Motor Vehicles (DMV) or the passport office, to provide security measures. Copyright © 2004 CRC Press, LLC



11

Current industry standards for software security include a multitude of features. Each one provides a barrier with limited secure capabilities. All the barriers act in unison to provide enough security to deter the most common forms of security breaches. Centuries ago a castle was the model of security. The castle sits on high ground, constructed of thick stone with limited points of entry; the drawbridge opens only from the inside; the walls are high and thick and surrounded by a moat; archers atop the walls aim at approaching attackers and so on. None of the individual barriers can stop an attack on its own, but in tandem the multiple barriers provided a suitable defense for most attacks. So it is with electronic records. Companies must implement security measures to ensure that access to a computer system is restricted to authorized individuals. Supervisors provide authorization for access by subordinates. This process is most likely outside of the computer system and may be conducted via paper or e-mail. Users should have access only to functions they need to use. Less mature systems gave all access rights to the system administrators. This was done because it was easy to do, but with increased security concerns, there is no reason to give any one person complete control over all functions. Just because a person has the capability to grant security access does not mean he or she should have access to all system functions. Computer systems should require passwords to be a minimum length. The system may also require the password to be constructed of a set of characters such that the password is not easily discerned. Requiring numbers and symbols to be present forces the password to be something other than a word to be found in a dictionary. Longer passwords are more secure but more difficult to remember. When password minimums are set to be long, users tend to write down their passwords, which makes them less secure. In the past few years, password minimum lengths were increased from four to ten characters, but have settled down to the most common value of eight. Cryptographers are promoting longer passwords based on phrases instead of strings of characters. While phrases may make passwords more secure, it is unclear how the longer password will be welcomed by users of systems that use the password as a component of an electronic signature. Passwords that stay constant are a liability. If unauthorized persons know a password, they will have system access for as long as the password remains the same. Password aging is the frequency with which passwords are required to change. Software that does not have this feature requires a manual policy to remind users to change their passwords. Industry has experimented with password aging for periods as long as one year and as short as one month. When passwords are required to change frequently, users tend to write them down, thereby making the passwords less secure. Picture a workstation with the password-bearing sticky notes affixed to the walls or the side of a personal computer (PC). Today, most password aging is set to two or three months. If users do not change their passwords by the expiration date, the system should block access until the password is changed. With all the changes in passwords, users tend to reuse the same ones. A re-use block prevents a previously used password from being used for a specified duration. Some systems never allow one to be reused. Some systems allow a password to be used only after a period of time, typically one year. A poor implementation of password aging disallows a password to be used a certain number of times, typically Copyright © 2004 CRC Press, LLC


12


four. The thinking is that if the change frequency is three months and the reuse frequency is four times, then that disallows a password to be reused within a oneyear period. The problem with this plan is that users can change their passwords at will, so they could possibly change them five times in five minutes and be back to their original password. A user name tracks system use in the audit trail and identifies the person making an electronic signature. Therefore, user names must be unique. Less mature systems allowed multiple users to have the same user name or identification. This can quickly manifest trouble. If two users have the same user name, it is not possible to track the users individually. These older systems often allowed a user name to be deleted as well. When records were displayed, the user name could not be tied with a person. In some cases, the deletion of the user name caused all records with that user name to display a blank, because the user was deleted. It was also often possible for a new user to obtain a user name that had been used previously. In some cases, when older records are reviewed, a new-hire name appears associated with the user name on records that were made prior to the newhire’s joining the company. Mature user name security rules allow only the inactivation of a user account; the user name can never be deleted or reused. Passwords do not need to be unique, and it is possible that two different people could have the same password. The key is that a user does not know another user has the same password. All passwords must be confidential. From the moment a password is typed into a computer, the password is available for theft. The number one way in which passwords are stolen is by spying — that is, someone looking over the shoulder of someone who types in his password. Passwords should be encrypted as soon as possible, meaning that the receiving software application should perform the encryption before the password is transmitted anywhere for authentication. Once users have logged on to a system, their user names should appear on the display at all times. This provides a way for users to know that the system correctly identifies them. In an environment where multiple people use a computer, one person can log on and then leave, and another person can use the system. The computer does not know that one person has left and another has come on. Users must verify that they are logged on to the system before performing any activities. It is then essential to instruct users to log off the computer when they are leaving, but it is not realistic to expect that to occur all the time. Consider the case of someone who thinks she is just going to the printer but winds up in a 20-minute conversation in the hall. That user would not have thought to log off in that case, but, until she returns to the system, it is vulnerable to someone else using her access rights. One way to limit the length of time a system is vulnerable when the user is not present is to have the system automatically lock the screen or log off after a set period of inactivity. Most operating systems allow the screen to be locked so that the log-on password must be reentered to access any software on the computer. This method is good, but still leaves the user logged on to individual software applications. It is best if both the operating system and the individual software applications provide an automatic lockout. Cryptographers say that any password can be cracked provided there is enough time. Years ago, cyber-criminals were called hackers. These people, mostly teenage Copyright © 2004 CRC Press, LLC



13

boys, gained unauthorized access to all sorts of computer networks, primarily for the fun of the challenge. Few hackers became malicious. Corporate spies, however, knew the hacker techniques, and the threat to companies became serious and widespread. Companies needed help securing their systems and, as a result, hired the hackers to protect them. As such, the hackers became legitimate and the term “crackers” was coined to identify the people who cracked passwords. Governments, especially the U.S. National Security Administration, Federal Bureau of Investigation (FBI) and military, employ large numbers of crackers. A lot of cracker technology is out there, and, as is true for all technology, it is just a matter of time until someone uses it illegally. Crackers used to obtain passwords by trying every word in the dictionary. They used simple programs to do this automatically, which worked very well because most passwords were dictionary words. Modern software allows the system administrator to set the number of failed log-on attempts so that when the number is exceeded, the account locks out and can be reset only by the system administrator. This forces the user to call the system administrator, thereby alerting the system administrator of a problem. Over the past few years, the number of failed attempts has been relaxed from three to five. This is probably because, over time, users have had many passwords, and the probability of forgetting a password has increased. Any period of absence from the system, such as a vacation or business trip, expands the likelihood of a lapse in memory. It is one thing if people are just returning from vacation and cannot remember their passwords; it is quite another thing if a real security breach has taken place. To make this feature even more useful, software can easily be programmed to automatically send an e-mail to the system administrator or IT help desk when an account is locked out. Company staff may catch a potential criminal in the act or may wind up helping a legitimate user faster than that person can make the call to get help. The automatic e-mail provides a record of events that the system administrator can use to detect patterns. What do criminals do when they get locked out of one computer? They try another computer and a pattern emerges. When an account is activated, the system expects the designated user to use the account in a short period of time. If the user does not access the account in that time, the system may be vulnerable to unauthorized access. Many system administrators issue a widely known temporary password to allows users to access a system the first time or when a password is reset. System administrators should not do this. They have to be instructed to verbally provide a unique, not easily guessed, temporary password to the user. The system itself should require the user to change the password immediately upon entry. If the user does not change the password for some time, another person could have entered. Mature security features allow an account to be locked out if the password is not changed in a short period, typically one day. Another time when automatic lockout should occur is when an account has not been used for a long period of time. If a user has left the company and the system administrator hasn’t been notified to inactivate the account, then it remains active and vulnerable to unauthorized use. If an account hasn’t been used in a few months, it should be automatically locked out. Many companies rely on password aging to perform this function. Copyright © 2004 CRC Press, LLC


14


When a user logs on to a computer system, she has created an entry point into the system. If the same user moves to another location, she has created another entry point. Since a user can be at only one entry point at a time, leaving entry points open creates liability. Secure systems should automatically log users off the previous entry point when logging on to a second. Some systems require the user to manually log off from the previous location before they can log on again. In the modern computing environment, all computers are networked together. Networks are interconnected to form an intranet, which is connected to the Internet. As the saying goes, a chain is only as strong as the weakest link. The network, meaning all computers, must be secure with respect to user access, virus protection, removable media, e-mail and physical security. Viruses can be destructive, but they may also be silent and capable of stealing passwords and copying data. The most common ways to acquire a virus is from opening e-mail attachments, downloading software from the Internet and using removable media such as a diskette. Viruses are not the only source of concern. Corporate espionage is commonplace. Sometimes entire computers are stolen, especially laptop computers. Some thieves prefer to just transfer intellectual property data to removable media and make off with the copy. There are plenty of stories of hard drives being stolen, leaving behind what appears to be a broken computer. The hard drive easily fits into a pocket and, by the time people figure out the hard drive has been stolen, the thief is long gone. Most companies could not function very long without the daily assistance of the IT staff. However, the biggest liability to any company is often just those people in whom they place the greatest trust. System administrators have the highest level of security and the most technical knowledge. That needs to change somewhat. First, system administrators should not know user passwords. The system administrator may issue a temporary password, but the user should change it upon initial system access so that the password is not known to the system administrator. System administrators should also perform work using secure individual passwords, not shared system administrator passwords. While shared passwords are still required by some systems, their use should be significantly curtailed. System administrators should self-police themselves by reviewing who is using the shared system administrator account. Companies must put procedures in place that ensure shared accounts are changed when a system administrator leaves the company. Data Transfer Computers transfer data between servers and clients, other computers, removable media, second parties and larger audiences. When data are transferred, there is the potential for them to be stolen, changed or destroyed. Today, security in the area of data transfer tends to be one of the least managed activities and therefore the least secure. It is very easy to send data as an attachment to e-mail, place a copy of data onto removable media and take it off site, or travel with a laptop computer. As soon as data leaves the company intranet firewall or the physical building, it is much more vulnerable to theft. All confidential data that leaves the company should be encrypted. Copyright © 2004 CRC Press, LLC



15

There are many inexpensive utilities to encrypt files, folders or entire hard drive partitions. Typically, the higher the person’s rank in the company, the more confidential data she has on her laptop computer and the more she travels. What can your competition or a foreign nation do with the data they have stolen from you? There are horror stories of clinical trial results becoming unblinded and placed on the Internet to manipulate stock prices. Sometimes the formulation to a new drug is used to manufacture drugs overseas before the drug has passed FDA approval in the U.S. Intellectual property is always a critical asset that needs diligent protection by IT staff and individual users. Operation Checks The regulation requires systems to include operational system checks to enforce correct sequencing of events and validity of input data. At first thought, this may not seem like data transfer, but it is the transfer of data from a human being or another system to the target system. When software is programmed to enforce an orderly set of steps, it guards against the biggest source of data corruption, the user. Users are people and people are fallible. People make mistakes because they are ignorant, tired, careless or preoccupied. Most of the time these mistakes go unnoticed until they create significant subsequent problems. A small error can have a reverberating effect. Systems must be designed to ensure that errors will be corrected as soon as possible. Errors may be detected in an input data check, preferably before the data is saved. Systems must alert users to errors so they can be researched and corrected. Enforcing logical rules is exactly what computers are best at. Computers are only as good as the software programs they execute. This is why user validation is essential to compliance with 21 CFR Part 11 as well as 45 CFR Parts 160, 162 and 164. By enforcing the proper sequence of steps in a process, the ability to make errors, commit fraud and corrupt data is significantly reduced. Archiving Systems should have limited and controlled delete capabilities. In most cases, users do not need to delete data; all they need to do is inactivate it. When data is inactivated, it is hidden from view, but remains on the system and can be retrieved at a later date. The people with access to the capability to delete data should be severely restricted, and procedures should be in place to guarantee that deletion occurs only with proper managerial oversight. With the exponential growth in computer data storage capacity, deletion of data is required less and less frequently. The one primary exception is audit trails. Audit trails tend to grow one or more orders of magnitude greater than the original data. Both 21 CFR Part 11 and 45 CFR Part 160 require the audit trail to be maintained for the life of the original data. This means that eventually — perhaps sooner than later — the audit trail will need to be archived. Making an archive involves creating two or more copies of the data, typically on removable permanent media such as CD-R or DVD-R and then deleting the original data. The archived data must be



16


stored in a secure location with the same access rights as the original data. Remember that predicate rules apply, so the same requirements for archiving paper data apply to electronic records. Audit Trails Audit trails must be in place to record the creation, modification or deletion of electronic records. This allows an electronic record to be known at any given time. The audit trail must be created automatically without user involvement. The audit trail must record user name, date, time, previous data and new data. Some applications require a reason for change to be included in the audit trail. Mature software provides a configuration option so that a reason-for-change dialogueue box can be displayed or not. Often users will want it required in some areas of the software but not in others. The software needs to enforce rules for ensuring that data indicating the reason for change has been entered when required. Some software applications provide a pick list of the most common reasons for change. In addition, the software may ensure an entry has been made by requiring some minimum number of characters to be entered. The minimum number of characters should be large enough to make entering the true value easier than trying to avoid an entry. Ten or more characters is usually effective. With paper systems, a change of data is readily known to everyone reviewing a document. In a typical good manufacturing practice (GMP) example, when some data is changed on paper, the old value is crossed out with a single line, the new value is written next to the old value and the change is dated and initialed. This is an audit trail, but it is not automatic and independent of the user. In today’s computer systems, when a change is made, the user simply overwrites the existing data, replacing it with new. On the screen there is no indication that a change has been made. The historical data should be in an audit trail, but users don’t look into audit trails on a regular basis. Researching an audit trail is time consuming, and it is difficult to separate changes that require investigation from changes that are normal and correct. In the current state of software maturity, paper systems are superior to computer systems when it comes to identifying changes that have been made. 21 CFR Part 11 does not specifically address this issue, and software vendors have been slow to adopt methods for correcting this shortcoming. This issue, however, will receive increasing attention, especially since records of human health may be at stake. The FDA has direct jurisdiction over companies that use computer systems to develop, manufacture, distribute and market products subject to published regulations, just as Public Welfare has jurisdiction over companies that provide healthcare. Neither has direct jurisdiction over software vendors. Industry standards develop because users — that is, companies that buy software — demand specific features. The only way to get vendors to make software better is to demand that features be added, and to work with vendors to make workable solutions. Successful software vendors stay attuned to published and proposed regulations and industry discussions about compliance, and software that meets industry standards continues to become available. Copyright © 2004 CRC Press, LLC



17

Several software vendors have adopted features to address on-screen indication of changes. Some vendors provide a separate window to display the audit trail below the data window. Each time a field is entered, the change history for that field is displayed. The user can scroll the window and resize it as needed. Other vendors have implemented on-screen indication by placing a small colored downward-pointing triangle adjacent to fields that have a change history. When the user clicks on the triangle with the mouse pointer, a pop-up window displays the audit trail for that field. When is a change recorded in the audit trail? If a user makes a change to some data and the data is saved as part of the electronic record, then the data becomes available to another user. At that point, the change must be recorded in the audit trail. If a user makes several changes to data and then saves the electronic record, only the last change, the one that was saved and is therefore available to other users, needs to be recorded in the audit trail. To ensure that an audit trail records the correct date and time, all servers and workstations should be synchronized with a reliable time source. Many companies synchronize workstations with a network server during the workstation start-up or log-on process. The network server is synchronized to a federal atomic clock on a routine basis.

COMPUTER SYSTEM VALIDATION, TRAINING AND DOCUMENTATION Computer systems are the hosts of electronic records. The computer system consists of the hardware, operating system, software utilities, application software, user instructions, training materials and the validation documentation. Validation is required to ensure the accuracy, reliability and performance of the system and therefore provides a suitable host environment for electronic records. Chapter 3 addresses validation in depth. Both 21 CFR Part 11 and the HIPAA regulations call out the requirement for users to have the education, experience and training necessary to perform their tasks, which include using the computer system as a tool to help generate and maintain electronic records, knowing when the computer system is not working as intended and what to do about it, and performing validation and revalidation activities. All activities relative to going electronic require documentation. Documentation must be in place for all activities relative to the validation process, operation of the system and supporting systems and training. Chapter 4 discusses documentation and training in depth.



2

The Regulations: Not Just What They Say, but What They Mean Law is order and good law is good order. Aristotle

The scope of Part 11 has affected companies eager to go electronic. As with many regulations, however, Part 11 is difficult to understand. Because of this, the FDA issued many guidance documents to explain its intentions and the meaning of the regulation. Often, these guidance documents did little to improve understanding. While Part 11 provided the basic guidelines, industry best practices led the way to industry standards. Both industry and the FDA used the industry standards to interpret and enforce Part 11 compliance. The regulated industry had a large set of legacy computer systems that were not fully Part 11 compliant. Even new systems were not fully Part 11 compliant. Software vendors were making efforts to upgrade software products to meet the regulations. As the industry standards evolved, the software vendors needed to continually upgrade their software. This led to a series of validation projects for the software users within the regulated industry. Industry and the FDA both understood that compliance with new systems was taking longer than was hoped. While trying to become compliant with new systems, some legacy systems were being replaced by new systems, but most were not being addressed. Without making a formal statement, the FDA was enforcing Part 11 based on risk. In most cases, the FDA would allow a company to buy time if it had a remediation plan. The plan listed the computer systems, their Part 11 compliance status and the company’s plan for bringing systems into compliance. Companies addressed the highest-risk and newest systems first, so with resources targeting the newer systems, legacy systems were still a long way from becoming the focus. Guidance for Industry; Part 11, Electronic Records; Electronic Signatures — Scope and Applicability was issued in February 2003 and then again in August 2003. It recalled all the previous guidance documents related to Part 11 and stated the FDA’s intent to not enforce Part 11 for systems put in place prior to 1997 for systems with less than high risk levels. The confusion in industry, the poor national economy and the political climate made ripe the opportunity for the FDA to maintain forward momentum while buying time to address the problems facing the regulated indus-



20


tries. The guidance document itself is unclear because virtually no systems are static, but evolve from year to year as they are upgraded and integrated with other systems. Since Part 11 applies to enhancements made to systems after 1997, this relaxing of the regulation’s enforcement may have little impact other than to slow the adoption of new Part 11-compliant software products to replace aging legacy systems. The guidance document also clarified some misunderstanding promoted by industry, consultation and the FDA itself. One issue relates to the use of wordprocessing software used to create paper records. In this case, an electronic file is made, but the file does not fall under the Part 11 regulation for an electronic record. This is sometimes referred to as the “word-processing rule.” This is very similar to the old “typewriter rule” that referred to paper records created on a typewriter. Since there is no electronic file associated with a typewriter, there can be no electronic record. Sometimes people interpret a regulation too strictly and create more work for compliance than was intended. While this clarification may be useful in the short term, industry has been moving away from paper records and has had great success with electronic records and signatures. 45 CFR Part 142 Security and Electronic Signature Standards; Proposed Rule August 12, 1998 is based on the concepts of 21 CFR Part 11. In it, the electronic signature standard is based on digital signatures. Simple user name and password electronic signatures are not workable in a noncentralized electronic data exchange environment. This advancement for digital signatures requires significant legal and social infrastructure changes that go well beyond the scope of FDA and Health Insurance Portability and Accountability (HIPAA) regulations. At press time, it remains unclear when Part 142 will be finalized. 45 CFR Parts 160, 162 and 164, Health Insurance Reform: Security Standards; Final Rule was issued on February 20, 2003 and becomes effective April 20, 2005. These regulations, directed at the healthcare industry, are based on many of the industry standards that arose from 21 CFR Part 11. In Part 164 some of the industry standards are written into the regulation, while some concepts are not clearly defined. Part 164 goes beyond Part 11 in some areas because the nature of electronic data for healthcare records requires more stringent controls for privacy and access. The additional details included in Part 164 are essential for the healthcare industry because it is not as structured as the pharmaceutical industry with respect to standard operating procedures and training requirements. Surely, in the next few years, the healthcare industry will learn much from other established regulated industries. 45 CFR Part 160 General Administrative Requirements addresses confidentiality of electronic healthcare information. The main objective is to protect this data from improper disclosure. Part 160 defines a multitude of healthcare providers and how they are responsible for ensuring data privacy. The use, maintenance and transmission of electronic data may be disclosed only on a need-to-know basis. Freedom to share information between companies and within a company is severely limited.



The Regulations: Not Just What They Say, but What They Mean

21

45 CFR Part 162 Administrative Requirements is a reserved section of the regulation that will be addressed in subsequent HIPAA regulations. 45 CFR Part 164 Security and Privacy is based on the concepts of the 21 CFR Part 11 Electronic Records and Electronic Signature rule for the pharmaceutical and allied industries. Since both regulations are based on current industry standards, one can assume that HIPAA will cause a rapid maturity in industry standards that will in turn raise the bar for regulatory compliance with 21 CFR Part 11. Part 164 is intended to protect against threats to security or integrity. The regulation requires companies to implement measures to prevent, detect, contain and correct security violations. It requires companies to periodically perform a risk assessment of their security vulnerabilities. Ideally, this risk assessment can become a regular component of an audit plan for the operations. (See Chapter 7 for more information about auditing.) A security official with adequate responsibility and authority must be appointed. All levels of the organization workforce must control access to information. Control must include policies for authorization, supervision, termination and password management. Management is tasked with responsibility to train the workforce to ensure compliance and issue security-awareness reminders that promote a continued state of importance and compliance. Companies must develop policies that sanction workforce members who fail to comply with security policies. Detection of noncompliance must be proactive; there must be regular review of system activity logs, audit trails, access reports and followthrough of violation incident reports. In line with industry standards that have evolved while 21 CFR Part 11 was maturing, Information technology (IT) groups must guard against malicious software by implementing virus protection, firewalls, controls for software installation and control of e-mail attachments. IT must proactively report system access violations and ensure corrective measures are taken. Companies are also required to devise plans for data backup and disaster recovery. Well beyond the scope of 21 CFR Part 11, HIPAA requires contingency plans for continued operation during emergency conditions. These plans must be periodically tested to demonstrate that they are viable. In line with current industry standards, HIPAA requires physical security controls for the workforce, visitors and maintenance personnel. Computer workstations must reside in secure locations with appropriate access controls. Security plans must address data transfer via mobile computer and removable media. Companies must also have policies that define electronic record retention schedules and data destruction procedures. Software involved with electronic data must employ unique user identification and display it on screen at all times. Software must automatically log a user off after a predefined period of inactivity. All data must be transferred and stored in an encrypted format. Audit trails must record all additions, changes and deletions of data. These rules apply to all partners that share data. The following table lists the basic wording of the regulations, their actual meaning, and the HIPAA equivalent.




22

What the Regulations Say

What the Regulations Mean

21 CFR Part 11 Subpart A — General Until this regulation took effect, paper records Provisions § 11.1 Scope. (a) The regulations were the focus of compliance. By making in this part set forth the criteria under which electronic records equivalent to paper the agency considers electronic records, records, the focus of compliance became electronic signatures and handwritten both paper and electronic records. In signatures executed to electronic records to practice, the fact that electronic records are be trustworthy, reliable and generally changed to keep them current in a real time equivalent to paper records and handwritten manner and paper records are inherently signatures executed on paper. static, electronic records are the focus of compliance. By making electronic signatures equivalent to handwritten signatures, the agency is opening the possibility of electronic records approved with electronic signatures to replace handwritten signatures. This allows companies to retain paper systems, use hybrid paper and electronic systems, or use fully electronic systems. (b) This part applies to records in electronic The agency is setting the scope of electronic form that are created, modified, maintained, records to include all agency regulations. In archived, retrieved or transmitted under any this manner, all of the previous and future records requirements set forth in agency regulations do not have to be rewritten to regulations. This part also applies to include a statement of acceptance for electronic records submitted to the agency electronic records. under requirements of the Federal Food, This section specifically excludes facsimiles Drug and Cosmetic Act and the Public from the definition of an electronic record. Health Service Act, even if such records are Paper that is transmitted by fax remains a not specifically identified in agency paper record, and the faxed copy is regulations. However, this part does not equivalent to a paper copy. apply to paper records that are, or have been, transmitted by electronic means. c) Where electronic signatures and their This text further explains the recognition of associated electronic records meet the electronic signatures as equivalent to requirements of this part, the agency will handwritten signatures as stated in 11.1 (a). consider the electronic signatures to be Electronic signatures are accepted as equivalent to full handwritten signatures, equivalent to any form of handwritten initials and other general signings as required signature such as handwritten initials. The by agency regulations unless specifically agency is not making a commitment to accept excepted by regulation(s) effective on or electronic signatures at all times and makes after August 20, 1997. allowances for future regulations to make exceptions. Companies should not be fearful of this exception. It is a standard escape clause that is used only in limited cases that are explained in the regulations. One such case is the requirement to notify the FDA that electronic signatures are being used at a


The HIPAA Parallel 164.306

160.103

N/A




(d) Electronic records that meet the requirements of this part may be used in lieu of paper records, in accordance with § 11.2, unless paper records are specifically required. § 11.2 (e) Computer systems (including hardware and software), controls and attendant documentation maintained under this part shall be readily available for, and subject to, the FDA inspection.

§ 11.2 Implementation.(a) For records required to be maintained but not submitted to the agency, persons may use electronic records in lieu of paper records or electronic signatures in lieu of traditional signatures, in whole or in part, provided that the requirements of this part are met. (b) For records submitted to the agency, persons may use electronic records in lieu of paper records or electronic signatures in lieu of traditional signatures, in whole or in part, provided that: (1) The requirements of this part are met; and (2) The document or parts of a document to be submitted have been identified in public docket No. 92S–0251 as being the type of submission the agency accepts in electronic form. This docket will identify specifically what types of documents or parts of documents are acceptable for submission in electronic form without paper records and the agency receiving unit(s) (e.g., specific center, office, division, branch) to which such submissions may be made.


What the Regulations Mean company. Section 11.100 (1) of this regulation specifically requires a handwritten signature for the notification; electronic signatures are not acceptable. Similar to the previous section, which addresses electronic signatures, this section states that electronic records are equivalent to paper records. Again, a standard escape clause is included to restrict the use of electronic records in special circumstances. A computer system is defined to be more than just the computer components. Industry standards recognize a computer system to be hardware, the operating system, software utilities, application software, user instructions, training materials and the validation documentation. The FDA is clearly stating that it will inspect the computer system and the supporting procedural infrastructure related to it. This regulation has not made allowances for electronic records to be used in place of paper records for the purpose of making submissions to the FDA. Submissions include correspondence for any and all reasons including applications for approval to market products. Regulations for submissions are separate from 21 CFR Part 11. Currently, each type of submission maintains a separate policy related to acceptance of electronic records.

23

The HIPAA Parallel

N/A

164.304

N/A



24



Documents to agency receiving unit(s) not specified in the public docket will not be considered as official if they are submitted in electronic form; paper forms of such documents will be considered as official and must accompany any electronic records. Persons are expected to consult with the intended agency receiving unit for details on how (e.g., method of transmission, media, file formats and technical protocols) and whether to proceed with the electronic submission. § 11.3 Definitions. (a) The definitions and Instead of listing all definitions for terms used interpretations of terms contained in section within this regulation, the agency is 201 of the act apply to those terms when used referencing a separate regulation. Assuming in this part. readers are familiar with the FDA regulations (b) The following definitions of terms also applicable to their businesses, the definitions apply to this part: essential to understanding the scope of 21 CFR Part 11 are included in the following section. 21 CFR Part 11 Subpart B — Electronic The requirement for a supporting procedural Records § 11.10 Controls for closed infrastructure is stated. As discussed in this systems. Persons who use closed systems to book, industry standards include the create, modify, maintain, or transmit following standard operating procedures electronic records shall employ procedures (SOPs): Facilities Security, Network and controls designed to ensure the Security, Computer System Back-up, Data authenticity, integrity, and, when Archiving, Computer System Maintenance appropriate, the confidentiality of electronic Event Recording, Electronic Signatures. records and to ensure that the signer cannot These supporting SOPs must be readily repudiate the signed record as not supplemented with system-specific genuine. Such procedures and controls shall procedure as required. include the following: (a) Validation of systems to ensure accuracy, As discussed in this book, the following SOPs reliability, consistent intended performance are applicable: Computer System Validation and the ability to discern invalid or altered and Computer System Change Control. records. (b) The ability to generate accurate and Electronic records are great for reviewing on complete copies of records in both human- computers, but they are not very easy to readable and electronic form suitable for review during an inspection. The requirement inspection, review and copying by the is to be able to print electronic records so that agency. Persons should contact the agency if exactly the same information is present. This there are any questions regarding the ability includes printing of the current electronic of the agency to perform such review and record and the audit trail. The printed copying of the electronic records. information does not have to be formatted to match the online view.


The HIPAA Parallel

N/A

164.306, 164.308, 164.310, 164.312, 164.314, 164.316

164.310

N/A





(c) Protection of records to enable their As discussed in this book, the following SOPs accurate and ready retrieval throughout the are applicable: Data Archiving and records-retention period. Electronic Record Retention. (d) Limiting system access to authorized System access must be limited to users who individuals. are granted access. The procedure for granting system-specific access is similar to that included in the Network Security SOP. The procedure may employ handwritten signatures or electronic signatures to authorize issuance of security privileges that allow user access to a system. In some systems, the request and issuance of user access is contained within the computer system itself. (e) Use of secure, computer-generated, time- This is the requirement for the automated audit stamped audit trails to independently record trail. The requirement to have record changes the date and time of operator entries and not obscure previously recorded information actions that create, modify or delete is met by including the previous data values electronic records. Record changes shall not in the audit trail. The regulation does not obscure previously recorded information. define the audit trail as an electronic record Such audit trail documentation shall be but establishes a requirement to retain auditretained for a period at least as long as that trail data for the same duration as the required for the subject electronic records electronic records. and shall be available for agency review and copying. (f) Use of operational system checks to This is the requirement for operational system enforce permitted sequencing of steps and checks to control the processes implemented events, as appropriate. in software. (g) Use of authority checks to ensure that only This section expands the requirements of authorized individuals can use the system, section (d) above. Access rights to individual electronically sign a record, access the system functions must be granted to operation or computer system input or output authorized users in a controlled fashion. This device, alter a record or perform the is often accomplished by creating roles that operation at hand. have pre-defined security access and then assigning the role to individual users. (h) Use of device (e.g., terminal) checks to In the modern distributed computer determine, as appropriate, the validity of the environment there are virtual connections source of data input or operational made between the input devices (client instruction. workstations) and the computer that retains the electronic record (server). Each time data is transmitted between the input device, such as a computer workstation, barcode reader or instrument, the receiving software application must confirm that it is appropriate for that device to be transmitting data at that


25

The HIPAA Parallel 164.316

164.306, 164.308, 164.310, 164.312, 164.314, 164.316

164.312

N/A

164.306, 164.308, 164.310, 164.312, 164.314, 164.316 164.306, 164.308, 164.310, 164.312, 164.314, 164.316



26


(i) Determination that persons who develop, maintain or use electronic record/electronic signature systems have the education, training and experience to perform their assigned tasks. (j) The establishment of and adherence to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures, in order to deter record and signature falsification.

(k) Use of appropriate controls over systems documentation including: (1) Adequate controls over the distribution of, access to and use of documentation for system operation and maintenance.

(2) Revision and change control procedures to maintain an audit trail that documents timesequenced development and modification of systems documentation. § 11.30 Controls for open systems. Persons who use open systems to create, modify, maintain or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, as appropriate, confidentiality of electronic records from the point of their creation to the point of their receipt. Such procedures and


What the Regulations Mean time. Typically, this is done by capturing the network address of the input device at the time of log-on and then verifying that data received comes with the same network address. If a user logs on at one computer workstation and then starts transmitting data from another, the receiving software application would not be able to confirm that the same person is responsible for the data and the data should be rejected. This requirement restates the predicate rule for training. It specifically addresses the skill of the computer user to ensure that reliable electronic records are generated and maintained. As discussed in this book, the Electronic Signature SOP is applicable. While the FDA requires only one authorized representative of the company to notify them that electronic signatures are in use, all users must understand and certify that their electronic signature is equivalent to their handwritten signature. This certification is usually the user’s signature on the training record of the Electronic Signature SOP. Assuming that the procedures for operation and maintenance of a computer system are established as SOPs, the SOP on SOPs provides the company’s guidelines for SOP control and distribution. Therefore, system-specific SOPs that describe the operation and maintenance of the system inherently have the appropriate controls. A standard part of SOPs is the version change history. Use of existing, well-established SOP documentation practices ensures compliance with this regulation. So far, the regulation has addressed closed systems. When users do not have direct control over the source of data, such as when the Internet is used, the FDA makes additional requirements. The objective is to make the open system as secure as a closed system. Industry standards employ end-toend encryption in addition to all previously

The HIPAA Parallel

164.308

164.308

164.316

164.316

164.306, 164.308, 164.310, 164.312, 164.314, 164.316





controls shall include those identified in mentioned security features. Digital § 11.10, as appropriate and additional signatures may provide a pathway for the measures such as document encryption and next evolution of computer system security, use of appropriate digital signature standards but this technology is still immature and to ensure, as necessary under the requires significant advancements in the circumstances, record authenticity, integrity structure of legal and societal frameworks. and confidentiality. § 11.50 Signature manifestations. (a) Signed An electronic signature contains several pieces electronic records shall contain information of data that permit identification of the signer, associated with the signing that clearly the exact time and the meaning. The data are indicates all of the following: (1) the printed exactly the same as what is required for a name of the signer; (2) the date and time handwritten signature. when the signature was executed; and (3) the meaning (such as review, approval, responsibility or authorship) associated with the signature. (b) The items identified in paragraphs (a)(1), The electronic signature is not defined as an (a)(2) and (a)(3) of this section shall be electronic record, but like the audit trail, must subject to the same controls as for electronic be managed and retained in the same manner records and shall be included as part of any as the electronic records. Additionally, the human readable form of the electronic record electronic record attached to an object, such (such as electronic display or printout). as a document, must be included in the online display or printed form of the object. This is in line with the requirement of 11.10 (b), the ability to generate accurate and complete copies of records in both human readable and electronic form. § 11.70 Signature/record linking. Electronic The electronic signature must be linked to the signatures and handwritten signatures electronic record in a secure manner that executed to electronic records shall be linked prevents the electronic signature from being to their respective electronic records to used as a signature on another electronic ensure that the signatures cannot be excised, record. This requirement is designed to copied or otherwise transferred to falsify an prevent fraud by normal means. Software electronic record by ordinary means. must be designed so that users and system administrators cannot excise a signature for reuse. The requirement for protection against fraud is not absolute and is provided in the context of “ordinary means.” Given enough resources, such as reverse engineering of the software, it is possible for a criminal to falsify an electronic signature. When implemented correctly, the probability for falsification of an electronic signature is less than the probability of falsifying a handwritten signature.


27

The HIPAA Parallel

N/A

N/A

N/A



28



21 CFR Part 11 Subpart C — Electronic An electronic signature must be unique at all Signatures § 11.100 General requirements. times during the life of the system. Since the (a) Each electronic signature shall be unique electronic signature must identify the signer, to one individual and shall not be reused by, the user name must be unique and can never or reassigned to, anyone else. be reassigned to another user. (b) Before an organization establishes, Processes must be in place to authenticate a assigns, certifies or otherwise sanctions an user before issuing an electronic signature. individual’s electronic signature, or any The process for obtaining a logon requires element of such electronic signature, the positive identification of the assigned user, organization shall verify the identity of the typically from the user’s immediate superior. individual. Since the user name is unique, the procedure for logon adequately addresses this requirement for electronic signatures. (c) Persons using electronic signatures shall, The FDA requires that a company inform them prior to or at the time of such use, certify to that electronic signatures are in use. The the agency that the electronic signatures in specifics of the computer systems and users their system, used on or after August 20, need not be disclosed. The preamble of the 1997, are intended to be the legally binding regulation provides suggested text for the equivalent of traditional handwritten required correspondence. signatures. (1) The certification shall be submitted in The correspondence used to notify the FDA paper form, signed with a traditional of electronic signature use must be submitted handwritten signature, to the Office of on paper with a handwritten signature. Regional Operations (HFC–100), 5600 Fishers Lane, Rockville, MD 20857. (2) Persons using electronic signatures shall, All users of electronic signatures must certify upon agency request, provide additional that they understand that their electronic certification or testimony that a specific signature is the legally binding equivalent of electronic signature is the legally binding their handwritten signature. Most companies equivalent of the signer’s handwritten use the training record of the Electronic signature. Signature SOP as the documented evidence for this certification. 21 CFR Part 11 § 11.200 Electronic Electronic signatures that do not use biometric signature components and controls. (a) components must contain two components to Electronic signatures that are not based upon ensure the authenticity of the signature. The biometrics shall: (1) Employ at least two standard model uses a public unique user distinct identification components such as an name and a secret password. There is no identification code and password. requirement for passwords to be unique. (i) When an individual executes a series of This part of the regulation is stated so vaguely signings during a single, continuous period that it has led to considerable confusion and of controlled system access, the first signing wide differences in implementation. After shall be executed using all electronic each logon, when users make their first signature components; subsequent signings electronic signature, they must use both shall be executed using at least one electronic electronic signature components, the user


The HIPAA Parallel N/A

N/A

N/A

N/A

N/A

N/A

N/A





name and password. After the first electronic signature and during the same continuous session, subsequent electronic signatures are permitted using only one of the components, provided the component can be executed only by the user. For the standard model, this allows use of the password alone as a single component to make an electronic signature. It is not clear why the FDA relaxed the requirement for subsequent signings that take place in a continuous period. Perhaps the burden of entering both components numerous times is the motivation. While the concept of a continuous session is not clear, most companies interpret this to mean the period during a single log-on session. If the user logs off or if automatic log-off occurs, the session is terminated. Most software implements an electronic signature so that both components are required at all times. The user name is provided as a default based on the user name of the user logged on and the user must always enter his password. (ii) When an individual executes one or more As soon as a continuous session is terminated, signings not performed during a single, the requirement for use of both electronic continuous period of controlled system signature components is reinstated. access, each signing shall be executed using all of the electronic signature components. (2) Be used only by their genuine owners; and The electronic signature must be established so that it can be used only by the authorized user. The use of a secret password provides compliance. The regulation is strictly interpreted and requires that passwords used as an electronic signature component must not be known by anyone other than the user. This means that system administrators, administrative staff, management, executive management or any other persons should not know a password other than their own. Under no circumstances should an administrative assistant execute an electronic signature for a superior.

29

The HIPAA Parallel

signature component that is only executable by and designed to be used only by, the individual.


N/A

N/A



30



(3) Be administered and executed to ensure Like the concept of “ordinary means,” the that attempted use of an individual’s FDA is placing limits on how far companies electronic signature by anyone other than its must go to ensure compliance. While they genuine owner requires collaboration of two must have procedures in place to safeguard or more individuals. electronic signature use, these safeguards do not have to address scenarios where people collude to perpetrate criminal activity. (b) Electronic signatures based upon Electronic signatures employing biometric biometrics shall be designed to ensure that components must meet the same single-user they cannot be used by anyone other than use criteria. Since the concept of a biometric their genuine owners. is to uniquely identify a user, this doesn’t provide much more direction other than to ensure that the biometric itself cannot be tangible, thereby making it vulnerable to theft and use by someone other than the intended user. § 11.300 Controls for identification As stated previously in the regulation, the codes/passwords. Persons who use electronic signature must be unique and electronic signatures based upon use of assigned to only one user. This section identification codes in combination with further explains that only the combination of passwords shall employ controls to ensure the user name and password must be unique. their security and integrity. Such controls Since user names must be unique, the shall include: (a) Maintaining the uniqueness requirement is already met, and therefore of each combined identification code and there is no requirement to have passwords be password, such that no two individuals have unique. the same combination of identification code and password. (b) Ensuring that identification code and Electronic signatures, like log-on criteria, password issuances are periodically checked, must be changed at regular intervals. recalled or revised (e.g., to cover such events Password aging, that is, the requirement for as password aging). the user to change his password after a specified maximum amount of time, is required for log-on criteria and therefore meets the requirement for electronic signatures. (c) Following loss management procedures to Regardless of the hardware and software electronically deauthorize lost, stolen, components used for making an electronic missing or otherwise potentially signature, there must be procedures in place compromised tokens, cards and other devices to issue and maintain them. For user-name that bear or generate identification code or and password components, this does not password information, and to issue provide any additional requirements beyond temporary or permanent replacements using those previously stated. suitable, rigorous controls.


The HIPAA Parallel N/A

N/A

164.306, 164.308, 164.310, 164.312, 164.314, 164.316

164.306, 164.308, 164.310, 164.312, 164.314, 164.316

164.306, 164.308, 164.310, 164.312, 164.314, 164.316





(d) Use of transaction safeguards to prevent The system itself must allow only authorized unauthorized use of passwords and/or persons to use their electronic signature at identification codes, and to detect and report the appropriate time and in association with in an immediate and urgent manner any objects that are within the scope of each attempts at their unauthorized use to the user’s allowed responsibilities. In addition, system security unit, and, as appropriate, to the system must be able to detect when organizational management. security breaches appear to be occurring. In most systems, failure to provide a log-on password after a certain number of predefined tries causes the account to be locked out. The system administrator is notified when the person who owns the account calls to get the account unlocked. In more mature systems, when the system locks an account, the system automatically notifies the system administrator by e-mail to speed up the notification process. (e) Initial and periodic testing of devices, such When devices are used as electronic signature as tokens or cards, that bear or generate components, procedures must be in place to identification code or password information account for all devices and ensure their to ensure that they function properly and proper operation on a continual basis. have not been altered in an unauthorized manner.

31

The HIPAA Parallel 164.306, 164.308, 164.310, 164.312, 164.314, 164.316

164.306, 164.308, 164.310, 164.312, 164.314, 164.316

45 CFR PARTS 160, 162 AND 164 AND INDUSTRY STANDARDS It takes time for industry standards to develop. Industry and the Department of Health and Human Welfare will undoubtedly have continuing dialogue about how the new regulations are to be interpreted and how they will apply in specific instances. The outcome remains to be seen. One thing is certain, however: the precedent for electronic record keeping standards has been set with efforts to comply with 21 CFR Part 11. Companies that must comply with the HIPAA electronic record keeping regulations can look to industry standards in practice in the food and drug industries. Here are key excerpts from the final rule that relate directly to the mandates for 21 CFR Part 11.

160.103 DEFINITIONS Disclosure the release, transfer, provision of, access to, or divulging in any other manner of information outside the entity holding the information. Electronic media (1) Electronic storage media including memory devices in computers (hard drives) and any removable/transportable digital memory medium, such as magnetic tape or disk, optical disk, or digital memory card Copyright © 2004 CRC Press, LLC


32


(2) Transmission media used to exchange information already in electronic storage media. Transmission media include, for example, the Internet (wide-open), extranet (using Internet technology to link a business with information accessible only to collaborating parties), leased lines, dial-up lines, private networks and the physical movement of removable/transportable electronic storage media. Certain transmission, including of paper, via facsimile and of voice, via telephone, are not considered to be transmissions via electronic media, because the information being exchanged did not exist in electronic form before the transmission. (3) Electronic protected heath information means information that comes within paragraphs (1) (i) transmitted by electronic media or (2) (ii) maintained in electronic media, of the definition of protected health information as specified in this section.

164.304 DEFINITIONS Access the ability or the means necessary to read, write, modify or communicate data/information or otherwise use any system resource. Administrative safeguards administrative actions, policies and procedures to manage the selection, development, implementation and maintenance of security measures to protect electronically protected health information and to manage the conduct of the covered entity’s workforce in relation to the protection of that information. Authentication the corroboration that a person is the one claimed. Availability the property that data or information is accessible and usable upon demand by an authorized person. Confidentiality the property that data or information is not made available or disclosed to unauthorized persons or processes. Encryption the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key. Facility the physical premises and the interior and exterior of a building(s). Information system an interconnected set of information resources under the same direct management control that shares common functionality. A system normally includes hardware, software, information, data, applications, communications and people. Integrity the property that data or information have not been altered or destroyed in an unauthorized manner. Malicious software software, for example, a virus, designed to damage or disrupt a system. Password confidential authentication information composed of a string of characters. Physical safeguards physical measures, policies and procedures to protect a covered entity’s electronic information systems and related buildings and equipment from natural and environmental hazards and unauthorized intrusion. Copyright © 2004 CRC Press, LLC



Security or Security measures encompass all of the administrative, physical and technical safeguards in an information system. Security incident the attempted or successful unauthorized access, use, disclosure, modification or destruction of information or interference with system operations in an information system. Technical safeguards the technology, policy and procedures for its use that protect electronically protected health information and control access to it. User a person or entity with authorized access. Workstation an electronic computing device, for example a laptop or desktop computer, or any other device that performs similar functions and electronic media stored in its immediate environment.

164.306 SECURITY STANDARDS: GENERAL RULES (a) General requirements. Covered entities must do the following: (1) Ensure the confidentiality, integrity and availability of all electronic protected health information the covered entity creates, receives, maintains or transmits. (2) Protect against any reasonably anticipated threats or hazards to the security or integrity of such information. (3) Protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required under subpart E of this part. (4) Ensure compliance with this subpart by its workforce. (b) Flexibility of approach. (1) Covered entities may use any security measures that allow the covered entity to reasonably and appropriately implement the standards and implementation specifications as specified in this subpart. (2) In deciding which security measures to use, a covered entity must take into account the following factors: (i) The size, complexity and capabilities of the covered entity. (ii) The covered entity’s technical infrastructure, hardware and software security capabilities. (iii) The costs of security measures. (iv) The probability and criticality of potential risks to electronic protected health information. (c) Standards. A covered entity must comply with the standards as provided in this section and in Sec. 164.308, Sec. 164.310, Sec. 164.312, Sec. 164.314 and Sec. 164.316 with respect to all electronic protected health information. (d) Implementation specifications. In this subpart: (1) Implementation specifications are required or addressable. If an implementation specification is required, the word “Required’’ appears in parentheses after the title of the implementation specifiCopyright © 2004 CRC Press, LLC

33


34


cation. If an implementation specification is addressable, the word “Addressable’’ appears in parentheses after the title of the implementation specification. (2) When a standard adopted in Sec. 164.308, Sec. 164.310, Sec. 164.312, Sec. 164.314, or Sec. 164.316 includes required implementation specifications, a covered entity must implement the implementation specifications. (1) When a standard adopted in Sec. 164.308, Sec. 164.310, Sec. 164.312, Sec. 164.314, or Sec. 164.316 includes addressable implementation specifications, a covered entity must: (i) Assess whether each implementation specification is a reasonable and appropriate safeguard in its environment, when analyzed with reference to the likely contribution to protecting the entity’s electronic protected health information; and (ii) As applicable to the entity: (A) Implement the implementation specification if reasonable and appropriate; or (B) If implementing the implementation specification is not reasonable and appropriate: (1) Document why it would not be reasonable and appropriate to implement the implementation specification; and (2) Implement an equivalent alternative measure if reasonable and appropriate. (e) Maintenance. Security measures implemented to comply with standards and implementation specifications adopted under Sec. 164.105 and this subpart must be reviewed and modified as needed to continue provision of reasonable and appropriate protection of electronic protected health information as described at Sec. 164.316.

SEC. 164.308 ADMINISTRATIVE SAFEGUARDS (a) A covered entity must, in accordance with Sec. 164.306: (1)(i) Standard: Security management process. Implement policies and procedures to prevent, detect, contain and correct security violations. (ii) Implementation specifications: (A) Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information held by the covered entity. (B) Risk management (Required). Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with Sec. 164.306(a). (C) Sanction policy (Required). Apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures of the covered entity.




(D) Information system activity review (Required). Implement procedures to regularly review records of information system activity, such as audit logs, access reports and security incident tracking reports. (2) Standard: Assigned security responsibility. Identify the security official responsible for the development and implementation of the policies and procedures required by this subpart for the entity. (3)(i) Standard: Workforce security. Implement policies and procedures to ensure that all members of its workforce have appropriate access to electronic protected health information, as provided under paragraph (a)(4) of this section and to prevent those workforce members who do not have access under paragraph (a)(4) of this section from obtaining access to electronic protected health information. (ii) Implementation specifications: (A) Authorization and/or supervision (Addressable). Implement procedures for the authorization and/or supervision of workforce members who work with electronic protected health information or in locations where it might be accessed. (B) Workforce clearance procedure (Addressable). Implement procedures to determine that the access of a workforce member to electronic protected health information is appropriate. (C) Termination procedures (Addressable). Implement procedures for terminating access to electronic protected health information when the employment of a workforce member ends or as required by determinations made as specified in paragraph (a)(3)(ii)(B) of this section. (4)(i) Standard: Information access management. Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements of subpart E of this part. (ii) Implementation specifications: (A) Isolating health care clearinghouse functions (Required). If a health care clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the electronic protected health information of the clearinghouse from unauthorized access by the larger organization. (B) Access authorization (Addressable). Implement policies and procedures for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process or other mechanism. (C) Access establishment and modification (Addressable). Implement policies and procedures that, based upon the entity’s access authorization policies, establish, document, Copyright © 2004 CRC Press, LLC

35



36

review and modify a user’s right of access to a workstation, transaction, program or process. (5)(i) Standard: Security awareness and training. Implement a security awareness and training program for all members of its workforce (including management). (ii) Implementation specifications. Implement: (A) Security reminders (Addressable). Periodic security updates. (B) Protection from malicious software (Addressable). Procedures for guarding against, detecting and reporting malicious software. (C) Log-in monitoring (Addressable). Procedures for monitoring log-in attempts and reporting discrepancies. (D) Password management (Addressable). Procedures for creating, changing and safeguarding passwords. (6)(i) Standard: Security incident procedures. Implement policies and procedures to address security incidents. (ii) Implementation specification: Response and Reporting (Required). Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity; and document security incidents and their outcomes. (7)(i) Standard: Contingency plan. Establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure and natural disaster) that damages systems that contain electronic protected health information. (ii) Implementation specifications: (A) Data backup plan (Required). Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information. (B) Disaster recovery plan (Required). Establish (and implement as needed) procedures to restore any loss of data. (C) Emergency mode operation plan (Required). Establish (and implement as needed) procedures to enable continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode. (D) Testing and revision procedures (Addressable). Implement procedures for periodic testing and revision of contingency plans. (E) Applications and data criticality analysis (Addressable). Assess the relative criticality of specific applications and data in support of other contingency plan components. (8) Standard: Evaluation. Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under Copyright © 2004 CRC Press, LLC



this rule and subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which an entity’s security policies and procedures meet the requirements of this subpart. (b)(1) Standard: Business associate contracts and other arrangements. A covered entity, in accordance with Sec. 164.306, may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity’s behalf only if the covered entity obtains satisfactory assurances, in accordance with Sec. 164.314(a) that the business associate will appropriately safeguard the information. (2) This standard does not apply with respect to: (i) The transmission by a covered entity of electronic protected health information to a healthcare provider concerning the treatment of an individual. (ii) The transmission of electronic protected health information by a group health plan or an HMO or health insurance issuer on behalf of a group health plan to a plan sponsor, to the extent that the requirements of Sec. 164.314(b) and Sec. 164.504(f) apply and are met; or (iii) The transmission of electronic protected health information from or to other agencies providing the services at Sec. 164.502(e)(1)(ii)(C), when the covered entity is a health plan that is a government program providing public benefits, if the requirements of Sec. 164.502(e)(1)(ii)(C) are met. (3) A covered entity that violates the satisfactory assurances it provided as a business associate of another covered entity will be in noncompliance with the standards, implementation specifications, and requirements of this paragraph and Sec. 164.314(a). (4) Implementation specifications: Written contract or other arrangement (Required). Document the satisfactory assurances required by paragraph (b)(1) of this section through a written contract or other arrangement with the business associate that meets the applicable requirements of Sec. 164.314(a).

SEC. 164.310 PHYSICAL SAFEGUARDS A covered entity must, in accordance with Sec. 164.306: (a)(1) Standard: Facility access controls. Implement policies and procedures to limit physical access to its electronic information systems and the facility or facilities in which they are housed, while ensuring that properly authorized access is allowed. (2) Implementation specifications: (i) Contingency operations (Addressable). Establish (and implement as needed) procedures that allow facility access in support of restoration of lost data under the disaster recovery plan and emergency mode operations plan in the event of an emergency. Copyright © 2004 CRC Press, LLC

37


38


(ii) Facility security plan (Addressable). Implement policies and procedures to safeguard the facility and the equipment therein from unauthorized physical access, tampering and theft. (iii) Access control and validation procedures (Addressable). Implement procedures to control and validate a person’s access to facilities based on their role or function, including visitor control, and control of access to software programs for testing and revision. (iv) Maintenance records (Addressable). Implement policies and procedures to document repairs and modifications to the physical components of a facility that are related to security (for example, hardware, walls, doors and locks). (b) Standard: Workstation use. Implement policies and procedures that specify 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 workstation or class of workstation that can access electronic protected health information. (c) Standard: Workstation security. Implement physical safeguards for all workstations that access electronic protected health information, to restrict access to authorized users. (d)(1) Standard: Device and media controls. Implement policies and procedures that govern the receipt and removal of hardware and electronic media that contain electronic protected health information into and out of a facility and the movement of these items within the facility. (2) Implementation specifications: (i) Disposal (Required). Implement policies and procedures to address the final disposition of electronic protected health information, and/or the hardware or electronic media on which it is stored. (ii) Media re-use (Required). Implement procedures for removal of electronic protected health information from electronic media before the media are made available for re-use. (iii) Accountability (Addressable). Maintain a record of the movements of hardware and electronic media and any person responsible therefore. (iv) Data backup and storage (Addressable). Create a retrievable, exact copy of electronic protected health information, when needed, before movement of equipment.

SEC. 164.312 TECHNICAL SAFEGUARDS A covered entity must, in accordance with Sec. 164.306: (a)(1) Standard: Access control. Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software Copyright © 2004 CRC Press, LLC



(b)

(c)(1)

(d)

(e)(1)

programs that have been granted access rights as specified in Sec. 164.308(a)(4). (2) Implementation specifications: (i) Unique user identification (Required). Assign a unique name and/or number for identifying and tracking user identity. (ii) Emergency access procedure (Required). Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency. (iii) Automatic log-off (Addressable). Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity. (iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information. Standard: Audit controls. Implement hardware, software and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. Standard: Integrity. Implement policies and procedures to protect electronic protected health information from improper alteration or destruction. (2) Implementation specification: Mechanism to authenticate electronic protected health information (Addressable). Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner. Standard: Person or entity authentication. Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed. Standard: Transmission security. Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network. (2) Implementation specifications: (i) Integrity controls (Addressable). Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of. (ii) Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.

SEC. 164.314 ORGANIZATIONAL REQUIREMENTS (a)(1) Standard: Business associate contracts or other arrangements. (i) The contract or other arrangement between the covered entity and its business associate required by Sec. 164.308(b) must


39



40

(2)

(1)

(2)

meet the requirements of paragraph (a)(2)(i) or (a)(2)(ii) of this section, as applicable. (ii) A covered entity is not in compliance with the standards in Sec. 164.502(e) and paragraph (a) of this section if the covered entity knew of a pattern of an activity or practice of the business associate that constituted a material breach or violation of the business associate’s obligation under the contract or other arrangement, unless the covered entity took reasonable steps to cure the breach or end the violation, as applicable, and, if such steps were unsuccessful — (A) Terminated the contract or arrangement, if feasible; or (B) If termination is not feasible, reported the problem to the Secretary. Implementation specifications (Required). (i) Business associate contracts. The contract between a covered entity and a business associate must provide that the business associate will — (A) Implement administrative, physical and technical safeguards that reasonably and appropriately protect the confidentiality, integrity and availability of the electronic protected health information that it creates, receives, maintains or transmits on behalf of the covered entity as required by this subpart; (B) Ensure that any agent, including a subcontractor, to whom it provides such information agrees to implement reasonable and appropriate safeguards to protect it; (C) Report to the covered entity any security incident of which it becomes aware; (D) Authorize termination of the contract by the covered entity, if the covered entity determines that the business associate has violated a material term of the contract. (ii) Other arrangements. (A) When a covered entity and its business associate are both governmental entities, the covered entity is in compliance with paragraph (a)(1) of this section, if — It enters into a memorandum of understanding with the business associate that contains terms that accomplish the objectives of paragraph (a)(2)(i) of this section; or Other law (including regulations adopted by the covered entity or its business associate) contains requirements applicable to the business associate that accomplish the objectives of paragraph (a)(2)(i) of this section. (B) If a business associate is required by law to perform a function or activity on behalf of a covered entity or to provide a service described in the definition of business associate as specified in Sec. 160.103 of this subchapter to a covered entity, the covered




entity may permit the business associate to create, receive, maintain, or transmit electronic protected health information on its behalf to the extent necessary to comply with the legal mandate without meeting the requirements of paragraph (a)(2)(i) of this section, provided that the covered entity attempts in good faith to obtain satisfactory assurances as required by paragraph (a)(2)(ii)(A) of this section, and documents the attempt and the reasons that these assurances cannot be obtained. (C) The covered entity may omit from its other arrangements authorization of the termination of the contract by the covered entity, as required by paragraph (a)(2)(i)(D) of this section if such authorization is inconsistent with the statutory obligations of the covered entity or its business associate. (b)(1) Standard: Requirements for group health plans. Except when the only electronic protected health information disclosed to a plan sponsor is disclosed pursuant to Sec. 164.504(f)(1)(ii) or (iii), or as authorized under Sec. 164.508, a group health plan must ensure that its plan documents provide that the plan sponsor will reasonably and appropriately safeguard electronic protected health information created, received, maintained, or transmitted to or by the plan sponsor on behalf of the group health plan. (2) Implementation specifications (Required). The plan documents of the group health plan must be amended to incorporate provisions to require the plan sponsor to — (i) Implement administrative, physical and technical safeguards that reasonably and appropriately protect the confidentiality, integrity and availability of the electronic protected health information that it creates, receives, maintains, or transmits on behalf of the group health plan; (ii) Ensure that the adequate separation required by Sec. 164.504(f)(2)(iii) is supported by reasonable and appropriate security measures; (iii) Ensure that any agent, including a subcontractor, to whom it provides this information agrees to implement reasonable and appropriate security measures to protect the information; and (iv) Report to the group health plan any security incident of which it becomes aware.

SEC. 164.316 POLICIES, PROCEDURES REQUIREMENTS

AND

DOCUMENTATION

A covered entity must, in accordance with Sec. 164.306: (a) Standard: Policies and procedures. Implement reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, or other requirements of this subpart, taking into account Copyright © 2004 CRC Press, LLC

41


42


those factors specified in Sec. 164.306(b)(2)(i), (ii),(iii) and (iv). This standard is not to be construed to permit or excuse an action that violates any other standard, implementation specification, or other requirements of this subpart. A covered entity may change its policies and procedures at any time, provided that the changes are documented and are implemented in accordance with this subpart. (b)(1) Standard: Documentation. (i) Maintain the policies and procedures implemented to comply with this subpart in written (which may be electronic) form; and (ii) If an action, activity or assessment is required by this subpart to be documented, maintain a written (which may be electronic) record of the action, activity, or assessment. (2) Implementation specifications: (i) Time limit (Required). Retain the documentation required by paragraph (b)(1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later. (ii) Availability (Required). Make documentation available to those persons responsible for implementing the procedures to which the documentation pertains. (iii) Updates (Required). Review documentation periodically, and update as needed, in response to environmental or operational changes affecting the security of the electronic protected health information. Note: The full text of 21 CFR Part 11, the subsequent guidance (February 2003; August 2003) and 45 CFR Parts 160, 162 and 164 appear in the appendixes.



3

Going Electronic: What You Need to Know and Do Nothing endures but change. Heraclitus

Every company’s operation is unique. While many functions are similar in companies that are in the same market space, no two companies operate exactly the same way. This is because people develop processes in response to the conditions and cultures of their companies. Further, the regulations tell you what you need to do; they don’t tell you how to do it. That’s for companies to determine. For each company it boils down to this: what will work best here? Once a company decides to go to electronic record keeping, it’s important that it select software that’s going to perform best for the intended needs and software that users and information technology (IT) will be able to install, validate and maintain in compliance with the regulations over time. This is not an easy task, but neither is it onerous. Companies must first evaluate their needs, then research available commercial off-the-shelf (COTS) software to find the best match. Multitudes of software developers tout convenient, easy-to-use products. Many claim to be compliant. Is a supplier’s claim of compliance then sufficient? For many reasons, the answer is no. First, software developers are not required to show compliance to the mandates of the Food and Drug Administration (FDA) or the Department of Public Welfare. Further, software developers don’t know how companies will use their products. What they do know is that the company, when it purchases software, will be required to show compliance. That is why they build systems that are compatible with the regulations. That’s surely a plus, but for companies subject to binding regulations, it is not enough. Finding the best match in software options requires the marriage of a company’s specific software needs with software capability. Bear in mind, as well, that software technology continues to evolve rapidly, and the options are growing rather than decreasing. To select the best software, companies must fully understand the specific role software will play within the culture of their own operations. Only with this knowledge will a successful transition to electronic record keeping occur.

SOFTWARE DEVELOPMENT AND USE: FROM THEN TILL NOW In the early days of computing, COTS software was simply not available. To gain advantages that computerized systems offered, companies developed software them-



44


selves, growing their information technology (IT) departments as they did so. They also sought out contractors who could develop programs for them. Soon software was in operation for many platforms, but the platforms had different architectures and different functionalities. This route soon proved costly, because companies quickly realized that predicate rules made ongoing maintenance mandatory. Ongoing maintenance, as a regulated requirement, posed a challenge that had to be incorporated into the overall cost. Further, as processes evolved, it followed that more functionality was needed, and software maintenance costs rose accordingly. In the early days of computing, systems were like islands, and moving data between them was impossible. Early computers differed from one another, and interfacing systems added to the cost of maintaining them. As the systems grew, maintenance costs grew proportionately. Developing and maintaining systems became expensive. In addition, problems inevitably arose when the employee who had designed a system left the company, and few if any other people knew how to operate it, much less troubleshoot it. Further, as the complexity of the computer systems increased, the need for troubleshooting grew, because more complex systems translated to more defects and failures. When failures actually affected products, the FDA made validation a requirement and started to look at systems more stringently. Companies that had developed their own software had a difficult time understanding that the software they themselves developed required validation. As a result, the FDA issued 483 observations for noncompliance and delivered warning letters. Soon companies took validation seriously and discovered that developing software themselves was indeed a costly venture that could put them in jeopardy. Although they didn’t rush out to replace the systems they had already put in place, they turned to software developers for solutions for new systems. Entrepreneurs who developed software soon saw a window of opportunity for new products. While many had the vision, however, few had mature products or abundant resources. In fact, software developers were experiencing many of the same problems companies were. Customized software could address a company’s specific needs, but the cost of creating a company-specific application was high. Thus, they sought to create software that they could sell to many customers, software that customers could then apply to fit their needs. They managed to do this by negotiating to build custom software for a client, but retaining the right to sell it to other companies who had similar requirements. That way, when another customer requested a similar product, the developer simply took the existing product and reworked it to suit the new client’s needs. The result was that much of the software was the same between clients, so creating the software for new clients became easier over time as well as more cost effective. This worked for a while, but as industry standards evolved and clients realized they could have more efficient systems, they started to ask for improvements. This meant the software developer had to revisit each product to make it better. Soon, the individual products lost their commonality with the developer’s other products and the result was that the developer again was producing customized software products. At this point, software developers realized they were back to square one: they were producing customized software and their costs were rising.



Going Electronic: What You Need to Know and Do

45

The road they found themselves traveling was not productive. Their solution was to draw upon the best and most common features individual clients wanted and merge them into smaller sets of standard products. This way, all customers received pretty much the core standard product base, but they were able to select and use the features they needed and turn off those they didn’t. By this process, developers defined their own products. When individual clients wanted a unique feature, the developers worked the feature into the core product. Configuration options were provided to clients as part of the software. Thus, clients got what they wanted and more, but developers had a product that had a general appeal to many customers. percentThis in turn led them to seek a larger market base. Soon they adopted programming standards that promoted common interfaces. With clients sharing some of the development and validation expenses, costs were reduced even further. New client requests for customizations helped evolve software even more, as developers either made the requested customizations into standard features or created more configuration options. This way, developers refined their products while the clients footed the bill. Soon existing clients realized the software was evolving and wanted the new features. Software upgrades were the answer, since they allowed all customers to take advantage of the evolving features. These products are what we now know as COTS software, although it is sometimes referred to as configurable off-the-shelf software. When a company buys software it is really buying the rights to use the software, not the software itself. The cost of the software is generally based on how many users the system will have or how many installations of the software there will be. While this seems costly, what a company pays to use the software is far less than it would if it were still developing software in-house. Further, COTS software has the added benefit of being built as the result of the input of many users, something to which the average company does not have access. A yearly maintenance fee paid to the developer, based on the total software license fee, is usually about 12 to 20 percent. Payment of this fee gives the client access to all upgrades and technical support for a year. Developers rely on dialogue with the clients to determine which enhancements the next versions of their products should have. When many clients request the same enhancements, developers often build them into future releases without additional charges. When a regulation changes to include a new requirement, most developers rework the product to incorporate it. This keeps the developer in high profile as a producer of a compliant product and keeps the systems in companies up to date. The high profile only serves to make the developer attractive to more customers. Further, as a developer gets more clients, the cost per customer usually goes down.

THE COTS SOFTWARE DEVELOPMENT LIFE CYCLE The software development life cycle (SDLC) encompasses the entire range of activities that start with the initial concept for software; it involves all development activities, operational use and ongoing maintenance, then ends with retirement.




46

During the life cycle many of the steps repeat as the software evolves and upgraded versions become available. To distinguish between developer and user validation, the product that the developer works with is commonly referred to as “software,” while the product the user works with is referred to as the “application.” The software is thus the commercial product, and the application is the specific use of software. The developer releases the software to many clients, each of whom uses the software as a different application. The following life cycle steps are applicable to COTS software: • •

•

• • • • • • • •

The developer creates the concept for software as a result of input from existing clients, its own experience and market research. The developer creates configurable software by selecting architectures, standards and methodologies that are based on its preferences and goals. The result is a product that it owns. The developer validates the software to ensure quality and intended operation to meet the needs of its clients. The product is available as COTS software. Independent of the developer’s activities, the users (clients) create a concept for a needed software application. The users purchase the COTS software that best seems to meet their application requirements. The users configure the software, create procedures and test the application to validate the application within the system they have created. The users release the application and system for production use (go-live). The developer maintains the software and issues upgrades to its clients. Users purchase the upgraded software or receive it as part of their maintenance agreement and revalidate their applications as needed. Users make controlled changes to their systems to evolve their application and improve their systems. The software developer may retire the software product, or the users may retire the application. In most cases, the system data migrates to another system, and a separate but similar life cycle takes place.

Purchasing COTS Software As software evolves, it becomes bigger and more complex and requires dedicated resources for maintenance. The requirement to validate software from the developer’s perspective makes the overhead associated with software development even larger, which is why most companies are moving from custom to COTS software. Most companies resort to custom development only as a last resort. When a company researches the market for software solutions, it must evaluate both the products and developer to ensure compliance with 21 CFR Part 11. Beware of developer claims for 21 CFR Part 11 compliance because developers make many claims based on their understanding of the regulation. Developer claims do not provide assurance that they have correctly interpreted the regula-




47

tions to meet current industry standards. When a company determines to use software from any source, it assumes complete liability for the operation of that software. The regulatory body never allows a company to blame a developer for noncompliance. Companies are increasingly turning to developers to provide solutions to evolve their computer systems. Developers have learned that it is not cost effective to provide custom solutions. Instead, they add new features requested by any customer to the product and provide configuration options that allow each customer to turn features on or off. While this works well and is cost effective, both developers and users are faced with an ongoing series of upgrades, each of which requires validation from their perspective. Choosing a Vendor When tasked with choosing a vendor, it is best to seek one with which the company can develop and maintain a long-term working relationship. Remember, the company is buying the right to use the software, not the software itself. A good developer has validated a product from the developer’s perspective and can assist a company in getting the system validated and in place. A good developer is the source of help, via a help desk, for the life of the COTS software. Before purchasing COTS software, it is necessary to identify the role the software will play within the company. The place to begin that process is by identifying the intended users and what they require. Forming a small task force with representatives from departments that will be impacted by the software is one place to start. This committee can then formulate a list of requirements that delineate what the software needs to do. Bear in mind that the focus of the list of requirements is what the software must do, not how it will do it. The next step is to do research on products on the market. Trade shows, advertisements in periodicals, direct-mail solicitation and offers of free demonstrations, discussions with industry associates who have such systems, information from employees who have worked in environments with electronic systems, and the Internet are valuable resources. It is not unusual for users to modify their requirements based on what they discover is available, because the research process frequently uncovers options they didn’t know about. The next step is to contact those vendors whose products seem most compatible with the company’s needs. It doesn’t hurt to contact many developers at first; companies typically create a “long list” of potential vendors as they begin the process. Sending a request for information (RFI) is a common way to contact a vendor and solicit information. Developers tout compliance verbally and in promotional materials. It’s best not take these claims at face value. The onus of purchasing a system that has the features a company wants lies with the users, not the developer. It’s generally prudent, then, to include the specific attributes the system must have in the RFI. Doing so will also help weed out vendors whose products cannot fulfill all the requirements. An RFI may ask for information such as the following:




48

• • • • • • • • • • • • • • • • • • • • • •

Access by authorized individuals only Password minimum length Requirements for passwords (alphanumeric) Frequency of password change Password reuse frequency Password encryption User name identification User name on screen Inactivation of a user name when a user leaves the company or department Automatic log-off after a period of inactivity Failed log-on attempts resulting in auto lockout to the system, with e-mail to system administrator Auto lockout of inactive accounts Automatic log-off from one location when a user logs on from another location Password known only by the user All user activity logs into the system Controlled delete capabilities Operational system checks of event sequencing and data input validity Audit trails to record the creation, modification or deletion of records Audit trail to record user name, date, time, previous data, new data, reason for change Configuration of reason for change as required or not for different types of data Changed data indicated to the user by on-screen indication (not only in the audit trail) Electronic signatures secure from modification or copying

Once a developer receives an RFI, it replies by explaining how its products and services can meet the user requirements. This correspondence can be verbal or written or both. Those who review the developer’s information must remain objective. It’s helpful to sort the RFI responses to form a product and developer comparison matrix. This makes comparing products with each other easier and permits more accurate assessment of the vendor and elimination of those products least compatible with the company’s needs. The result of the comparison should yield a “short list” of suitable vendors. The next step is to send out a request for proposal (RFP) to all of the developers on the short list. Companies typically carry out this chore in accord with the purchasing agent for the organization. As a formal request for information about what the vendor can deliver in terms of its products and services, the RFP is considered legally binding. The RFP usually requests information about the associated costs, software licensing policies and additional components. Cost, while important, should not be the main force driving the purchase, but it is certainly a budgetary factor. The total number of users, the number of concurrent users, the number of client installations, or the number of server installations as required for production, testing, training and Copyright © 2004 CRC Press, LLC



49

development environments all factor into cost. That said, quality and performance should drive the selection of the appropriate vendor. In addition to the software itself, companies must determine the other software and hardware components required for running the software. Database software, operating systems, additional hardware, back-up software and other software may be required and sometimes companies find that the target software developer does not make them available. Many developers are, however, willing to help in securing hardware and other components, but the cost can be higher than if the company’s IT department does it. From the RFP replies, the actual costs to be incurred should be clear, and the list can be narrowed down to one or two developers. Securing references from the vendor is next. Ideally, the references will represent relatively new clients in the same business or of the same company size. Checking references will reveal the developer’s strengths and weaknesses. Checking references may narrow the choices to one developer, not change the choices, or require a revisit to the short list of potential vendors. Sometimes the largest “name” developer is not the best choice because it has too many clients to service. Many smaller developers can provide superior products, services and support, and welcome the opportunity to do so. They may even provide appealing incentives. Once a developer is selected, the quality assurance (QA) group needs to audit the vendor and prepare a developer evaluation report. QA can conduct the audit either on site or remotely. This audit should include a review of the history of the product and developer and a review of the standard operating procedure (SOP) infrastructure that address the full software development life cycle and quality standards for the products. (See also Developer and User Validation in this chapter and Chapter 7.) If the audit results are not favorable, it is time to consider alternative developers. If the audit results are favorable, the procurement process can continue and a contract be drawn. A purchase requisition (PR) or purchase order (PO) may accompany the contract. The contract typically addresses the following: • •

•

• •

Developer product(s) and services. Responsibilities of the developer for installation. (Some companies engage the developer to perform installation, but a more effective approach is to have the developer teach the company’s IT staff the installation procedure. This provides an invaluable education for maintenance activities such as upgrades and reinstallation.) Implementation services such as training, configuration assistance and project management. (Again, it can be useful to have the developer train key company employees who in turn can train the rest of the users. This is beneficial because only the users will fully understand the application in-house.) Maintenance fees for technical support and upgrades. (Note that it’s wise to include increase limitations.) Payment schedule and method (Ideally, the contract should divide payments, with the first up front, the next after installation and the last after




50

a reasonable time for user validation. Remember that all developers are in business to make a profit and will generally be more accommodating before they receive full payment. In addition, most COTS developers will agree to more favorable terms than those they initially presented.) The purchase process for COTS software is a major component for ensuring quality. It is important to understand that developers and users come into working relationships from different perspectives, and each must accept responsibility for different aspects of the union. The developer becomes the company’s partner, and there must be a solid confidence level that they can work together for the long run.

ESCROW ACCOUNTS Sometimes companies set up an escrow account for the software source code. If there is doubt about the developer’s ability to continue to provide services or updates, an escrow account may make sense. An escrow account for COTS is much like an escrow account for a home purchase; it relies on a third-party agreement. The developer provides the source code to the escrow account holder. Companies that purchased escrow agreements can then get the source code from the escrow account holder if the software developer ceases to remain in business. Most of the time, however, companies fail to understand the escrow agreement and pay for something of little value. While they seem sound in concept, escrow agreements are not always advantageous. Each company pays an annual escrow fee that is often expensive. The escrow account keeps just one copy of the source code from which copies are made should they be needed. Nevertheless, each company has to pay the annual fee. By industry practice, developers back up all source code and store it in a secure off-site location, so the escrow agreement does not add much to their overhead. Second, there is no definitive way to ensure that the escrow holder receives the source code for each release. Nor is there a way to know that what the developer issued to escrow is comprehensive and accurate. Further, even if a company does secure the source code, it would need software development experts to maintain it. Finally, there is no way to force the issuing of the source code between the time the company stops making upgrades and the time it goes out of business. If a long time elapses, the company may be in the same position it would be without the source code agreement. Instead of relying on escrow agreements, it’s usually best to be proactive in dealings with developers. When selecting one, it’s sensible to check references, perform due diligence on financial records and evaluate the facilities. Next is verification that all data can be exported with industry standard utilities. Having a user join the COTS software user group and keep in contact with other companies that use the same products helps keep the company in touch with industry practices and provides a stronger user position for keeping the developer informed of emerging needs. There really is power in numbers. Periodic reevaluation of the developer is also judicious because, if a company is headed for ruin, there will be time to start establishing relationships with competitors that have compatible products. Copyright © 2004 CRC Press, LLC



51

If a developer does go out of business, usually a portion of the company will regroup to form a support team or another company will step in to provide ongoing support. Most of the time, another company will acquire a troubled company and provide a migration path to its products. This is the avenue to a new developer relationship. Developer and User Validation For the FDA and Part 11, validation makes sure the processes in software are correct. In HIPAA, validation is required to make sure that security features, plans and workforce training are correct. While the statement varies slightly, the result is the same in that the companies must validate the software, and the same validation approaches and concepts are applicable to both. In the text of the regulation, HIPAA doesn’t seem to require the traceablity and documentation for validation, but this will be seen in the next few years as the industry standards develop. How can a company really be sure it is compliant if it has no documentation to prove it? It seems probable that the methods that evolved under Part 11 will be adopted for HIPAA. A safeguard for validating HIPAA-driven systems is to produce documents attesting to the effectiveness of the process. Think of the nightmare that could ensue should documentation be mandated after the fact and no accurate records of the validation event exist. Many companies that develop software, and those that purchase and use it, initially perform computer system validation because it is required by federal regulation. After a few successful validation projects, most companies start to understand that computer system validation is a good business practice for many other reasons. The documentation required by the FDA and other regulatory agencies is often required by customers and business partners. Validation methodology enhances project management efforts and ensures that projects are implemented on schedule and within budget. It reduces labor costs by increasing employee efficiency and effectiveness. This in turn saves money by discovering defects early, before failures occur in production. Legal liability, not regulatory concern, is becoming the most important reason to perform validation. Software is made and used by people, so it is guaranteed to be imperfect. Software and process defects increase with software complexity. Having the evidence that computer systems are correct for their purpose and operating properly demonstrates corporate responsibility and provides a defense against claims of negligence. The FDA has understood that evidence of effective operation is necessary. Many of the predicate rules and guidance documents have spelled out the requirement for validation. An example is the FDA’s document General Principles of Software Validation. Although this is a draft document, the principles it lays out have been fundamentally accepted as standard industry practices. This document says the following: Any software used to automate any part of the device production process or any part of the quality system must be validated for its intended use, as required by 21 CFR




52

820.70. [1] This requirement applies to any software used to automate device design, testing, component acceptance, manufacturing, labeling, packaging, distribution, complaint handling, or to automate any other aspect of the quality system. Such software may be developed in-house or under contract, but it is most likely to be purchased offthe-shelf for a particular intended use. This off-the-shelf software may have many capabilities, only a few of which are needed by the device manufacturer. The software must be validated for those specific uses for which it is intended. All production and/or quality system software must have documented requirements which fully define its intended use and against which testing results and other verification evidence can be compared, to show that the production and/or quality system software is validated for its intended use. (Guidance for Industry, General Principles of Software Validation, CDRH, Version 1.1, June 1, 1997.

The FDA made validation of software for its intended use a requirement in Part 11: “Validation of systems to ensure accuracy, reliability, consistent intended performance and the ability to discern invalid or altered records.” (21 Code of Federal Regulations, Part 11; Electronic Records; Electronic Signatures; Final Rule §11.10.) To validate software for its intended use, validation must be performed from both the developer’s and user’s perspectives. The software user assumes complete liability for the operation of that software; therefore, the users must ensure that both developer and user validation have been performed. When users purchase COTS software, they must ensure that the developer has adequately performed validation. Developers of COTS software generally do not have any FDA or other regulations that apply directly to them because they are not distributing a regulated product such as a medical device. Software validation performed by developers cannot satisfy regulatory requirements because such developers, either external or in-house, are not the users and do not know the specific application of the software. Only the users fully understand the specific use of the software. Users make changes to the software as their business processes evolve; they must therefore perform validation of the software application on an ongoing basis. Within industry today, software validation is often not performed or is inadequately performed because companies fail to understand that user and developer software validation are different. Many companies do not have staff with the broad range of experience needed to perform developer evaluation and user validation activities, and some companies mistakenly believe they have completed software validation by performing a developer evaluation. Developer evaluation and qualification is part of the software validation process and helps fulfill regulatory requirements.But the effort expended to identify the software product and evaluate the developer is only a small portion of the entire software validation effort. Software validation guidance documents are riddled with technical terms that describe both developer and user software validation. This may contribute to companies’ confusing the activities that developers should perform with the software validation activities that the users should perform. The requirements of software validation from the user’s and developer’s perspectives do have many steps in common, but the focus of each step is somewhat different. The following table Copyright © 2004 CRC Press, LLC



53

User

Developer

Determines what the software has to do to carry out the specific business processes Determines how the software functions will be used to meet the needs of the end users Determines what testing demonstrates that the software application operates as intended

Determines the functionality the software needs to have to be useful to the users Determines how to develop the functions the software must have Determines what demonstrates that the software is capable of performing the pre-defined functions Not applicable

Determines what testing demonstrates that the software is installed correctly Determines whether users know how to use the software to perform their jobs Determines the potential hazards (risks) associated with the use of the software and associated business processes Determines how changes to the software configuration and business processes are to be managed Determines when and if the system is ready for production use

Determines the content of training materials that explain how the software can be used Determines the potential hazards associated with the software as related to its interaction with the operating environment Determines how changes to the software functions are to be managed Determines when and if the product is ready for sale (release)

illustrates the differences in the software validation prospective between the user and developer: Developer Validation Developer validation of software is required regardless of whether developers, in-house staff or contractors develop it. The process of developing and validating software is a primary method for establishing software quality. Users must ensure that the developer has procedures in place that require all versions of the software to be validated in a consistent manner. The evaluation team should review the developer’s procedures to ensure that all required elements of the software development life cycle are addressed. Then, the evaluation team should verify that the validation deliverables follow the governing procedures for the specific version of software they are interested in buying. Every developer has a different set of procedures, but even if the information is organized in different formats, the content should cover the following: Product Requirements Product requirements define the product objectives. Many developers incorporate the product requirements into the design specifications. Often companies will describe product requirements only in marketing and sales materials. Software makers determine product requirements by asking questions like these: • •

From a business perspective, what is the software intended to do? What primary functions does the software perform? What regulatory requirements and industry standards (21 CFR Part 11) are supported?




54

• • •

Who are the intended users of the software? What operating environment is required to run the software? What range of system sizes is the software capable of supporting?

Software Development Project Plan The software development project plan describes how a specific version of the software will be developed, validated and released to customers. Some developers use the same plan for every project. In that case, a separate plan is not needed. The plan answers the following questions: • • • • •

How will the system be developed and validated? Who are the project team members? In addition to the software, what product deliverables are needed? (training materials, user manuals, release notes and so forth) When does the software need to be issued to customers? Who is responsible for product release?

Design Specifications Design specifications provide the details for the product requirements. The specifications provide instructions to the developers so they know what to implement in the software. In essence, design specificaion s result form answering these questions: • •

What are the functions that support the product requirements? What configuration options will be provided?

Technical Specifications Technical specifications provide details of how the design specifications are transferred into program code. Many developers claim they incorporate the technical details into the design specifications, but usually they are not present. Developers determine specifications by answering the following questions: • • •

How are the design specifications translated into the software architecture? How is the technical design and program code reviewed to ensure quality? What development tools and information (build notes) are needed for creating the executable program code?

Testing Developers test their software to ensure that individual program functions are working as intended. Testing is often referred to as unit testing. Only the program developer knows the exact computer instructions used to perform a function. Software testers cannot perform this level of testing. Rarely do developers document their testing. What is needed is assurance that each has tested the code before release to the next step in the development process. The question to answer is this: •

How did the developers verify operation of the program?




55

Release Notes Release notes are a critical deliverable that must accompany every software version update. They describe what new and changed functionality is present and what functionality is known to be incomplete or defective (bugs). Before a user can place an upgraded software version into production use, the users must perform user validation. Most often this takes place in a test environment, and all changes are tested, as are the functional areas that have been potentially impacted by the changes. The notes should contain answers to the following questions: • •

What changes, new features, bugs, incomplete development, or other issues do the users need to know about? What user documentation and training materials are provided to assist users in their revalidation efforts?

Design Hazard Analysis The design hazard analysis measures the risk associated with the design and technical specifications. The objective is to determine, before the software is fully developed, what could possibly go wrong and provide preventive measures as part of the design. Most developers claim that this form of risk assessment is included in the design and technical specification, but usually no documentation of the assessment has been made. These queries warrant answers: • •

What risks are associated with design of the system and how can users be affected? How are these risks mitigated?

Software Quality Assurance Test Protocol The software quality assurance test protocol details how the quality of the software is assessed independently from the software developer. Often this documentation is called a test plan. Many companies find that paper documentation is difficult to manage and use during testing and have resorted to placing the test cases in an online database that may contain the test results and be used to track defects as well. The test plan should address all product components such as the program code, user manuals, training materials, installation scripts, operating environment requirements, release notes and so forth, as follows: • • •

How will the software be tested? Who will perform the testing? How are defects managed?

Software Quality Assurance Test Report The software quality assurance test report contains the results from testing, proof that test results have been approved by a responsible second party, a description of any outstanding defects (bugs), and provides authorization for the software to advance to the next stage of development. Many companies that use online databases Copyright © 2004 CRC Press, LLC



56

for the test plan do not create documentation for the test report. In that case, there must be documentation that ensures all defects are appropriately addressed and an authorized person has released the appropriate version of the software. Important queries here are the following: • •

How are test results approved? What are the test results and readiness of the software?

Product Release Product release is the formal process of issuing the completed product package, including all product components, to the end users. Once the product is released, it may be duplicated on media such as a CD or placed on a web site for download. Procedures must be in place to ensure that the appropriate complete product package is made available and functions correctly. Typically, the customer service group tests the product packages as part of the release process. The process should answer the following questions: • •

Who approves release of software to the customer? How are the released product packages verified?

If a developer does not have procedures for documenting the required elements, users must decide if the developer is going to be a suitable long-term partner. Sometimes, a company will hold off making a purchasing decision until the developer has had time to take corrective actions. Many developers will readily make changes to their process because they know that if one evaluation finds a problem, most likely another one will find the same.

USER VALIDATION When a company has completed a developer evaluation and the contract has been signed, validation of the software application can begin. The focus changes from how to build the software to how the users will employ the software to accomplish their business processes. Often management incorrectly believes software validation activities can be assigned to the developer or temporary personnel. This approach fails because neither the developer nor a temporary resource has the understanding of the company culture and its business processes. In addition, users do not gain the education and experience needed to operate and maintain the computer system and business processes. This approach also fails to build the relationship between the developers and users that is necessary for validation of software upgrades and subsequent software validation projects. User validation is not going to go away, and, as more systems are deployed and interconnected, more validation and revalidation will be required. It is for this reason that the users themselves must be the ones to perform validation. User validation is an essential skill that should be part of everyone’s job. Since users are going to be involved with an endless series of validation projects, it is to their benefit to become Copyright © 2004 CRC Press, LLC



57

experienced and efficient at performing validation. From this process, users gain detailed understanding of the computer system and are better able to keep the processes that involve the computer system up to date and efficient. All of the revalidation time and effort pays for itself by reducing future problems. Management may have difficulty measuring the lack of problems and therefore may not be able to justify the resources required for user validation work. It really is very simple to understand by equating it to what would happen if an automobile is not maintained; eventually it will break down and strand its negligent owner. The cost of repairs, the risk to safety and the overall stressful situation would result in costs that are orders of magnitude higher than what preventive maintenance costs would have been. Modern software is highly configurable and no two applications are identical. All software, regardless of origin, must be validated from the user perspective. Indeed, the regulations call for validation of the software for its “intended use.” Modern software is highly configurable and no two applications of the same software are identical. While validation provides some measure of confidence that the software can work as intended, the developer is not the user and cannot know the actual intended use. User validation involves the computer system and the processes in which it is used. Computer system validation from the user perspective is itself process validation. User validation is not intended to repeat the developer’s validation. In user validation the users gain detailed understanding of the system to create processes that are meaningful to their businesses. Testing is intended to show that the functions work according to the configuration and specifics of the application. Typically, when a new software product is implemented, there is a long and difficult user validation project. The users must be trained to use the software and adapt existing processes to new methods. Software features have to be evaluated to see how they can be used to improve the current processes. Users must develop manual work-arounds for features that are not present in the software. The process of validating the application of software in the context of the system is a primary method for establishing software quality. The computer system consists of the hardware, operating system, software utilities, application software, user instructions, training materials and the validation documentation. Every company should have a computer system validation procedure that outlines the contents of each user validation documentation deliverable. This documentation will be used as the basis for revalidation projects, so it is worth the time and effort to make the procedure clear and understandable from its origin. The validation process is less onerous when viewed as a series of steps that compose the whole. Following ten steps leads the way to validation of the system. But first, however, it’s important to make sure that upper management is committed to the process and that there are representatives from every area who will have access to and use the COTS software. These people should be the end users of the system, and they should make up a validation team and serve as liaisons with their respective areas within the company, so that all employees remain informed of progress. Typically, one person serves as the validation lead and guides the process from inception to completion. Each step of the process produces documentation that Copyright © 2004 CRC Press, LLC



58

captures the events in the validation. (See Chapter Four for more information on documentation.) By the time the validation is complete there should be a validation packet that contains all the documentation relative to the validation.

TEN STEPS

TO

COMPUTER SYSTEM USER VALIDATION

Step One —While selecting a vendor and purchasing a product is part of the validation process, the actual in-house validation activities do not begin until the product comes to the company. The first activity should be to identify the actual user requirements. Even though the company selected the vendor based on user requirements, it’s a good idea to revisit them at this point, because as users research the market and learn about available products, the user requirements may change. Step Two —The logical next step is a plan. The project plan details the resources for the user validation project. It also identifies any related projects, timing requirements or dependencies. In essence, the plan is the roadmap for the validation. Step Three — This is the plan for installing the system in-house. Users must take responsibility here, even though the primary resources may be the internal technical staff and developer representatives. Here is where to determine who will install the system and how. Step Four — Once the installation is complete, it is time to assess the results. Were there any discrepancies from the installation plan? The post-installation assessment leads logically to the next step. Step Five — Once the system is in place, it is time to set the functional specification to identify and describe all of the software functions that are to be used to implement the system. Typically, all menu pathways are traversed to create an outline of the available functions. The functions should be described according to how they will be used for each specific application. Functions that are not expected to be used should be identified as such. All configuration options should be listed and the selected values explained. All security privileges and roles should be defined without specifying individual names. Sometimes configuration options are centralized in the software, and other times they are spread out among modules or functional areas. Developers may list configuration options as “customizations” or “preferences.” However, in COTS software, the concept of a customization involves changing the program code, so these terms can be misleading. Preferences that affect only cosmetic features for individual users do not need to be included with the specifications for the configuration. Step Six — Step Six is hazard analysis. This makes an assessment of each function in the context of the processes in which it is used. The hazard analysis assumes the function is not working as intended and defines what effect this could have on the system processes. Once the effects are known, mitigations are defined to limit the probability or severity of the hazard. Validation requires users to demonstrate that the system is working as Copyright © 2004 CRC Press, LLC



59

intended and know when the system is not working properly. The hazard analysis frequently results in changes to system processes that in turn affect the functional specifications. Step Seven — Step Seven is testing the system with actual users to verify the operation of each function in the context of the processes in which it is used. To prepare for this step requires users to receive training in the system. The validation team members have the most experience with the system and typically are the ones to train the trainers or train the end users directly. (See Chapter 4 for more information about training.) Whenever possible, real data should be used, since it exercises the system in the conditions of its application. Only functions that are planned for system use need to be tested. Often during testing, the users will find failures that were not found during developer validation. It is important to have open dialogue with the developer to ensure quick resolution. If failures are frequent, companies should consider further evaluation of the developer and validation documentation, before deciding to place the system into production use. Step Eight — The next step is to assess the testing. Test results need to be reviewed by someone other than the tester. In essence, this is the time to determine if the system is working as it should be and that users know why and how to use it. Step Nine — Step Nine is verification that all system components are available and the system is ready for production use. Many companies use the system release report as the means to approve the system for production use. Some companies use a change order process to make such approvals. This is also the point at which to determine which additional users need training, who will do the training and who will manage and maintain the system. Step Ten — System review occurs after the system has been used in production for a set period of time. In most cases, this is a period of 15 to 30 days. At the end of the period, the number and severity of the changes are assessed to determine the success of the validation process. If there are a few minor changes, that is normal. If there are many or significant changes, it may mean that validation was incomplete or inadequate. Sometimes portions of the validation project must be repeated and process changes are required. In this case, care must be taken to verify that production use of the system is carefully reviewed to ensure accuracy and safety. Only when there is a high degree of confidence that all essential user requirements have been met should there be final approval for system operation.

USER

AND

DEVELOPER COMBINED VALIDATION

In some cases, in-house development staff or contracted development groups can work closely with the users to develop software. Often this applies to customizations used to interface two systems, and developer and user validation efforts can occur conjointly. The developers and users still have their separate objectives, so care must Copyright © 2004 CRC Press, LLC


60


be taken to include the necessary steps from both perspectives. A benefit of interfaces is that they make the transfer of data seamless and thereby increase efficiency. At the same time, the new software that has been developed must be maintained. The interface software must be evaluated each time any system connected to the interface is changed to determine whether it requires modification and revalidation. Often the interface must be revalidated to make the evaluation. Interfaces often require more maintenance overhead than originally thought. This is why the adoption of standard interfaces made available through programming standards is so important. Operating Environments Software executes in an operating environment, which is a subset of components that compose the system. The software operates in conjunction with the computer hardware, operating system and other software components. Every system has at least one operating environment: the production environment. Additional operating environments may be necessary to provide a place for users to validate unreleased software or to separate test and training data from production data. Users should establish operating environments as part of the initial software installation, but additional operating environments may become necessary as the system matures. For a new system, the production environment may be suitable for the validation and training activities. In this case, users must ensure that nonproduction data is not intermixed with production data. This may or may not be possible with a single operating environment. For most document control and clinical trials systems, users can subdivide the production environment into separate areas. Other systems may not have a means to segregate the data. When a system is first installed, the focus is on the initial validation project. If subsequent revalidation scenarios are not considered, future validation efforts may be significantly hampered by the lack of foresight. The system consists of many hardware and software components. Users must assume that any and all of these components will be changed or replaced over the lifetime of the system. Each time a change is made, it must be validated without affecting the system in production use. The key to revalidation is its completion before making the change to the production environment. In this manner, any failures, problems or updated documentation are addressed before any potential impacts to production data and released products. The software components for a server may include application software, database software, operating system software and various software utilities. To update any of these components without affecting the production environment, a totally separate computer server is needed. Usually this second server, referred to as the “test server,” is used for validation, training, development and experimentation. One benefit of having a second server is built-in redundancy for disaster recovery. If the production server fails, the test server can be wiped clean and rebuilt as the production server. It is critical to have the test and training environments match the target production environment. This means that all software components must be exactly the same version and have the same configuration settings. Users must be confident that the Copyright © 2004 CRC Press, LLC



61

production environment will work exactly the same as the environments used for validation and training. Therefore, it is best to decide on the number of operating environments and include their creation as part of the initial installation activities. Some companies elect to have more than the production and test operating environments. There may be a need for a software development environment or a separate training environment. For critical applications, there may be redundant production environments with automatic switchover or load-balancing functionality. Each operating environment requires ongoing maintenance to keep it up to date. When a change is made to one environment, that environment becomes different from the others. This difference is fine for a period of time, but at some point, the other environments will have to undergo the same change to keep them up to date. For example, assume a company has three environments: production, testing and training. For the initial validation project, all three environments need to be the same. The users need to validate in the test environment; the production environment must match the test environment; and the training environment must match the production environment. All three environments start out the same, but configuration changes during validation in one environment must be made to the other two. Now assume the initial validation project is complete, the system is in production use and another change is necessary. First, the change is made only to the test environment. This allows the users to validate the change without affecting the production environment. The training environment must remain unchanged because current training must be performed in an environment equal to the production environment. Once the change has passed validation, the change can then be made to the training environment, which allows the users to be trained before the change is made to the production environment. Once the users have been trained and the appropriate documentation is updated, the change can be made to the production environment. At this point, all three operating environments match again. This approach is not too difficult when only one change happens, but it gets challenging when several changes are involved. Most companies struggle with the best approach for each system. One approach is to require each change to be fully processed with all operating environments updated before another change can be initiated. Another way is to batch a set of changes. While the batch tends to delay changes, it helps keep updates to procedures and other documentation manageable. Most companies employ both approaches with single changes reserved for emergencies, and all other changes made in a batch. The batch approach has limitations, however. If you batch too many changes, the interactions can be difficult to predict and validate. Usually it is best to have several small batches spaced a few weeks apart rather than have one large batch. The time between batches is important so that any problems in the production environment can be associated with the proper batch of changes. Computer System Validation Computer systemvalidation of instruments and devices was well understood before computers were in wide use and computer software validation (CVS) became the norm. The standard approach for this type of validation took the form of installation Copyright © 2004 CRC Press, LLC



62

qualification (IQ), operation qualification (OQ) and performance qualification (PQ). Typically, each qualification was documented as a protocol and a report. In some cases, all three qualifications were combined as sections of a compound protocol. To reduce documentation further, some protocols were written so that the results could be recorded directly in the same documentation, thereby making the protocol and report one document. When the first computer systems were deployed, many companies relied on the validation approach they knew. While the IQ/OQ/PQ model worked well for standalone instruments and devices, the complexity of computer systems required an updated validation approach. In early computer system validation efforts, the IQ/OQ/PQ approach was used to validate the computer hardware. Since the approach did not directly relate to the software, validation was often completely ignored. Current industry practices have since created the following system component categories: • • • •

Dedicated hardware: stand-alone instruments and devices, not themselves general-purpose computers Computer hardware: stand-alone general-purpose computers (PCs, servers, workstations) Software: programs developed to run on general-purpose computer hardware Application: software uses for a specific intended purpose

Validation Models for System Components •

•

•

Dedicated hardware is typically validated using the IQ/OQ/PQ approach. IQ provides installation instructions for the hardware as configured for the target system. Operational Qualification (OQ) demonstrates that the hardware is functioning according to the developer’s specifications. PQ demonstrates that the hardware is functioning according to the specific system (user) requirements. Computer hardware is typically validated using only IQ. IQ provides installation instructions for the hardware as configured for the target system. OQ is not required because the computer hardware is tested when the application software is validated. PQ is not required because the computer hardware is tested when the application software is validated. Software is validated with primary steps including the following: • Product requirements • Design specifications • Technical specifications • Quality assurance testing • Application software is typically validated as computer system validation (CSV). It focuses on the process of implementing an entire system, rather than a single device. CSV’s primary steps include following the ten steps delineated in the Computer SystemValidation section of this chapter. CSV for application software includes all aspects of the IQ/OQ/PQ approach. The installation stage of computer system vali-




63

dation addresses installation of the computer hardware and application software. The user testing stage of computer system validation addresses operational qualification by testing the functions to be used in the system and any connections (interfaces) to dedicated hardware or other systems. Each function should be tested with all applicable scenarios: • • • • •

Normal or expected activities using real data Unexpected data, improper data types, error conditions, empty fields, zero values Data on boundaries; less than, equal to, greater than Exercise of relationships between data Exercise of interfaces to dedicated hardware and other systems with normal and abnormal conditions

The user testing stage of computer system validation addresses performance qualification by testing the application software and computer hardware working together as a whole system: • • • •

Maximum realistic number of simultaneous users (software licensing contstraints) Data size limitations Response time slowdowns based on use and processing activities Effects on other systems

Each system has a unique blend of hardware and software components. The validation portion of the change control process can use the validation approach that best suits the change to be made. Users must decide which approach provides comprehensive validation while minimizing the resources and documentation requirements. For example, if a software patch is needed, the installation stage of computer system validation may be all that is necessary to perform and document the validation activities. For a configuration parameter change, the user testing stage of computer system validation may be all that is required. For a minor process change, again the user testing stage may be required along with revision of any affected documents. Minor software upgrades may be handled as a change control batch or a full validation project with testing focused on the changes from the previous version. The latter approach is a bit more time consuming but keeps the validation documentation up to date and ready for when it is needed as part of a major software upgrade. Major software upgrades are usually handled as a new computer system validation project. The previous computer system validation project documentation is used as the basis for the new project. All changes made to the software application and system need to be included in the new project documentation. For this reason, it is often best to spend a little time updating the documentation for each minor software revision, rather than spending a lot of time trying to remember and update the documentation during the major software revision project.



64


RETROSPECTIVE VALIDATION Retrospective validation means validation that takes place after the computer system has been placed into production use. 21 CFR Part 11 requires that computer system validation take place prior to production use. This includes all system changes and revalidation efforts. For systems that were in place prior to 1997 when the regulation was promulgated, or for systems that were placed into production without proper validation, companies must perform retrospective validation. In the mid-1990s the idea of validating a system based on review of the historical records was discussed within industry and with the FDA. Many companies thought that demonstrating that the system did not show a history of failures would allow them to avoid the rigor of user validation. Some companies made significant efforts to review failure logs and system changes, but they had no methodology to follow and they had little documentation to make their case. Some retrospective validation efforts took longer than what would have been needed for a prospective validation project. When the FDA reviewed these retrospective validation reports, it often agreed there was evidence that the system was working as intended but it found little evidence to show that the system would work correctly in future conditions and scenarios. The FDA thus rejected the “look-back” retrospective validation approach. Today, there is no acceptable excuse for not performing prospective user validation. However, if a company has put a system into production use without performing validation, it is better to perform validation retrospectively than not at all. It is one thing to perform validation late; it is entirely different and much more severe to not perform validation at all.



4

Documentation and Training Have common sense … and stick to the point. Somerset Maugham

“Write it down” is the caveat in regulated industries. As far as the Food and Drug Administration (FDA) is concerned, “If you didn’t write it down, it didn’t happen.” It’s therefore imperative that companies have documents required to put a commercial off-the-shelf (COTS) software system in place and manage it effectively. When a company determines to go to electronic record keeping, it must produce an infrastructure of documents that show how the system works, who knows how to manage it, and what’s in place to ensure its security and integrity. While 21 CFR Part 11 is explicit in this requirement, predicate rules for the industry also call for extensive documentation. The requirements are not as clear cut for compliance with 45 CFR Parts 160, 162 and 164 relative to the Health Insurance Portability and Accountability Act (HIPAA). However, when you consider that some FDA-regulated companies that conduct clinical trials will also have to comply with HIPAA for patient record keeping, it’s important to remember that there are predicate rules that mandate documentation. It’s a small step from there to determine that good supporting documentation makes good business sense when a company determines to go to electronic records. Indeed, as industry standards evolve for HIPAA, we will see if the practices ultimately follow those already established for Part 11. It seems likely that they will. Moreover, whether they do or not, good documentation paves the way for more efficient systems management going forward. Following the directives for Part 11 compliance can thus make good sense for HIPAA-driven systems. For Part 11 compliance, companies must produce documents that detail the system validation step by step, from first identifying user requirements to taking the system live into production. The documentation that accompanies going to an electronic record keeping operation may extend as far as human resources records and documents, as well as correspondence with and information from the software vendor. It will surely encompass dialogue between the company and the FDA and can apply to dialogue with the Department of Public Welfare, which oversees HIPAA. What this all translates to is a small mountain of documents that serve as the proof of compliant installation and operation.




66

Where does the documentation to support electronic record keeping start? The first step is to identify the documents the system needs to have in place. All information from the software vendor such as correspondence, agreements and product information are integral to the documentation infrastructure. Then there must be a repository for all the documents required by the installation, validation and release into production. There also needs to be an infrastructure of procedures that delineate everything from vendor selection to system operation and document management to employee training. And, employees should be trained in using the system that is undergoing validation. Moreover, training on procedures that are put in place to support the system is necessary.

THE VALIDATION PACKET A good way to begin the documentation process is to start a validation packet that compiles all the documentation associated with the validation. The point to begin the compilation of data is at the very beginning of the process, in fact, right at the decision to go to an electronic system. The validation packet will then continue to grow as the company moves toward having a working system in place. The packet can take many forms, and the one a company chooses should be the one that works best within that company’s culture. If, for instance, the company has an electronic documentation system, documents produced as part of the validation will logically reside in the system as they are reviewed and approved. However, much of the documentation that supports a validation may be in hard copy. Such documentation can be scanned into the electronic system, or it can be placed in a large binder with separate sections for the various documents that confirm the validation steps. Thus, a physical binder, or an electronic folder, or a combination of both, can serve to capture the validation documentation. Preparing the binder in reasonable sequence allows the inclusion of related paperwork as the project progresses. It is also a ready reference for charting progress during the validation since it builds in tandem with the steps in the validation process. And, it encompasses the process of assessing supporting documents that must be in place to support the electronic record keeping system. The following is an example of a sequence of sections that affords a logical arrangement for final presentation. These mirror the validation process described in Chapter 3: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Introduction/Overview User Requirements (Step One) Vendor Information Contracts, Invoices, Receipts and Correspondence Project Plan (Step Two) Installation (Plan and Confirmation; Steps Three and Four) Functional Specifications (Step Five) Hazard Analysis (Step Six) Testing (Plan and Confirmation; Steps Seven and Eight) System Release and System Review (Steps Nine and Ten)



Documentation and Training

67

By the time a company is ready to begin the documentation process, it has accumulated information such as lists of requirements for systems and end users, purchase orders and agreements with the vendor. These documents can go into section three, Vendor Information. The product and vendor comparison matrix and vendor evaluations that led up to the vendor selection and subsequent qualification can also go into this section. Reference checks from any of the vendor’s other clients as well as queries to and responses from the vendor, such as the request for information (RFI), belong here. This section is the place to put any vendor brochures and sales information that explain the system. A vendor’s claims often reflect its expertise, and promotional material gives a “bird’s-eye view” of the system for anyone reviewing the validation. Promotional materials may also include a list of the vendor’s clients; such a list provides additional support for the rationale for purchasing and using the system. If the vendor has made any information available about its quality system, this is the place to include it. (Remember, a large binder was the recommendation.) Even if the purchasing or legal department retains original licensing agreements and contracts, copies should reside in the binder, as should copies of purchasing requisitions or purchase orders. Other documents that show proof of a sound software procurement process and a working relationship between the company and the vendor are also valid additions to the binder. Section four, Contracts, Invoices, Receipts and Correspondence, is the place to house these documents. In this section as well belong all contractual deliverables, the itemized services the vendor will provide and the schedule of payments. Typically, the payment agreements are for 90 percent of the cost up front and the final 10 percent when the system is up and running, but other arrangements, such as two thirds up front and one third when the system is in production, are possible. As the validation process moves forward, there will undoubtedly be correspondence with the vendor such as queries and responses about installation or operation. These can build into section four chronologically. Section six, Installation, is the place to put the vendor’s loading instructions. All documentation related to the installation itself belongs in this section. If, for instance, there were problems in installation, this is the place to detail them and their resolution. Finally, this section needs to identify who actually performed the installation. Sometimes vendors will send technicians (for a fee) to install the software; sometimes companies engage consultants to perform installation; and sometimes company information technology (IT) staff handles it. A record of the actual people who install the software belongs here. As the validation project proceeds, other sections of the validation packet build systematically. As documents for each phase of the validation are completed, reviewed and approved, they move into the binder. The binder reflecting the initial system validation is complete when the system is in production and a system review report in place. An introduction or overview, which is optional, can wrap it up. Such a component summarizes the process, so anyone assessing the validation can see at a glance what the validation set out to do and what the validation accomplished. Copyright © 2004 CRC Press, LLC



68

VALIDATION DOCUMENTS The validation process, from start to completion, involves the generation of validation documents. These documents provide the complete picture of what was planned and what happened and what the outcome is. They lay the foundation for the operation of the system, capture issues that need to be addressed and serve as the base upon which to build future validation efforts for the system. Companies that have a formal validation process in place typically produce templates for the validation documents. If no such templates exist, the validation effort itself is a good place to set the standard and develop a template that can be used for other validation projects. Templates for validation documents can parallel those used for standard procedures in that they can have a standard heading identifying the document as a validation document just like a standard operating procedure (SOP) does, a document number integral to the company’s document control system, a title identifying the document as a plan, functional specifications, or system review and so forth. These documents work well with a numbering matrix. For each document, the first item should be a purpose statement. The following documents are examples of those typically produced in a validation effort.

USER REQUIREMENTS Even if the company has defined user requirements as part of the software procurement process, it is a good idea to revisit the requirements, because the software the company ultimately purchases may provide more or different options from those originally sought. The first document should capture the user requirements in relation to the system to be installed in the company. The user requirements document gives the following information: • • • • •

The purpose of the document (to identify the user requirements) What the system needs to do for the intended users Who will use the system (individuals and groups) What the preferred operating environment is What size system is needed (taking into consideration projected growth of the company)

Project Plan The project plan details the resources for the user validation project. It also identifies any related projects, timing requirements or dependencies. It gives the following information: • • • •

The purpose of the plan (to spell out the validation project) How the system is to be validated Who will validate the system (specific people) What the validation deliverables are (identification of the documents that must be in place)




• •

69

When the system is needed in production Who carries responsibility for budgeting system costs

Installation Protocol The installation protocol spells out the installation instructions and installation test cases. Users must take responsibility for this document even though the primary resources may be the internal technical staff and developer representatives. Included should be the following: • • • • •

The purpose of the protocol (to lay out the plan for the installation) Who will install the system What will be installed How the system will be installed and tested What operating environments will be created (production, test, training, development)

Installation Report The installation report summarizes the installation results, describes any discrepancies from the Installation Protocol and finalizes the installation stage of user validation. It contains the following information: • • •

The purpose of the report (to assess the installation) What the installation results are What outstanding issues resulted, if any, as well as their resolution

Functional Specifications The functional specifications identify and describe all of the software functions that are to be used to implement the system. Typically, all menu pathways are traversed to create an outline of the available functions. The functions should be described according to how they will be used for each specific application. Functions that are not expected to be used should be identified as such. All configuration options should be listed and the selected values explained. All security privileges and roles should be defined without specifying individual names. Sometimes configuration options are centralized in the software and other times the configuration options are spread out among modules or functional areas. Developers may list configuration options as “customizations” or “preferences.” In COTS software, the concept of a customization involves changing the program code, so these terms are misleading. Preferences that affect only cosmetic features for individual users do not need to be included with the specifications for the configuration. Specifications need to cover the following: • •

The purpose of the document (to describe the functional specifications) Which functions implement the user requirements




70

• • •

How the system will be configured How existing and new processes will be performed by the system How each function in the system is to be used

Hazard Analysis The hazard analysis makes an assessment of each function in the context of the processes in which it is used. It assumes the function is not working as intended and defines what effect this could have on the system processes. Once the effects are known, mitigations are defined to limit the probability or severity of the hazard. Validation requires users to demonstrate that the system is working as intended and know when it is not. The hazard analysis frequently results in changes to system processes that in turn affect the functional specifications. The analysis should contain such information as: • • •

The purpose of the document (to identify risks) What are the specific risks are associated with use of the system How risks are to be managed

User Testing Protocol The user testing protocol describes the test conditions, test data and expected results to verify the operation of each function in the context of the processes in which it is used. Whenever possible, real data should be used since they exercise the system in the conditions of its application. Only functions that are planned for system use require testing. It is not unusual for the users to find failures during validation that the developer did not identify. It is therefore important to have open dialogue with the developer to ensure quick resolution. If failures are frequent, companies should consider further evaluation of the developer and validation documentation before deciding to place the system into production use. The protocol includes: • • • •

The purpose of the document (to describe the system testing) How the system will be tested Who will perform the testing (specific people) How defects, if any, are managed

User Testing Report The user testing report describes the results of the testing, identifies the deviations from the user testing protocol and includes the test results. Someone other than the tester needs to review test results. Test results must be documented so they are readily available during an audit. Today, most test results are still documented on paper as screen shots and reports. The report contains the following: • • •

The purpose of the report (to assess the testing) How test results are reviewed and approved The results from testing




71

System Release Report The system release report is used to verify and document that all system components are available and the system is ready for production use. Once testing is complete, the main emphasis is on review and approval of the SOPs and other documents that describe how to use and maintain the system. These documents, along with supplemental training materials, are the basis for user training. Since the validation team members have the most experience with the system, they typically are the ones to train the trainers or train the end users directly. Many companies use the system release report as the means to approve the system for production use. Some companies use a change order process to make such approvals. The report outlines: • • • • •

The purpose of the report (to send the system into production) When the system will be put into production use Which users require training Who will train the users How the system will be maintained under change control

System Review Report The system review report is written after the system has been in production for a set period of time. In most cases, this is a period of 15 to 30 days. For systems that are used infrequently, this time period may be longer. At the end of the period, the number and severity of the changes are assessed to determine the success of validation process. A few minor changes are normal. If there are many or significant changes, it may mean that validation was incomplete or inadequate. Sometimes portions of the validation project must be repeated and the process changed. In such a case, care must be taken to ensure that production use of the system is carefully reviewed to ensure accuracy and safety. This report verifies that the user requirements have been met by the system in production. Only when there is a high degree of confidence that all essential user requirements have been met should the system review report be approved to indicate the end of the validation project. The report delineates: • • • •

The purpose of the document (to assess whether the system is working as intended) How the system works in production What deficiencies, if any, there were in the validation Who is responsible for approving the completion of the validation project

SYSTEM SUPPORT DOCUMENTS The plan for the validation should have identified the documents the system requires for support. To create an environment that is compatible and compliant with the binding regulations, SOPs reflecting acceptable processes are necessary to build the infrastructure of support for the system. These documents must be



72


approved through the company’s existing system for document preparation, review, approval and issue. Other documentation that may need generation or review are logbooks, correspondence with the FDA, user accountability confirmation and reference documents that identify responsibilities such as who may officially approve and sign documents.

STANDARD OPERATING PROCEDURES What SOPs does the new application need to support it? A logical way to start is by reviewing the company’s SOP index. Note that this book refers to all procedures as SOPs, but companies increasingly are making distinctions between policies, SOPs, instructions and methods. If such a system is in place, a look at all these document types to assess what needs to be in place may be necessary. Approved procedures may exist that satisfy the needs of the COTS software system. Sometimes existing documents require a bit of modification to allow them to encompass the new system. Sometimes, however, totally new documents need to be written. All modification to or generation of documents needs to occur within the company’s document control system. Many companies create a set of infrastructure procedures that provide minimum requirements for all systems and then create a detailed system-specific set of instructions. SOPs such as training, computer system maintenance event recording, electronic signatures and computer system validation may be directly applicable to all systems. If this infrastructure is not in place, an option is to write procedures that are system specific, rather than applicable company wide. All systems must be covered by system-specific SOPs that address operation of the application. These SOPs are not a step-by-step tutorial on the use of the application. Rather, they define a process and how the computer system is part of it. A company may elect to have generic SOPs that are used as the foundations for systemspecific SOPs. Some companies use generic SOPs for all computer systems, while others have only system-specific SOPs. The company’s network is a resource utilized by most computer systems. If the network security and network backup SOPs provide guidelines applicable to specific computer systems, the system-specific SOPs should reference these SOPs instead of restating their contents. Changes in security access, roles and privileges occur often in all systems and require system-specific SOPs. SOPs for data archiving and computer system change control provide guidelines applicable to all systems, but the differences and details of each system may require separate system-specific SOPs. For instance, an electronic application may require several SOPs to support the system. A top-level procedure may be one that explains the system, tells what the system does and identifies who manages it. This document may even include the transition steps from an existing system to the new electronic one. Additional documents then give the “how-to” for any number of individual users. There is a lot of flexibility in how the documents work together and what they say, and the documents will ultimately reflect the particular culture of the company that puts them in place. When a company adopts an electronic application, it needs Copyright © 2004 CRC Press, LLC



73

to make sure the documents that support that system pair up with other documents and that there are no disconnects or overlaps — or worse, contradictions. The following SOPs support all computer systems and system-specific SOPs fill in the remaining details: Document Management This SOP defines the format, identification, retention, control, approval, distribution and review of documents, including SOPs. Some companies maintain a separate SOP only for SOPs, which delineates how SOPs are generated, reviewed, approved, distributed, revised and finally archived. SOPs are usually word processing documents. The electronic files are themselves electronic records. While most SOPs are still approved with handwritten signatures on paper originals, hybrid systems are widely used to distribute SOPs electronically. Electronic distribution can be performed without expensive document control software. Modern operating systems allow folders, also known as directories, to be made read-only, with access limited to selected individuals. To distribute SOPs to users of a network, the SOP files that are effective can be copied to a folder that allows read-only access to those people who need access. While the SOPs do not contain approval signatures, the paper originals that are filed with document control are available to show approval. Typically, companies will add a watermark or footer to these public documents to indicate that, if printed, they are valid only on the day of printing. In this simple system, a revised SOP could replace a superseded SOP in the effective public folder on any day. Often some users cannot rely exclusively on electronic distribution of SOPs. Laboratory workers may require paper official copies of SOPs to do their bench work. In this case, the document control function has to distribute official paper copies, but the number is significantly reduced from the full paper distribution method. Training An SOP that defines the content and retention of training, as well as the responsibility for conducting training and the method for managing training records is necessary. Training records may be fully electronic, approved with electronic signatures, or manually controlled. Currently, most training records are maintained exclusively on paper, or as hybrid systems where a summary of each paper training record is entered into a computer system. The electronic portion of the hybrid system allows for quick retrieval of training information related to what is needed and what has occurred for any individual. (See the end of this chapter for more details on electronic record keeping system training.) Facilities Security Building security is the first perimeter for defense of electronic records. An SOP on facilities security should address access control to the facility, user access accounts, account termination, visitors and security device loss management. Server rooms and other areas containing critical computer system hardware and electronic records Copyright © 2004 CRC Press, LLC


74


must have additional security and access limits. The facility security SOP gives the big picture of how the facility remains secure from entry by unauthorized persons. Network Security Network access is the second perimeter for defense of electronic records. A network security SOP should address user accounts, user account termination, password requirements, mandatory password change intervals, screen saver password use, remote access, Internet access, virus protection, ethics, data transfer, software licensing and e-mail use. This SOP can also address time-setting practices for all electronic systems. Electronic records are required to have the date and time on printouts. How the integrity of the date and time are maintained can reside in this SOP, or a company may elect to write a separate time-stamp SOP that addresses dates and times that are set to the locale of the facility where the records reside. Workplace Security Awareness Program The HIPAA regulations specifically call for a security awareness and training for all members of the workforce including management. There must be a program in place that delineates how security information is to be disseminated to the workforce and the timeframe for periodic security updates. Such a program can also spell out the process for terminating access to an electronic record keeping system Computer System Back-up Electronic records located on networked servers, individual workstations and other hardware components must have back-up systems in place. An SOP on back-up should allow for the recovery of data. No more than 24 hours’ worth of data should ever be lost. This SOP should address what gets backed up and what doesn’t, as well as how back-ups are managed. Management of media labeling, media reuse, restoration, testing and media destruction all rightfully fit into this SOP. Data Archiving Archiving in this context means the copying of original data to another media and then deletion of the original copy. Archiving makes more storage space available. Archived data must be retrievable for inspections and use in years to come. Archived data is original data that must be kept as secure and accessible as the original data. The archiving procedure must include a procedure for ensuring the archived data exactly matches the original data. A minimum of two archives should be retained so as to allow for a single loss of archival media. Computer System Maintenance Event Recording Typically, each server and each client (user workstation) has an event logbook. These logs create an audit trail for system maintenance. Each event record contains the date of the event, description, testing explanation, tester and date of completion.




75

Events are activities that affect a system but do not require change control. Events include hardware upgrades such as the addition of memory, minor software utility upgrades such as updated virus protection software and all installation activities. IT makes changes to the systems that do not directly affect the regulated software application. In this manner, the event log book contains a chronological history of events without the formality of change control documentation. Computer System Disaster Recovery Disaster recovery is one of the most misunderstood procedures. Most companies dread putting together a disaster recovery plan because they approach it from the perspective of following a disaster. People tend to give up and not have a plan at all. The truth is, when a disaster occurs few if any IT people are interested in reviewing a disaster recovery plan because they are busy working on solutions to the immediate problems. Some IT groups state that their entire disaster recovery plan is based on restoration of data from backups. This is dangerously inadequate. Any computer system disaster recovery plan must be an integral part of the company’s overall disaster recovery strategy. A good way to create a disaster recovery plan is to look at the problem proactively. Companies need to ask this question: what preventive steps should we take today to ensure that we can recover from a disaster? Bear in mind, a disaster could be as small as a single power supply failure or a downed network switch, or as huge as the destruction of an entire building. The key is to determine which hardware and software are involved in the computer systems. Next, determine how to recover from a failure of any single computer system component. Preventive measures include the design of the server room, redundant supporting systems, spare hardware, off-site storage of components, service contracts, supplier arrangements, staff notification hierarchies and staff cross-training. Information System Monitoring and Review HIPAA require procedures for monitoring systems and the regular review of information related to system activities. Monitoring must include log-in attempts and reporting discrepancies, while system review includes audit logs, access reports and security incident tracking. Security Incident Procedure The HIPAA regulations call for this procedure. Such a procedure tells how to respond to identified or suspected security incidents and how to mitigate harmful effects of such incidents. Electronic Signatures To satisfy the requirements of 21 CFR Part 11 there must be written policies that hold users accountable for actions initiated under their electronic signature. This policy applies to all computer systems that employ electronic signatures.



76


Electronic Record Retention Electronic records require the same set of retention times as paper records. Companies need a data retention policy that addresses all forms of data. The policy for electronic records may be part of the overall policy or be maintained as a separate SOP. This procedure should address the duration and location of electronic records for short- and long-term periods. Procedures for moving records between locations, tracking and reviewing them prior to destruction, and the method for destruction must be addressed. Electronic record retention applies to original data, backups and archives. Control of Electronic Mail e-mail systems create volumes of electronic data that include message text and attached files. Opinions vary on whether e-mail falls within the scope of 21 CFR Part 11’s electronic records rule. Companies must determine the regulatory issues and legal liability associated with e-mail retention and establish e-mail back-up, archive and retention policies. In many cases, there is an advantage to deleting email messages after a specified period, typically 60 to 90 days. Companies that delete e-mail regularly retain back-ups for the same specified period and do not create archives. Most lawyers agree that e-mail is a liability. Plaintiffs can obtain a court order that grants them full access to a company’s e-mail data. Of course, if a company does not retain e-mail for a long duration, there is less liability because there is less data to reveal. If people want to keep some e-mail, they can transfer the data to another format such as a word processing file. Computer Software Procurement Thorough evaluation of potential vendors is necessary to select the one that offers the optimum product for the company’s needs. The procurement process must allow for uniform assessment of products so that fair comparison can be made. Once product vendors are identified, they must be evaluated to determine their commitment to a long-term relationship and their compliance with 21 CFR Part 11 and HIPAA. The procurement procedure should detail how Purchasing, Legal, IT, quality assurance (QA) and system owners work together. The purchase of software has evolved into a very complex process with little uniformity between vendors. Many companies find the assistance of a consultant who specializes in 21 CFR Part 11, HIPAA and computer software to be invaluable in determining how best to develop contracts for software procurement. Aside from selecting the best product and vendor, the procurement process involves software licensing, platform selection, selection of multiple operating environments, software connectivity such as back-end databases, interfaces, customizations, maintenance agreements, training, installation, user validation and ongoing confirmation of quality standards. It is important to remember that software is not purchased like an item at a store. Software procurement creates a form of marriage between the companies. The regulated company assumes full liability for the use of the software, and, once the software is purchased, it is almost impossible to replace a vendor in a cost-effective manner.




77

Software Vendor Auditing An audit should examine the software development life cycle (SDLC) practices, regulatory experience, vendor history, financial strength and product history. Companies may not have this expertise in-house and may rely on consultants. This procedure provides details on how to evaluate a prospective vendor during the software procurement process. Computer System Change Control Each system needs to have a change control procedure. During the initial user validation, the configuration of the system is fully documented and set accordingly. During production use, systems require small changes. Instead of repeating the complete validation process, change control is used to perform a miniature validation. Some companies have a general change control procedure used as the basis for developing system-specific change control procedures. Other companies have implemented a single change control procedure that is used by all systems. At first, it may seem easier to create one change control procedure for all systems, but all of the different people and process flows involved with multiple systems can make a single change control procedure complex and difficult to manage. The change control procedure addresses request initiation, request approval, validation and request closure. Change control is usually used to validate minor software version upgrades, configuration changes and process changes. In this way there is a chronological history of changes made to the system. Some changes, such as for major upgrades, require the rigor of a full validation project. Validation of a system consists of an ongoing series of validation projects with change control documentation between them. Computer System Validation User validation addresses the entire system that consists of hardware, operating system, software utilities, application software, user instructions and training materials. A step-by-step procedure that guides users to create a standard set of documentation works best. Computer System Retirement Many companies do not put a retirement policy in place because systems tend to evolve into other systems rather than move to retirement. When this occurs, the data is transferred to the new system as part of the new system’s validation project. Any data not transferred can be archived as defined in the archive procedure and the data can be retained according to the electronic record retention policy. If a retirement procedure is warranted, the most important objective is to make sure that all of the data can be accessed in a usable manner once the system is taken out of production use. Archives are useless if no other systems can access their data. In some cases, hardware components such as removable media drives or entire computers must be archived. Copyright © 2004 CRC Press, LLC



78

Signature Log/Look-Up Table SOP When a company uses electronic signatures in its electronic records, it is useful to create a signature log/look-up table. Access to an electronic system is generally limited to legitimate signers only. Such a log is managed by a system administrator. The SOP details how changes to the list should be archived so that the identification of signers of records can be performed. This is useful when a user who has signed a document is no longer with the company, but the signature needs to be verified.

HUMAN RESOURCES Depending on the COTS software application, human resources (HR) may need to play a role. For instance, how the company hires and terminates people may need to be addressed. If an application, for instance, allows access to a large number of employees, system administrators will need to know which new hires require training on the system. Conversely, when employees separate from the company, system administrators will need to disable their ability to access the system. This is all part of keeping the system secure. HR may elect to include information such as this in the employee manual, or they may have a policy in place that outlines employee responsibilities in managing confidential information, such as patient data or drug master formulas. At a minimum, HR needs to have change-controlled procedures or policies in place that adapt to the evolving work environment.

ADDITIONAL RECORDS Electronic Signature Notification When a company decides to use electronic signatures in its first software application, it needs to notify the appropriate regulatory bodies beforehand. A simple statement is all that is necessary; it does not need to be detailed. In fact, the preamble to 21 CFR Part 11 offers this suggestion for preparing notification to the FDA: Pursuant to Section 11.100 of Title 21 of the Code of Federal Regulations, this is to certify that [name of organization] intends that all electronic signatures executed by our employees, agents, or representatives, located anywhere in the world, are the legally binding equivalent of traditional handwritten signatures.

The final rule instructs persons to send certifications to the FDA’s Office of Regional Operations (HFC–100), 5600 Fishers Lane, Rockville, MD 20857. Persons outside the United States may send their certifications to the same office. Companies often use the exact wording in the preamble, making the notification brief, standard and satisfactory. Note that the HIPAA regulations so far don’t mention electronic signatures. A future regulation will most likely address digital signatures and this issue has been in draft since 1996. Copyright © 2004 CRC Press, LLC



79

Minimum Required Signatures List When companies use electronic records and electronic signatures, they generally create a minimum required signature list. This list identifies primary and alternate signatories for categories of documents.

SYSTEM USER TRAINING The need for training cannot be stressed enough. Whenever a company puts a new system in place, electronic or otherwise, training is necessary, and such training needs to occur according to the SOPs in place for the system. The need for training is spelled out abundantly in the predicate rules that apply to 21 CFR Part 11, and the HIPAA regulations do so as well. It doesn’t matter whether people using the COTS software are full time, part time, temporary employees or consultants. They cannot access and use the system unless they have had training appropriate to their responsibilities on the system. The system’s integrity depends on it. For 21 CFR Part 11, predicate rules for training apply. Here are some excerpts from the regulations:

21 CFR PART 211 — CURRENT GOOD MANUFACTURING PRACTICE FOR FINISHED PHARMACEUTICALS Subpart B — Organization and Personnel § 211.25 Personnel Qualifications (a) Each person engaged in the manufacture, processing, packing, or holding of a drug product shall have education, training and experience, or any combination thereof, to enable that person to perform the assigned functions. Training shall be in the particular operations that the employee performs and in current good manufacturing practice (including the current good manufacturing practice regulations in this chapter and written procedures required by these regulations) as they relate to the employee’s functions. Training in current good manufacturing practice shall be conducted by qualified individuals on a continuing basis and with sufficient frequency to assure that employees remain familiar with CGMP requirements applicable to them. (b) Each person responsible for supervising the manufacture, processing, packing, or holding of a drug product shall have the education, training and experience, or any combination thereof, to perform assigned functions in such a manner as to provide assurance that the drug product has the safety, identity, strength, quality and purity that it purports or is represented to possess. § 211.34 Consultants Consultants advising on the manufacture, processing, packing, or holding of drug products shall have sufficient education, training and experience, or any combination thereof, to advise on the subject for which they are retained. Records shall be




80

maintained stating the name, address and qualifications of any consultants and the type of service they provide.

21 CFR PART 606 — CURRENT GOOD MANUFACTURING PRACTICE FOR BLOOD AND BLOOD COMPONENTS Subpart B — Organization and Personnel § 606.20 Personnel (b) The personnel responsible for the collection, processing, compatibility testing, storage or distribution of blood or blood components shall be adequate in number, educational background, training and experience, including professional training as necessary, or combination thereof, to assure competent performance of their assigned functions and to ensure that the final product has the safety, purity, potency, identity and effectiveness it purports or is represented to possess. All personnel shall have capabilities commensurate with their assigned functions, a thorough understanding of the procedures or control operations they perform, the necessary training or experience and adequate information concerning the application of pertinent provisions of this part to their respective functions.

21 CFR PART 820 — QUALITY SYSTEM REGULATIONS Subpart B — Quality System Requirements § 820.20 Management Responsibility (2) Resources. Each manufacturer shall provide adequate resources, including the assignment of trained personnel, for management, performance of work and assessment activities, including internal quality audits, to meet the requirements of this part. § 820.25 Personnel (b) Training. Each manufacturer shall establish procedures for identifying training needs and ensure that all personnel are trained to adequately perform their assigned responsibilities. Training shall be documented. As part of their training, personnel shall be made aware of the device defects which may occur from the improper performance of their specific jobs. Subpart G — Production and Process Controls § 820.70 Production and Process Controls (d) Personnel. Each manufacturer shall establish and maintain requirements for the health, cleanliness, personal practices and clothing of personnel if Copyright © 2004 CRC Press, LLC



81

contact between such personnel and product or environment could reasonably be expected to have an adverse effect on product quality. The manufacturer shall ensure that maintenance and other personnel who are required to work temporarily under special environmental conditions are appropriately trained or supervised by a trained individual. ICH Q7A Good Manufacturing Practice Guide for Active Pharmaceutical Ingredients 3 Personnel 3.1 Personnel Qualifications

3.10 There should be an adequate number of personnel qualified by appropriate education, training and/or experience to perform and supervise the manufacture of intermediates and APIs. 3.12 Training should be regularly conducted by qualified individuals and should cover, at a minimum, the particular operations that the employee performs and GMP as it relates to the employee’s functions. Records of training should be maintained. Training should be periodically assessed. Violation of these procedures may prove costly to the company by regulatory intervention. The newly approved HIPAA regulations are clear about the need for training as well. Implicit throughout the regulations is the need for training, because the system must remain secure. To keep it thus, users must understand and abide by the policies and procedures in place. Specifically, the regulation calls for training of employees as well as management: 45 CFR Part 164.308 (5)(i) Standard: Security awareness and training. Implement a security awareness and training program for all members of its workforce (including management).

Clearly, then, no one should access an electronic record keeping system without training. Training for computer systems is usually based on training sessions, mentoring and review of system-specific SOPs. During training sessions, people often indicate that they understand how to use a system, but in reality, they may be hesitant to admit they don’t fully comprehend. When there is an audience, they can be particularly reluctant to admit they don’t. Trainers need to take the human variables into account. Some people grasp concepts and systems quickly; others require more explanation and demonstration. It’s important that training be positive in nature; this is not the place for punitive messages. The thing to stress is that the system is integral to the workplace and optimal operation is the standard to achieve. Verification that trainees understand that they need to perform their duties relative to the system is essential. Checklists that trainers complete while watching users access and use the system are a good way to verify that training is successful. Other methods for verification include testing that trainees complete, usually true or false Copyright © 2004 CRC Press, LLC


82


or multiple choice. Training verification will immediately identify those users who require more training to develop the skill set they need. Periodic update training should also occur, as should retraining when necessary. Periodic update training can occur at regular intervals, or when the system undergoes controlled changes. When any user demonstrates a weakness in performing any assigned function, either through forgetfulness or inattention, retraining is in order. Such retraining can occur with hands-on demonstration — a “walk-through” of the function that is proving troublesome. As with initial training, trainees need to demonstrate their capability in performing their tasks adequately. And, of course, all training needs to be fully documented. Some companies retain training records within departments; others keep training records in HR. Some organizations maintain individual training files for all employees, as well as group training records. However training occurs, it needs to be conducted according to the approved SOP in place for training.



5

Security, Accountability and Change Management

We must make automatic and habitual, as early as possible, as many actions as we can. The more of the daily details of life we can hand over to the effortless custody of automatism, the more our higher powers of mind can be set free for their own proper work. William James

Once a commercial off-the-shelf (COTS) software system has been installed and validated, and is operational with trained users, it is imperative that it maintain its integrity. To make sure the COTS system serves the organization as it should means the system must remain secure and that any changes to it be carefully managed. The regulations and industry standards conjointly call out the need for security. Why all the security measures? As industry leaders met over the years since 21 CFR Part 11 was passed into law, this has been a prevailing question. The answer is that the primary responsibility of the Food and Drug Administration (FDA) is to guard the safety of the population. The FDA mandates security measures to ensure that the information it receives is accurate and reliable. From this information, the FDA approves drugs and devices for human use and monitors their use to ensure ongoing public safety. If data are corrupt or fraudulent, the efficacy and safety of products may be compromised and lead to patient injury or death. The Health Insurance Portability and Accountability Act (HIPAA) regulations address Protected Health Information (PHI) and call for privacy and security. Privacy means the control of access, use and disclosure (effective 2003); and security means the safeguarding of data integrity, confidentiality and availability (effective 2005). Safeguarding the data does not mean that the system itself must remain static, however. Systems continually evolve over time. In the life cycle of COTS software, many changes will undoubtedly need implementation. As software companies learn about customer needs and build new functionalities into systems, for instance, companies using the COTS software may elect to get the upgrade. Or companies may determine that they need to interface one system with another. Changes to a system can cover a broad spectrum. Change management addresses activities that are not directly related to the day-to-day functionality of the system, and as such, change management is an important aspect of keeping the system optimally operational.



84


Companies typically assign information technology (IT) staff to manage systems with which they are familiar. It becomes their responsibility to oversee security measures and controls for the system. The HIPAA regulations call for administrative safeguards for security and security management, and identification of a security official who is responsible for the development and implementation of the policies and procedures (45 CFR Section 164.308).

MANAGING THE SYSTEM Just as upper management must be dedicated to supporting the system financially and throughout its validation process, they must be committed to the secure operation and management of the system when it is up and running. They are responsible for ensuring security awareness and training, and dealing with potential vulnerabilities. Management cannot sit back and wait for a breach in security or mismanaged change to occur. They must actively look for weaknesses and implement preventive measures. Further, they must be assertive in their support of the system; it is from upper management that the dictates come for employees to “buy into” the electronic system and keep it functioning as it should. Upper management must support auditing of the system and corrective actions to it. This sort of proactive stance helps ensure the system will remain secure and compliant, and function smoothly and efficiently.

SECURITY Regulated companies, the FDA, and the Department of Public Welfare enforce data security procedures to make sure that products meet acceptable quality and safety standards. Data must be accurate and readily available to ensure that product development, manufacturing, release and distribution can be reviewed and investigated at any time. This information is critical in assessing liability, and failure to maintain this data can have significant financial repercussions. Many companies fear the government and are misguided in thinking that the agencies are “out to get them.” In practice, the FDA and the Department of Public Health are in place to help companies achieve regulatory compliance and therefore help them limit their liability. Usually, companies have much greater financial risk potential resulting from litigation related to product use or improper disclosure than they do from the regulators. Keeping a COTS system secure involves many factors. Foremost are the behaviors of the people who access it. Close behind are the methods by which they access the system. Thus, once a system is operational, companies must continually strive to educate the workforce and monitor all activities relative to the system. Security measures must be in place for today and provide protections for the future.

THE PEOPLE FACTOR Data integrity requires vigilance on the part of all people who are responsible for the creation, maintenance and use of data. Many companies feel that their staff is like a family, and as such, there is a bond of trust. While this may carry a modicum Copyright © 2004 CRC Press, LLC



85

of truth, the fact is that there are many dysfunctional families, and if you are not looking for breaches in data integrity, you most likely will not find any. In the year 2000, upwards of 70 percent of unauthorized break-ins were committed by company insiders. Employees with malicious intentions exploit human error to subvert corporate defenses. Attacks occur at all levels and result in losses such as compromised intellectual property, financial harm, fraud and adulterated products. Companies rarely admit to attacks because the publicity can result in loss of consumer trust and diminished corporate image. Nevertheless, security can be compromised in a number of ways.

FRAUD There are many stories where ego or greed has influenced people to commit fraud. This fraud may or may not be detected by the company or an inspecting body such as the FDA, and in some cases, inappropriate and adulterated products have been marketed. In one case, a clinical trials manager with a large number of stock options manipulated clinical trial data to ensure the stock price would rise. In another case, a research scientist falsified a report to FDA to help ensure that the next phase of clinical trials would be granted. This scientist knew the current drug candidate did not work as intended but was trying to buy time to correct the formulation.

VANDALISM Sometimes people intent on vandalism target a company’s data. Like a dreaded computer virus unleashed to attack computer systems, someone with a grudge can set out to destroy data. The destruction of data can bring a company’s work to a halt, resulting in missed product release dates, or worse, delay or lack of appropriate medical treatment and financial hardship. The people in the organization with the highest level of security access also have the most destructive potential. A disgruntled network administrator, database developer, or system administrator may have the knowledge and intent to commit many forms of vandalism, some of which have little risk of detection. It is for this reason that all terminated staff, for any reason, must have all security access removed before notification of termination.

TERRORISM Terrorism is always a potential threat as well. If a terrorist can adulterate a product before distribution, he may have succeeded in creating a formidable weapon with massive potential. Unleashing a biological agent in something as common as cough syrup could lead to a significant number of deaths before the contamination is detected. One story involves a manufacturer of children’s vitamins. The weight of the vitamins during the final manufacturing stage was higher than the sum of all the ingredients combined. A careful search of the electronic and paper batch records showed no errors in the cumulative weights. The quality control records showed the product met all specifications. Where did the extra weight come from and what were the extra ingredients? Were the unknown ingredients harmful? In this case, the Copyright © 2004 CRC Press, LLC


86


company played it safe and destroyed the entire batch, a costly proposition at best. However, consider the ramifications of putting a seriously adulterated product on the market.

THEFT There are countless stories where the actions of a single individual or a small group of people has gone undetected for an extended period. It is for this reason that the FDA is cautious, and companies should be as well. Data security is equally important with patient records; identity theft has been on the rise, much of it attributable to unauthorized access to people’s personal records. Further, most companies agree that their intellectual property is their greatest financial asset. Companies must defend themselves against theft of data. Physical security, network security, application security and electronic signatures all provide barriers to theft. People can use computers to copy data easily without detection. Most companies have detailed policies in place that protect data on their servers and restrict access to view, change and delete data. Most companies also have executives who work “all the time” and “everywhere.” These people frequently copy data to their laptop computers and travel. The data is highly confidential, mobile and, without encryption, is an easy target for corporate espionage. Thieves really do search through trash receptacles for abandoned electronic media, eavesdrop, steal entire desktop computers and look over peoples' shoulders while they type their passwords. Sometimes, thieves are so adept that they can remove a hard drive carrying important data, leaving the computer itself intact, and a lot of time can elapse before the theft is even discovered.

SECURITY DEFENSES Security is becoming a large part of all aspects of life. In recent years, companies have put up defenses against computer attacks with firewalls and virus protection. The threat of an outside attack is unlikely, but the threat from an internal attack remains high. PricewaterhouseCooper estimates that companies are losing more than $45 billion per year from computer attacks, and that 80 percent originate internally. Industry regulations are addressing computer security issues and compliance requires disclosure of all security breaches. The Securities and Exchange Commission (SEC) may soon require public companies to disclose all security breaches, and this information would be available via the Freedom of Information Act (FOI). The new HIPAA regulations require IT to be proactive in finding security breaches in that they will have to routinely review security logs and audit trails. HIPAA also require the workforce to be continually reminded of their responsibilities for ensuring a secure computing environment. As computer systems become more complex, security procedures will surely become more complex. IT will be challenged to promote security without placing a burden on users, thereby defeating the gains that computers bring to business processes.




COMMITMENT

TO

87

SECURITY

All employees must thus understand their role in promoting data security and take responsibility for ensuring the data they work with is secure. It follows that the people who work directly with the data are the ones best able to detect security breaches. Everything is vulnerable to exploitation, and the security chain really is only as secure as the weakest link. Therefore, it behooves organizations to take every measure to ensure data security and integrity and eliminate any weak links. Life literally may depend on it. While serious, deliberate data theft does occur, most security violations result from simple, seemingly innocent “bending” of the rules, failure to fully understand them or deliberate disregard of them. The reasons employees do this are many. Small companies may well start out as a “family” operation; but as they grow, they acquire new employees and long term employees seek new opportunities outside the firm. In addition, when there is a bond of original employees, these employees often resist change, with a “That’s not how we do it here” attitude, or “I know what’s best for this company.” In larger companies, there may be a sense of disconnection with the company’s goals and principles of operation. Employees may thus feel that “It doesn’t apply to me,” or “This company doesn’t know who I am.” Attitudes such as these are generally counterproductive to maintaining a secure system, but they are not uncommon when a company undergoes a major change, such as to a new system for electronic record keeping. An observation is that with any major change, 50 percent of the workforce will willingly embrace the new system; another 25 percent may need persuasion; and the final 25 percent may be so resistant that their efforts may be better expended apart from the system. When employees demonstrate poor work habits for whatever reason, corrective action, rather than punitive action, is preferred and should be implemented as necessary. When there is a disgruntled or unhappy worker who is systematically creating problems with the system, however, management needs to address the personnel problem. If the initial training and verification have shown the worker to have a solid working knowledge of the system, the issue is not the caliber of the training or the skills of the employee, but rather one of attitude. The HIPAA regulations specifically call for sanctions against workforce members who “fail to comply with the security policies and procedures of the covered entity” (45 CFR Section 164.308). Thus, the message the employee needs to receive is that the record of poor performance will find its way into the employee appraisal and may have other ramifications such as termination. The Security Mindset Security needs to be a mindset. Everyone must keep security in his or her awareness, practice good habits and communicate observations with each other. This sort of communication can be difficult, but it is critical to security — so much so that it should be stressed from the first training employees receive. Communicating observations may entail discussing system weaknesses at a meeting or drawing an administrator’s attention to them. Consider the case of a door that doesn’t shut properly



88


or a fluctuation in temperature in a room that houses equipment that must reside in a controlled temperature. Vigilance in observing and reporting such breaches can and should foster a team spirit and continue to build a successful operation. Security experts often state that security is in the details. Everyone must be aware of the people with whom they come into contact. Visitors should look and act like visitors. If a visitor is not wearing a visitor’s badge or appears to be in an inappropriate area, it is each employee’s responsibility to notify the appropriate people. Saying “It isn't my problem” is always incorrect because security is everyone’s problem and responsibility. This is the message all employees need to have to make the system secure. Not all communication about system breaches is easy, however. Seeing someone loan a card key to another employee, even one known to be trustworthy, should be a trigger to make both parties aware of their non-compliant behavior. Yet most employees observing such an action are reluctant to act, because a confrontation can provoke defensive, negative and even hostile reactions, and it’s human nature to avoid the unpleasant. However, it’s important that employees understand the significance of what they are doing and that the security-breaching behavior stops. What is the best way to address such a situation? Sometimes a simple query may reveal that they don’t really understand the rules or feel that “They don’t apply to me.” The message that needs communication is that the procedures are in place for a purpose and all employees must follow them. In the case of the example of the misused key card, a suggestion that the key card holder accompany the other person or have the other person obtain a temporary card key may be a simple solution. In other situations it may be wise to contact supervisory personnel. Staff who violate procedures in place and compromise security may need retraining. If retraining fails to deliver the message, the employee may need to be reassigned to duties that do not permit access to records. Those who knowingly and habitually violate procedures, despite retraining, should be subject to dismissal. Indeed, violation of established procedures in most regulated industries is grounds for termination. There are some aspects of security where the only person who can really ensure compliance is the person himself. When an employee makes a password, no one knows what it is, and no one knows if he has complied with the format requirements. Passwords made from words in a dictionary or those that have an added number at the end or beginning of a word in a dictionary are best left unused since they are inadequate. Password standards have evolved over time. People first used words they knew, and these passwords were easily cracked. Then people were told not to use words so they added a number to the end. Again they were easy to crack. The idea is to add a number or symbol in the middle of the password to make it difficult to crack. Some systems require upper- and lower-case characters to be used, but this has turned out to be troublesome because when people can't remember their passwords they tend to call the IT help desk, which results in higher administrative overhead costs, and then they select easier passwords because they don't like the hassle and embarrassment of dealing with a forgotten password. It is for this reason that industry standards require the software to enforce password makeup rules. In the future, biometrics may replace user-supplied passwords. Copyright © 2004 CRC Press, LLC



89

A common security breach is password sharing — and it may seem innocent enough. If a person has a particularly clever password, the temptation to share may be overwhelming. Or suppose someone innocently says, “I use my cats’ names.” All an eavesdropper intent on data theft needs to do is find out the cats’ names and try them all to see which one is currently in use. No matter what a person’s rank and security level, a criminal can target his accounts as the means to gain unauthorized access. Each employee must take the responsibility for security personally. Another security breach occurs because system users have many passwords, and they change them frequently. It can be difficult to remember them, and therefore people write them down. But passwords should be handled just like social security numbers and be restricted from access by anyone other than the user. Security procedures therefore instruct employees to keep passwords in a secure location. FDA inspectors actually look under mouse pads and keyboards, and in desk drawers to see if passwords are present. If they are, a citation is the probable result. If employees need to write down passwords, the best place to keep them is in a place that they are accustomed to keeping safe, such as in a locked cabinet to which only they have the key. If people must write their passwords down, it is best to write them so they are disguised (encrypted) in a manner that only they can decipher. Instead of remembering all the passwords, they would then need only to remember a simple encryption rule. Since no one ever knows the encryption rule, they never need to change it. An encryption rule can be as simple as adding a favorite number to each value in the password. Another way is to substitute special easy-toremember letters for specific numbers. For example, substitute “e” for “3.”

ONGOING COMMUNICATION Security needs to be an issue that is always on the front burner. People are fallible — they forget; they remember incorrectly; they become distracted or tired; they make errors. It doesn’t matter what the work environment is, human fallibility is a given. Yet companies can minimize this vulnerability to systems by building security into the culture of the company. Security should be stressed from the moment an electronic data keeping system comes to the company. It should be stressed to the employees in place at that time; it should be stressed to new hires during orientation to their new jobs. A good way to continue security awareness is to host regular meetings, or forums. Putting security on meeting agendas whenever there is an issue is wise, and keeping security on meeting agendas as an update item, even if brief, helps keep the awareness current. Making system security the topic of a company forum is a good way to answer employee questions that may come up; moreover, it brings the workforce together and stresses the team effort. People are less likely to deviate from accepted practices when they participate in dialogue about the systems and their operations. Another good way to keep employees informed is to put system information in the company newsletter. Publishing milestones – such as the thousandth record processed or the final legacy document loaded into a system – provides incentive for good performance. Sometimes IT people will send out an “all hands” e-mail as a “tip sheet” Copyright © 2004 CRC Press, LLC


90


or provide a question and answer forum electronically. Finally, the company’s employee appraisal program should include job duties relative to the system. Much of security, then, involves good management, which translates to the ability to develop and foster good work practices and team loyalty. Rewarding good habits and excellent results is a recognized way to foster continuing solid performance. IT staff such as network administrators, system administrators, help desk technicians and software developers must provide leadership in the area of data security. They must set standards, keep up to date on the latest technologies, actively search for security breaches, provide periodic security updates and evolve security infrastructure to meet the changing needs of all staff.

MANAGING PASSWORDS: A KEYCHAIN The concept of a physical keychain has been implemented in software to create a secure place to store passwords. For a physical keychain, the security of the keychain is paramount. In a software keychain, the contents of the keychain are encrypted so the user needs only to remember one password in order to obtain access to all passwords. In some implementations, such as the Apple Macintosh Operating System, applications can access the keychain directly, and a user needs only to provide the keychain password each time a password is necessary. The keychain is reasonably secure in that it does not contain the keychain password itself. The keychain password is used to encrypt the contents of the keychain. The keychain resists repeated attempts to guess a password by exponentially increasing a time between allowable authentication attempts. Each time an authentication attempt fails, a user has to wait longer before attempting to enter another keychain password. Users still have to change passwords according to the requirements of each application. When they change a password in an application, they have to make the same change in the keychain. If the keychain is lost or corrupted, all of the passwords it contains are lost. Regular backups minimize this risk of loss. However, when a user forgets the keychain password, there is no way to get back the passwords. In this case, all applications would have to have the password reset by the system administrators.

BIOMETRIC KEYCHAINS The current approach for user log-on and electronic signatures employs user-defined passwords. The holder of the keys is always the weakest link. Companies must focus on user education and training on corporate procedures. Internal advertising such as posters, intranet links, corporate e-mail and newsletters are effective in bringing awareness to the issues. Management must continually remind users of their responsibilities for physical, network and application-specific security measures. Regulated companies and the computer industry must work together to reduce security vulnerability. The next evolution in computer security most likely will be the adoption of biometric controls for passwords. The most commercially mature biometric technology is fingerprint recognition. This technology has already gained popularity for employee time card records. Fingerprint scanners have proven to be Copyright © 2004 CRC Press, LLC



91

reliable and effective at virtually eliminating fraud associated with work hour record keeping. A second area of adoption for fingerprint recognition addresses physical security. Fingerprint-activated door locks are replacing keys and key cards because they offer significant advantages in security administration and protection. For computer systems, there are no readily available solutions for standardizing all of the operating systems and application software to use biometrics in place of passwords. As the numbers of applications grow, the numbers of passwords grow, and the likelihood that users will write down passwords resulting in compromised security increases. The concept of a keychain provides a single secure location for all passwords. With a keychain, the user needs to remember only one password. For a biometric keychain, the user defined keychain password is replaced with a simple fingerprint scan. The biometric keychain can include all of the passwords for network log on, screen saver and applications. The biometric keychain software runs on the user workstation and looks for password prompts. When a prompt is made, the biometric keychain software senses it and requests a biometric fingerprint scan. If the scan matches, thereby authenticating the user, the software issues the password that corresponds to the requesting prompt. With a biometric keychain, the operating system and applications do not need any modification. Users still need to change passwords according to the password aging requirements. If an application does not have an automatic password-aging feature, the user can configure the biometric keychain to require a password change at a set frequency. When a new password is required, the user can have the biometric keychain software automatically create a random password. The user would not have to remember the password since all that’s needed to retrieve it is a matching fingerprint scan. In this manner, all applications can have unique, difficult to copy passwords. Another beneficial feature of a biometric keychain is that folders, directories, hard drive partitions and removable media contents can be encrypted with a password that is activated by an individual's fingerprint. Users frequently retain confidential data on portable laptop computers and removable media. Theft or loss of this data can be a significant security breach, so users must be proactive in security measures. IT help desk statistics show that approximately 40 percent of all computer technical assistance inquires are related to forgotten passwords. With a biometric keychain there are no passwords to remember or type, so companies may find that the biometric approach pays for itself in reduced technical support overhead. The fingerprint scanner generates an image of the fingerprint pattern, identifying the unique pattern of ridges, loops and whorls. From the pattern, a personal digital code template is generated and stored. The template cannot be used to reproduce the fingerprint pattern. The fingerprint pattern is not stored, and therefore cannot be stolen. The personal digital code template is stored in the digital keychain file along with all of the passwords. The entire keychain file is encrypted and can only be opened with a matching fingerprint scan. Current fingerprint scanner attributes include the following: • •

Small standard interface, such as a universal serial bus (USB) device Stand alone or integrated scanner with a keyboard or mouse




92

• • • • • • • • • • •

Wear resistant, long lasting, reliable >1M touches Dry finger read, no special finger preparation, not dependent on oils left by fingers Static discharge management Cleans easily Low cost Simple software interface No user training Not fooled by “gel finger” covers Not fooled by latent images or copies of fingerprints Not fooled by fake or dead fingers Not fooled by a scanner playback device

Typically, fingerprint scanners look like the following devices:

“ethentica USB 2500” fingerprint scanner courtesy of Security First Corporation, 949-858-7525, www.securityfirstcorp.com.

In the coming years it is very likely that fingerprint scanners will be built into keyboards, mice, door locks, airline ticket kiosks, automatic teller machines (ATMs), garage door openers, guns, telephones for long distance access, cell phones, personal




93

digital assistants (PDAs) and other portable electronic devices, point-of-sales devices at gas stations and restaurants and so forth. Once the fingerprint scanners are in place, security software will evolve so that more elaborate biometric security measures can be implemented. As digital signatures come into play, biometrics can be used to provide authentication access without the use of passwords at all. By combining all the biometric keychains in a central database, applications will have a standard method for user authentication that will eliminate passwords and allow for mobile users to have controlled access from multiple computers and multiple physical locations.

CHANGE MANAGEMENT Once a system is operational, organizations need to exercise change control measures. Systems change every time data is entered into the system. Normal use of the system should be performed according to controlled procedures, and all changes should be captured in the audit trail. Change control address changes to the configuration and functionality of the system. These changes should be captured in the audit trail as well. Each change to the system has to be assessed for risk and the impact on existing processes and procedures. The scope and impact of changes can be widely different. It is therefore inefficient to have one process for dealing with all types of changes. Understanding the potential impact of changes is the key to determining how changes should be managed. For changes that are not expected to have any impact on the processes carried out by the system, less rigorous consideration and documentation is needed than for changes that directly affect system functionality. Most companies thus adopt a three-tiered approach for change management. Tier One The Computer System Maintenance Event Recording SOP provides a process for recording events without formal change control. Each computer system that runs a regulated application requires a system event log that includes both server and client computers (user workstations). The log may consist of a physical log book or be a virtual log contained in an electronic database. Typically, an IT representative creates an event log upon installation of the first regulated application. The log is similar to the maintenance record for an automobile in that it captures the service history. The log provides a chronological history of planned and unplanned activities that have impacted the system. The log is useful for troubleshooting problems and defining the current system configuration. Events may include the following: hardware changes, such as memory, hard drive, power supply and peripherals directly attached; the operating system, such as upgrades and patches; minor software utility upgrades such as updated virus protection software; or software utility upgrades, new installations and removals. The event log does not record changes that directly affect the installed regulated software applications. In this manner, the event log contains a chronological history of events without the formality of change control documentation.




94

Tier Two The Computer System Change Control SOP provides a process for making small changes without performing a complete validation project. The changes can have significant effects on system operation provided the scope of the change is not widespread. The change control procedure incorporates a miniature validation project. The change control procedure is used to validate minor software version upgrades, configuration changes, and process changes. In this way there is a chronological history of functional changes made to the system. Change control involves the following steps: 1. 2. 3. 4. 5. 6. 7.

The change request is made. The impact and risk of the change are assessed. Change request is approved. Change request is logged. Test cases are developed to verify the success of the change. Test cases are approved. The change is made, including updates to SOPs and other supporting documentation. 8. The test cases are executed. 9. The test results are reviewed. 10. Change control documentation is approved and archived. The change goes live into the production system. All changes have a risk of introducing unexpected behavior into the system. Whenever possible, changes should be made to an environment that is similar but separate from the production environment. A test environment provides a safe place to make and test changes to the configuration of the system. When testing has verified the change is correct, the change can be applied to the production environment. Testing is required in the production environment to verify that the change is the same as the change made and tested in the test environment. This does not require complete duplication of testing performed in the test environment, but rather requires a limited set of test cases be repeated. Tier Three The Computer System Validation SOP provides a process for validating a complete system. It is used for the initial validation and for revalidation when major changes are made to the system. A validation project is necessary when the developer provides a major upgrade, when the system is used for a new purpose or to validate an interface made with another system.

MAINTAINING

A

ROBUST SYSTEM

Changes to a system, whether minor or major, require control. The level of activity hinges on the nature of the control. One thing is certain, however: change to the system must be systematically and consistently handled. A fast way to fall out of compliance is to handle an activity one way one time and another way the next time.




95

SOPs must be in place to provide directions that help people make consistent decisions as to how each type of change will be managed. Handling change well means the system will be able to grow and adapt as the company moves forward, keeping abreast of changes in industry standards and technological innovation. As each change arises, either from a real-time event or a proposal, users must be involved in deciding which of the change control tiers to apply. Most companies create a change control SOP that is specific to the system. In this SOP users provide examples of the common types of changes and assign them to the appropriate tier. The SOP also provides instructions as to how to fill out the change control documentation. For some changes, both a change control and event log must receive entries. Also, most revalidation projects require an event log entry to record installation of updated software. With many systems in place, a company may have many change control SOPs. A good way to ensure that all change control SOPs follow a similar methodology is to create a generic change control procedure that sets the minimum standard for all system-specific change control procedures. Administering change control takes diligence on the part of the users, especially the system administrators. Some users may interpret the change control SOP one way, while the same change initiated by another user may be interpreted another way. It is best, therefore, to have the event logs and change control requests reviewed by the primary system administrator as they arise. Many companies create a change control committee. These tend to slow down the process of administrating change control, however. A workable compromise is to have the system administrator review all change control requests and form an ad hoc committee only as necessary. In addition, the quality group should review the event logs and change control documentation to ensure compliance with the generic and system-specific change control procedures.

REMAINING COMPLIANT Sound electronic record keeping systems rely on commitment and direction from upper management, and the conjoint efforts of users and IT staff. Maintaining security and managing change is not something delegated to a select group of employees. IT staff is involved with systems during validation and as issues requiring resolution arise. Users are involved at all times; therefore, users must take responsibility for system security and change and for making sure that IT is performing its functions, while IT must continue to provide proactive support. The bottom line is this: system users own the data and are most affected if loss occurs.



6

Auditing Electronic Record Keeping Systems

Let no act be done at haphazard, nor otherwise than according to the finished rules that govern its kind. Marcus Aurelius Antoninus

Companies need to audit to ensure their electronic record keeping systems continue to function as they were intended to. Compliance with 21 CFR Part 11 means compliance with applicable predicate rules that drive the Food and Drug Administration (FDA)-regulated companies that produce food, drugs, cosmetics, medical devices or biologics. The new Health Insurance Portability and Accountability Act (HIPAA) regulations, 45 CFR Parts 160, 162 and 164, which speak to electronic record keeping, call out the requirement for auditing as “information system activity review.” This means a procedure for conducting internal audits of the electronic record keeping system must be in place. These audits need to address system activities, such as log-ins, file access, security incidents and the like. A regular system of audits can look at policies and procedures that drive the system and explore how the system really works. Regular audits serve to verify conditions and signal change; they give a barometric reading of how the system is actually working and present a picture of the system over time. A solid, working system that serves the company efficiently is the goal. Such a system will be able to withstand serious scrutiny by regulatory bodies. More important, however, regular audits are tools for doing good business because they can eliminate any hindrances that affect the bottom line, the profit margin of the company. Think of the time and expense that correcting a mangled record would entail. Think of the domino effect that a piece of incorrect information logged into a system could generate. Monitoring the system is thus just as much about good business practices as it is compliance; these two go hand in hand. In the predicate rules compatible with 21 CFR Part 11, the need for internal audits is spelled out or implied. For medical devices, the requirement is clearly stated in 21 CFR 820.20b Audit Procedures: Quality audits shall be conducted by individuals who do not have direct responsibility for the matters being audited. Corrective action(s), including a reaudit of deficient matters, shall be taken when necessary.




98

A report of the results of each quality audit and reaudit(s), where taken, shall be made and such reports shall be reviewed by management having responsibility for the matters audited. The dates and results of quality audits and reaudits shall be documented.

21 CFR Part 211, the section of the CFR that addresses pharmaceuticals, does not explicitly call for audits, but industry has interpreted 180 (e) as the requirement: Written records required by this part shall be maintained so that data therein can be used for evaluating, at least annually, the quality standards of each drug product to determine the need for changes in drug product specifications or manufacturing or control procedures.

Part 164.308 (D) of the 45 CFR HIPAA regulations for electronic records call for auditing this way: Information system activity review (Required). Implement procedures to regularly review records of information system activity, such as audit logs, access reports and security incident tracking reports.

While the regulations may directly or indirectly call for auditing, they don’t tell what needs auditing or how it should occur. That’s up to each organization to determine. The critical component is to have audits occur with regularity. While audits are requirements of the regulations, companies do not need to fear that the results of audits, if negative, will work against the company. The regulatory bodies understand that audits are diagnostic tools for internal review and assessment. Selfmonitoring, by way of regular auditing, is healthy. The FDA, for instance, does not typically ask to see audit results, but will ask to see documentation of an auditing program, which is defined in a company standard operating procedure (SOP). Audits also serve as tools to accomplish standardization. If the company has more than one site that must interface with others, audits can point out disparities that can then be adjusted, paving the way for uniform systems at each site. Consider that regulatory agencies look for standard procedures for interfacing systems; if one site manages the system one way and another site takes a different approach, it can raise a red flag. A regulatory citation in such an area translates to lots of time and effort spent trying to attain conformity after the fact. It’s much less time consuming and costly to use the audit activity to assess what needs to happen to achieve standardization as a regular business activity. In other words, it amounts to keeping your house in order all the time, not just when there are repercussions from a regulatory inspection. As systems grow and evolve, auditing should play a key role. Audit results are often the triggers for changes that will improve the system. Audits also spot trends, which a single look at a system cannot do. If there is a repeating pattern that shows a weakness in the system, a good audit program will spot it and instigate corrective action. This ensures continuing integrity and optimal operation.




ESTABLISHING

AN

99

AUDIT FUNCTION

Most companies that comply with predicate rules issued by the FDA have audit functions in place, but start-ups, smaller companies and healthcare providers may not. To comply with the regulations that mandate auditing requires top-down support. That means upper management must understand the need for an auditing function and allocate the resources for auditing activities. Resources for an auditing function include people who do not directly input data to or manage the system and can look at it objectively. In 21 CFR Part 11-compliant companies, these people usually make up the quality unit. Time is also a factor. Audits and evaluations take time, so there must be a sufficient understanding that the auditing function is not disruptive, but rather an integral activity for maintaining quality. Finally, the auditing function demands budgetary support for staffing auditors or retaining consultants to perform auditing activities. Whether the company retains staff auditors or engages consultants to perform the audits, it needs to understand that auditors must have the skills to perform the duties for which they are employed or contractually retained. Good auditors therefore know the regulations that apply to the systems they audit, and they keep their knowledge current. They also keep themselves apprised of industry standards as they evolve. A broad-based understanding of the overall operation is a good attribute, as is a working knowledge of computer systems. All of these attributes can be acquired through training, which is readily available through numerous industry organizations. More important, good auditors are inquisitive, thorough and logical. Further, they do not bring to the table their own prejudices about the systems they audit. They must remain bias free to reach objective conclusions. The auditor’s role is not to police the system, but rather to be a catalyst for improving systems, processes and the work environment in general, and ensuring its ability to move forward effectively. While the regulations call for audits, they don’t tell how or how often an organization should conduct them. All they say is that companies must audit. The size of the company and its electronic record keeping systems, as well as the resources allocated to auditing, in large part determine the schedule for regular auditing. A solid auditing program captures the big picture. Thus, an audit may look at system logs during one audit, and if they are in order and there are no audit observations, the auditors may not revisit that component of the system during the subsequent audit. If, however, the audit uncovers a violation such as failure to maintain the procedure for maintaining the logs, the auditors may want to have another look at that part of the system prior to the next regularly scheduled audit. Other triggers for audits in addition to those regularly scheduled may be customer or patient complaints about products or records; an increase in the number of deviations or nonconformances in the system; a 483, warning letter or other citation; the extension of systems to a new site; or new processes. The auditors must thus be attuned to the signals for audits.




100

Good auditing practices can also keep the organization at the ready for an outside inspection. If a regulatory body such as the FDA plans a visit, the auditing function can help ensure that things are running smoothly. Similarly, if a company merger is planned and the company will undergo due diligence, the auditing function is a key asset in making sure the organization is functioning as it should. What can happen when companies haven’t looked at themselves closely can be disastrous when a potential partner, client or regulatory body inspects. Management is responsible for determining the need to audit, scheduling audits and supporting the actual auditing activities. Who actually performs the audits for a given function will depend on the scope of the audit and the skill set of the auditor. In a small company, one person may be responsible for all auditing activities. In a larger organization, a staff of auditors may be necessary, and preliminary auditing work may be completed by a manager, while the actual auditing is done by a staff member with results are assessed conjointly. The evolving regulations and industry standards, as well as the focus on continuing improvement, will continue to drive the need for audits. However, it is important to keep in mind that audits, when performed effectively, can streamline processes and facilitate efficient operations. That translates to a healthy bottom line.

THE SCOPE

OF THE

AUDIT

Sometimes the scope of an audit is determined by upper management or even requested by the chief executive officer (CEO). Consider, for example, a company that is planning to host a board of directors meeting where a new system is to be explained. The CEO may request an audit of that system to ensure a complete, accurate presentation and that there are no surprises. In most instances, however, the scope of an audit is based on the audit schedule and the resources a company has. Determining the scope of the audit is the place to begin any audit activity. What is the purpose of the audit? The scope of an initial audit of an electronic record keeping system may be broad. Consider the case of a system that is new to an organization, has undergone validation and been operational for six months. An audit of such a system should include everything from the supporting systems and documentation, including the training records, to the actual operation of the system, including printouts and verification of the dates and time on documents, as well as how users input data and how the system administrators manage the system. In essence, such an audit looks at all the functionalities of the system, its operation and its supporting documentation. The scope of subsequent audits may look at any component of the system. If, for instance, several users have complained about a certain difficulty with the system, the audit may look at the function of the system related to the difficulty, as well as the training records of the users to discover whether the difficulty actually rests within the system itself or if the recurring problem is the result of improper system use or management. The scope of any audit is not always an easy call. Too broad a scope can mean the auditors will not probe deeply enough into the system, but a very narrow focus can mean they will overlook its inherent characteristics. One way to make sure the Copyright © 2004 CRC Press, LLC



101

entire spectrum of the system is covered is to schedule audits that focus on one particular aspect. Once an audit history is in place, an assessment of the scope of previous audits can take place. Then, based on how the system is operating, the scope of subsequent audits can be broadened to include more functions, or narrowed to probe more deeply. If the results of previous audits show a negative trend, say a repeat error message when a particular function occurs, then a deeper probe into that function with a trend matrix and analysis for root cause is in order. If, however, the audit program is running smoothly and not uncovering any significant findings, but there are repeated problems with the system, that is a signal that the scope of the audits is not inclusive enough. Audits, over time, should serve to improve the system by catching all disconnects and negative trends and spurring corrective action.

PREPARING

TO

AUDIT

Once a company determines to audit an electronic system and has identified the scope, it needs to conduct some activities preliminary to the actual audit itself. These naturally involve reviewing the binding regulations and the documents in place in support of the system. Auditors must also understand the organization’s current needs. Have they changed since the system was last assessed? Is this audit going into virgin territory, where there has been no previous audit, or is it looking at a system that has undergone significant change? For instance, does the company now have a new partnering arrangement and hence new users, that must be taken into account? Has it changed the product line that the system manages? Has the volume of data input into the system increased or decreased dramatically? Have the facilities that house the system been renovated? All of these are factors in preparing to audit, and each needs to be addressed.

THE BINDING REGULATIONS The regulations that apply can be any of the CFR or any state, federal or worldwide authority that drives the management of electronic records. Thus, if a system is subject to 21 CFR Part 11, the predicate rules that apply may be from any part of Title 21 of the CFR, such as Parts 211, 820 or 606, which spell out good manufacturing practices for pharmaceuticals, medical devices and biologics, respectively. Consider the case of an electronic history record system for a medical device. Such a system is subject to manufacturing controls as delineated in 21 CFR Part 820.184 Device History Record as well as 21 CFR Part 11 Electronic Records; Electronic Signatures. Thus, depending on the application of the electronic record keeping system, any number of regulations may apply. For instance, electronic records generated in the tracking of radioactive materials are subject to Environmental Protection Agency (EPA) regulations. Electronic records for drugs containing narcotics are subject to Drug Enforcement Agency (DEA) regulations, and electronic records for clinical trials are subject to the ICH and other regulations. Thus, auditors must understand how these regulations marry up to the specific regulations that address electronic record keeping. Predicate rules apply.




102

DOCUMENT REVIEW Preparing to audit a system entails looking at the documents in place that support it. Companies have to maintain documents that show control of their systems and processes, and the facilities relative to them. If, for instance, the audit will address the change control aspect of the system, the SOP on system change control warrants review. This SOP in turn may point to other documentation that must be in place and current to support the system. Such documentation will include logs that record changes to the system itself as well as to user workstations. Also subject to review should be any test records that have been generated as a result of changes and training that occurs because of those changes. As auditors review the documents in place, they may find that the focus of the audit needs to be readjusted. For instance, do the documents present a complete view? Are there any overlaps? Are there any contradictions? Consider an audit of a Laboratory Information Management System (LIMS). To audit such a system, an auditor will need to review the SOP on the operation of the system, as well as laboratory methods that apply to the system. Depending on the scope of the audit, documentation review may extend to change control and system security. In reviewing the documentation, auditors should also look for any documents that were generated in response to nonconformance to the written procedures. In the case of systems such as LIMS, a spate of out-of-specification (OOS) results may indicate a problem that needs assessment. Documentation of the system, then, offers a view of how the system should run and how it actually does. Documentation by itself, however, does not prove that the system is running as it should, or that the system users properly adhere to the SOPs for the system. Then, too, the system may be working properly but lack the documentation to support it. In such a case, the preliminary document review has already found a serious problem: lack of documentation means lack of control and verification. Additional documentation that can be helpful in preparing to audit are previous audit reports and records, if any. Many companies do not retain audit reports. They are, however, required to show proof that they do audit. This they do in spreadsheets or log books that tell what underwent an audit, who the auditor(s) was, the date of the audit and select comments, if applicable. If a previous audit report is available, it will identify the status of the system at the last audit. A previous audit report will also show whether the audit was adequate or whether it overlooked any pertinent areas. If corrective action was indicated, a logical component of the planned audit is to include that component to see if the corrective action was satisfactory.

SCHEDULING

THE

AUDIT

The preliminary work generally presents a picture of what needs to happen. This is the basis for the actual audit plan. The auditors should be able to tell the focus of the audit and how long it will take. The next logical step is to schedule it. Scheduling an audit that will be effective requires flexibility. Scheduling depends on both the scope of the audit and on the audit area. If the scope of the audit means




103

looking at a system that interfaces with many sites, multiple time slots must be arranged. If one site is the focus, a single time slot may be all that’s needed. Also important is consideration of the work flow and user activity. If the company has acquired several new clients and users are working overtime to input data into the system, the audit is best reserved until that activity is complete. Finally, the start date must allow enough time for the auditors to prepare the audit materials. It is best to schedule the audit when the system is operating under normal work conditions. In addition, scheduling it for the end of July is better than scheduling it for Wednesday, July 17 at 2 p.m. This sort of rigidity can lead users and administrators, if they know the precise time of the audit, to stage activities that don’t yield a true picture of how the system works. Many companies do not announce audits; others do. The advantage of an unannounced audit is, of course, that auditors will see the system at work in its usual routine. The advantage of an announced audit is that there can be dialogue about the time the audit occurs. Consider the case of an audit of a system that occurs while the majority of users are attending a conference. Some flexibility is necessary. An audit can be announced to a department head, for instance, but not to users. That way, the auditors most probably will see the system work as it typically does. For an announced audit, it is usually wise to confirm in writing, even if there has been dialogue. Confirming in writing “formalizes” the audit and recaps what it will cover and with whom the auditors will need to speak. Putting it in writing also affords the opportunity to verify previous discussions and avoid misunderstanding about what is going to occur. Finally, written notification becomes part of the history of the audit itself. An e-mail is usually sufficient. The recipient of the correspondence can then respond and, if there are any questions, the audit team can provide additional information. This sort of give and take helps dispel the notion that auditors are synonymous with the police. Dialogue helps foster the attitude that audits are beneficial to all concerned, as they generally are.

AUDIT MEASUREMENTS Before a company audits anything, it needs to have a standard in place for measuring the results. The best way to measure results is to develop a system of ratings for observations. This system must be consistent for all auditing activities. There is no value in auditing a system using variable measurements. No true picture of the system will ever emerge unless the rating system is standard and understood by all auditors. If a company uses different audit measurements, the audit itself becomes less reliable. How can a company develop such standards? It doesn’t matter whether ratings are “class” or “grade” or numerical or alphabetic. What does matter is consistency, so anyone reviewing an audit report will know at a glance the outcome and what it means. The best way to establish a rating system is to define conditions and attribute a rating to each. Companies generally have four or five ratings that they apply to observations. The following is an example of one rating system: Copyright © 2004 CRC Press, LLC



104

1. Exceeds requirements. The system is operating optimally. 2. Meets requirements. The system is operating as it should, but there is some room for improvement. 3. Minor nonconformance. There is a nonconformance that does not have major impact. 4. Major nonconformance. A regulated requirement is missing and an impact is probable. 5. Severe nonconformance. A regulated requirement is missing and can cause severe effects, up to and including death. It is important to note that all grade systems have pitfalls. Some people are “grade conscious” and focus on the audit rating rather than the observation. Some companies, to counter this possibility, reserve the rating system for the sole use of the auditors. Thus, a system is not being graded per se, but the observations are.

THE AUDIT PLAN The plan is perhaps the single most important component of an audit. Nothing throws an audit off track more quickly than failure to lay it out beforehand. The plan is the roadmap for the actual audit. Some auditors like to prepare a flow diagram to help the audit stay on target. A flow diagram shows the sequence of the activities for a system. A flow diagram also helps the auditors themselves understand the system they are about to look at and assess. A written audit plan is also wise. Some companies insist on a formal document that outlines what is to occur. Others construct agendas that serve as the plan. Still others communicate the plan in internal correspondence. Sometimes, too, companies use a combination of approaches to reach a workable format. A plan, in any form, is helpful because it shows how each of the items to receive audit fits into the larger picture. Typically, a plan will include a control number, usually generated through a formal numbering system for the company’s documentation and the following elements: • • • • • • •

Time and date Purpose statement Explanation of the scope Items to undergo audit and the sequence A list of documents for review The name(s) of the auditor Managerial approval signature and date

It is best to remember that any audit plan put together at this stage may be subject to change as the final details are worked out.

CHECKLISTS

AND

NOTEBOOKS

In preparation for the audit, auditors can prepare checklists to capture information during the actual audit. A checklist is also a concrete reminder of what needs to be done; relying on memory alone can open the opportunity to overlook what’s in the Copyright © 2004 CRC Press, LLC



105

plan. Many companies have checklists for standard auditing that can be modified for individual audits. There is no formula for devising checklists. Many companies use a format that identifies the regulation and the respective element of the audit. Most checklists include room for comments and observations. Regardless of the format employed, auditors need to remember that the purpose of the checklists is to capture data during the physical audit. Auditors usually also keep notebooks into which they record observations. This is prudent, because the checklists don’t, by their nature, allow room for recording pertinent details relative to the observation. Notebooks are the place where auditors make notes to themselves, pose questions that the audit has raised, identify issues they need to pursue and record what they’ve seen and heard. Conjointly, notebooks and checklists are the tools that allow auditors to capture the information that will go into the audit report.

CONDUCTING

THE

ACTUAL AUDIT

The best audits occur when auditors understand the culture of the organization they are auditing. Auditing a large system that several hundred people use will be different from auditing a small system with 50 users. Variables might be the tenure, attitudes and habits of the employees. Are they long-time staff or new hires? Are they resistant to electronic record keeping, enthusiastic or fearful? What is the mix of personalities? Is there a language barrier that can impede communication? Are there ethnic habits that may affect the work flow? All of these are factors to consider when an audit addresses an electronic record keeping system. Auditors should record the names of the people they interview and capture the information conveyed verbally. They should also identify the documents they review by title, number, version and effective date. They should also record how the audit proceeds and note whether there are any visible or suspected nonconformances. Recording questions that may arise during the audit is also wise. Sometimes people subject to an audit ask how “the system looks.” It’s usually best for auditors to refrain from volunteering opinions during the audit, since they need to look at the audit results, usually in tandem with members of management, to make a clear assessment. The last caveat for auditors is to take the necessary time to audit thoroughly. They should not rush through the audit; it’s important that they understand the system they are looking at.

INTERVIEWING USERS Unless the audit is unannounced, the preaudit correspondence should have identified the staff the auditors will need to speak with, and there should be no last-minute surprises. When auditors meet with system administrators, users or information technology (IT) people, they can ask them how the system is working, what is working well and what could be better in relation to their input into the system. It is important that auditors hear what is said, as well as what is not. This requires good listening skills. Auditors should be cooperative and interested in what the interviewees have to say. A secretive or cold demeanor, for instance, can have a Copyright © 2004 CRC Press, LLC


106


negative effect by raising defenses and making interviewees feel “put on the spot.” Auditors are not interrogators; they are information gatherers. Thus, the attitude of the auditor sets the tone for the audit in its entirety. Bear in mind, however, that human personality encompasses many variables and there is no guarantee that an open position on the part of the auditor will yield cooperation. But, if staff members are demonstrably uncooperative, that can be telling as well. Lack of cooperation may stem from many sources: discontent with the work conditions, internal management problems, the insecurity of the interviewee or a cultural expectation. While it may appear that the auditor is not receiving the information he wants, he is receiving information that may be equally important. Lack of cooperation may be, in a worst-case scenario, a cover-up of poor work practices or a violation of the SOPs that drive the system. It may also point to problems with the potential to escalate and injure the system. If cooperation is lacking, the auditor may decline to complete the audit and arrange for a re-audit after the lack of cooperation has been addressed by management. While the possibility of lack of cooperation is always present, it is not typical. Most people will share their insights and provide information. As they do, auditors should chart the information. If the information is unclear, the auditor may interrupt and pose questions. A good way to garner clear understanding of what is being said is to rephrase. “So what you’re saying is that the system automatically logs you off if you’ve been gone for five minutes — or is it then?” This sort of feedback from the auditor will prompt clarification of key points. System users and administrators should know the system well, and when people know something well they often overlook key attributes because, to them, they are commonplace. It is up the auditor to probe. Good questioning techniques yield the best information. Asking questions that cannot be answered with “yes” or “no” ensures getting information. Open-ended questions start with words like “Who,” “What,” “Where,” “When,” “Why” and “How.” Consider a question like this: “Does the printout include the time and date?” A yes or no response is likely. It’s best to rephrase the question like this: “How do you know when the record was printed?” That way the interviewee will have to explain. Sometimes an interviewee will not answer the question directly. This may happen because the interviewee has her own agenda and wants to get a different message across. It may be that she doesn’t know the answer; it may be that she doesn’t want to give the answer; or it may be that she doesn’t understand the question. The auditor should listen to the answer to the question and then rephrase the original question until a clear answer is proffered. This amounts to active listening. It’s important to note, too, that people communicate with more than just words. Auditors must thus look at nonverbal signals that people send out. Does an interviewee stammer or fidget or fail to make eye contact? Does he stand defensively with crossed arms and glower? These may be indicators that there is something the interviewee does not want the auditor to know. It may also be, however, that the interviewee is simply nervous or has a defensive attitude. The ability to observe mannerisms and make sense of them evolves over time, and good auditors develop a natural instinct for it.




107

OBSERVING SYSTEM OPERATION Once the auditor has spoken with the people who support and use the system, it’s time to actually look at the system in operation. Every system will have mix of users and IT who access and maintain it. Thus the thrust of the observations will be contingent on the actual matrix within individual companies and their systems. Do users accurately follow the documents that support the system? Equally important are the work habits of the users and IT staff. Do any users have their passwords displayed openly, such as affixed to their workstation on sticky notes? Do they log on and off properly? Do users clearly seem to know how to use the system, or are they having trouble? How are problems handled? Are log books that record changes to the system or workstations up to date and complete? Who maintains them? Where do they reside? Auditors should look at the system itself and how it is functioning. For instance, how are printed records handled? Do they indicate that the record is valid only on the print date, if that’s what the driving SOP says? If record transfer is part of the system, how does it occur? Are printouts clear and legible and identical to the electronic record displayed on the screen? Questions like these warrant pursuit. Initial audits of electronic record keeping systems should look at all of the following areas, including documentation and work practices related to them. Subsequent audits may focus on one or two of these areas, particularly if the previous audit produced an observation in the area. Training Training is a requirement. The audit needs to determine whether training occurs when it should and that there are records in place to verify that it did. New users must be trained prior to system access, users who have repeated problems with the system require training and all users require training in modifications to the system. In addition, training records must be current and in place. Building Security When the audit looks at security, it needs to probe into the activities of facility operations. Who has access to the facilities and thus possibly the system? How are visitors received into the company? What sort of security exists to keep visitors from accessing the hardware and software? How do employees enter and depart the building? What happens when people leave the employ of the company? Can they reenter at will, or are their key cards disabled? Computer Security When employees’ job duties change, are they disabled from using the system and how does this occur? Does human resources notify system administrators to block these employees’ access to the system? Does an IT help desk representative ensure that a person asking for a password reset is really the person associated with the



108


account to be reset? Is there a mandatory password change interval? How are new security roles or changes to existing ones modified by IT? Backup How are data on networked servers, workstations and parts of systems backed up? Where is backed-up data stored? How is it managed? Media, labeling, reuse and destruction should also receive attention. Archiving Data How is data archived to make more storage space available on the system? How are archived data retrieved? System Maintenance Event Recording Is there an audit trail of modifications to the hardware and operating environment? Does the audit trail for the system, typically in log books, identify the date of the modification, a description of the modification, testing explanation, the name of the tester and the date of completion? Change Control Are system-specific modifications captured in writing? Do change records, usually logs, capture the initial request for a change, request approval, modification testing, test case approval and request closure? Disaster Recovery Can systems be brought back on line following the loss of hardware, software or data? Is there spare equipment in place, or is there a maintenance agreement with the vendor? Is the maintenance agreement up to date? Has spare equipment been validated? Electronic Signature Policy If the system employs electronic signatures, have all signatories signed accountability statements attesting to the fact that they understand their electronic signature is the legally binding equivalent of a manual signature? Where are these records kept? Electronic Record Retention Does the system retain records according to the regulations? Electronic records require the same retention times as paper records. Computer System Validation Has the system undergone a validation? Do the records of the validation point to a robust system? Has the system been upgraded or modified beyond what change control addresses? If so, has the system undergone revalidation or partial revalidation? Copyright © 2004 CRC Press, LLC



109

Nonconformances At any time during the audit, the auditors may observe what appears to be a nonconformance. If they have done their homework well, they will have come into the audit with expectations that activities occur according to approved procedures. Are activities occurring as they should or are there disconnects? Each auditor needs to note the observed or suspected nonconformance and record it, so that the audit report can address it sufficiently. When a nonconformance is apparent or probable, the auditor may probe into it for more information, provided it falls within the planned scope. The audit itself should not venture beyond the planned scope; doing so is tantamount to going off on a tangent. Veering off in a new direction can sabotage the purpose of the audit. An observed nonconformance, however, can lead to an additional audit, one with a narrower scope, but one that probes into the area where the nonconformance resides.

INFORMATION EXCHANGE When more than one auditor is involved in the audit, it is a good idea to periodically meet to assess the progress. A periodic exchange of information may alert one auditor to look more closely at a process or system operation. A periodic exchange of information with department managers is also a courtesy. Letting them know how the audit is progressing reiterates a common goal: to assess the system so it can function optimally. At the end of the audit, auditors can participate in a wrap-up meeting where they present an overview of the audit findings. This is also a good place to state what the auditors saw and did not see. Citing what is good about the system operation and employee work habits is a good place to begin. Then, if there are any areas that will need improvement, the auditors can present that information objectively. Finally, the auditors should ask for feedback. Feedback helps ensure that the information that goes into the audit report is both accurate and trustworthy. It is always possible that an auditor has misinterpreted an observation. If it has not already been discussed during the audit, this is a good time to clarify. It should also be clear that the results of the audit will be subject to review and evaluation.

EVALUATING

AND

REPORTING RESULTS

It is a rare auditor who does not form opinions during the actual auditing process. But it is usually only at the end of the physical audit that a pattern emerges. The next step is for the auditors to evaluate the results in conjunction with management. This includes assessing what went well and what could have been better during the audit process. And, of course, it is imperative to look at the observations in total. For instance, was an entry missing from a logbook? If so, was this a one-time occurrence, or does it point to a trend? Similarly, an observation that some staff do not adhere to procedures properly may indicate that training is ineffective or that there is inadeCopyright © 2004 CRC Press, LLC



110

quate management review. Or, an observation that effective dates on documents are more than two years old may point to inadequate document review and revision.

REPORTING AUDIT RESULTS Audit results are usually written out for a specific audience, which may be department managers in the company and the quality assurance (QA) group, if such a function is staffed internally. If a short report is all that is needed, a memo or executive summary may suffice. If the audit was extensive, however, and many sites and interfacing systems were involved, a longer report may be necessary. The audit report should summarize the findings, then present them sequentially. These should be objective and straightforward. For instance, an observation may be that system administrators do not have access to the procedure for exporting data from the system. Sometimes audit reports also include recommendations, especially if the auditors are members of the QA group. Companies that engage external auditors may also request recommendations from them, based on their observations.

FUTURE AUDITS If the audit results were favorable, the next audit may take place at a regular interval, typically one year. If there were significant nonconformances, people responsible for corrective action generally respond to the audit report findings and tell how and when they will implement corrective action. A review of the audit response should assess whether the proposed corrective actions are suitable. It is best to keep in mind that there are many solutions to most problems. Just because the person driving the audit itself would resolve a problem one way, does not mean another way is not equally good. If the solution will resolve the problem, it is an acceptable solution. If the solution doesn’t seem to address the root problem adequately, there may need to be discussion until an acceptable resolution is attained. It is important for the person(s) responsible for the auditing function to retain documentation of the interchange. Notebooks can also prove invaluable during the problem resolution process because they contain the observations and notations captured during the physical audit. Once a corrective action plan is accepted, it is smart to verify the completion of each corrective action. The company may then schedule a follow-up audit that looks at the nonconforming areas in more depth to see if the problem has been resolved within the predetermined timeframe. Companies sometimes retain the audit documentation to review prior to a subsequent audit. Other companies do not and rely on an audit log to see what was audited, when and by whom. What is required, however, is that companies keep records that reflect an ongoing audit process. Often this takes the form of a log.

KEEPING

THE

AUDIT FUNCTION VITAL

Since audits are necessary, they should be part of the overall operation of a company. While an overall plan for auditing may work well for several years, it may need Copyright © 2004 CRC Press, LLC



111

adjustment as changes occur within the company. For instance, if an area undergoes significant growth, it may require a different auditing approach. It may be that where one audit was sufficient, the area may require two or more. Conversely, if a company determines to outsource some of its activities, internal audits may decrease, while external audits receive more focus.

AUDITING

AND THE

REGULATORY INSPECTION

A good auditing program is essential for hosting a regulatory inspection. Regular looks at the system keep it fine-tuned and running efficiently. It is far better for an auditor to spot a problem area than it is for a regulatory inspector to do so. However, the auditing function, while necessary and valuable, is not sufficient preparation for receiving an inspection. An inspection may encompass many systems, or may focus solely on the electronic record keeping function. Since 21 CFR Part 11 has been in effect for more than five years, companies should anticipate that electronic record keeping will receive some focus. HIPAA-compliant companies would also be prudent to expect an inspection to focus on records and security. Organizations often put together a preparation team to prepare for an inspection. When a regulatory body, potential partner, or client inspects a company, the company has no way of knowing what the inspectors will want to evaluate, to whom they will want to speak or what they will want to see. It is smart, therefore, to designate a company employee to serve as the host for an inspection and to have a protocol in place for receiving an inspection. Such a document, usually an SOP, spells out the process for hosting an inspection, from the moment the inspectors come to the site to the time they exit the facilities. This document should spell out what the company will make available to inspectors and what it will not. For instance, the organization may not make internal audit reports available to regulatory agency personnel, and is not obliged to do so. It may, however, make a favorable report available to an inspection team evaluating the company to determine to use it as a contractor. The SOP should also state whether the company allows photographing and delineate whether any employees may sign affidavits upon request. Most companies have policies that don’t allow either. It is always a good idea to keep abreast of trends and rulings. Guidance documents also provide information about what may occur during an inspection. Warning letters resulting from inspections, posted on the FDA’s website, are good indicators of current regulatory thinking. So are industry publications that address electronic record keeping and inspection techniques and focuses.

THE MOCK INSPECTION Before an inspection happens, many companies conduct a mock inspection to prepare the employees. The mock inspection can be performed by the QA group or an outside contractor. The outside contractor is often the best option, because employees won’t know the personality of the contractor, and the mock inspection is thus more likely to simulate a real inspection. This exercise will help prepare staff for the actual event. They should be instructed not to volunteer information and to refer questions to managerial staff or Copyright © 2004 CRC Press, LLC


112


the host. When a mock inspection occurs, the mock “inspector” should see what the actual inspector will see. After a mock inspection, there should be evaluation of what occurred and an assessment of the probable results of an actual inspection. If employees failed to behave appropriately, such as by blurting out confidential information or pointing out problematic areas, they should be cautioned to refrain from doing so during the actual inspection. The important thing to remember is this: you can never predict the outcome of an inspection, but you can keep your house in order and prepare staff and systems for inspections.



7

Moving Forward

Integrity without knowledge is weak and useless and knowledge without integrity is dangerous and dreadful. Samuel Johnson

Standards change. That is a simple statement, but it carries a powerful message. It behooves companies to assess changes in industry standards. These changes are what companies frequently are measured against. Industry standards are how industry and the Food and Drug Administration (FDA) or another regulatory body conjointly interpret the regulations, which, by themselves, do not change all that much. Watching trends in regulatory rulings to see if the company is moving in a compatible direction is common sense. It boils down to this: If companies remain proactive and vigilant, there will be fewer unpleasant surprises regarding compliance. Changes to regulations may require activities that were not in the initial game plan. Is there anything the company needs to do to meet any new directives? Being ever watchful and adaptable are key. At the root of remaining compliant with regulations is full understanding of the regulatory goals and why they are necessary. Companies may consider forming a committee devoted to assessing compliance needs. Such a committee can make inroads in educating the work force about validation issues and the applicable regulations, and provide encouragement and advice for validation teams. A committee can also serve as a liaison with upper management so that the executive team understands and supports validation efforts.

COMPUTER SYSTEM VALIDATION COMMITTEE A useful way to acquire and share information required for compliance is to form a 21 CFR Part 11 Committee or a 45 CFR Parts 160, 162, 164 committee. Prior to promulgation of 21 CFR Part 11, this committee was often referred to as the Computer System Validation Committee (CSVC). More recently it has been called the Part 11 Committee (P11C). It is probable that Health Insurance Portability and Accountability Act (HIPAA)-driven systems will develop a comparable terminology. Members representing all departments involved with current good manufacturing practices (cGMPs), good clinical practices (GCPs), good laboratory practices (GLPs), good distribution practices (GDPs) or other binding regulations can compose the P11C. Members can also include information technology (IT) personnel, as well as quality assurance (QA) and regulatory representatives. A validation committee usually has an acting chair and chairs may rotate. A committee can provide many benefits to the organization. All departments may use committee members as con113 Copyright © 2004 CRC Press, LLC



114

sultants on departmental project teams. A typical validation committee for 21 CFR Part 11 performs the following functions within a company: • • •

• • • • • • •

Develops a company SOP infrastructure that meets current regulatory and industry requirements. Performs gap analysis for existing systems and develops remediation plans for 21 CFR Part 11 compliance. Inventories all software and uniformly assesses it for validation requirements. The software inventory contains the validation status or justification as to why validation is not necessary. The software inventory also facilitates compliance with software licensing requirements. Informs all departments of proposed software projects to leverage crossdepartmental work flows. Ensures that all departments receive current and uniform education. Arbitrates cross-departmental project issues. Shares their project experience to promote continual procedural improvement. Maintains a repository of information on current regulatory and industry standards and shares this information throughout the organization. Evaluates proposed computer systems to ensure user requirements represent all intended users in the organization. The committee chair summarizes and reports the status of computer system validation to senior management.

What the committee does not do is assume responsibility for performing the actual software validation, which should always remain the responsibility of the software users. The P11C does not prioritize projects or make other executive management decisions. It is purely a functional group that facilitates decision making and paves the way for company-wide 21 CFR Part 11 compliance. The committee usually has a member representing QA, IT and each functional group in the organization that uses regulated software and electronic records. When the committee is first established, it may be necessary to meet once a week for several months. Once the standard operating procedure (SOP) infrastructure and inventory are drafted, the committee may need to meet only once a month. To leverage training and education resources, members of the committee obtain continuing education through seminars and conferences in a rotating fashion. It is the responsibility of the attending member to train the remaining members of the committee.

CHANGING COMPANY CULTURES Electronic record keeping and all that it entails change company cultures. It may not seem so at first, but the first steps to go to electronic record keeping will start a ripple effect in the company culture. Companies strive to set goals, instill processes, strengthen management and offer incentives; these all build an infrastructure unique to the company. Computer systems (software) are a dominant and increasing part of business infrastructure. Copyright © 2004 CRC Press, LLC


Moving Forward

115

The requirement for computer system validation in 21 CFR Part 11, for instance, has a far-reaching impact on companies. The activities that occur during user validation unify the software, procedures and people to create a system. During user validation, users receive detailed training on the system, learn how to implement their current processes using the new system and learn how to use the system to perform functions that were previously unavailable. The process of validation creates a new set of procedures that guide the operation of the system. Most importantly, users learn that the software is a tool in a process and the users are responsible for ensuring that the process is operating as intended. Through user validation, management learns that the computer system is an extension of human resources. As the business changes, the computer systems must change as well. Think of the computer software as a virtual employee. It has similar needs such as training, performance reviews and time off that occur as upgrades, revalidation and maintenance downtime respectively. In this sense, it is part of the workforce. The change in company culture results in people taking personal responsibility for the ongoing health of the system. When the system provides unexpected or incorrect results, the users are more likely to be readily aware and take responsibility for corrective actions. Users take pride in the system and take ownership of their data. The users, IT staff and vendor work together to maximize the value of the computer system. Computer system validation is not a one-time event. Software is constantly evolving to keep up with the increasingly complex needs of the people who use it. Therefore, validation is an ongoing necessity. By making validation a part of the company culture, companies are promoting continual process improvement. The end result is exactly what the FDA intended; improved data integrity, security and training, with less chance of failure.

GAP ANALYSIS Gap analysis measures a company’s level of compliance with respect to current industry standards. As the HIPAA regulations drive industry standards for patient records, gap analysis will be able to do the same. The gap analysis technique can be used in many areas. When performing a gap analysis for 21 CFR Part 11, it is best to start with the SOP infrastructure. Any gaps found there will surely result in gaps in other areas. To perform a gap analysis for the SOP infrastructure, all of the company’s procedures are reviewed to determine how they measure up to the requirements defined in current industry standards. An experienced consultant can usually perform a procedural gap analysis in a day or two. Another type of gap analysis involves comparing a software application’s functionality against the current industry standards for 21 CFR Part 11 compliance or 45 CFR Parts 160, 162 and 164. The analysis involves review of the software functionality and system procedures. The users are an excellent resource for making these assessments. Once the gaps are known, the company can create a remediation plan that documents the strategy for evolving the system into compliance. Copyright © 2004 CRC Press, LLC


116


COMPUTER SYSTEM INVENTORY To perform a gap analysis for all software applications, a company must have a list of all software in use. This is an industry standard for FDA-regulated companies, and the FDA will request a software inventory during an inspection, so it is best to keep it up to date. Again, the existing industry standards are likely to set the benchmark for the HIPAA regulations. The inventory should list all software used in the company, not just regulated applications. Software that is not regulated should be identified with a statement that justifies the rationale. The inventory should contain the validation status, which can be as simple as “not validated,” “validated” or “in the validation process” (prospective or retrospective). The inventory should also contain the status of functionality compliance to the regulations. The status can be a simple measure such as “good,” “fair” or “poor.” The objective is to provide a means to rank the inventory, not restate what is in the gap analysis. Often the software licensing records can be used to start the inventory process. The software inventory is much more complex than a list of software, because some can be used to make many applications. Database and spreadsheet software such as MS Excel, MS Access and Claris FileMaker are application-building tools. The software itself does not require validation and does not require compliance. Instead, each application made with these software tools must be evaluated to determine whether the application is regulated. Regulated applications must be validated and be compliant. Inclusion of regulated applications in the software inventory makes the inventory a much more complex and difficult assignment. The validation committee is the logical resource for performing this duty. A regulated application involves all good practice (GxP) data and is used to make decisions that affect product quality and patient safety. Simple lists are not regulated applications. Often the end users and quality assurance staff are the only people who can make the determination that an application is regulated or not. The software inventory should contain all regulated applications. It is not practical or necessary to include nonregulated applications in the software inventory. Most companies, especially large companies, spend a tremendous amount of time and resources creating a comprehensive software inventory before they address validation status. This approach is counterproductive. The requirement for computer system validation is by far the greatest regulatory requirement. Computer system validation is more important than having full compliance with the features required by 21 CFR Part 11. Companies should create a preliminary software inventory by quickly identifying the high-risk regulated software applications and their validation status. Software that is not validated should undergo a gap analysis to create a remediation plan. The remediation plan may indicate that the software needs to be retired, replaced or upgraded. Whatever the case, the primary objective is to make any necessary changes and perform computer system validation as soon as possible. Once the preliminary software inventory has been made and the required remediation plans have been completed, management can prioritize projects. Following this step, the software inventory can be made more complete and can identify regulated software applications with less than high risk. Sometimes a software Copyright © 2004 CRC Press, LLC


Moving Forward

117

application, such as an Excel spreadsheet application, is found to be of high risk and not compliant with the regulations. For example, sometimes a spreadsheet application is used for quality control testing and product release. In this case, redesign and validation of application is necessary, as well as review of project priorities. Software Inventory Elements • • • • • •

Software Version Validation status 21 CFR Part 11 status (resulting from gap analysis) Remediation Plan complete Priority

It is important to understand that only a small percentage of software is highly 21 CFR Part 11 compliant. For commercial off-the-shelf (COTS) software, most vendors are evolving their products into compliance. As industry standards change, the evolution continues. Some vendors are unwilling or unable to make their products compliant. This is also true for many homegrown software products. Without a plan for compliance, these software products are orphaned. If a fairly compliant COTS solution is available, industry standard requires that orphaned software be replaced in accordance with the priority hierarchy for all software. Since the software inventory must be kept up to date, it is the basis for a company’s overall software validation strategy. New systems must be 21 CFR Part 11 compliant and must be validated. Upgrades to legacy systems must be validated. It is true the FDA will have little leniency when it comes to new installations. Even though 21 CFR Part 11 has been in effect for more than five years, virtually no companies are compliant in all areas. The FDA will focus on systems based on risk. Companies that provide the FDA with a comprehensive validation strategy and show good faith in executing them will most likely be considered favorably during inspections. Will the need to be compliant go away? It seems certain that companies will continue to acquire COTS software, and system requirements will continue to be more complex. That systems requiring validation will become more plentiful is a certainty. Computer technology evolves rapidly, and the future may bring dramatic new technologies that alter the way regulated industries do business. The FDA itself may find new ways of assessing systems and provide industry with guidance on just what to expect. It has been said we are just at the beginning phase of electronic record keeping. Where technology and the law, in tandem, will take us is unknown right now. That it will change the face of how we do business tomorrow is certain.

REVALIDATION When a system has undergone validation and is operational, it is easy to become complacent and think you’ve finished with the business of validation. This sort of Copyright © 2004 CRC Press, LLC


118


thinking leads to the easiest way to fall out of compliance. Initial validation in itself is insufficient. The bottom line is this: No validation is ever a stand-alone event. Rather, it is the first of many events that ensure the system operates as intended. For a system with a 10-year life cycle, the initial validation comprises only about 20 percent of the activities that account for what it takes to keep the system compliant. The other 80 percent of the validation effort occurs as subsequent revalidation activities in the form of change control or validation projects. The combination of the initial validation project, maintenance event logs, change control documentation and subsequent revalidation projects provides proof of a computer system’s ongoing validation status. Even if the company has not upgraded the system or made significant changes to it over time, it still needs close attention. Normal troubleshooting — assessing why something happened and how to fix it — can be a trigger to question whether the system needs to change and whether those changes require full or partial revalidation. An audit of the system may also point to better ways to operate it and manage records. An audit can be also be a trigger for questioning whether the system needs to be modified and subsequently validated. An electronic record keeping system is thus an ongoing endeavor.

REMAINING VIGILANT Keeping a system running well and assessing it with regularity is essential. Also essential is the need to keep abreast of industry standards because they do change. Standards for HIPAA regulations are guaranteed to evolve and change, because they are not yet fully in place. It will take time for industry to respond to the new regulations, just as it took time for industry to understand Part 11 and set standards for implementing and maintaining electronic records. Further, the ability to meet industry standards plays a large part in how companies are measured. Thus, it is prudent to watch trends in regulatory rulings. If, for instance, the FDA cites a company for faulty electronic record keeping and posts it on the Web, it is a good idea to find out why the company received a citation and see whether the same thing applies to your business. Other places to gain information about evolving industry standards are forums, professional associations and conferences, training seminars and publications. Many government as well as private enterprise publications provide useful information. Many things factor into trends. For instance, the trend is to the adoption of biometrics, especially fingerprint scanners. This is probably due directly to terrorism. Also, the use of virtual private networks (VPNs) to increase security while expanding network access is a new standard that companies are embracing. Gone are the days when all people have to drive to their place of employment to do their work. With VPNs and wireless Internet connections, people can work from virtually anywhere. Iris scanners are also being adopted. Consider that airline companies now routinely use iris scanners to ascertain that the pilots are who they are supposed be. One thing is certain: technology will continue to advance and electronics will play an even greater role in creating records.



Moving Forward

119

There has been enough time for the FDA-regulated companies to determine what needs to be done and how to do it. Companies must understand that a regulatory inspection will include a look at electronic record keeping. Be prepared.



8

Frequently Asked Questions

Knowledge is of two kinds. We know the subject ourselves, or we know where we can find the information about it. Dr. Samuel Johnson

Going to electronic record keeping means assessing the requirements and implementing procedures that satisfy those requirements. Each organization is unique, however, so undoubtedly questions will arise. Because industry standards are in place, many questions have clear answers. The following are questions frequently asked about 21 CFR Part 11 Electronic Records; Electronic Signatures. The answers yield solid advice for satisfying both 21 CFR Part 11 and the Health Insurance Portability and Accountability Act (HIPAA) regulations that address electronic records (45 CFR Parts 160, 162 and 164).

BINDING REGULATIONS 1. Q. What are the precise regulations that address electronic record keeping? A. 21 CFR Part 11 Electronic Records; Electronic Signatures became law in 1997. Industry standards have evolved since then. In 2003, the Department of Public Welfare passed 45 CFR Parts 160, 162, and 164, as part of the HIPAA regulations, into law. The requirements of these regulations parallel those of 21 CFR Part 11. HIPAA requires the same types of electronic controls as Part 11, so the HIPAA-driven industry can use the already established standards developed by the Part 11-driven industry. In short, industry standards affect all electronic records regardless of industry. Since Part 11 and HIPAA are related for electronic records, industry standards in one will affect the other. 2. Q. Why should companies impacted by 21 CFR Part 11 look at HIPAA regulations? A. HIPAA will affect many of the Part 11-driven industries. Companies conducting clinical trials, for instance, will need to adhere to the HIPAA regulations for electronic record keeping, since clinical trials rely on patient records.



122


3. Q. What exactly constitutes an electronic record? A. Electronic records cover a wide scope. The Federal Register, in the mid 1990s, defined an electronic record as “any combination of text, graphics, data, audio, pictorial, or other information representation in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system.” 4. Q. Does 21 CFR Part 11 apply only to those systems that employ electronic signatures? A. The regulation applies to all systems that manage records electronically. Electronic signatures are optional. 5. Q. An electronic record is printed and then faxed to a second company. The second company receives the fax on a standard fax machine that creates a print out. Does Part 11 apply to the second company for this record? A. No. Part 11 specifically excludes the transmission of paper records. If the data received by the second company is used to support good practices (GxP) data or there is risk involved related to decision making based on this information, predicate rules would apply to the paper record. 6. Q. In the previous scenario, the second company receives the fax on a computer and saves the data in a file, which is then printed. Does Part 11 apply to the second company for this record? A. If the data received by the second company is used to support GxP data or there is risk involved related to decision-making based on this information, Part 11 would apply to the electronic record. 7. Q. Does 21 CFR 11 apply to just those systems acquired after the final rule was made effective in 1997? A. No. The regulation applies to all systems. However, the February 2003 guidance document indicates that the FDA is not enforcing Part 11 requirements on pre-1997 systems provided they don’t have significant risk. 8. Q. If a company complies with the text of the regulation, is it sufficient to avoid citation? A. No. The FDA issues the regulation, but it takes time for industry to respond and establish standards for compliance. These standards evolve from discussions between companies and the agency. The Food and Drug Administration (FDA) can therefore cite a company for failure to comply with industry standards. 9. Q. If a small company still uses paper records and does so compliantly, will the FDA ever mandate that it must employ electronic record keeping? A. Probably not. But it is likely that companies that hold onto paper record keeping will fall behind, and the inability to use electronic record keeping will impair their ability to maintain a viable business position. Copyright © 2004 CRC Press, LLC



123

10. Q. Are there plans to harmonize electronic records and signature requirements between the U.S. and the European Union (EU) regulatory agencies? A. Available EU documents that delineate electronic record keeping embody the same principles and controls that 21 CFR Part 11 spells out. 11. Q. Does 21 CFR Part 11 apply only to electronic records that are inspected by the FDA? A. No. The regulation also applies to electronic records not submitted to the FDA that are relative to the company’s design, development, manufacture, packaging, distribution and tracking of its products. 12. Q. Should an international company have worldwide procedures in place that address 21 CFR Part 11? A. The FDA does not expect a company to have one set of procedures that are applicable to all sites the company may have. Each facility should have procedures specific to the operations that take place there. Bear in mind, for FDA-regulated products made for export to the U.S., the company must have SOPs that cover the predicate rules as well as Part 11. 13. Q. What can a company do if it suspects it is not fully compliant? A. First it needs to become informed, then it needs to take action. Company staff can become educated by attending conferences and seminars. A gap analysis, performed by a qualified consultant, will also reveal where the company is deficient. Armed with the correct knowledge, the company can take measures to bring it into compliance. 14. Q. Are companies required to adhere to guidance documents issued by the FDA? A. Guidance documents are not binding and are subject to revision and repeal. While a guidance document may reflect the FDA’s position at one point in time, companies should always remain compliant with the intent of the actual regulations.

SOFTWARE VENDORS 15. Q. If a company wants to install an electronic record keeping system, can it contact the FDA for advice and recommendations for software? After all, the FDA has been auditing companies with electronic record keeping, so it has first-hand knowledge of which systems work well and why. A. The FDA never endorses specific products or evaluates software aside from that used in regulated companies. To recommend products or even publish a list of “acceptable” software would be unfair to software developers. Copyright © 2004 CRC Press, LLC


124


16. Q. Why aren’t vendors of COTS software regulated by the FDA? A. The FDA can regulate only companies that produce goods that fall under the FDA’s legislative jurisdiction. Regulated companies do, however, assume all liability for their vendors, and therefore companies basically regulate what vendors provide; this, in turn, makes them indirectly regulated by the FDA. This is an interesting “trickle-down” concept that really works quite well. 17. Q. A legacy system went into production prior to 1997, when Part 11 became effective. The vendor has provided software upgrades that include audit trails. The users have not installed the upgrades. Is the system exempt from Part 11? A. First, the regulation has no legacy exemption, so the upgrade and validation are required. According to the Febuary 2003 and August 2003 guidance documents, the FDA is not enforcing compliance for legacy systems with less than high risk. The availability of upgrades that provide Part 11 required functionality removes the legacy exemption for all but low-risk systems. Installation and validation must be included in a remediation plan, with prioritization based on risk. 18. Q. If a company does a thorough job auditing a software vendor and finds that the vendor is totally compliant with the binding regulations, must the company still perform user validation of the system? A. Yes. Software must be validated from both the developer and user perspectives. Even if software was developed expressly for a unique need and is not commercially available, it should still undergo developer validation to ensure its suitability for its designated function. This does not eliminate the need to perform user validation because the system must also be validated for its intended use, and only the users know exactly what that is. 19. Q. Many software vendors provide user training. Is that sufficient or must companies also train users? A. Vendor training can be useful, but it is not sufficient. Users must undergo training on the processes specific to the application of the software and their individual tasks. Only users know what that application is. One solution is to have the vendor train a select group of people, have those people design the training in how it will be used in-house and then deliver it to the users. 20. Q. What’s the difference between developer and user validation? A. Developer and user validation have commonalties, but the primary difference is that they are validating for different objectives. The developer wants to confirm that the product provides all the functionalities it has built in. The user wants to confirm that the product does what it is intended to do in the actual company environment. Copyright © 2004 CRC Press, LLC



125

21. Q. If we purchase software that a vendor says has been validated and is 21 CFR Part 11 compliant, why do we need to validate again? A. Vendor claims do not ensure compliance with the regulation because they are not regulated and never undergo audits from regulating agencies. Further, even when a vendor shows evidence of validation, it is validation from the developer’s perspective, not that of the end users’ perspective. The regulations require validation from the users’ perspective. 22. Q. Is it possible for a product to be 21 CFR Part 11 compliant even if the vendor is not 21 CFR Part 11 compliant? A. For the product to be compliant, both vendor and product must meet the regulatory requirements. A product is made by the vendor. The quality of the vendor can directly affect the quality of the product. 23. Q. Aren’t large, well-established software vendors preferable to smaller, newer software vendors? A. Not necessarily. Often innovation and compliance are easier to achieve at a smaller company. Further, some software vendors with products that have been on the market for a length of time may not be keeping up with industry standards in their products. Thus, it is best to investigate a range of vendors to find the most suitable match between company needs and available, compliant software. 24. Q. When a software vendor issues an upgrade that it has validated, can a company install the upgrade into the production environment without additional validation? A. Users must validate all changes. An upgrade is such a change, and according to the complexity of the upgrade, may require partial to complete revalidation. Depending on risk, validation should occur in a test environment before making the upgrade to the production environment. 25. Q. Should a company always upgrade when the developer makes an upgrade available? A. It depends. Users should first determine whether the upgrade has features that will improve the operation of their application. If there are significant changes, such as a feature that improves the audit trail, they may opt to do so. However, many companies hold off on incorporating upgrades if they don’t really need them. This makes sense because changes to software often mean there are bugs in the system that need to be worked out. Thus, waiting a while for feedback to see how the system fares in production elsewhere may be prudent. 26. Q. How does a company know what changes have been included in an upgrade? A. The vendor should supply release notes that detail the changes made between software versions. The release notes may be posted on their web site or included with the software upgrade package. Copyright © 2004 CRC Press, LLC


126


COMPUTER SYSTEM VALIDATION 27. Q. The validation process may uncover the need for supporting documents, such as an SOP for computer system validation. If such a document is drafted, but not approved and active, can the system undergoing validation still go into production? A. Yes. However, users are responsible for ensuring that procedures for system operation and maintenance are approved prior to production use of the system. Any documents that need to be in place should be propelled through the review and approval process concurrent with the actual validation, so that they are in place before the system is used in the work environment. 28. Q. Should computer system validation be an information technology (IT) responsibility? A. End users, usually a validation team, have the primary responsibility for performing validation. IT staff are often part of the validation team and provides assistance during the process. 29. Q. When a company has limited resources, can it farm out the validation responsibility to temporary staff or consultants? A. Companies can certainly retain experts to assist in the validation process, but only actual users have the experience necessary to perform computer system validation. Only they know the culture of the company and the record keeping needs that the application will serve. 30. Q. Is there anything companies can do to make the validation process less laborious? A. The reason most validation projects take so long is a lack of project team understanding and experience. It is important to understand exactly what the requirements for the computer system are and to formulate a working plan that will drive the process forward. The use of document templates is highly advantageous. 31. Q. Can the validation use simulated data to test the system? A. Yes. However, the validation environment should use a copy of production data whenever possible. 32. Q. What is the difference between prospective validation and retrospective validation? A. Prospective validation occurs before production use. Companies sometimes think prospective validation needs to occur only before an FDA inspection, but this is erroneous. Retrospective validation occurs after a system is in use. Retrospective validation should apply only to systems that were in place before the legislation requiring validation, and, as such, should be phasing out.




127

33. Q. When a system is put into use, is validation complete? A. The validation project does not end until the system has been assessed after production use, typically after 30 days. For some systems with infrequent use, the assessment period may be longer, perhaps as long as 90 days. 34. Q. Is the only reason to perform validation because it is required by the regulations? A. Validation makes good business sense because it saves money by discovering system defects before production use. That alone should be reason enough to validate. 35. Q. IQ/OQ/PQ has been required in the predicate rules for a long time. Is it sufficient for validation? A. Computer system validation (CSV) is better suited for validation of complex computer systems because it addresses the process involved with the use of complex software. Installation operation and performance qualification (IQ/OQ/PQ) is intended for qualification of instruments and equipment. Today, most systems that have instruments also have interfaces to computers running complex software. In this case, IQ/OQ/PQ is performed for the instruments and CSV is performed for the entire system. 36. Q. Does the FDA validate its systems that receive electronic records from industry? A. Yes. The FDA validates agency systems that read and maintain regulatory submissions from industry. 37. Q. What is the objective of installation qualification? A. The objective is to document installation instructions and verify that the software is operational. 38. Q. In CSV where are the configuration options documented? A. Functional specifications should include the settings of all configuration options and user-defined parameters. 39. Q. When a computer system is accessed via the Internet, is validation of the Internet required? A. The Internet cannot be validated, but the secure access and encryption components must be validated. 40. Q. What types of software do not need computer system validation? A. Software to generate timesheets, word processing, page layout and drawing, e-mail systems, Internet browsers, multimedia and project scheduling programs do not require validation.



128


41. Q. If a new system is not 21 CFR Part 11 compliant is there any requirement to perform computer system validation? A. Yes, all systems should be validated regardless of their level of 21 CFR Part 11 compliance. Depending on risk, a remediation plan is required to address bringing the system into compliance. 42. Q. How long can a system function before it requires revalidation? A. There is no set time limit. Some systems can be in place and operative for years and not require revalidation, provided the company does not upgrade or change the system significantly. Minor changes can be managed with change control procedures that include validation of the changes based on risk and scope. What all systems do require is periodic audits to affirm that they are functioning as they should be. If an audit finds a deficiency, full or partial revalidation may be a recommended corrective action. 43. Q. How do the user requirements and functional specifications relate to each other? A. The user requirements describe what the users want the system to do on a high level. The functional specifications explain the details of how the system performs functions that implement the requirements. One user requirement may be related to many functional specifications. These are mapped out in a traceability matrix that is part of the functional specifications document. 44. Q. What is the role of quality assurance (QA) in a computer system validation project? A. QA performs an independent review of all validation documentation. QA staff are not directly part of the project team; rather they ensure that the project documentation reflects the requirements of the computer system validation process SOPs. 45. Q. How is risk assessed during a computer system validation project? A. One of the required validation documents is a hazard analysis. Each functional specification is assessed for potential failures and process risks. 46. Q. Does database and spreadsheet software need validation? A. Software used to develop applications does not need validation, but all applications that work with GxP data need to undergo computer system validation.

ELECTRONIC RECORDS 47. Q. Once an electronic record is printed, initialed and dated, can the electronic record be discarded? A. No. Electronic records must be maintained regardless of any printed records created from them. Copyright © 2004 CRC Press, LLC



129

48. Q. Does 21 CFR Part 11 permit companies, at their option, to submit to the FDA any required record in electronic format? A. No. The types of records that the FDA will accept in electronic format are defined in regulations separate from Part 11. 49. Q. Must a company provide the FDA with electronic copies of electronic records? A. The company must provide electronic copies of electronic records if the FDA demands them. However, if access to electronic records requires training, it may be too cumbersome for the company and the inspector to go through the training process, so controlled printed copies may suffice, provided they are printed from the electronic records on demand, and not previously printed. 50. Q. What responsibility does a company have for electronic records once they are submitted to the FDA? A. The responsibilities are the same as for paper submissions. Once records are submitted to the FDA, the corresponding source records require control to ensure their reliability. 51. Q. Can a company that uses electronic record keeping archive records in paper format? A. No. The guidance issued in August of 2003 eases the restriction a bit by making the distinction between Part 11 records and other records. The FDA recommendation is that “you determine, based on the predicate rules, whether specific records are Part 11 records. Records that are required to be retained under predicate rules are Part 11 records and must be archived. Part 11 requires that electronic records be archived in electronic form. The records must be protected to enable them to be retrieved during the length of the retention period specified in the regulation that mandates them. Further, paper copies lack metadata information such as time and date stamps, audit trails and other information that is required for electronic records. 52. Q. If a firm stops using an electronic system in favor of a different system, for instance if it is partnering with a company that uses that system, does it have to retain the hardware and software needed to read records archived in the first electronic system? A. Part 11 says electronic records must be retrievable throughout the record retention period established in the predicate rules. This doesn’t mean, however, that the hardware and software need to be retained. Companies can convert to another technology that can read the records. What is important is that transferred records are identical to the records in the original system, and that meta data and electronic signature-record links are retained. Only if the data cannot be transferred do the original hardware and software need to be retained. Copyright © 2004 CRC Press, LLC



130

53. Q. How should a firm handle legacy documents created prior to the implementation of electronic record keeping? Can it maintain them as paper copies, or must they be put into the electronic system as well? A. If the documents are still active, as in the case of SOPs and laboratory methods, these documents should be brought into the system. This can happen in two ways: they can undergo review (usually a two-year cycle) and be brought into the system as revisions to existing documents, or, if there are no changes, imported as legacy documents and subjected to quality control checks to ensure exact replication of the paper document. Documents bearing signatures can be scanned into electronic form and imported into the system, following a quality control (QC) check. 54. Q. If a company uses contract research organizations for GMP or GCP activities, where should the records reside? A. Contract research organizations (CROs) generally make replicate copies of documents that go to the company. The arrangements companies have with and the requirements for CRO activities are usually spelled out in an approved procedure. The bottom line is that companies must be able to track and produce their documents. The company has full liability and responsibility for all work performed by their subcontractors. 55. Q. What’s the best way to bring CRO documents into an electronic system within a company? A. Sometimes CROs transfer approved documents electronically. When this happens the records must be subject to QC checks to ensure accuracy. If there are handwritten signatures they must be scanned. If a document is in paper format, the entire document must be subject to scanning and QC check. As soon as the document enters the company’s electronic system, the audit trail begins. 56. Q. If a company converts product design documents in microfilm form to “pdf” electronic versions, does it need to retain the microfilm after the conversion is finished? A. The company doesn’t have to retain the microfilm when it completes the conversion unless the predicate rule requires that the originals be archived.

ELECTRONIC SIGNATURES

AND

ACCOUNTABILITY

57. Q. Is a scanned paper containing a handwritten signature an electronic signature? A. No. Scanning does not perform authentication of the handwritten signature. The scanned image is an electronic record that is subject to Part 11.




131

58. Q. Can the technology used to capture a handwritten signature on a credit card receipt at a retail store be used as an electronic signature? A. No. Digital ink does not provide a way to authenticate the signer. 59. Q. What data must be provided when an electronic signature is displayed? A. The signer’s printed name, date and time of signing, and meaning of the signature must be present. 60. Q. After a company notifies the FDA that it plans to use electronic signatures, does it have to wait until the FDA approves or acknowledges the notification before it can actually employ electronic signatures? A. No. It is sufficient to give notification “prior to or at the time of such use” or within 30 days after a system goes into production The certification, either by an individual or business establishment, verifies in writing that electronic signatures are the legally binding equivalent of handwritten signatures. If the certification is somehow deficient, the FDA will contact the submitter and instruct on how to correct the deficiency. Many companies use the language in the Part 11 preamble to attest to their intent to use electronic signatures. 61. Q. Does a company that uses electronic signatures have to inform the FDA of all users who have this capability? A. No. It is sufficient to inform the FDA that the company is using electronic signatures. It is unreasonable to expect notification every time the company has a new hire or transfers an employee who will access electronic records and sign them electronically. Regulated companies have to keep internal records of all people who use electronic signatures. 62. Q. Is an electronic signature made with a user name and password legally binding like a handwritten signature made with a pen? A. Yes. They are equally binding. 63. Q. When many electronic signatures are required in a contiguous session, can one user have permission to copy the other signatures and paste them to a record? A. No. Electronic signatures may not be copied by anyone. In the event a person who must sign a document is unavailable, that person can assign a designee. Most companies give more than one person authority to sign a record and maintain a log or reference document that indicates who can sign for which records and who are alternate signatories. 64. Q. If a user leaves a company, does the user’s signature information have to be retained within the system? A. Yes. The user’s signature is linked to the records he signed electronically. This does not mean, however, that an employee who leaves the company




132

remains a user of the system. Once a person leaves the company, his access to the system should be disabled. 65. Q. What forms of electronic signature are available? A. Most electronic signatures use a public user name and private password. The password may be replaced with a biometric such as a fingerprint or iris scan. A token or keycard may be used to supplement or replace the user name but cannot be used in place of the password. 66. Q. What is the primary difficulty with electronic signatures? A. Passwords are forgotten or stolen. In a single year, approximately 40 percent of help-desk calls were related to forgotten passwords. 67. Q. What are the advantages of biometric signatures? A. There are many. Biometric signatures are unique to every individual, they can’t be shared, and they don’t have to be changed periodically. Furthermore, users don’t need to remember them because they can’t forget them; they can’t lose them; and others can’t find them, steal them or guess them.

SECURITY 68. Q. What exactly does “computer security” mean? A. The regulations do not clearly explain computer security. However, industry standards have evolved to define computer security as having the following characteristics: • Authentication. The system must be able to tell if users are who they say they are. • Authorization. The system must be able to tell which users are allowed access to which features of the system. • Privacy. Security must prevent breaches of confidentiality. That is, unauthorized persons may not have access to information. • Integrity. The system must be able to tell if data have been altered, by whom, and when, and whether the accessor was authorized to change data. 69. Q. How are 21 CFR Part 11 and HIPAA security rules related? A. Industry standards for 21 CFR Part 11 compliance have been adopted into generally accepted computing security requirements. HIPAA has adopted these industry standards. As HIPAA compliance generates new standards, they will be adopted into generally accepted computing security requirements. As such, both regulations reinforce and evolve the other. 70. Q. How do most computer security violations occur? A. Most security violations are not the result of Internet hackers or crackers. Company insiders commit more violations. Copyright © 2004 CRC Press, LLC



133

71. Q. How are passwords stolen? A. The most common way passwords are stolen is by watching someone type in his password. Password theft can also occur because system users write them down and leave them accessible. Training is important, so that these eventualities do not become realities. 72. Q. Do passwords have to be a minimum length? A. Yes. The regulations do not identify password requirements. Industry standards have determined acceptable password characteristics. Generally, passwords should be at least eight characters and include characters to make them non-words. 73. Q. If a password is not reported stolen or lost, is it necessary to periodically change it? A. Yes. Passwords must be changed regularly to guard against password theft and keep the system secure. 74. Q. Suppose two people have the same name, like John Smith. Can they both use jsmith as their user name if their passwords are different? A. No. User names must be unique. Typically, the middle initial is used in a case such as this. 75. Q. Is it necessary for the user name to appear on the computer display at all times while the user is logged on to the software application? A. Yes. The user name should appear on the screen while the user is logged on. Security is not maintained by the user name, but by the passwords known only to users. 76. Q. When a user leaves the company, the user name should be inactivated. Can the user name ever be reused? A. No. The user name should not be reused. There would be no way to determine which user, the old or the new, is related to transaction history and audit trails. 77. Q. What happens when a user forgets to log off from a system? A. The computer system should automatically block system access after a period of inactivity. 78. Q. What happens if a user mistypes a password? A. Most systems allow for typing errors. However, if a user types a password incorrectly several times in a row, the system should block access to that user. 79. Q. When a user forgets her password, can a system administrator tell her what it is? Can an IT person retrieve it from the system? A. No. People do forget their passwords. However, no one should know another person’s password, even a system administrator (SA) or IT. These Copyright © 2004 CRC Press, LLC



134

people can, however, give the user a temporary password that allows the user to log on and change the password to a new one. 80. Q. Should users log off or lock their systems when they are away from their computer workstation? A. Yes. Logging off should be a requirement that is stated in the SOP on the system. Further, some systems automatically log users off after a certain period of time. 81. Q. When confidential data is copied to a laptop computer, how can security be ensured? A. Confidential data should be encrypted before being transferred to the mobile media (laptop computer, CD, diskette, etc.). A password known only to the intended user allows that user to reverse the encryption and access the data. In this manner, if the mobile media is lost or stolen, there is no way for other people to access the encrypted data. Therefore, the data remains confidential even if lost or stolen. 82. Q. What security procedures are required for compliance? A. There must be an approved procedure for system security as well as a facility security procedure. Both are required for 21 CFR Part 11 compliance. 83. Q. Since many computer software systems are easy to use, is training really necessary, particularly if a user is already familiar with a system, say from another work environment? A. Yes. Training is mandatory. All people who can generate an electronic record or make an electronic signature must be trained on a written policy that explains their responsibility in electronic record keeping. Even if people have used exactly the same software in a different work setting, they must demonstrate ability to use it in the new work environment. 84. Q. Which groups are primarily responsible for computer security? A. IT assists the users with security by providing tools and policies, but the users are ultimately responsible for security.

SYSTEMS 85. Q. Is an “open” system considered “closed” when all users have logged off from the system? A. No. The categorizations are based on control of system access. A closed system is one to which the people responsible for the data control all available methods of user access. In an open system the users still have limited and controlled access, but the people responsible for the data don’t have full control of the methods of user access. Taking a closed system and putting it on the Internet changes the classification to open. The people responsible for the data cannot control the Internet. This is why Part 11 Copyright © 2004 CRC Press, LLC



135

says that there are additional controls for open systems. Open systems require encryption that closed systems aren’t required to have. 86. Q. If a company uses a contracted T1 line to a remote facility, is it still considered a “closed” system? A. The system is closed if the company is responsible for the content of the records and controls access to the system that contains the records. The remote facility is the repository for the records. However, if the records are stored on a contracted server, then the system is open, because access to those servers is not controlled by the users. 87. Q. What are “controls” to determine an open or closed system? Do controls mean procedures? A. Controls are any measures a company takes to ensure the trustworthiness and reliability of records and signatures. Some measures may be physical, such as hardware, backup and access to sites. Others may be procedural, such as SOPS that spell out how users use the system. 88. Q. How should a company handle dates and times? A. Dates and times must be managed to allow chronological recording of events without ambiguity. The preamble to 21 CFR Part 11 indicates dates and times should be local to the signer. 89. Q. What format should be used for dates? A. In the U.S., numbers for the day and month can be easily confused, especially when dates are used internationally. The date format such as ddMMM-yyyy, where the month is abbreviated with letters, should be used. 90. Q. Do companies need to have time stamps certified by an outside party? A. No, but a company can decide to engage the services of an outside party to affirm accuracy of time stamps. However, the company needs to have an SOP that addresses time stamps to ensure that electronic records reflect the true time relative to the locale of the company. 91. Q. If all data from a computer system is transferred to a new system, do the old system data or hardware need to be archived? A. The data do not need to be archived as long as the transfer of data to the new system is validated. However, if the audit trail is not transferred, it must be retained so that re-creation of electronic records at any point in time is possible. This may mean that both the data and audit trail need to be archived, and this may even require hardware to be archived. 92. Q. If a server has dual redundant power supplies and one fails, do the users have to approve a change control document before IT makes the repair? A. No, IT can make the repair in real time and fill out an event log. IT should informally notify the system administrator that a failure occurred. Copyright © 2004 CRC Press, LLC


136


93. Q. Companies have long since maintained inventory of equipment. Is it necessary to do the same with software? A. A software inventory should include all software applications used for regulated applications. 94. Q. The FDA focuses on compliance for “high-risk systems.” What is considered a high-risk system? A. How systems are determined to be high risk has not been clearly defined. Companies must, therefore, determine whether their systems are high risk. This they do by inventorying software, assessing the criticality of the data the systems handle, performing gap analysis and implementing remediation plans. Risk is based on the outcome of a failure on product and patient safety as well as accuracy of electronic data.

AUDIT TRAILS 95. Q. Why is an audit trail important? A. Audit trails are required to record the creation, modification and deletion of electronic records. Audit trails provide a history of a record, from conception through archiving. It allows the electronic record to be recreated for any point in time. 96. Q. What data must an audit trail capture whenever a record is modified? A. Audit trails must record the user name, date, time and previous data. 97. Q. Does an audit trail always have to be electronic? A. The audit trail has to be electronic when the related record is electronic. 21 CFR Part 11 11.10(e) calls for a computer-generated audit trail. 98. Q. Are there any instances where it may be acceptable to have a paper audit trail for an electronic record? A. No. Audit trails must be automatically generated by the computer, so there is no chance of fraud. 99. Q. If an electronic record is annotated electronically, much like a sticky note on a paper record, is the annotation part of the record and subsequently subject to an audit trail? A. Electronic annotations are part of the electronic record, and, like the record to which they are affixed, they need to be trustworthy and reliable. Often annotations carry significant information such as reviewer agreement or instructions about the record. 100. Q. Can an electronic record be created without an audit trail, and the audit trail begin at the time of electronic signature? A. The regulations require that an audit trail begin when a record is initially created. Copyright © 2004 CRC Press, LLC



137

101. Q. Does the audit trail need to record all data entered by a user? A. No. Only data that are saved to the computer system need to be recorded in the audit trail. If data are entered, changed or deleted prior to saving, they should not be recorded in the audit trail.

STAYING INFORMED 102. Q. How can companies keep abreast of changes in the regulations and their interpretation? A. Changes in regulations are far less common than changes in industry standards, and the regulations are always available in the Code of Federal Regulations. However, FDA rulings between an existing CFR and the next annual copy indicate how the FDA is interpreting industry practices. Companies must be vigilant in watching trends in regulations and interpretations. Good sources are newsletters such as The Drug GMP Report and The Pink Sheet. The FDA Web site also publishes warning letters that can serve as a source for gauging the perspectives of the agency. The following are also resources companies can tap into: www.fdcreports.com (the pink and gold sheets that have the FDA 483 and warning letters) www.hipaadvisory.com (HIPAA resource) [email protected] (Institute of Validation Technology, journal, conferences) www.pharmconferences.com (Advanstar) www.PDA.org (Parenteral drug association, conferences, publications) www.sqa.org (Society of QA) www.iqa.org (Institute of QA) www.qaiusa.com (QA Institute) www.diahome.org (Drug Information Association) www.acrpnet.org (Association of Clinical Research Professionals) www.CptPharma.org (Center for Pharmaceutical Training) www.cpie.com (Center for Innovation and Education) www.cfpa.com (Center for Professional Advancement) [email protected] www.computersystem.com [email protected] www.writeitdown.biz [email protected]


PH2164_Appendix I.fm Page 139 Monday, November 24, 2003 12:43 PM

Appendix I FEDERAL REGISTER Thursday, March 20, 1997

PART II DEPARTMENT OF HEALTH AND HUMAN SERVICES FOOD

AND

DRUG ADMINISTRATION

21 CFR PART 11 ELECTRONIC RECORDS; ELECTRONIC SIGNATURES; FINAL RULE ELECTRONIC SUBMISSIONS; ESTABLISHMENT NOTICE

OF

PUBLIC DOCKET;

DEPARTMENT OF HEALTH AND HUMAN SERVICES FOOD

AND

DRUG ADMINISTRATION

21 CFR Part 11 [Docket No. 92N–0251] RIN 0910–AA29

ELECTRONIC RECORDS; ELECTRONIC SIGNATURES AGENCY: Food and Drug Administration, HHS. ACTION: Final rule. SUMMARY: The Food and Drug Administration (FDA) is issuing regulations that provide criteria for acceptance by FDA, under certain circumstances, of electronic records, electronic signatures, and handwritten signatures executed to electronic records as equivalent to paper records and handwritten signatures executed on paper. These regulations, which apply to all FDA program areas, are intended to permit the widest possible use of electronic technology, compatible with FDA’s responsibility to promote and protect public health. The use of electronic records as well as



140


their submission to FDA is voluntary. Elsewhere in this issue of the Federal Register, FDA is publishing a document providing information concerning submissions that the agency is prepared to accept electronically. DATES: Effective August 20, 1997. Submit written comments on the information collection provisions of this Þnal rule by May 19, 1997. ADDRESSES: Submit written comments on the information collection provisions of this Þnal rule to the Dockets Management Branch (HFA–305), Food and Drug Administration, 12420 Parklawn Dr., rm. 1–23, Rockville, MD 20857. The Þnal rule is also available electronically via Internet: http:// www.fda.gov. FOR FURTHER INFORMATION CONTACT: Paul J. Motise, Center for Drug Evaluation and Research (HFD– 325), Food and Drug Administration, 7520 Standish Pl., Rockville, MD 20855, 301–594–1089. E-mail address via Internet: [email protected], or Tom M. Chin, Division of Compliance Policy (HFC–230), Food and Drug Administration, 5600 Fishers Lane, Rockville, MD 20857, 301–827– 0410. E-mail address via Internet: [email protected] SUPPLEMENTARY INFORMATION:

I. BACKGROUND In 1991, members of the pharmaceutical industry met with the agency to determine how they could accommodate paperless record systems under the current good manufacturing practice (CGMP) regulations in parts 210 and 211 (21 CFR parts 210 and 211). FDA created a Task Force on Electronic IdentiÞcation/Signatures to develop a uniform approach by which the agency could accept electronic signatures and records in all program areas. In a February 24, 1992, report, a task force subgroup, the Electronic IdentiÞcation/Signature Working Group, recommended publication of an advance notice of proposed rulemaking (ANPRM) to obtain public comment on the issues involved. In the Federal Register of July 21, 1992 (57 FR 32185), FDA published the ANPRM, which stated that the agency was considering the use of electronic identiÞcation/signatures, and requested comments on a number of related topics and concerns. FDA received 53 comments on the ANPRM. In the Federal Register of August 31, 1994 (59 FR 45160), the agency published a proposed rule that incorporated many of the comments to the ANPRM, and requested that comments on the proposed regulation be submitted by November 29, 1994. A complete discussion of the options considered by FDA and other background information on the agency’s policy on electronic records and electronic signatures can be found in the ANPRM and the proposed rule. FDA received 49 comments on the proposed rule. The commenters represented a broad spectrum of interested parties: Human and veterinary pharmaceutical Copyright © 2004 CRC Press, LLC


Appendix I

141

companies as well as biological products, medical device, and food interest groups, including 11 trade associations, 25 manufacturers, and 1 Federal agency.

II. HIGHLIGHTS OF THE FINAL RULE The Þnal rule provides criteria under which FDA will consider electronic records to be equivalent to paper records, and electronic signatures equivalent to traditional handwritten signatures. Part 11 (21 CFR part 11) applies to any paper records required by statute or agency regulations and supersedes any existing paper record requirements by providing that electronic records may be used in lieu of paper records. Electronic signatures which meet the requirements of the rule will be considered to be equivalent to full handwritten signatures, initials, and other general signings required by agency regulations. Section 11.2 provides that records may be maintained in electronic form and electronic signatures may be used in lieu of traditional signatures. Records and signatures submitted to the agency may be presented in an electronic form provided the requirements of part 11 are met and the records have been identiÞed in a public docket as the type of submission the agency accepts in an electronic form. Unless records are identiÞed in this docket as appropriate for electronic submission, only paper records will be regarded as ofÞcial submissions. Section 11.3 deÞnes terms used in part 11, including the terms: Biometrics, closed system, open system, digital signature, electronic record, electronic signature, and handwritten signature. Section 11.10 describes controls for closed systems, systems to which access is controlled by persons responsible for the content of electronic records on that system. These controls include measures designed to ensure the integrity of system operations and information stored in the system. Such measures include: (1) Validation; (2) the ability to generate accurate and complete copies of records; (3) archival protection of records; (4) use of computer-generated, time-stamped audit trails; (5) use of appropriate controls over systems documentation; and (6) a determination that persons who develop, maintain, or use electronic records and signature systems have the education, training, and experience to perform their assigned tasks. Section 11.10 also addresses the security of closed systems and requires that: (1) System access be limited to authorized individuals; (2) operational system checks be used to enforce permitted sequencing of steps and events as appropriate; (3) authority checks be used to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform operations; (4) device (e.g., terminal) checks be used to determine the validity of the source of data input or operation instruction; and (5) written policies be established and adhered to holding individuals accountable and responsible for actions initiated under their electronic signatures, so as to deter record and signature falsiÞcation. Section 11.30 sets forth controls for open systems, including the controls required for closed systems in § 11.10 and additional measures such as document encryption and use of appropriate digital signature standards to ensure record authenticity, integrity, and conÞdentiality. Copyright © 2004 CRC Press, LLC


142


Section 11.50 requires signature manifestations to contain information associated with the signing of electronic records. This information must include the printed name of the signer, the date and time when the signature was executed, and the meaning (such as review, approval, responsibility, and authorship) associated with the signature. In addition, this information is subject to the same controls as for electronic records and must be included in any human readable forms of the electronic record (such as electronic display or printout). Under § 11.70, electronic signatures and handwritten signatures executed to electronic records must be linked to their respective records so that signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means. Under the general requirements for electronic signatures, at § 11.100, each electronic signature must be unique to one individual and must not be reused by, or reassigned to, anyone else. Before an organization establishes, assigns, certiÞes, or otherwise sanctions an individual’s electronic signature, the organization shall verify the identity of the individual. Section 11.200 provides that electronic signatures not based on biometrics must employ at least two distinct identiÞcation components such as an identiÞcation code and password. In addition, when an individual executes a series of signings during a single period of controlled system access, the Þrst signing must be executed using all electronic signature components and the subsequent signings must be executed using at least one component designed to be used only by that individual. When an individual executes one or more signings not performed during a single period of controlled system access, each signing must be executed using all of the electronic signature components. Electronic signatures not based on biometrics are also required to be used only by their genuine owners and administered and executed to ensure that attempted use of an individual’s electronic signature by anyone else requires the collaboration of two or more individuals. This would make it more difÞcult for anyone to forge an electronic signature. Electronic signatures based upon biometrics must be designed to ensure that such signatures cannot be used by anyone other than the genuine owners. Under § 11.300, electronic signatures based upon use of identiÞcation codes in combination with passwords must employ controls to ensure security and integrity. The controls must include the following provisions: (1) The uniqueness of each combined identiÞcation code and password must be maintained in such a way that no two individuals have the same combination of identiÞcation code and password; (2) persons using identiÞcation codes and/or passwords must ensure that they are periodically recalled or revised; (3) loss management procedures must be followed to deauthorize lost, stolen, missing, or otherwise potentially compromised tokens, cards, and other devices that bear or generate identiÞcation codes or password information; (4) transaction safeguards must be used to prevent unauthorized use of passwords and/or identiÞcation codes, and to detect and report any attempt to misuse such codes; (5) devices that bear or generate identiÞcation codes or password information, such as tokens or cards, must be tested initially and periodically to ensure that they function properly and have not been altered in an unauthorized manner. Copyright © 2004 CRC Press, LLC


Appendix I

143

III. COMMENTS ON THE PROPOSED RULE A. GENERAL COMMENTS 1. Many comments expressed general support for the proposed rule. Noting that the proposal’s regulatory approach incorporated several suggestions submitted by industry in comments on the ANPRM, a number of comments stated that the proposal is a good example of agency and industry cooperation in resolving technical issues. Several comments also noted that both industry and the agency can realize signiÞcant beneÞts by using electronic records and electronic signatures, such as increasing the speed of information exchange, cost savings from the reduced need for storage space, reduced errors, data integration/trending, product improvement, manufacturing process streamlining, improved process control, reduced vulnerability of electronic signatures to fraud and abuse, and job creation in industries involved in electronic record and electronic signature technologies. One comment noted that, when part 11 controls are satisÞed, electronic signatures and electronic records have advantages over paper systems, advantages that include: (1) Having automated databases that enable more advanced searches of information, thus obviating the need for manual searches of paper records; (2) permitting information to be viewed from multiple perspectives; (3) permitting determination of trends, patterns, and behaviors; and (4) avoiding initial and subsequent document misÞling that may result from human error. There were several comments on the general scope and effect of proposed part 11. These comments noted that the Þnal regulations will be viewed as a standard by other Government agencies, and may strongly inßuence the direction of electronic record and electronic signature technologies. One comment said that FDA’s position on electronic signatures/electronic records is one of the most pressing issues for the pharmaceutical industry and has a signiÞcant impact on the industry’s future competitiveness. Another comment said that the rule constitutes an important milestone along the Nation’s information superhighway. FDA believes that the extensive industry input and collaboration that went into formulating the Þnal rule is representative of a productive partnership that will facilitate the use of advanced technologies. The agency acknowledges the potential beneÞts to be gained by electronic record/electronic signature systems. The agency expects that the magnitude of these beneÞts should signiÞcantly outweigh the costs of making these systems, through compliance with part 11, reliable, trustworthy, and compatible with FDA’s responsibility to promote and protect public health. The agency is aware of the potential impact of the rule, especially regarding the need to accommodate and encourage new technologies while maintaining the agency’s ability to carry out its mandate to protect public health. The agency is also aware that other Federal agencies share the same concerns and are addressing the same issues as FDA; the agency has held informal discussions with other Federal agencies and participated in several interagency groups on electronic records/electronic signatures and information technology issues. FDA looks forward to exchanging information and experience with other agencies for mutual beneÞt and to promote a consistent Federal policy on electronic records and signatures. The agency also notes that Copyright © 2004 CRC Press, LLC


144


beneÞts, such as the ones listed by the comments, will help to offset any system modiÞcation costs that persons may incur to achieve compliance with part 11.

B. REGULATIONS VERSUS GUIDELINES 2. Several comments addressed whether the agency’s policy on electronic signatures and electronic records should be issued as a regulation or recommended in a guideline. Most comments supported a regulation, citing the need for a practical and workable approach for criteria to ensure that records can be stored in electronic form and are reliable, trustworthy, secure, accurate, conÞdential, and authentic. One comment speciÞcally supported a single regulation covering all FDA-regulated products to ensure consistent requirements across all product lines. Two comments asserted that the agency should only issue guidelines or ‘‘make the regulations voluntary.’’ One of these comments said that by issuing regulations, the agency is shifting from creating tools to enhance communication (technological quality) to creating tools for enforcement (compliance quality). The agency remains convinced, as expressed in the preamble to the proposed rule (59 FR 45160 at 45165), that a policy statement, inspection guide, or other guidance would be an inappropriate means for enunciating a comprehensive policy on electronic signatures and records. FDA has concluded that regulations are necessary to establish uniform, enforceable, baseline standards for accepting electronic signatures and records. The agency believes, however, that supplemental guidance documents would be useful to address controls in greater detail than would be appropriate for regulations. Accordingly, the agency anticipates issuing supplemental guidance as needed and will afford all interested parties the opportunity to comment on the guidance documents. The need for regulations is underscored by several opinions expressed in the comments. For example, one comment asserted that it should be acceptable for supervisors to remove the signatures of their subordinates from signed records and replace them with their own signatures. Although the agency does not object to the use of a supervisor’s signature to endorse or conÞrm a subordinate’s actions, removal of an original signature is an action the agency views as falsiÞcation. Several comments also argued that an electronic signature should consist of only a password, that passwords need not be unique, that it is acceptable for people to use passwords associated with their personal lives (like the names of their children or their pets), and that passwords need only be changed every 2 years. FDA believes that such procedures would greatly increase the possibility that a password could be compromised and the chance that any resulting impersonation and/or falsiÞcation would continue for a long time. Therefore, an enforceable regulation describing the acceptable characteristics of an electronic signature appears necessary.

C. FLEXIBILITY

AND

SPECIFICITY

3. Several comments addressed the ßexibility and speciÞcity of the proposed rule. The comments contended that agency acceptance of electronic records systems should not be based on any particular technology, but rather on the adequacy of Copyright © 2004 CRC Press, LLC


Appendix I

145

the system controls under which they are created and managed. Some comments claimed that the proposed rule was overly prescriptive and that it should not specify the mechanisms to be used, but rather only require owners/users to design appropriate safeguards and validate them to reasonably ensure electronic signature integrity and authenticity. One comment commended the agency for giving industry the freedom to choose from a variety of electronic signature technologies, while another urged that the Þnal rule be more speciÞc in detailing software requirements for electronic records and electronic notebooks in research and testing laboratories. The agency believes that the provisions of the Þnal rule afford Þrms considerable ßexibility while providing a baseline level of conÞdence that records maintained in accordance with the rule will be of high integrity. For example, the regulation permits a wide variety of existing and emerging electronic signature technologies, from use of identiÞcation codes in conjunction with manually entered passwords to more sophisticated biometric systems that may necessitate additional hardware and software. While requiring electronic signatures to be linked to their respective electronic records, the Þnal rule affords ßexibility in achieving that link through use of any appropriate means, including use of digital signatures and secure relational database references. The Þnal rule accepts a wide variety of electronic record technologies, including those based on optical storage devices. In addition, as discussed in comment 40 of this document, the Þnal rule does not establish numerical standards for levels of security or validation, thus offering Þrms ßexibility in determining what levels are appropriate for their situations. Furthermore, while requiring operational checks, authority checks, and periodic testing of identifying devices, persons have the ßexibility of conducting those controls by any suitable method. When the Þnal rule calls for a certain control, such as periodic testing of identiÞcation tokens, persons have the option of determining the frequency.

D. CONTROLS FOR ELECTRONIC SYSTEMS COMPARED PAPER SYSTEMS

WITH

4. Two comments stated that any controls that do not apply to paper-based document systems and handwritten signatures should not apply to electronic record and signature systems unless those controls are needed to address an identiÞed unique risk associated with electronic record systems. One comment expressed concern that FDA was establishing a much higher standard for electronic signatures than necessary. In attempting to establish minimum criteria to make electronic signatures and electronic records trustworthy and reliable and compatible with FDA’s responsibility to promote and protect public health (e.g., by hastening the availability of new safe and effective medical products and ensuring the safety of foods), the agency has attempted to draw analogies to handwritten signatures and paper records wherever possible. In doing so, FDA has found that the analogy does not always hold because of the differences between paper and electronic systems. The agency believes some of those differences necessitate controls that will be unique to electronic technology and that must be addressed on their own merits and not evaluated on the basis of their equivalence to controls governing paper documents. Copyright © 2004 CRC Press, LLC


146


The agency found that some of the comments served to illustrate the differences between paper and electronic record technologies and the need to address controls that may not generally be found in paper record systems. For example, several comments pointed out that electronic records built upon information databases, unlike paper records, are actually transient views or representations of information that is dispersed in various parts of the database. (The agency notes that the databases themselves may be geographically dispersed but linked by networks.) The same software that generates representations of database information on a screen can also misrepresent that information, depending upon how the software is written (e.g., how a query is prepared). In addition, database elements can easily be changed at any time to misrepresent information, without evidence that a change was made, and in a manner that destroys the original information. Finally, more people have potential access to electronic record systems than may have access to paper records. Therefore, controls are needed to ensure that representations of database information have been generated in a manner that does not distort data or hide noncompliant or otherwise bad information, and that database elements themselves have not been altered so as to distort truth or falsify a record. Such controls include: (1) Using time-stamped audit trails of information written to the database, where such audit trails are executed objectively and automatically rather than by the person entering the information, and (2) limiting access to the database search software. Absent effective controls, it is very easy to falsify electronic records to render them indistinguishable from original, true records. The traditional paper record, in comparison, is generally a durable unitized representation that is Þxed in time and space. Information is recorded directly in a manner that does not require an intermediate means of interpretation. When an incorrect entry is made, the customary method of correcting FDA-related records is to cross out the original entry in a manner that does not obscure the prior data. Although paper records may be falsiÞed, it is relatively difÞcult (in comparison to falsiÞcation of electronic records) to do so in a nondetectable manner. In the case of paper records that have been falsiÞed, a body of evidence exists that can help prove that the records had been changed; comparable methods to detect falsiÞcation of electronic records have yet to be fully developed. In addition, there are signiÞcant technological differences between traditional handwritten signatures (recorded on paper) and electronic signatures that also require controls unique to electronic technologies. For example, the traditional handwritten signature cannot be readily compromised by being ‘‘loaned’’ or ‘‘lost,’’ whereas an electronic signature based on a password in combination with an identiÞcation code can be compromised by being ‘‘loaned’’ or ‘‘lost.’’ By contrast, if one person attempts to write the handwritten signature of another person, the falsiÞcation would be difÞcult to execute and a long-standing body of investigational techniques would be available to detect the falsiÞcation. On the other hand, many electronic signatures are relatively easy to falsify and methods of falsiÞcation almost impossible to detect. Accordingly, although the agency has attempted to keep controls for electronic record and electronic signatures analogous to traditional paper systems, it Þnds it necessary to establish certain controls speciÞcally for electronic systems.



Appendix I

E. FDA CERTIFICATION

147 OF

ELECTRONIC SIGNATURE SYSTEMS

5. One comment requested FDA certiÞcation of what it described as a low-cost, biometric-based electronic signature system, one which uses dynamic signature veriÞcation with a parameter code recorded on magnetic stripe cards. The agency does not anticipate the need to certify individual electronic signature products. Use of any electronic signature system that complies with the provisions of part 11 would form the basis for agency acceptance of the system regardless of what particular technology or brand is used. This approach is consistent with FDA’s policy in a variety of program areas. The agency, for example, does not certify manufacturing equipment used to make drugs, medical devices, or food.

F. BIOMETRIC ELECTRONIC SIGNATURES 6. One comment addressed the agency’s statement in the proposed rule (59 FR 45160 at 45168) that the owner of a biometric/behavioral link could not lose or give it away. The comment stated that it was possible for an owner to ‘‘lend’’ the link for a Þle to be opened, as a collaborative fraudulent gesture, or to unwittingly assist a fraudulent colleague in an ‘‘emergency,’’ a situation, the comment said, that was not unknown in the computer industry. The agency acknowledges that such fraudulent activity is possible and that people determined to falsify records may Þnd a means to do so despite whatever technology or preventive measures are in place. The controls in part 11 are intended to deter such actions, make it difÞcult to execute falsiÞcation by mishap or casual misdeed, and to help detect such alterations when they occur (see § 11.10 (introductory paragraph and especially §§ 11.10(j) and 11.200(b)).

G. PERSONNEL INTEGRITY 7. A few comments addressed the role of individual honesty and trust in ensuring that electronic records are reliable, trustworthy, and authentic. One comment noted that Þrms must rely in large measure upon the integrity of their employees. Another said that subpart C of part 11, Electronic Signatures, appears to have been written with the belief that pharmaceutical manufacturers have an incentive to falsify electronic signatures. One comment expressed concern about possible signature falsiÞcation when an employee leaves a company to work elsewhere and the employee uses the electronic signature illegally. The agency agrees that the integrity of any electronic signature/electronic record system depends heavily upon the honesty of employees and that most persons are not motivated to falsify records. However, the agency’s experience with various types of records and signature falsiÞcation demonstrates that some people do falsify information under certain circumstances. Among those circumstances are situations in which falsiÞcations can be executed with ease and have little likelihood of detection. Part 11 is intended to minimize the opportunities for readily executing falsiÞcations and to maximize the chances of detecting falsiÞcations.



148


Concerning signature falsiÞcation by former employees, the agency would expect that upon the departure of an employee, the assigned electronic signature would be ‘‘retired’’ to prevent the former employee from falsely using the signature.

H. SECURITY OF INDUSTRY ELECTRONIC RECORDS SUBMITTED FDA

TO

8. Several comments expressed concern about the security and conÞdentiality of electronic records submitted to FDA. One suggested that submissions be limited to such read-only formats as CD–ROM with raw data for statistical manipulation provided separately on ßoppy diskette. One comment suggested that in light of the proposed rule, the agency should review its own internal security procedures. Another addressed electronic records that may be disclosed under the Freedom of Information Act and expressed concern regarding agency deletion of trade secrets. One comment anticipated FDA’s use of open systems to access industry records (such as medical device production and control records) and suggested that such access should be restricted to closed systems. The agency is well aware of its legal obligation to maintain the conÞdentiality of trade secret information in its possession, and is committed to meet that obligation regardless of the form (paper or electronic) a record takes. The procedures used to ensure conÞdentiality are consistent with the provisions of part 11. FDA is also examining other controls, such as use of digital signatures, to ensure submission integrity. To permit legitimate changes to be made, the agency does not believe that it is necessary to restrict submissions to those maintained in read-only formats in all cases; each agency receiving unit retains the ßexibility to determine whatever format is most suitable. Those intending to submit material are expected to consult with the appropriate agency receiving unit to determine the acceptable formats. Although FDA access to electronic records on open systems maintained by Þrms is not anticipated in the near future, the agency believes it would be inappropriate to rule out such a procedure. Such access can be a valuable inspection tool and can enhance efÞciencies by reducing the time investigators may need to be on site. The agency believes it is important to develop appropriate procedures and security measures in cooperation with industry to ensure that such access does not jeopardize data conÞdentiality or integrity.

I. EFFECTIVE DATE/GRANDFATHERING 9. Several comments addressed the proposed effective date of the Þnal rule, 90 days after publication in the Federal Register, and suggested potential exemptions (grandfathering) for systems now in use. Two comments requested an expedited effective date for the Þnal rule. One comment requested an effective date at least 18 months after publication of the Þnal rule to permit Þrms to modify and validate their systems. One comment expressed concern about how the rule, in general, will affect current systems, and suggested that the agency permit Þrms to continue to use existing electronic record systems that otherwise conform to good manufacturing or laboratory practices until these Þrms make major modiÞcations to those systems or until



Appendix I

149

5 years have elapsed, whichever comes Þrst. Several other comments requested grandfathering for speciÞc sections of the proposed rule. The agency has carefully considered the comments and suggestions regarding the Þnal rule’s effective date and has concluded that the effective date should be 5 months after date of publication in the Federal Register. The agency wishes to accommodate Þrms that are prepared now to comply with part 11 or will be prepared soon, so as to encourage and foster new technologies in a manner that ensures that electronic record and electronic signature systems are reliable, trustworthy, and compatible with FDA’s responsibility to promote and protect public health. The agency believes that Þrms that have consulted with FDA before adopting new electronic record and electronic signature technologies (especially technologies that may impact on the ability of the agency to conduct its work effectively) will need to make few, if any, changes to systems used to maintain records required by FDA. The agency believes that the provisions of part 11 represent minimal standards and that a general exemption for existing systems that do not meet these provisions would be inappropriate and not in the public interest because such systems are likely to generate electronic records and electronic signatures that are unreliable, untrustworthy, and not compatible with FDA’s responsibility to promote and protect public health. Such an exemption might, for example, mean that a Þrm could: (1) Deny FDA inspectional access to electronic record systems, (2) permit unauthorized access to those systems, (3) permit individuals to share identiÞcation codes and passwords, (4) permit systems to go unvalidated, and (5) permit records to be falsiÞed in many ways and in a manner that goes undetected. The agency emphasizes that these regulations do not require, but rather permit, the use of electronic records and signatures. Firms not conÞdent that their electronic systems meet the minimal requirements of these regulations are free to continue to use traditional signatures and paper documents to meet recordkeeping requirements.

J. COMMENTS BY ELECTRONIC MAIL (E-MAIL) AND ELECTRONIC DISTRIBUTION OF FDA DOCUMENTS 10. One comment speciÞcally noted that the agency has accepted comments by email and that this provides an additional avenue for public participation in the rulemaking process. Another comment encouraged FDA to expand the use of electronic media to provide information by such open systems as bulletin boards. The agency intends to explore further the possibility of continuing to accept public comments by e-mail and other electronic means. For this current experiment, the agency received only one comment by e-mail. The comment that addressed this issue was, itself, transmitted in a letter. The agency recognizes the beneÞts of distributing information electronically, has expanded that activity, and intends to continue that expansion. Although only one e-mail comment was received, the agency does not attribute that low number to a lack of ability to send e-mail because the agency received e-mail from 198 persons who requested the text of the proposed rule, including requests from people outside the United States.



150

K. SUBMISSIONS

Achieving and Maintaining Compliance BY

FACSIMILE (FAX)

11. One comment said that part 11 should include a provision for FDA acceptance of submissions by fax, such as import form FDA 2877. The comment noted that the U.S. Customs Service accepts fax signatures on its documents, and claimed that FDA’s insistence on hard copies of form FDA 2877 is an impediment to imports. The agency advises that part 11 permits the unit that handles import form FDA 2877 to accept that record in electronic form when it is prepared logistically to do so. As noted in the discussion on § 11.1(b) in comment 21 of this document, the agency recognizes that faxes can be in paper or electronic form, based on the capabilities of the sender and recipient.

L. BLOOD BANK ISSUES 12. Two comments addressed blood bank issues in the context of electronic records and electronic signatures and said the agency should clarify that part 11 would permit electronic crossmatching by a central blood center for individual hospitals. One comment stated that remote blood center and transfusion facilities should be permitted to rely on electronically communicated information, such as authorization for labeling/issuing units of blood, and that the electronic signature of the supervisor in the central testing facility releasing the product for labeling and issuance should be sufÞcient because the proposed rule guards against security and integrity problems. One comment questioned whether, under part 11, electronic signatures would meet the signature requirements for the release of units of blood, and if there would be instances where a full signature would be required instead of a technician’s identiÞcation. Another comment asserted that it is important to clarify how the term ‘‘batch’’ will be interpreted under part 11, and suggested that the term used in relation to blood products refers to a series of units of blood having undergone common manufacturing processes and recorded on the same computerized document. The comment contrasted this to FDA’s current view that each unit of blood be considered a batch. The agency advises that part 11 permits release records now in paper form to be in electronic form and traditional handwritten signatures to be electronic signatures. Under part 11, the name of the technician must appear in the record display or printout to clearly identify the technician. The appearance of the technician’s identiÞcation code alone would not be sufÞcient. The agency also advises that the deÞnition of a ‘‘batch’’ for blood or other products is not affected by part 11, which addresses the trustworthiness and reliability of electronic records and electronic signatures, regardless of how a batch, which is the subject of those records and signatures, is deÞned.

M. REGULATORY FLEXIBILITY ANALYSIS 13. One comment said that, because part 11 will signiÞcantly impact a substantial number of small businesses, even though the impact would be beneÞcial, FDA is required to perform a regulatory ßexibility analysis and should publish such an analysis in the Federal Register before a Þnal rule is issued.



Appendix I

151

The comment states that the legislative history of the Regulatory Flexibility Act is clear that, ‘‘signiÞcant economic impact,’’ as it appears at 5 U.S.C. 605(b) is neutral with respect towhether such impact is beneÞcial or adverse. Contrary to the comment’s assertion, the legislative history is not dispositive of this matter. It is well established that the task of statutory construction must begin with the actual language of the statute. (See Bailey v. United States, 116 S. Ct. 595, 597 (1996).) A statutory termmust not be construed in isolation; a provision that may seem ambiguous in isolation is often clariÞed by the remainder of the statute. (See Dept. Of Revenue of Oregon v. ACF Industries, 114 S. Ct. 843, 850 (1994).) Moreover, it is a fundamental canon of statutory construction that identical terms within the same statute must bear the same meaning. (See Reno v. Koray, 115 S. Ct. 2021, 2026 (1995).) In addition to appearing in 5 U.S.C. 605(b), the term ‘‘signiÞcant economic impact’’ appears elsewhere in the statute. The legislation is premised upon the congressional Þnding that alternative regulatory approaches may be available which ‘‘minimize the signiÞcant economic impact’’ of rules (5 U.S.C. 601 note). In addition, an initialregulatory ßexibility analysis must describe signiÞcant regulatory alternatives that ‘‘minimize any signiÞcant economic impact’’ (5 U.S.C. 603(c)). Similarly, a Þnal regulatory ßexibility analysis must include a description of the steps the agency has taken to ‘‘minimize any signiÞcant economic impact’’ (5 U.S.C. 604(a)(5)). The term appeared as one of the elements of a Þnal regulatory ßexibility analysis, as originally enacted in 1980. (See Pub. L. No. 96–354, 3(a), 94 Stat. 1164, 1167 (1980) (formerly codiÞed at 5 U.S.C. 604(a)(3)).) In addition, when Congress amended the elements of a Þnal regulatory ßexibility analysis in 1996, it re-enacted the term, as set forth above. (See Pub. L. 104–121, 241(b), 110 Stat. 857, 865 (1996) (codiÞed at 5 U.S.C.604(a)(5)).) Unless the purpose of the statute was intended to increase the economic burden of regulations by minimizing positive or beneÞcial effects, ‘‘signiÞcant economic impact’’ cannot include such effects. Because it is beyond dispute that the purpose of the statute is not increasing economic burdens, the plain meaning of ‘‘signiÞcant economic impact’’ is clear and necessarily excludes beneÞcial or positive effects of regulations. Even where there are some limited contrary indications in the statute’s legislative history, it is inappropriate to resort to legislative history to cloud a statutory text that is clear on its face. (See Ratzlaff v. United States, 114 S. Ct. 655, 662 (1994).) Therefore, the agency concludes that a Þnal regulatory ßexibility analysis is not required for this regulation or any regulation for which there is no signiÞcant adverse economic impact on small entities. Notwithstanding these conclusions, FDA has nonetheless considered the impact of the rule on small entities. (See section XVI. of this document.)

N. TERMINOLOGY 14. One comment addressed the agency’s use of the word ‘‘ensure’’ throughout the rule and argued that the agency should use the word ‘‘assure’’ rather than ‘‘ensure’’ because ‘‘ensure’’ means ‘‘to guarantee or make certain’’ whereas ‘‘assure’’ means



152


‘‘to make conÞdent.’’ The comment added that ‘‘assure’’ is also more consistent with terminology in other regulations. The agency wishes to emphasize that it does not intend the word ‘‘ensure’’ to represent a guarantee. The agency prefers to use the word ‘‘ensure’’ because it means to make certain.

O. GENERAL COMMENTS REGARDING THE PRESCRIPTION DRUG MARKETING ACT OF 1987 (PDMA) 15. Three comments addressed the use of handwritten signatures that are recorded electronically (SRE’s) under part 11 and PDMA. One Þrm described its delivery information acquisition device and noted its use of time stamps to record when signatures are executed. The comments requested clariÞcation that SRE’s would be acceptable under the PDMA regulations. One comment assumed that subpart C of part 11 (Electronic Signatures) would not apply to SRE’s, noting that it was not practical under PDMA (given the large number of physicians who may be eligible to receive drug product samples) to use such alternatives as identiÞcation codes combined with passwords. The agency advises that part 11 applies to handwritten signatures recorded electronically and that such signatures and their corresponding electronic records will be acceptable for purposes of meeting PDMA’s requirements when the provisions of part 11 are met. Although subpart C of part 11 does not apply to handwritten signatures recorded electronically, the agency advises that controls related to electronic records (subpart B), and the general provisions of subpart A, do apply to electronic records in the context of PDMA. The agency emphasizes, however, that part 11 does not restrict PDMA signings to SRE’s, and that organizations retain the option of using electronic signatures in conformance with part 11. Furthermore, the agency believes that the number of people in a given population or organization should not be viewed as an insurmountable obstacle to use of electronic signatures. The agency is aware, for example, of efforts by the American Society of Testing and Materials to develop standards for electronic medical records in which digital signatures could theoretically be used on a large scale.

P. COMMENTS

ON THE

UNIQUE NATURE

OF

PASSWORDS

16. Several comments noted, both generally and with regard to §§ 11.100(a), 11.200(a), and 11.300, that the password in an electronic signature that is composed of a combination of password and identiÞcation code is not, and need not be, unique. Two comments added that passwords may be known to system security administrators who assist people who forget passwords and requested that the rule acknowledge that passwords need not be unique. One comment said that the rule should describe how uniqueness is to be determined. The agency acknowledges that when an electronic signature consists of a combined identiÞcation code and password, the password need not be unique. It is possible that two persons in the same organization may have the same password. However, the agency believes that where good password practices are implemented, Copyright © 2004 CRC Press, LLC


Appendix I

153

such coincidence would be highly unlikely. As discussed in section XIII. of this document in the context of comments on proposed § 11.300, records are less trustworthy and reliable if it is relatively easy for someone to deduce or execute, by chance, a person’s electronic signature where the identiÞcation code of the signature is not conÞdential and the password is easily guessed. The agency does not believe that revising proposed § 11.100(a) is necessary because what must remain unique is the electronic signature, which, in the case addressed by the comments, consists not of the password alone, but rather the password in combination with an identiÞcation code. If the combination is unique, then the electronic signature is unique. The agency does not believe that it is necessary to describe in the regulations the various ways of determining uniqueness or achieving compliance with the requirement. Organizations thereby maintain implementation ßexibility. The agency believes that most system administrators or security managers would not need to know passwords to help people who have forgotten their own. This is because most administrators or managers have global computer account privileges to resolve such problems.

IV. SCOPE (§ 11.1) 17. One comment suggested adding anew paragraph to proposed § 11.1 that would exempt computer record maintenance software installed before the effective date of the Þnal rule, and that would exempt electronic records maintained before that date. The comment argued that such exemptions were needed for economic and constitutional reasons because making changes to existing systems would be costly and because the imposition of additional requirements after the fact could be regarded as an ex post facto rule. The comment said Þrms have been using electronic systems that have demonstrated reliability and security for many years before the agency’s publication of the ANPRM, and that the absence of FDA’s objections in inspectional form FDA 483 was evidence of the agency’s acceptance of the system. As discussed in section III.I. of this document, the agency is opposed to ‘‘grandfathering’’ existing systems because such exemptions may perpetuate environments that provide opportunities for record falsiÞcation and impair FDA’s ability to protect and promote public health. However, the agency wishes to avoid any confusion regarding the application of the provisions of part 11 to systems and electronic records in place before the rule’s effective date. Important distinctions need to be made relative to an electronic record’s creation, modiÞcation, and maintenance because various portions of part 11 address matters relating to these actions. Those provisions apply depending upon when a given electronic record is created, modiÞed, or maintained. Electronic records created before the effective date of this rule are not covered by part 11 provisions that relate to aspects of the record’s creation, such as the signing of the electronic record. Those records would not, therefore, need to be altered retroactively. Regarding records that were Þrst created before the effective date, part 11 provisions relating to modiÞcation of records, such as audit trails for record changes and the requirement that original entries not be obscured, would apply only to those modiÞcations made on or after the rule’s effective date, not to Copyright © 2004 CRC Press, LLC


154


modiÞcations made earlier. Likewise, maintenance provisions of part 11, such as measures to ensure that electronic records can be retrieved throughout their retention periods, apply to electronic records that are being maintained on or after the rule’s effective date. The hardware and software, as well as operational procedures used on or after the rule’s effective date, to create, modify, or maintain electronic records must comply with the provisions of part 11. The agency does not agree with any suggestion that FDA endorsement or acceptance of an electronic record system can be inferred from the absence of objections in an inspection report. Before this rulemaking, FDA did not have established criteria by which it could determine the reliability and trustworthiness of electronic records and electronic signatures and could not sanction electronic alternatives when regulations called for signatures. A primary reason for issuing part 11 is to develop and codify such criteria. FDA will assess the acceptability of electronic records and electronic signatures created prior to the effective date of part 11 on a case-by-case basis. 18. One comment suggested that proposed § 11.1 exempt production of medical devices and in vitro diagnostic products on the grounds that the subject was already adequately addressed in the medical device CGMP regulations currently in effect in § 820.195 (21 CFR 820.195), and that additional regulations would be confusing and would limit compliance. The agency believes that part 11 complements, and is supportive of, the medical device CGMP regulations and the new medical device quality system regulation, as well as other regulations, and that compliance with one does not confound compliance with others. Before publication of the ANPRM, the agency determined that existing regulations, including the medical device CGMP regulations, did not adequately address electronic records and electronic signatures. That determination was reinforced in the comments to the ANPRM, which focused on the need to identify what makes electronic records reliable, trustworthy, and compatible with FDA’s responsibility to promote and protect public health. For example, the provision cited by the comment, § 820.195, states ‘‘When automated data processing is used for manufacturing or quality assurance purposes, adequate checks shall be designed and implemented to prevent inaccurate data output, input, and programming errors.’’ This section does not address the many issues addressed by part 11, such as electronic signatures, record falsiÞcation, or FDA access to electronic records. The relationship between the quality system regulation and part 11 is discussed at various points in the preamble to the quality system regulation. 19. One comment asserted that for purposes of PDMA, the scope of proposed part 11 should be limited to require only those controls for assessing signatures in paper-based systems because physicians’ handwritten signatures are executed to electronic records. The comment further asserted that, because drug manufacturers’ representatives carry computers into physicians’ ofÞces (where the physicians then sign sample requests and receipts), only closed system controls should be needed. The agency believes that, for purposes of PDMA, controls needed for electronic records bearing handwritten signatures are no different from controls needed for the same kinds of records and signatures used elsewhere, and that proposed § 11.1 need not make any such distinction. Copyright © 2004 CRC Press, LLC


Appendix I

155

In addition, the agency disagrees with the implication that all PDMA electronic records are, in fact, handled within closed systems. The classiÞcation of a system as open or closed in a particular situation depends on what is done in that situation. For example, the agency agrees that a closed system exists where a drug producer’s representative (the person responsible for the content of the electronic record) has control over access to the electronic record system by virtue of possessing the portable computer and controlling who may use the computer to sign electronic records. However, should the Þrm’s representative transfer copies of those records to a public online service that stores them for the drug Þrm’s subsequent retrieval, the agency considers such transfer and storage to be within an open system because access to the system holding the records is controlled by the online service, which is not responsible for the record’s content. Activities in the Þrst example would be subject to closed system controls and activities in the second example would be subject to open system controls. 20. One comment urged that proposed § 11.1 contain a clear statement of what precedence certain provisions of part 11 have over other regulations. The agency believes that such statements are found in § 11.1(c): Where electronic signatures and their associated records meet the requirements of this part, the agency will consider the electronic signatures to be equivalent to full handwritten signatures, initials, and other general signings as required under agency regulations unless speciÞcally excepted by regulations * * *.

and § 11.1(d) (‘‘Electronic records that meet the requirements of this part may be used in lieu of paper records, in accordance with § 11.2, unless paper records are speciÞcally required.’’). These provisions clearly address the precedence of part 11 and the equivalence of electronic records and electronic signatures. To further clarify the scope of the rule, FDA has revised § 11.1 to apply to electronic records submitted to the agency under requirements of the Federal Food, Drug, and Cosmetic Act (the act) and the Public Health Service Act (the PHS Act). This clariÞes the point that submissions required by these statutes, but not speciÞcally mentioned in the Code of Federal Regulations (CFR), are subject to part 11. 21. Proposed § 11.1(b) stated that the regulations would apply to records in electronic form that are created, modiÞed, maintained, or transmitted, under any records requirements set forth in Chapter I of Title 21. One comment suggested that the word ‘‘transmitted’’ be deleted from proposed § 11.1(b) because the wording would inappropriately apply to paper documents that are transmitted by fax. The comment noted that if the records are in machine readable form before or after transmission, they would still be covered by the revised wording. The agency does not intend part 11 to apply to paper records even if such records are transmitted or received by fax. The agency notes that the records transmitted by fax may be in electronic form at the sender, the recipient, or both. Part 11 would apply whenever the record is in electronic form. To remedy the problem noted by the comment, the agency has added a sentence to § 11.1(b) stating that part 11 does not apply to paper records that are, or have been, transmitted by electronic means. Copyright © 2004 CRC Press, LLC


156


22. One comment asked whether paper records created by computer would be subject to proposed part 11. The comment cited, as an example, the situation in which a computer system collects toxicology data that are printed out and maintained as ‘‘raw data.’’ Part 11 is intended to apply to systems that create and maintain electronic records under FDA’s requirements in Chapter I of Title 21, even though some of those electronic records may be printed on paper at certain times. The key to determining part 11 applicability, under § 11.1(b), is the nature of the system used to create, modify, and maintain records, as well as the nature of the records themselves. Part 11 is not intended to apply to computer systems that are merely incidental to the creation of paper records that are subsequently maintained in traditional paperbased systems. In such cases, the computer systems would function essentially like manual typewriters or pens and any signatures would be traditional handwritten signatures. Record storage and retrieval would be of the traditional ‘‘Þle cabinet’’ variety. More importantly, overall reliability, trustworthiness, and FDA’s ability to access the records would derive primarily from well-established and generally accepted procedures and controls for paper records. For example, if a person were to use word processing software to generate a paper submission to FDA, part 11 would not apply to the computer system used to generate the submission, even though, technically speaking, an electronic record was initially created and then printed on paper. When records intended to meet regulatory requirements are in electronic form, part 11 would apply to all the relevant aspects of managing those records (including their creation, signing, modiÞcation, storage, access, and retrieval). Thus, the software and hardware used to create records that are retained in electronic form for purposes of meeting the regulations would be subject to part 11. Regarding the comment about ‘‘raw data,’’ the agency notes that speciÞc requirements in existing regulations may affect the particular records at issue, regardless of the form such records take. For example, ‘‘raw data,’’ in the context of the good laboratory practices regulations (21 CFR part 58), include computer printouts from automated instruments as well as the same data recorded on magnetic media. In addition, regulations that cover data acquisition systems generally include requirements intended to ensure the trustworthiness and reliability of the collected data. 23. Several comments on proposed § 11.1(b) suggested that the phrase ‘‘or archived and retrieved’’ be added to paragraph (b) to reßect more accurately a record’s lifecycle. The agency intended that record archiving and retrieval would be part of record maintenance, and therefore already covered by § 11.1(b). However, for added clarity, the agency has revised § 11.1(b) to add ‘‘archived and retrieved.’’ 24. One comment suggested that, in describing what electronic records are within the scope of part 11, proposed § 11.1(b) should be revised by substituting ‘‘processed’’ for ‘‘modiÞed’’ and ‘‘communicated’’ for ‘‘transmitted’’ because ‘‘communicated’’ reßects the fact that the information was dispatched and also received. The comment also suggested substituting ‘‘retained’’ for ‘‘maintained,’’ or adding the word ‘‘retained,’’ because ‘‘maintain’’ does not necessarily convey the retention requirement. Copyright © 2004 CRC Press, LLC


Appendix I

157

The agency disagrees. The word ‘‘modiÞed’’ better describes the agency’s intent regarding changes to a record; the word ‘‘processed’’ does not necessarily infer a change to a record. FDA believes ‘‘transmitted’’ is preferable to ‘‘communicated’’ because ‘‘communicated’’ might infer that controls to ensure integrity and authenticity hinge on whether the intended recipient actually received the record. Also, as discussed in comment 22 of this document, the agency intends for the term ‘‘maintain’’ to include records retention. 25. Two comments suggested thatproposed § 11.1(b) explicitly state that part 11 supersedes all references to handwritten signatures in 21 CFR parts 211 through 226 that pertain to a drug, and in 21 CFR parts 600 through 680 that pertain to biological products for human use. The comments stated that the revision should clarify coverage and permit blood centers and transfusion services to take full advantage of electronic systems that provide process controls. The agency does not agree that the revision is necessary because, under § 11.1(b) and (c), part 11 permits electronic records or submissions under all FDA regulations in Chapter I of Title 21 unless speciÞcally excepted by future regulations. 26. Several comments expressed concern that the proposed rule had inappropriately been expanded in scope from the ANPRM to address electronic records as well as electronic signatures. One comment argued that the scope of part 11 should be restricted only to those records that are currently required to be signed, witnessed, or initialed, and that the agency should not require electronic records to contain electronic signatures where the corresponding paper records are not required to be signed. The agency disagrees with the assertion that part 11 should address only electronic signatures and not electronic records for several reasons. First, based on comments on the ANPRM, the agency is convinced that the reliability and trustworthiness of electronic signatures depend in large measure on the reliability and trustworthiness of the underlying electronic records. Second, the agency has concluded that electronic records, like paper records, need to be trustworthy, reliable, and compatible with FDA’s responsibility to promote and protect public health regardless of whether they are signed. In addition, records falsiÞcation is an issue with respect to both signed and unsigned records. Therefore, the agency concludes that although the ANPRM focused primarily on electronic signatures, expansion of the subject to electronic records in the proposed rule was fully justiÞed. The agency stresses that part 11 does not require that any given electronic record be signed at all. The requirement that any record bear a signature is contained in the regulation that mandates the basic record itself. Where records are signed, however, by virtue of meeting a signature requirement or otherwise, part 11 addresses controls and procedures intended to help ensure the reliability and trustworthiness of those signatures. 27. Three comments asked if there were any regulations, including CGMP regulations, that might be excepted from part 11 and requested that the agency identify such regulations. FDA, at this time, has not identiÞed any current regulations that are speciÞcally excepted from part 11. However, the agency believes it is prudent to provide for such exceptions should they become necessary in the future. It is possible that, as Copyright © 2004 CRC Press, LLC


158


the agency’s experience with part 11 increases, certain records may need to be limited to paper if there are problems with the electronic versions of such records. 28. One comment requested clariÞcation of the meaning of the term ‘‘general signings’’ in proposed § 11.1(c), and said that the distinction between ‘‘full handwritten’’ signatures and ‘‘initials’’ is unnecessary because handwritten includes initials in all common deÞnitions of handwritten signature. The comment also suggested changing the term ‘‘equivalent’’ to ‘‘at least equivalent’’ because electronic signatures are not precise equivalents of handwritten signatures and computer-based signatures have the potential of being more secure. The agency advises that current regulations that require records to be signed express those requirements in different ways depending upon the agency’s intent and expectations. Some regulations expressly state that records must be signed using ‘‘full handwritten’’ signatures, whereas other regulations state that records must be ‘‘signed or initialed;’’ still other regulations implicitly call for some kind of signing by virtue of requiring record approvals or endorsements. This last broad category is addressed by the term ‘‘general signings’’ in § 11.1(c). Where the language is explicit in the regulations, the means of meeting the requirement are correspondingly precise. Therefore, where a regulation states that a signature must be recorded as ‘‘full handwritten,’’ the use of initials is not an acceptable substitute. Furthermore, under part 11, for an electronic signature to be acceptable in place of any of these signings, the agency only needs to consider them as equivalent; electronic signatures need not be superior to those other signings to be acceptable. 29. Several comments requested clariÞcation of which FDA records are required to be in paper form, and urged the agency to allow and promote the use of electronic records in all cases. One comment suggested that proposed § 11.1(d) be revised to read, in part, ‘‘* * * unless the use of electronic records is speciÞcally prohibited.’’ The agency intends to permit the use of electronic records required to be maintained but not submitted to the agency (as noted in § 11.2(a)) provided that the requirements of part 11 are met and paper records are not speciÞcally required. The agency also wishes to encourage electronic submissions, but is limited by logistic and resource constraints. The agency is unaware of ‘‘maintenance records’’ that are currently explicitly required to be in paper form (explicit mention of paper is generally unnecessary because, at the time most regulations were prepared, only paper-based technologies were in use) but is providing for that possibility in the future. For purposes of part 11, the agency will not consider that a regulation requires ‘‘maintenance’’ records to be in paper form where the regulation is silent on the form the record must take. FDA believes that the comments’ suggested wording does not offer sufÞcient advantages to adopt the change. However, to enable FDA to accept as many electronic submissions as possible, the agency is amending § 11.1(b) to include those submissions that the act and the PHS Act speciÞcally require, even though such submissions may not be identiÞed in agency regulations. An example of such records is premarket submissions for Class I and Class II medical devices, required by section 510(k) of the act (21 U.S.C. 360(k)).



Appendix I

159

30. Several comments addressed various aspects of the proposed requirement under § 11.1(e) regarding FDA inspection of electronic record systems. Several comments objected to the proposal as being too broad and going beyond the agency’s legal inspectional authority. One comment stated that access inferred by such inspection may include proprietary Þnancial and sales data to which FDA is not entitled. Another comment suggested adding the word ‘‘authorized’’ before ‘‘inspection.’’ Some comments suggested revising proposed § 11.1(e) to limit FDA inspection only to the electronic records and electronic signatures themselves, thus excluding inspection of hardware and software used to manage those records and signatures. Other comments interpreted proposed § 11.1(e) as requiring them to keep supplanted or retired hardware and software to enable FDA inspection of those outdated systems. The agency advises that FDA inspections under part 11 are subject to the same legal limitations as FDA inspections under other regulations. The agency does not believe it is necessary to restate that limitation by use of the suggested wording. However, within those limitations, it may be necessary to inspect hardware and software used to generate and maintain electronic records to determine if the provisions of part 11 are being met. Inspection of resulting records alone would be insufÞcient. For example, the agency may need to observe the use and maintenance of tokens or devices that contain or generate identiÞcation information. Likewise, to assess the adequacy of systems validation, it is generally necessary to inspect hardware that is being used to determine, among other things, if it matches the system documentation description of such hardware. The agency has concluded that hardware and software used to generate and maintain electronic records and signatures are ‘‘pertinent equipment’’ within the meaning of section 704 of the act (21 U.S.C. 374). The agency does not expect persons to maintain obsolete and supplanted computer systems for the sole purpose of enabling FDA inspection. However, the agency does expect Þrms to maintain and have available for inspection documentation relevant to those systems, in terms of compliance with part 11, for as long as the electronic records are required by other relevant regulations. Persons should also be mindful of the need to keep appropriate computer systems that are capable of reading electronic records for as long as those records must be retained. In some instances, this may mean retention of otherwise outdated and supplanted systems, especially where the old records cannot be converted to a form readable by the newer systems. In most cases, however, FDA believes that where electronic records are accurately and completely transcribed from one system to another, it would not be necessary to maintain older systems. 31. One comment requested that proposed part 11 be revised to give examples of electronic records subject to FDA inspection, including pharmaceutical and medical device production records, in order to reduce the need for questions. The agency does not believe that it is necessary to include examples of records it might inspect because the addition of such examples might raise questions about the agency’s intent to inspect other records that were not identiÞed. 32. One comment said that the regulation should state that certain security related information, such as private keys attendant to cryptographic implementation, is not



160


intended to be subject to inspection, although procedures related to keeping such keys conÞdential can be subject to inspection. The agency would not routinely seek to inspect especially sensitive information, such as passwords or private keys, attendant to security systems. However, the agency reserves the right to conduct such inspections, consistent with statutory limitations, to enforce the provisions of the act and related statutes. It may be necessary, for example, in investigating cases of suspected fraud, to access and determine passwords and private keys, in the same manner as the agency may obtain specimens of handwritten signatures (‘‘exemplars’’). Should there be any reservations about such inspections, persons may, of course, change their passwords and private keys after FDA inspection. 33. One comment asked how persons were expected to meet the proposed requirement, under § 11.1(e), that computer systems be readily available for inspection when such systems include geographically dispersed networks. Another comment said FDA investigators should not be permitted to access industry computer systems as part of inspections because investigators would be untrained users. The agency intends to inspect those parts of electronic record or signature systems that have a bearing on the trustworthiness and reliability of electronic records and electronic signatures under part 11. For geographically dispersed systems, inspection at a given location would extend to operations, procedures, and controls at that location, along with interaction of that local system with the wider network. The agency would inspect other locations of the network in a separate but coordinated manner, much the same way the agency currently conducts inspections of Þrms that have multiple facilities in different parts of the country and outside of the United States. FDA does not believe it is reasonable to rule out computer system access as part of an inspection of electronic record or signature systems. Historically, FDA investigators observe the actions of establishment employees, and (with the cooperation of establishment management) sometimes request that those employees perform some of their assigned tasks to determine the degree of compliance with established requirements. However, there may be times when FDA investigators need to access a system directly. The agency is aware that such access will generally require the cooperation of and, to some degree, instruction by the Þrms being inspected. As new, complex technologies emerge, FDA will need to develop and implement new inspectional methods in the context of those technologies.

V. IMPLEMENTATION (§ 11.2) 34. Proposed § 11.2(a) stated that for ‘‘records required by chapter I of this title to be maintained, but not submitted to the agency, persons may use electronic records/signatures in lieu of paper records/conventional signatures, in whole or in part, * * *.’’ Two comments requested clariÞcation of the term ‘‘conventional signatures.’’ One comment suggested that the term ‘‘traditional signatures’’ be used instead. Another suggested rewording in order to clarify the slash in the phrase ‘‘records/ signatures.’’ Copyright © 2004 CRC Press, LLC


Appendix I

161

The agency advises that the term ‘‘conventional signature’’ means handwritten signature. The agency agrees that the term ‘‘traditional signature’’ is preferable, and has revised § 11.2(a) and (b) accordingly. The agency has also clariÞed proposed § 11.2(a) by replacing the slash with the word ‘‘or.’’ 35. One comment asked if the term‘‘persons’’ in proposed § 11.2(b) would include devices because computer systems frequently apply digital time stamps on records automatically, without direct human intervention. The agency advises that the term ‘‘persons’’ excludes devices. The agency does not consider the application of a time stamp to be the application of a signature. 36. Proposed § 11.2(b)(2) provides conditions under which electronic records or signatures could be submitted to the agency in lieu of paper. One condition is that a document, or part of a document, must be identiÞed in a public docket as being the type of submission the agency will accept in electronic form. Two comments addressed the nature of the submissions to the public docket. One comment asked that the agency provide speciÞcs, such as the mechanism for updating the docket and the frequency of such updates. One comment suggested making the docket available to the public by electronic means. Another comment suggested that acceptance procedures be uniform among agency units and that electronic mail be used to hold consultations with the agency. One comment encouraged the agency units receiving the submissions to work closely with regulated industry to ensure that no segment of industry is unduly burdened and that agency guidance is widely accepted. The agency intends to develop efÞcient electronic records acceptance procedures that afford receiving units sufÞcient ßexibility to deal with submissions according to their capabilities. Although agencywide uniformity is a laudable objective, to attain such ßexibility it may be necessary to accommodate some differences among receiving units. The agency considers of primary importance, however, that all part 11 submissions be trustworthy, reliable, and in keeping with FDA regulatory activity. The agency expects to work closely with industry to help ensure that the mechanics and logistics of accepting electronic submissions do not pose any undue burdens. However, the agency expects persons to consult with the intended receiving units on the technical aspects of the submission, such as media, method of transmission, Þle format, archiving needs, and technical protocols. Such consultations will ensure that submissions are compatible with the receiving units’ capabilities. The agency has revised proposed § 11.2(b)(2) to clarify this expectation. Regarding the public docket, the agency is not at this time establishing a Þxed schedule for updating what types of documents are acceptable for submission because the agency expects the docket to change and grow at a rate that cannot be predicted. The agency may, however, establish a schedule for updating the docket in the future. The agency agrees that making the docket available electronically is advisable and will explore this option. Elsewhere in this issue of the Federal Register, FDA is providing further information on this docket.

VI. DEFINITIONS (§ 11.3) 37. One comment questioned the incorporation in proposed § 11.3(a) of deÞnitions under section 201 of the act (21 U.S.C. 321), noting that other FDA regulations Copyright © 2004 CRC Press, LLC


162


(such as 21 CFR parts 807 and 820) lack such incorporation, and suggested that it be deleted. The agency has retained the incorporation by reference to deÞnitions under section 201 of the act because those deÞnitions are applicable to part 11. 38. One comment suggested adding the following deÞnition for the term ‘‘digital signature:’’ ‘‘data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery, e.g., by the recipient.’’ The agency agrees that the term digital signature should be deÞned and has added new § 11.3(b)(5) to provide a deÞnition for digital signature that is consistent with the Federal Information Processing Standard 186, issued May 19, 1995, and effective December 1, 1995, by the U.S. Department of Commerce, National Institute of Standards and Technology (NIST). Generally, 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 such that the identity of the signer and the integrity of the data can be veriÞed.’’ FDA advises that the set of rules and parameters is established in each digital signature standard. 39. Several comments suggested various modiÞcations of the proposed deÞnition of biometric/behavioral links, and suggested revisions that would exclude typing a password or identiÞcation code which, the comments noted, is a repeatable action. The comments suggested that actions be unique and measurable to meet the intent of a biometric method. The agency agrees that the proposed deÞnition of biometric/behavioral links should be revised to clarify the agency’s intent that repetitive actions alone, such as typing an identiÞcation code and password, are not considered to be biometric in nature. Because comments also indicated that it would be preferable to simplify the term, the agency is changing the term ‘‘biometric/ behavioral link’’ to ‘‘biometrics.’’ Accordingly, § 11.3(b)(3) deÞnes the term ‘‘biometrics’’ to mean ‘‘a method of verifying an individual’s identity based on measurement of the individual’s physical feature(s) or repeatable action(s) where those features and/or actions are both unique to that individual and measurable.’’ 40. One comment said that the agency should identify what biometric methods are acceptable to verify a person’s identity and what validation acceptance criteria the agency has used to determine that biometric technologies are superior to other methods, such as use of identiÞcation codes and passwords. The agency believes that there is a wide variety of acceptable technologies, regardless of whether they are based on biometrics, and regardless of the particular type of biometric mechanism that may be used. Under part 11, electronic signatures that employ at least two distinct identiÞcation components such as identiÞcation codes and passwords, and electronic signatures based on biometrics are equally acceptable substitutes for traditional handwritten signatures. Furthermore, all electronic record systems are subject to the same requirements of subpart B of part 11 regardless of the electronic signature technology being used. These provisions include requirements for validation. Regarding the comment’s suggestion that FDA apply quantitative acceptance criteria, the agency is not seeking to set speciÞc numerical standards or statistical Copyright © 2004 CRC Press, LLC


Appendix I

163

performance criteria in determining the threshold of acceptability for any type of technology. If such standards were to be set for biometrics-based electronic signatures, similar numerical performance and reliability requirements would have to be applied to other technologies as well. The agency advises, however, that the differences between system controls for biometrics-based electronic signatures and other electronic signatures are a result of the premise that biometrics-based electronic signatures, by their nature, are less prone to be compromised than other methods such as identiÞcation codes and passwords. Should it become evident that additional controls are warranted for biometrics-based electronic signatures, the agency will propose to revise part 11 accordingly. 41. Proposed § 11.3(b)(4) deÞned a closed system as an environment in which there is communication among multiple persons, and where system access is restricted to people who are part of the organization that operates the system. Many comments requested clariÞcation of the term ‘‘organization’’ and stated that the rule should account for persons who, though not strictly employees of the operating organization, are nonetheless obligated to it in some manner, or who would otherwise be granted system access by the operating organization. As examples of such persons, the comments cited outside contractors, suppliers, temporary employees, and consultants. The comments suggested a variety of alternative wording, including a change of emphasis from organizational membership to organizational control over system access. One comment requested clariÞcation of whether the rule intends to address speciÞc disciplines within a company. Based on the comments, the agency has revised the proposed deÞnition of closed system to state ‘‘an environment in which system access is controlled by persons who are responsible for the content of electronic records that are on the system.’’ The agency agrees that the most important factor in classifying a system as closed or open is whether the persons responsible for the content of the electronic records control access to the system containing those records. A system is closed if access is controlled by persons responsible for the content of the records. If those persons do not control such access, then the system is open because the records may be read, modiÞed, or compromised by others to the possible detriment of the persons responsible for record content. Hence, those responsible for the records would need to take appropriate additional measures in an open system to protect those records from being read, modiÞed, destroyed, or otherwise compromised by unauthorized and potentially unknown parties. The agency does not believe it is necessary to codify the basis or criteria for authorizing system access, such as existence of a Þduciary responsibility or contractual relationship. By being silent on such criteria, the rule affords maximum ßexibility to organizations by permitting them to determine those criteria for themselves. 42. Concerning the proposed deÞnition of closed system, one comment suggested adding the words ‘‘or devices’’ after ‘‘persons’’ because communications may involve nonhuman entities. The agency does not believe it is necessary to adopt the suggested revision because the primary intent of the regulation is to address communication among humans, not devices. Copyright © 2004 CRC Press, LLC


164


43. One comment suggested deÞning a closed system in terms of functional characteristics that include physical access control, having professionally written and approved procedures with employees and supervisors trained to follow them, conducting investigations when abnormalities may have occurred, and being under legal obligation to the organization responsible for operating the system. The agency agrees that the functional characteristics cited by the comment are appropriate for a closed system, but has decided that it is unnecessary to include them in the deÞnition. The functional characteristics themselves, however, such as physical access controls, are expressed as requirements elsewhere in part 11. 44. Two comments said that the agency should regard as closed a system in which dial-in access via public phone lines is permitted, but where access is authorized by, and under the control of, the organization that operates the system. The agency advises that dial-in access over public phone lines could be considered part of a closed system where access to the system that holds the electronic records is under the control of the persons responsible for the content of those records. The agency cautions, however, that, where an organization’s electronic records are stored on systems operated by third parties, such as commercial online services, access would be under control of the third parties and the agency would regard such a system as being open. The agency also cautions that, by permitting access to its systems by public phone lines, organizations lose the added security that results from restricting physical access to computer terminal and other input devices. In such cases, the agency believes Þrms would be prudent to implement additional security measures above and beyond those controls that the organization would use if the access device was within its facility and commensurate with the potential consequences of such unauthorized access. Such additional controls might include, for example, use of input device checks, caller identiÞcation checks (phone caller identiÞcation), call backs, and security cards. 45. Proposed § 11.3(b)(5) deÞned electronic record as a document or writing comprised of any combination of text, graphic representation, data, audio information, or video information, that is created, modiÞed, maintained, or transmitted in digital form by a computer or related system. Many comments suggested revising the proposed deÞnition to reßect more accurately the nature of electronic records and how they differ from paper records. Some comments suggested distinguishing between machine readable records and paper records created by machine. Some comments noted that the term ‘‘document or writing’’ is inappropriate for electronic records because electronic records could be any combination of pieces of information assembled (sometimes on a transient basis) from many noncontiguous places, and because the term does not accurately describe such electronic information as raw data or voice mail. Two comments suggested that the agency adopt deÞnitions of electronic record that were established, respectively, by the United Nations Commission on International Trade Law (UNCITRAL) Working Group on Electronic Data Interchange, and the American National Standards Institute/ Institute of Electrical and Electronic Engineers Software Engineering (ANSI/ IEEE) Standard (729–1983). The agency agrees with the suggested revisions and has revised the deÞnition of ‘‘electronic record’’ to emphasize this unique nature and to clarify that the agency does not regard a paper record to be an electronic record simply because it was Copyright © 2004 CRC Press, LLC


Appendix I

165

created by a computer system. The agency has removed ‘‘document or writing’’ from this deÞnition and elsewhere in part 11 for the sake of clarity, simplicity, and consistency. However, the agency believes it is preferable to adapt or modify the words ‘‘document’’ and ‘‘writing’’ to electronic technologies rather than discard them entirely from the lexicon of computer technology. The agency is aware that the terms ‘‘document’’ and ‘‘electronic document’’ are used in contexts that clearly do not intend to describe paper. Therefore, the agency considers the terms ‘‘electronic record’’ and ‘‘electronic document’’ to be generally synonymous and may use the terms ‘‘writing,’’ ‘‘electronic document,’’ or ‘‘document’’ in other publications to describe records in electronic form. The agency believes that such usage is a prudent conservation of language and is consistent with the use of other terms and expressions that have roots in older technologies, but have nonetheless been adapted to newer technologies. Such terms include telephone ‘‘dialing,’’ internal combustion engine ‘‘horse power,’’ electric light luminance expressed as ‘‘foot candles,’’ and (more relevant to computer technology) execution of a ‘‘carriage return.’’ Accordingly, the agency has revised the deÞnition of electronic record to mean ‘‘any combination of text, graphics, data, audio, pictorial, or other information representation in digital form that is created, modiÞed, maintained, archived, retrieved, or distributed by a computer system.’’ 46. Proposed § 11.3(b)(6) deÞned an electronic signature as the entry in the form of a magnetic impulse or other form of computer data compilation of any symbol or series of symbols, executed, adopted or authorized by a person to be the legally binding equivalent of the person’s handwritten signature. One comment supported the deÞnition as proposed, noting its consistency with dictionary deÞnitions (Random House Dictionary of the English Language, Unabridged Ed. 1983, and American Heritage Dictionary, 1982). Several other comments, however, suggested revisions. One comment suggested replacing ‘‘electronic signature’’ with ‘‘computer based signature,’’ ‘‘authentication,’’ or ‘‘computer based authentication’’ because ‘‘electronic signature’’ is imprecise and lacks clear and recognized meaning in the information security and legal professions. The comment suggested a deÞnition closer to the UNCITRAL draft deÞnition: (1) [a] method used to identify the originator of the data message and to indicate the originator’s approval of the information contained therein; and (2) that method is as reliable as was appropriate for the purpose for which the data message was generated or communicated, in the light of all circumstances, including any agreement between the originator and the addressee of the data message.

One comment suggested replacing ‘‘electronic signature’’ with ‘‘electronic identiÞcation’’ or ‘‘electronic authorization’’ because the terms include many types of technologies that are not easily distinguishable and because the preamble to the proposed rule gave a rationale for using ‘‘electronic signature’’ that was too ‘‘esoteric for practical consideration.’’ The agency disagrees that ‘‘electronic signature’’ as proposed should be replaced with other terms and deÞnitions. As noted in the preamble to the proposed rule, the Copyright © 2004 CRC Press, LLC


166


agency believes that it is vital to retain the word ‘‘signature’’ to maintain the equivalence and signiÞcance of various electronic technologies with the traditional handwritten signature. By not using the word ‘‘signature,’’ people may treat the electronic alternatives as less important, less binding, and less in need of controls to prevent falsiÞcation. The agency also believes that use of the word signature provides a logical bridge between paper and electronic technologies that facilitates the general transition from paper to electronic environments. The term helps people comply with current FDA regulations that speciÞcally call for signatures. Nor does the agency agree that this reasoning is beyond the reach of practical consideration. The agency declines to accept the suggested UNCITRAL deÞnition because it is too narrow in context in that there is not always a speciÞed message addressee for electronic records required by FDA regulations (e.g., a batch production record does not have a speciÞc ‘‘addressee’’). 47. Concerning the proposed deÞnition of ‘‘electronic signature,’’ other comments suggested deletion of the term ‘‘magnetic impulse’’ to render the term media neutral and thus allow for such alternatives as an optical disk. Comments also suggested that the term ‘‘entry’’ was unclear and recommended its deletion. Two comments suggested revisions that would classify symbols as an electronic signature only when they are committed to permanent storage because not every computer entry is a signature and processing to permanent storage must occur to indicate completion of processing. The agency advises that the proposal did not limit electronic signature recordings to ‘‘magnetic impulse’’ because the proposed deÞnition added, ‘‘or other form of computer data * * *.’’ However, in keeping with the agency’s intent to accept a broad range of technologies, the terms ‘‘magnetic impulse’’ and ‘‘entry’’ have been removed from the proposed deÞnition. The agency believes that recording of computer data to ‘‘permanent’’ storage is not a necessary or warranted qualiÞer because it is not relevant to the concept of equivalence to a handwritten signature. In addition, use of the qualiÞer regarding permanent storage could impede detection of falsiÞed records if, for example, the signed falsiÞed record was deleted after a predetermined period (thus, technically not recorded to ‘‘permanent’’ storage). An individual could disavow a signature because the record had ceased to exist. For consistency with the proposed deÞnition of handwritten signature, and to clarify that electronic signatures are those of individual human beings, and not those of organizations (as included in the act’s deÞnition of ‘‘person’’), FDA is changing ‘‘person’’ to ‘‘individual’’ in the Þnal rule. Accordingly, § 11.3(b)(7) deÞnes electronic signature as a computer data compilation of any symbol or series of symbols executed, adopted, or authorized by an individual to be the legally binding equivalent of the individual’s handwritten signature. 48. Proposed § 11.3(b)(7) (redesignated § 11.3(b)(8) in the Þnal rule) deÞned ‘‘handwritten signature’’ as the name of an individual, handwritten in script by that individual, executed or adopted with the present intention to authenticate a writing in a permanent form. The act of signing with a writing or marking instrument such as a pen or stylus is preserved. The proposed deÞnition also stated that the scripted name, while conventionally applied to paper, may also be applied to other devices which capture the written name. Copyright © 2004 CRC Press, LLC


Appendix I

167

Many comments addressed this proposed deÞnition. Two comments suggested that it be deleted on the grounds it is redundant and that, when handwritten signatures are recorded electronically, the result Þts the deÞnition of electronic signature. The agency disagrees that the deÞnition of handwritten signature should be deleted. In stating the criteria under which electronic signatures may be used in place of traditional handwritten signatures, the agency believes it is necessary to deÞne handwritten signature. In addition, the agency believes that it is necessary to distinguish handwritten signatures from electronic signatures because, with handwritten signatures, the traditional act of signing one’s name is preserved. Although the handwritten signature recorded electronically and electronic signatures, as deÞned in part 11, may both ultimately result in magnetic impulses or other forms of computerized symbol representations, the means of achieving those recordings and, more importantly, the controls needed to ensure their reliability and trustworthiness are quite different. In addition, the agency believes that a deÞnition for handwritten signature is warranted to accommodate persons who wish to implement record systems that are combinations of paper and electronic technologies. 49. Several comments suggested replacing the reference to ‘‘scripted name” in the proposed deÞnition of handwritten signature with ‘‘legal mark’’ so as to accommodate individuals who are physically unable to write their names in script. The comments asserted that the term ‘‘legal mark’’ would bring the deÞnition to closer agreement with generally recognized legal interpretations of signature. The agency agrees and has added the term ‘‘legal mark’’ to the deÞnition of handwritten signature. 50. One comment recommended thatthe regulation state that, when the handwritten signature is not the result of the act of signing with a writing or marking instrument, but is applied to another device that captures the written name, a system should verify that the owner of the signature has authorized the use of the handwritten signature. The agency declines to accept this comment because, if the act of signing or marking is not preserved, the type of signature would not be considered a handwritten signature. The comment appears to be referring to instances in which one person authorizes someone else to use his or her stamp or device. The agency views this as inappropriate when the signed record does not clearly show that the stamp owner did not actually execute the signature. As discussed elsewhere in this preamble, the agency believes that where one person authorizes another to sign a document on his or her behalf, the second person must sign his or her own name (not the name of the Þrst person) along with some notation that, in doing so, he or she is acting in the capacity, or on behalf, of the Þrst person. 51. One comment suggested that where handwritten signatures are captured by devices, there should be a register of manually written signatures to enable comparison for authenticity and the register also include the typed names of individuals. The agency agrees that the practice of establishing a signature register has merit, but does not believe that it is necessary, in light of other part 11 controls. As noted elsewhere in this preamble (in the discussion of proposed § 11.50), the agency agrees that human readable displays of electronic records must display the name of the signer. Copyright © 2004 CRC Press, LLC


168


52. Several comments suggested various editorial changes to the proposed definition of handwritten signature including: (1) Changing the word ‘‘also’’ in the last sentence to ‘‘alternatively,’’ (2) clarifying the difference between the words ‘‘individual’’ and ‘‘person,’’ (3) deleting the words ‘‘in a permanent form,’’ and (4) changing ‘‘preserved’’ to‘‘permitted.’’ One comment asserted that the last sentence of the proposed deÞnition was unnecessary. The agency has revised the deÞnition of handwritten signature to clarify its intent and to keep the regulation as ßexible as possible. The agency believes that the last sentence of the proposed deÞnition is needed to address devices that capture handwritten signatures. The agency is not adopting the suggestion that the word ‘‘preserved’’ be changed to ‘‘permitted’’ because ‘‘preserved’’ more accurately states the agency’s intent and is a qualiÞer to help distinguish handwritten signatures from others. The agency advises that the word ‘‘individual’’ is used, rather than ‘‘person,’’ because the act’s deÞnition of person extends beyond individual human beings to companies and partnerships. The agency has retained the term ‘‘permanent’’ to discourage the use of pencils, but recognizes that ‘‘permanent’’ does not mean eternal. 53. One comment asked whether a signature that is Þrst handwritten and then captured electronically (e.g., by scanning) is an electronic signature or a handwritten signature, and asked how a handwritten signature captured electronically (e.g., by using a stylus-sensing pad device) that is afÞxed to a paper copy of an electronic record would be classiÞed. FDA advises that when the act of signing with a stylus, for example, is preserved, even when applied to an electronic device, the result is a handwritten signature. The subsequent printout of the signature on paper would not change the classiÞcation of the original method used to execute the signature. 54. One comment asserted that a handwritten signature recorded electronically should be considered to be an electronic signature, based on the medium used to capture the signature. The comment argued that the word signature should be limited to paper technology. The agency disagrees and believes it is important to classify a signature as handwritten based upon the preserved action of signing with a stylus or other writing instrument. 55. One comment asked if the deÞnition of handwritten signature encompasses handwritten initials. The agency advises that, as revised, the deÞnition of handwritten signature includes handwritten initials if the initials constitute the legal mark executed or adopted with the present intention to authenticate a writing in a permanent form, and where the method of recording such initials involves the act of writing with a pen or stylus. 56. Proposed § 11.3(b)(8) (redesignated as § 11.3(b)(9) in the Þnal rule) deÞned an open system as an environment in which there is electronic communication among multiple persons, where system access extends to people who are not part of the organization that operates the system. Several comments suggested that, for simplicity, the agency deÞne ‘‘open system’’ as any system that does not meet the deÞnition of a closed system. One Copyright © 2004 CRC Press, LLC


Appendix I

169

comment suggested that the deÞnition be deleted on the grounds it is redundant, and that it is the responsibility of individual Þrms to take appropriate steps to ensure the validity and security of applications and information, regardless of whether systems are open or closed. Other comments suggested deÞnitions of ‘‘open system’’ that were opposite to what they suggested for a closed system. The agency has revised the deÞnition of open system to mean ‘‘an environment in which system access is not controlled by persons who are responsible for the content of electronic records that are on the system.’’ The agency believes that, for clarity, the deÞnition should stand on its own rather than as any system that is not closed. The agency rejects the suggestion that the term need not be deÞned at all because FDA believes that controls for open systems merit distinct provisions in part 11 and deÞning the term is basic to understanding which requirements apply to a given system. The agency agrees that companies have the responsibility to take steps to ensure the validity and security of their applications and information. However, FDA Þnds it necessary to establish part 11 as minimal requirements to help ensure that those steps are, in fact, acceptable.

VII. ELECTRONIC RECORDS — CONTROLS FOR CLOSED SYSTEMS (§ 11.10) The introductory paragraph of proposed § 11.10 states that: Closed systems used to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and conÞdentiality of electronic records, and to ensure that the signer cannot readily repudiate the signed record as not genuine. * * *

The rest of the section lists speciÞc procedures and controls. 57. One comment expressed full support for the list of proposed controls, calling them generally appropriate and stated that the agency is correctly accommodating the ßuid nature of various electronic record and electronic signature technologies. Another comment, however, suggested that controls should not be implemented at the time electronic records are Þrst created, but rather only after a document is accepted by a company. The agency disagrees with this suggestion. To ignore such controls at a stage before ofÞcial acceptance risks compromising the record. For example, if ‘‘preacceptance’’ records are signed by technical personnel, it is vital to ensure the integrity of their electronic signatures to prevent record alteration. The need for such integrity is no less important at preacceptance stages than at later stages when managers ofÞcially accept the records. The possibility exists that some might seek to disavow, or avoid FDA examination of, pertinent records by declaring they had not been formally ‘‘accepted.’’ In addition, FDA routinely can and does inspect evolving paper documents (e.g., standard operating procedures and validation protocols) even though they have yet to receive a Þrm’s Þnal acceptance. 58. One comment said proposed § 11.10 contained insufÞcient requirements for Þrms to conduct periodic inspection and monitoring of their own systems and Copyright © 2004 CRC Press, LLC


170


procedures to ensure compliance with the regulations. The comment also called for a clear identiÞcation of the personnel in a Þrm who would be responsible for system implementation, operation, change control, and monitoring. The agency does not believe it is necessary at this time to codify a self-auditing requirement, as suggested by the comment. Rather, the agency intends to afford organizations ßexibility in establishing their own internal mechanisms to ensure compliance with part 11. Self-audits, however, may be considered as a general control, within the context of the introductory paragraph of § 11.10. The agency encourages Þrms to conduct such audits periodically as part of an overall approach to ensure compliance with FDA regulations generally. Likewise, the agency does not believe it is necessary or practical to codify which individuals in an organization should be responsible for compliance with various provisions of part 11. However, ultimate responsibility for part 11 will generally rest with persons responsible for electronic record content, just as responsibility for compliance with paper record requirements generally lies with those responsible for the record’s content. 59. Several comments interpreted proposed § 11.10 as applying all procedures and controls to closed systems and suggested revising it to permit Þrms to apply only those procedures and controls they deem necessary for their own operations, because some requirements are excessive in some cases. The agency advises that, where a given procedure or control is not intended to apply in all cases, the language of the rule so indicates. SpeciÞcally, use of operational checks (§ 11.10(f)) and device checks (§ 11.10(h)) is not required in all cases. The remaining requirements do apply in all cases and are, in the agency’s opinion, the minimum needed to ensure the trustworthiness and reliability of electronic record systems. In addition, certain controls that Þrms deem adequate for their routine internal operations might nonetheless leave records vulnerable to manipulation and, thus, may be incompatible with FDA’s responsibility to protect public health. The suggested revision would effectively permit Þrms to implement various controls selectively and possibly shield records from FDA, employ unqualiÞed personnel, or permit employees to evade responsibility for fraudulent use of their electronic signatures. The agency believes that the controls in § 11.10 are vital, and notes that almost all of them were suggested by comments on the ANPRM. The agency believes the wording of the regulation nonetheless permits Þrms maximum ßexibility in how to meet those requirements. 60. Two comments suggested that the word ‘‘conÞdentiality’’ in the introductory paragraph of proposed § 11.10 be deleted because it is unnecessary and inappropriate. The comments stated that Þrms should determine if certain records need to be conÞdential, and that as long as records could not be altered or deleted without appropriate authority, it would not matter whether they could read the records. The agency agrees that not all records required by FDA need to be kept conÞdential within a closed system and has revised the reference in the introductory paragraph of § 11.10 to state ‘‘* * * and, when appropriate, the conÞdentiality of electronic records.’’ The agency believes, however that the need for retaining the conÞdentiality of certain records is not diminished because viewers cannot change them. It may be prudent for persons to carefully assess the need for record conÞdentiality. (See, e.g., 21 CFR 1002.42, ConÞdentiality of records furnished by dealers Copyright © 2004 CRC Press, LLC


Appendix I

171

and distributors, with respect to certain radiological health products.) In addition, FDA’s obligation to retain the conÞdentiality of information it receives in some submissions hinges on the degree to which the submitter maintains conÞdentiality, even within its own organization. (See, e.g., 21 CFR 720.8(b) with respect to cosmetic ingredient information in voluntary Þlings of cosmetic product ingredient and cosmetic raw material composition statements.) 61. One comment asked if theprocedures and controls required by proposed § 11.10 were to be built into software or if they could exist in written form. The agency expects that, by their nature, some procedures and controls, such as use of time-stamped audit trails and operational checks, will be built into hardware and software. Others, such as validation and determination of personnel qualiÞcations, may be implemented in any appropriate manner regardless of whether the mechanisms are driven by, or are external to, software or hardware. To clarify this intent, the agency has revised the introductory paragraph of proposed § 11.10 to read, in part, ‘‘Persons who use closed systems to create, modify* * *.’’ Likewise, for clarity and consistency, the agency is introducing the same phrase, ‘‘persons who use * * *’’ in §§ 11.30 and 11.300. 62. One comment contended that the distinction between open and closed systems should not be predominant because a $100,000 transaction in a closed system should not have fewer controls than a $1 transaction in an open system. The agency believes that, within part 11, Þrms have the ßexibility they need to adjust the extent and stringency of controls based on any factors they choose, including the economic value of the transaction. The agency does not believe it is necessary to modify part 11 at this time so as to add economic criteria. 63. One comment suggested that the reference to repudiation in the introductory paragraph of § 11.10 should be deleted because repudiation can occur at any time in legal proceedings. Another comment, noting that the proposed rule appeared to address only nonrepudiation of a signer, said the rule should address nonrepudiation of record ‘‘genuineness’’ or extend to nonrepudiation of submission, delivery, and receipt. The comment stated that some Þrms provide nonrepudiation services that can prevent someone from successfully claiming that a record has been altered. In response to the Þrst comment, the agency does not agree that the reference to repudiation should be deleted because reducing the likelihood that someone can readily repudiate an electronic signature as not his or her own, or that the signed record had been altered, is vital to the agency’s basic acceptance of electronic signatures. The agency is aware that the need to deter such repudiation has been addressed in many forums and publications that discuss electronic signatures. Absent adequate controls, FDA believes some people would be more likely to repudiate an electronically-signed record because of the relative ease with which electronic records may be altered and the ease with which one individual could impersonate another. The agency notes, however, that the rule does not call for nonrepudiation as an absolute guarantee, but requires that the signer cannot ‘‘readily’’ repudiate the signature. In response to the second comment, the agency agrees that it is also important to establish nonrepudiation of submission, delivery, and receipt of electronic records, but advises that, for purposes of § 11.10, the agency’s intent is to limit nonrepudiation Copyright © 2004 CRC Press, LLC


172


to the genuineness of the signer’s record. In other words, an individual should not be able to readily say that: (1) He or she did not, in fact, sign the record; (2) a given electronic record containing the individual’s signature was not, in fact, the record that the person signed; or (3) the originally signed electronic record had been altered after having been signed. 64. Proposed § 11.10(a) states that controls for closed systems are to include the validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to conclusively discern invalid or altered records. Many comments objected to this proposed requirement because the word ‘‘conclusively’’ inferred an unreasonably high and unattainable standard, one which is not applied to paper records. The agency intends to apply the same validation concepts and standards to electronic record and electronic signature systems as it does to paper systems. As such, FDA does not intend the word ‘‘conclusively’’ to suggest an unattainable absolute and has, therefore, deleted the word from the Þnal rule. 65. One comment suggested qualifying the proposed validation requirement in § 11.10(a) to state that validation be performed ‘‘where necessary’’ and argued that validation of commercially available software is not necessary because such software has already been thoroughly validated. The comment acknowledged that validation may be required for application programs written by manufacturers and others for special needs. The agency disagrees with the comment’s claim that all commercial software has been validated. The agency believes that commercial availability is no guarantee that software has undergone ‘‘thorough validation’’ and is unaware of any regulatory entity that has jurisdiction over general purpose software producers. The agency notes that, in general, commercial software packages are accompanied not by statements of suitability or compliance with established standards, but rather by disclaimers as to their Þtness for use. The agency is aware of the complex and sometimes controversial issues in validating commercial software. However, the need to validate such software is not diminished by the fact that it was not written by those who will use the software. In the future, the agency may provide guidance on validation of commercial software used in electronic record systems. FDA has addressed the matter of software validation in general in such documents as the ‘‘Draft Guideline for the Validation of Blood Establishment Computer Systems,’’ which is available from the Manufacturers Assistance and Communications Staff, Center for Biologics Evaluation and Research (HFM–42), Food and Drug Administration, 1401 Rockville Pike, Rockville, MD 20852–1448, 301–594–2000. This guideline is also available by sending e-mail to the following Internet address: [email protected]). For the purposes of part 11, however, the agency believes it is vital to retain the validation requirement. 66. One comment requested an explanation of what was meant by the phrase ‘‘consistent intended’’ in proposed § 11.10(a) and why ‘‘consistent performance’’ was not used instead. The comment suggested that the rule should distinguish consistent intended performance from well-recognized service ‘‘availability.’’ The agency advises that the phrase ‘‘consistent intended performance’’ relates to the general principle of validation that planned and expected performance is based Copyright © 2004 CRC Press, LLC


Appendix I

173

upon predetermined design speciÞcations (hence, ‘‘intended’’). This concept is in accord with the agency’s 1987 ‘‘Guideline on General Principles of Process Validation,’’ which is available from the Division of Manufacturing and Product Quality, Center for Drug Evaluation and Research (HFD–320), Food and Drug Administration, 7520 Standish Pl., Rockville, MD 20855, 301– 594–0093). This guideline deÞnes validation as establishing documented evidence that provides a high degree of assurance that a speciÞc process will consistently produce a product meeting its predetermined speciÞcations and quality attributes. The agency believes that the comment’s concepts are accommodated by this deÞnition to the extent that system ‘‘availability’’ may be one of the predetermined speciÞcations or quality attributes. 67. One comment said the rule should indicate whether validation of systems does, or should, require any certiÞcation or accreditation. The agency believes that although certiÞcation or accreditation may be a part of validation of some systems, such certiÞcation or accreditation is not necessary in all cases, outside of the context of any such approvals within an organization itself. Therefore, part 11 is silent on the matter. 68. One comment said the rule should clarify whether system validation should be capable of discerning the absence of electronic records, in light of agency concerns about falsiÞcation. The comment added that the agency’s concerns regarding invalid or altered records can be mitigated by use of cryptographically enhanced methods, including secure time and date stamping. The agency does not believe that it is necessary at this time to include an explicit requirement that systems be capable of detecting the absence of records. The agency advises that the requirement in § 11.10(e) for audit trails of operator actions would cover those actions intended to delete records. Thus, the agency would expect Þrms to document such deletions, and would expect the audit trail mechanisms to be included in the validation of the electronic records system. 69. Proposed § 11.10(b) states that controls for closed systems must include the ability to generate true copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency, and that if there were any questions regarding the ability of the agency to perform such review and copying, persons should contact the agency. Several comments objected to the requirement for ‘‘true’’ copies of electronic records. The comments asserted that information in an original record (as may be contained in a database) may be presented in a copy in a different format that may be more usable. The comments concluded that, to generate precise ‘‘true’’ copies of electronic records, Þrms may have to retain the hardware and software that had been used to create those records in the Þrst place (even when such hardware and software had been replaced by newer systems). The comments pointed out that Þrms may have to provide FDA with the application logic for ‘‘true’’ copies, and that this may violate copyright provisions. One comment illustrated the difference between ‘‘true’’ copies and other equally reliable, but not exact, copies of electronic records by noting that pages from FDA’s paper publications (such as the CFR and the Compliance Policy Guidance Manual) look quite different from electronic copies posted to FDA’s bulletin board. The comments suggested different wording that would effectively require accurate and complete copies, but not necessarily ‘‘true’’ copies. Copyright © 2004 CRC Press, LLC


174


The agency agrees that providing exact copies of electronic records in the strictest meaning of the word ‘‘true’’ may not always be feasible. The agency nonetheless believes it is vital that copies of electronic records provided to FDA be accurate and complete. Accordingly, in § 11.10(b), ‘‘true’’ has been replaced with ‘‘accurate and complete.’’ The agency expects that this revision should obviate the potential problems noted in the comments. The revision should also reduce the costs of providing copies by making clear that Þrms need not maintain obsolete equipment in order to make copies that are ‘‘true’’ with respect to format and computer system. 70. Many comments objected to the proposed requirement that systems be capable of generating electronic copies of electronic records for FDA inspection and copying, although they generally agreed that it was appropriate to provide FDA with readable paper copies. Alternative wording was suggested that would make providing electronic copies optional, such that persons could provide FDA with nothing but paper copies if they so wished. The comments argued that providing FDA with electronic copies was unnecessary, unjustiÞed, not practical considering the different types of computer systems that may be in use, and would unfairly limit Þrms in their selection of hardware and software if they could only use systems that matched FDA’s capabilities (capabilities which, it was argued, would not be uniform throughout the United States). One comment suggested that the rule specify a particular format, such as ASCII, for electronic copies to FDA. The agency disagrees with the assertion that FDA need only be provided with paper copies of electronic records. To operate effectively, the agency must function on the same technological plane as the industries it regulates. Just as Þrms realize efÞciencies and beneÞts in the use of electronic records, FDA should be able to conduct audits efÞciently and thoroughly using the same technology. For example, where Þrms perform computerized trend analyses of electronic records to improve their processes, FDA should be able to use computerized methods to audit electronic records (on site and off, as necessary) to detect trends, inconsistencies, and potential problem areas. If FDA is restricted to reviewing only paper copies of those records, the results would severely impede its operations. Inspections would take longer to complete, resulting in delays in approvals of new medical products, and expenditure of additional resources both by FDA (in performing the inspections and transcribing paper records to electronic format) and by the inspected Þrms, which would generate the paper copies and respond to questions during the resulting lengthened inspections. The agency believes that it also may be necessary to require that persons furnish certain electronic copies of electronic records to FDA because paper copies may not be accurate and complete if they lack certain audit trail (metadata) information. Such information may have a direct bearing on record trustworthiness and reliability. These data could include information, for example, on when certain items of electronic mail were sent and received. The agency notes that people who use different computer systems routinely provide each other with electronic copies of electronic records, and there are many current and developing tools to enable such sharing. For example, at a basic level, records may be created in, or transferred to, the ASCII format. Many different commercial programs have the capability to import from, and export to, electronic records having different formats. Firms use electronic data interchange (commonly Copyright © 2004 CRC Press, LLC


Appendix I

175

known as EDI) and agreed upon transaction set formats to enable them to exchange copies of electronic records effectively. Third parties are also developing portable document formats to enable conversion among several diverse formats. Concerning the ability of FDA to handle different formats of electronic records, based upon the emergence of format conversion tools such as those mentioned above, the agency’s experience with electronic submissions such as computer assisted new drug applications (commonly known as CANDA’s), and the agency’s planned Submissions Management and Review Tracking System (commonly known as SMART), FDA is conÞdent that it can work with Þrms to minimize any formatting difÞculties. In addition, substitution of the words ‘‘accurate and complete’’ for ‘‘true,’’ as discussed in comment 69, should make it easier for Þrms to provide FDA with electronic copies of their electronic records. FDA does not believe it is necessary to specify any particular format in part 11 because it prefers, at this time, to afford industry and the agency more ßexibility in deciding which formats meet the capabilities of all parties. Accordingly, the agency has revised proposed § 11.10(b) to read: The ability to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency. Persons should contact the agency if there are any questions regarding the ability of the agency to perform such review and copying of the electronic records.

71. Proposed § 11.10(c) states that procedures and controls for closed systems must include the protection of records to enable their accurate and ready retrieval throughout the records retention period. One Þrm commented that, because it replaces systems often (about every 3 years), it may have to retain supplanted systems to meet these requirements. Another comment suggested that the rule be modiÞed to require records retention only for as long as ‘‘legally mandated.’’ The agency notes that, as discussed in comment 70 of this document, persons would not necessarily have to retain supplanted hardware and software systems provided they implemented conversion capabilities when switching to replacement technologies. The agency does not believe it is necessary to add the qualiÞer ‘‘legally mandated’’ because the retention period for a given record will generally be established by the regulation that requires the record. Where the regulations do not specify a given time, the agency would expect Þrms to establish their own retention periods. Regardless of the basis for the retention period, FDA believes that the requirement that a given electronic record be protected to permit it to be accurately and readily retrieved for as long as it is kept is reasonable and necessary. 72. Proposed § 11.10(e) would require the use of time-stamped audit trails to document record changes, all write-to-Þle operations, and to independently record the date and time of operator entries and actions. Record changes must not obscure previously recorded information and such audit trail documentation must be retained for a period at least as long as required for the subject electronic documents and must be available for agency review and copying. Many comments objected to the proposed requirement that all write-to-Þle operations be documented in the audit trail because it is unnecessary to document Copyright © 2004 CRC Press, LLC


176


all such operations. The comments said that this would require audit trails for such automated recordings as those made to internal buffers, data swap Þles, or temporary Þles created by word processing programs. The comments suggested revising § 11.10(e) to require audit trails only for operator entries and actions. Other comments suggested that audit trails should cover: (1) Operator data inputs but not actions, (2) only operator changes to records, (3) only critical write-to-Þle information, (4) operator changes as well as all actions, (5) only new entries, (6) only systems where data can be altered, (7) only information recorded by humans, (8) information recorded by both humans and devices, and (9) only entries made upon adoption of the records as ofÞcial. One comment said audit trails should not be required for data acquisition systems, while another comment said audit trails are critical for data acquisition systems. It is the agency’s intent that the audit trail provide a record of essentially who did what, wrote what, and when. The write-to-Þle operations referenced in the proposed rule were not intended to cover the kind of ‘‘background’’ nonhuman recordings the comments identiÞed. The agency considers such operator actions as activating a manufacturing sequence or turning off an alarm to warrant the same audit trail coverage as operator data entries in order to document a thorough history of events and those responsible for such events. Although FDA acknowledges that not every operator ‘‘action,’’ such as switching among screen displays, need be covered by audit trails, the agency is concerned that revising the rule to cover only ‘‘critical’’ operations would result in excluding much information and actions that are necessary to document events thoroughly. The agency believes that, in general, the kinds of operator actions that need to be covered by an audit trail are those important enough to memorialize in the electronic record itself. These are actions which, for the most part, would be recorded in corresponding paper records according to existing recordkeeping requirements. The agency intends that the audit trail capture operator actions (e.g., a command to open a valve) at the time they occur, and operator information (e.g., data entry) at the time the information is saved to the recording media (such as disk or tape), in much the same manner as such actions and information are memorialized on paper. The audit trail need not capture every keystroke and mistake that is held in a temporary buffer before those commitments. For example, where an operator records the lot number of an ingredient by typing the lot number, followed by the ‘‘return key’’ (where pressing the return key would cause the information to be saved to a disk Þle), the audit trail need not record every ‘‘backspace delete’’ key the operator may have previously pressed to correct a typing error. Subsequent ‘‘saved’’ corrections made after such a commitment, however, must be part of the audit trail. At this time, the agency’s primary concern relates to the integrity of human actions. Should the agency’s experience with part 11 demonstrate a need to require audit trails of device operations and entries, the agency will propose appropriate revisions to these regulations. Accordingly, the agency has revised proposed § 11.10(e) by removing reference to all write-to-Þle operations and clarifying that the audit trail is to cover operator entries and actions that create, modify, or delete electronic records.



Appendix I

177

73. A number of comments questioned whether proposed § 11.10(e) mandated that the audit trail be part of the electronic record itself or be kept as a separate record. Some comments interpreted the word ‘‘independently’’ as requiring a separate record. Several comments focused on the question of whether audit trails should be generated manually under operator control or automatically without operator control. One comment suggested a revision that would require audit trails to be generated by computer, because the system, not the operator, should record the audit trail. Other comments said the rule should facilitate date and time recording by software, not operators, and that the qualiÞer ‘‘securely’’ be added to the language describing the audit trail. One comment, noting that audit trails require validation and qualiÞcation to ensure that time stamps are accurate and independent, suggested that audit trails be required only when operator actions are witnessed. The agency advises that audit trail information may be contained as part of the electronic record itself or as a separate record. FDA does not intend to require one method over the other. The word ‘‘independently’’ is intended to require that the audit trail not be under the control of the operator and, to prevent ready alteration, that it be created independently of the operator. To maintain audit trail integrity, the agency believes it is vital that the audit trail be created by the computer system independently of operators. The agency believes it would defeat the purpose of audit trails to permit operators to write or change them. The agency believes that, at this time, the source of such independent audit trails may effectively be within the organization that creates the electronic record. However, the agency is aware of a situation under which time and date stamps are provided by trusted third parties outside of the creating organization. These third parties provide, in effect, a public electronic notary service. FDA will monitor development of such services in light of part 11 to determine if a requirement for such third party services should be included in these regulations. For now, the agency considers the advent of such services as recognition of the need for strict objectivity in recording time and date stamps. The agency disagrees with the premise that only witnessed operator actions need be covered by audit trails because the opportunities for record falsiÞcation are not limited to cases where operator actions are witnessed. Also, the need for validating audit trails does not diminish the need for their implementation. FDA agrees with the suggestion that the proposed rule be revised to require a secure audit trail — a concept inherent in having such a control at all. Accordingly, proposed § 11.10(e) has been revised to require use of ‘‘secure, computer-generated’’ audit trails. 74. A few comments objected to the requirement that time be recorded, in addition to dates, and suggested that time be recorded only when necessary and feasible. Other comments speciÞcally supported the requirement for recording time, noting that time stamps make electronic signatures less vulnerable to fraud and abuse. The comments noted that, in any setting, there is a need to identify the date, time, and person responsible for adding to or changing a value. One of the comments suggested that the rule require recording the reason for making changes to electronic records. Other comments implicitly supported recording time.



178


FDA believes that recording time is a critical element in documenting a sequence of events. Within a given day a number of events and operator actions may take place, and without recording time, documentation of those events would be incomplete. For example, without time stamps, it may be nearly impossible to determine such important sequencing as document approvals and revisions and the addition of ingredients in drug production. Thus, the element of time becomes vital to establishing an electronic record’s trustworthiness and reliability. The agency notes that comments on the ANPRM frequently identiÞed use of date/time stamps as an important system control. Time recording, in the agency’s view, can also be an effective deterrent to records falsiÞcation. For example, event sequence codes alone would not necessarily document true time in a series of events, making falsiÞcation of that sequence easier if time stamps are not used. The agency believes it should be very easy for Þrms to implement time stamps because there is a clock in every computer and document management software, electronic mail systems and other electronic record/electronic applications, such as digital signature programs, commonly apply date and time stamps. The agency does not intend that new technologies, such as cryptographic technologies, will be needed to comply with this requirement. The agency believes that implementation of time stamps should be feasible in virtually all computer systems because effective computer operations depend upon internal clock or timing mechanisms and, in the agency’s experience, most computer systems are capable of precisely recording such time entries as when records are saved. The agency is implementing the time stamp requirement based on the understanding that all current computers, electronic document software, electronic mail, and related electronic record systems include such technologies. The agency also understands that time stamps are applied automatically by these systems, meaning Þrms would not have to install additional hardware, software, or incur additional burden to implement this control. In recognition of this, the agency wishes to clarify that a primary intent of this provision is to ensure that people take reasonable measures to ensure that those built in time stamps are accurate and that people do not alter them casually so as to readily mask unauthorized record changes. The agency advises that, although part 11 does not specify the time units (e.g., tenth of a second, or even the second) to be used, the agency expects the unit of time to be meaningful in terms of documenting human actions. The agency does not believe part 11 needs to require recording the reason for record changes because such a requirement, when needed, is already in place in existing regulations that pertain to the records themselves. 75. One comment stated that proposed § 11.10(e) should not require an electronic signature for each write-to-Þle operation. The agency advises that § 11.10(e) does not require an electronic signature as the means of authenticating each write-to-Þle operation. The agency expects the audit trail to document who did what and when, documentation that can be recorded without electronic signatures themselves. 76. Several comments, addressing the proposed requirement that record changes not obscure previously recorded information, suggested revising proposed § 11.10(e) to apply only to those entries intended to update previous information. Copyright © 2004 CRC Press, LLC


Appendix I

179

The agency disagrees with the suggested revision because the rewording is too narrow. The agency believes that some record changes may not be ‘‘updates’’ but signiÞcant modiÞcations or falsiÞcations disguised as updates. All changes to existing records need to be documented, regardless of the reason, to maintain a complete and accurate history, to document individual responsibility, and to enable detection of record falsiÞcations. 77. Several comments suggestedreplacing the word ‘‘document’’ with ‘‘record’’ in the phrase ‘‘Such audit trails shall be retained for a period at least as long as required for the subject electronic documents * * *’’ because not all electronic documents are electronic records and because the word document connotes paper. As discussed in section III.D. of this document, the agency equates electronic documents with electronic records, but for consistency, has changed the phrase to read ‘‘Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records * * *.’’ 78. Proposed §11.10(k)(ii) (§ 11.10(k)(2) in this regulation) addresses electronic audit trails as a systems documentation control. One comment noted that this provision appears to be the same as the audit trail provision of proposed § 11.10(e) and requested clariÞcation. The agency wishes to clarify that the kinds of records subject to audit trails in the two provisions cited by the comment are different. Section 11.10(e) pertains to those records that are required by existing regulations whereas § 11.10(k)(2) covers the system documentation records regarding overall controls (such as access privilege logs, or system operational speciÞcation diagrams). Accordingly, the Þrst sentence of § 11.10(e) has been revised to read ‘‘Use of secure, computer-generated, time-stamped audit trails to independently record and date the time of operator entries and actions that create, modify, or delete electronic records.’’ 79. Proposed § 11.10(f) states that procedures and controls for closed systems must include the use of operational checks to enforce permitted sequencing of events, as appropriate. Two comments requested clariÞcation of the agency’s intent regarding operational checks. The agency advises that the purpose of performing operational checks is to ensure that operations (such as manufacturing production steps and signings to indicate initiation or completion of those steps) are not executed outside of the predeÞned order established by the operating organization. 80. Several comments suggested that, for clarity, the phrase ‘‘operational checks’’ be modiÞed to ‘‘operational system checks.’’ The agency agrees that the added modiÞer ‘‘system’’ more accurately reßects the agency’s intent that operational checks be performed by the computer systems and has revised proposed § 11.10(f) accordingly. 81. Several comments suggested revising proposed § 11.10(f) to clarify what is to be checked. The comments suggested that ‘‘steps’’ in addition to ‘‘events’’ be checked, only critical steps be checked, and that ‘‘records’’ also be checked. The agency intends the word ‘‘event’’ to include ‘‘steps’’ such as production steps. For clarity, however, the agency has revised proposed § 11.10(f) by adding the word ‘‘steps.’’ The agency does not, however, agree that only critical steps need Copyright © 2004 CRC Press, LLC


180


be subject to operational checks because a given speciÞc step or event may not be critical, yet it may be very important that the step be executed at the proper time relative to other steps or events. The agency does not believe it necessary to add the modiÞer ‘‘records’’ to proposed § 11.10(f) because creation, deletion, or modiÞcation of a record is an event. Should it be necessary to create, delete, or modify records in a particular sequence, operational system checks would ensure that the proper sequence is followed. 82. Proposed § 11.10(g) states that procedures and controls for closed systems must include the use of authority checks to ensure that only authorized individuals use the system, electronically sign a record, access the operation or device, alter a record, or perform the operation at hand. One comment suggested that the requirement for authority checks be qualiÞed with the phrase ‘‘as appropriate,’’ on the basis that it would not be necessary for certain parts of a system, such as those not affecting an electronic record. The comment cited pushing an emergency stop button as an example of an event that would not require an authority check. Another comment suggested deleting the requirement on the basis that some records can be read by all employees in an organization. The agency advises that authority checks, and other controls under § 11.10, are intended to ensure the authenticity, integrity, and conÞdentiality of electronic records, and to ensure that signers cannot readily repudiate a signed record as not genuine. Functions outside of this context, such as pressing an emergency stop button, would not be covered. However, even in this example, the agency Þnds it doubtful that a Þrm would permit anyone, such as a stranger from outside the organization, to enter a facility and press the stop button at will regardless of the existence of an emergency. Thus, there would likely be some generalized authority checks built into the Þrm’s operations. The agency believes that few organizations freely permit anyone from within or without the operation to use their computer system, electronically sign a record, access workstations, alter records, or perform operations. It is likely that authority checks shape the activities of almost every organization. The nature, scope, and mechanism of performing such checks is up to the operating organization. FDA believes, however, that performing such checks is one of the most fundamental measures to ensure the integrity and trustworthiness of electronic records. Proposed § 11.10(g) does not preclude all employees from being permitted to read certain electronic records. However, the fact that some records may be read by all employees would not justify deleting the requirement for authority checks entirely. The agency believes it is highly unlikely that all of a Þrm’s employees would have authority to read, write, and sign all of its electronic records. 83. One comment said authority checks are appropriate for document access but not system access, and suggested that the phrase ‘‘access the operation or device’’ be deleted. The comment added, with respect to authority checks on signing records, that in many organizations, more than one individual has the authority to sign documents required under FDA regulations and that such authority should be vested with the individual as designated by the operating organization. Another comment said proposed § 11.10(g) should explicitly require access authority Copyright © 2004 CRC Press, LLC


Appendix I

181

checks and suggested that the phrase ‘‘use the system’’ be changed to ‘‘access and use the system.’’ The comment also asked for clariÞcation of the term ‘‘device.’’ The agency disagrees that authority checks should not be required for system access because, as discussed in comment 82 of this document, it is unlikely that a Þrm would permit any unauthorized individuals to access its computer systems. System access control is a basic security function because system integrity may be impeached even if the electronic records themselves are not directly accessed. For example, someone could access a system and change password requirements or otherwise override important security measures, enabling individuals to alter electronic records or read information that they were not authorized to see. The agency does not believe it necessary to add the qualiÞer ‘‘access and’’ because § 11.10(d) already requires that system access be limited to authorized individuals. The agency intends the word ‘‘device’’ to mean a computer system input or output device and has revised proposed § 11.10(g) to clarify this point. Concerning signature authority, FDA advises that the requirement for authority checks in no way limits organizations in authorizing individuals to sign multiple records. Firms may use any appropriate mechanism to implement such checks. Organizations do not have to embed a list of authorized signers in every record to perform authority checks. For example, a record may be linked to an authority code that identiÞes the title or organizational unit of people who may sign the record. Thus, employees who have that corresponding code, or belong to that unit, would be able to sign the record. Another way to implement controls would be to link a list of authorized records to a given individual, so that the system would permit the individual to sign only records in that list. 84. Two comments addressed authority checks within the context of PDMA and suggested that such checks not be required for drug sample receipt records. The comments said that different individuals may be authorized to accept drug samples at a physician’s ofÞce, and that the large number of physicians who would potentially qualify to receive samples would be too great to institute authority checks. The agency advises that authority checks need not be automated and that in the context of PDMA such checks would be as valid for electronic records as they are for paper sample requests because only licensed practitioners or their designees may accept delivery of drug samples. The agency, therefore, acknowledges that many individuals may legally accept samples and, thus, have the authority to sign electronic receipts. However, authority checks for electronic receipts could nonetheless be performed by sample manufacturer representatives by using the same procedures as the representatives use for paper receipts. Accordingly, the agency disagrees with the comment that proposed § 11.10(g) should not apply to PDMA sample receipts. The agency also advises that under PDMA, authority checks would be particularly important in the case of drug sample request records because only licensed practitioners may request drug samples. Accordingly, proposed § 11.10(g) has been revised to read: ‘‘Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand.’’ Copyright © 2004 CRC Press, LLC


182


85. Proposed § 11.10(h) states that procedures and controls for closed systems must include the use of device (e.g., terminal) location checks to determine, as appropriate, the validity of the source of data input or operational instruction. Several comments objected to this proposed requirement and suggested its deletion because it is: (1) Unnecessary (because the data source is always known by virtue of system design and validation); (2) problematic with respect to mobile devices, such as those connected by modem; (3) too much of a ‘‘how to;’’ (4) not explicit enough to tell Þrms what to do; (5) unnecessary in the case of PDMA; and (6) technically challenging. One comment stated that a device’s identiÞcation, in addition to location, may be important and suggested that the proposed rule be revised to require device identiÞcation as well. FDA advises that, by use of the term ‘‘as appropriate,’’ it does not intend to require device checks in all cases. The agency believes that these checks are warranted where only certain devices have been selected as legitimate sources of data input or commands. In such cases, the device checks would be used to determine if the data or command source was authorized. In a network, for example, it may be necessary for security reasons to limit issuance of critical commands to only one authorized workstation. The device check would typically interrogate the source of the command to ensure that only the authorized workstation, and not some other device, was, in fact, issuing the command. The same approach applies for remote sources connected by modem, to the extent that device identity interrogations could be made automatically regardless of where the portable devices were located. To clarify this concept, the agency has removed the word ‘‘location’’ from proposed § 11.10(h). Device checks would be necessary under PDMA when the source of commands or data is relevant to establishing authenticity, such as when licensed practitioners order drug samples directly from the manufacturer or authorized distributor without the intermediary of a sales representative. Device checks may also be useful to Þrms in documenting and identifying which sales representatives are transmitting drug sample requests from licensed practitioners. FDA believes that, although validation may demonstrate that a given terminal or workstation is technically capable of sending information from one point to another, validation alone would not be expected to address whether or not such device is authorized to do so. 86. Proposed § 11.10(i) states that procedures and controls for closed systems must include conÞrmation that persons who develop, maintain, or use electronic record or signature systems have the education, training, and experience to perform their assigned tasks. Several comments objected to the word ‘‘conÞrmation’’ because it is redundant with, or more restrictive than, existing regulations, and suggested alternate wording, such as ‘‘evidence.’’ Two comments interpreted the proposed wording as requiring that checks of personnel qualiÞcations be performed automatically by computer systems that perform database type matches between functions and personnel training records. The agency advises that, although there may be some overlap in proposed § 11.10(i) and other regulations regarding the need for personnel to be properly qualiÞed for Copyright © 2004 CRC Press, LLC


Appendix I

183

their duties, part 11 is speciÞc to functions regarding electronic records, an issue that other regulations may or may not adequately address. Therefore, the agency is retaining the requirement. The agency does not intend to require that the check of personnel qualiÞcations be performed automatically by a computer system itself (although such automation is desirable). The agency has revised the introductory paragraph of § 11.10, as discussed in section VII. of this document, to clarify this point. The agency agrees that another word should be used in place of ‘‘conÞrmation,’’ and for clarity has selected ‘‘determination.’’ 87. One comment suggested that the word ‘‘training’’ be deleted because it has the same meaning as ‘‘education’’ and ‘‘experience,’’ and objected to the implied requirement for records of employee training. Another comment argued that applying this provision to system developers was irrelevant so long as systems perform as required and have been appropriately validated. The comment suggested revising proposed § 11.10(i) to require employees to be trained only ‘‘as necessary.’’ One comment, noting that training and experience are very important, suggested expanding proposed § 11.10(i) to require appropriate examination and certiÞcation of persons who perform certain high-risk, high-trust functions and tasks. The agency regards this requirement as fundamental to the proper operation of a facility. Personnel entrusted with important functions must have sufÞcient training to do their jobs. In FDA’s view, formal education (e.g., academic studies) and general industry experience would not necessarily prepare someone to begin speciÞc, highly technical tasks at a given Þrm. Some degree of on-the-job training would be customary and expected. The agency believes that documentation of such training is also customary and not unreasonable. The agency also disagrees with the assertion that personnel qualiÞcations of system developers are irrelevant. The qualiÞcations of personnel who develop systems are relevant to the expected performance of the systems they build and their ability to explain and support these systems. Validation does not lessen the need for personnel to have the education, training, and experience to do their jobs properly. Indeed, it is highly unlikely that poorly qualiÞed developers would be capable of producing a system that could be validated. The agency advises that, although the intent of proposed § 11.10(i) is to address qualiÞcations of those personnel who develop systems within an organization, rather than external ‘‘vendors’’ per se, it is nonetheless vital that vendor personnel are likewise qualiÞed to do their work. The agency agrees that periodic examination or certiÞcation of personnel who perform certain critical tasks is desirable. However, the agency does not believe that at this time a speciÞc requirement for such examination and certiÞcation is necessary. 88. Proposed § 11.10(j) states that procedures and controls for closed systems must include the establishment of, and adherence to, written policies that hold individuals accountable and liable for actions initiated under their electronic signatures, so as to deter record and signature falsiÞcation. Several comments suggested changing the word ‘‘liable’’ to ‘‘responsible’’ because the word ‘‘responsible’’ is broader, more widely understood by employees, more positive and inclusive of elements of honesty and trust, and more supportive of a broad range of disciplinary measures. One comment argued that the requirement Copyright © 2004 CRC Press, LLC


184


would not deter record or signature falsiÞcation because employee honesty and integrity cannot be regulated. The agency agrees because, although the words ‘‘responsible’’ and ‘‘liable’’ are generally synonymous, ‘‘responsible’’ is preferable because it is more positive and supportive of a broad range of disciplinary measures. There may be a general perception that electronic records and electronic signatures (particularly identiÞcation codes and passwords) are less signiÞcant and formal than traditional paper records and handwritten signatures. Individuals may therefore not fully equate the seriousness of electronic record falsiÞcation with paper record falsiÞcation. Employees need to understand the gravity and consequences of signature or record falsiÞcation. Although FDA agrees that employee honesty cannot be ensured by requiring it in a regulation, the presence of strong accountability and responsibility policies is necessary to ensure that employees understand the importance of maintaining the integrity of electronic records and signatures. 89. Several comments expressed concern regarding employee liability for actions taken under their electronic signatures in the event that such signatures are compromised, and requested ‘‘reasonable exceptions.’’ The comments suggested revising proposed § 11.10(j) to hold people accountable only where there has been intentional falsiÞcation or corruption of electronic data. The agency considers the compromise of electronic signatures to be a very serious matter, one that should precipitate an appropriate investigation into any causative weaknesses in an organization’s security controls. The agency nonetheless recognizes that where such compromises occur through no fault or knowledge of individual employees, there would be reasonable limits on the extent to which disciplinary action would be taken. However, to maintain emphasis on the seriousness of such security breeches and deter the deliberate fabrication of ‘‘mistakes,’’ the agency believes § 11.10 should not provide for exceptions that may lessen the import of such a fabrication. 90. One comment said the agency should consider the need for criminal law reform because current computer crime laws do not address signatures when unauthorized access or computer use is not an issue. Another comment argued that proposed § 11.10(j) should be expanded beyond ‘‘individual’’ accountability to include business entities. The agency will consider the need for recommending legislative initiatives to address electronic signature falsiÞcation in light of the experience it gains with this regulation. The agency does not believe it necessary to address business entity accountability speciÞcally in § 11.10 because the emphasis is on actions and accountability of individuals, and because individuals, rather than business entities, apply signatures. 91. One comment suggested that proposed § 11.10(j) should be deleted because it is unnecessary because individuals are presumably held accountable for actions taken under their authority, and because, in some organizations, individuals frequently delegate authority to sign their names. As discussed in comments 88 to 90 of this document, the agency has concluded that this section is necessary. Furthermore it does not limit delegation of authority as described in the comment. However, where one individual signs his or her name Copyright © 2004 CRC Press, LLC


Appendix I

185

on behalf of someone else, the signature applied should be that of the delegatee, with some notation of that fact, and not the name of the delegator. This is the same procedure commonly used on paper documents, noted as ‘‘X for Y.’’ 92. Proposed § 11.10(k) states that procedures and controls for closed systems must include the use of appropriate systems documentation controls, including: (1) Adequate controls over the distribution, access to, and use of documentation for system operation and maintenance; and (2) records revision and change control procedures to maintain an electronic audit trail that documents time-sequenced development and modiÞcation of records. Several comments requested clariÞcation of the type of documents covered by proposed § 11.10(k). One comment noted that this section failed to address controls for record retention. Some comments suggested limiting the scope of systems documentation to application and conÞgurable software, or only to software that could compromise system security or integrity. Other comments suggested that this section should be deleted because some documentation needs wide distribution within an organization, and that it is an onerous burden to control user manuals. The agency advises that § 11.10(k) is intended to apply to systems documentation, namely, records describing how a system operates and is maintained, including standard operating procedures. The agency believes that adequate controls over such documentation are necessary for various reasons. For example, it is important for employees to have correct and updated versions of standard operating and maintenance procedures. If this documentation is not current, errors in procedures and/or maintenance are more likely to occur. Part 11 does not limit an organization’s discretion as to how widely or narrowly any document is to be distributed, and FDA expects that certain documents will, in fact, be widely disseminated. However, some highly sensitive documentation, such as instructions on how to modify system security features, would not routinely be widely distributed. Hence, it is important to control distribution of, access to, and use of such documentation. Although the agency agrees that the most critical types of system documents would be those directly affecting system security and integrity, FDA does not agree that control over system documentation should only extend to security related software or to application or conÞgurable software. Documentation that relates to operating systems, for example, may also have an impact on security and day-to-day operations. The agency does not agree that it is an onerous burden to control documentation that relates to effective operation and security of electronic records systems. Failure to control such documentation, as discussed above, could permit and foster records falsiÞcation by making the enabling instructions for these acts readily available to any individual. 93. Concerning the proposed requirement for adequate controls over documentation for system operation and maintenance, one comment suggested that it be deleted because it is under the control of system vendors, rather than operating organizations. Several comments suggested that the proposed provision be deleted because it duplicates § 11.10(e) with respect to audit trails. Some comments also objected to maintaining the change control procedures in electronic form and suggested deleting the word ‘‘electronic’’ from ‘‘electronic audit trails.’’ Copyright © 2004 CRC Press, LLC


186


The agency advises that this section is intended to apply to systems documentation that can be changed by individuals within an organization. If systems documentation can only be changed by a vendor, this provision does not apply to the vendor’s customers. The agency acknowledges that systems documentation may be in paper or electronic form. Where the documentation is in paper form, an audit trail of revisions need not be in electronic form. Where systems documentation is in electronic form, however, the agency intends to require the audit trail also be in electronic form, in accordance with § 11.10(e). The agency acknowledges that, in light of the comments, the proposed rule may not have been clear enough regarding audit trails addressed in § 11.10(k) compared to audit trails addressed in § 11.10(e) and has revised the Þnal rule to clarify this matter. The agency does not agree, however, that the audit trail provisions of § 11.10(e) and (k), as revised, are entirely duplicative. Section 11.10(e) applies to electronic records in general (including systems documentation); § 11.10(k) applies exclusively to systems documentation, regardless of whether such documentation is in paper or electronic form. As revised, § 11.10(k) now reads as follows: (k) Use of appropriate controls oversystems documentation including: (1) Adequate controls over the distributionof, access to, and use of documentation for system operation and maintenance. (2) Revision and change control proceduresto maintain an audit trail that documents time-sequenced development and modiÞcation of systems documentation.

VIII. ELECTRONIC RECORDS — CONTROLS FOR OPEN SYSTEMS (§ 11.30) Proposed § 11.30 states that: ‘‘Open systems used to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity and conÞdentiality of electronic records from the point of their creation to the point of their receipt.’’ In addition, § 11.30 states: * * * Such procedures and controls shall include those identiÞed in § 11.10, as appropriate, and such additional measures as document encryption and use of established digital signature standards acceptable to the agency, to ensure, as necessary under the circumstances, record authenticity, integrity, and conÞdentiality.

94. One comment suggested that the reference to digital signature standards be deleted because the agency should not be setting standards and should not dictate how to ensure record authenticity, integrity, and conÞdentiality. Other comments requested clariÞcation of the agency’s expectations with regard to digital signatures: (1) The kinds that would be acceptable, (2) the mechanism for announcing which standards were acceptable (and whether that meant FDA would be certifying particular software), and (3) a deÞnition of digital signature. One comment asserted that FDA should accept international standards for digital signatures. Some comCopyright © 2004 CRC Press, LLC


Appendix I

187

ments also requested a deÞnition of encryption. One comment encouraged the agency to further deÞne open systems. The agency advises that § 11.30 requires additional controls, beyond those identiÞed in § 11.10, as needed under the circumstances, to ensure record authenticity, integrity, and conÞdentiality for open systems. Use of digital signatures is one measure that may be used, but is not speciÞcally required. The agency wants to ensure that the digital signature standard used is, in fact, appropriate. Development of digital signature standards is a complex undertaking, one FDA does not expect to be performed by individual Þrms on an ad hoc basis, and one FDA does not now seek to perform. The agency is nonetheless concerned that such standards be robust and secure. Currently, the agency is aware of two such standards, the RSA (Rivest-ShamirAdleman), and NIST’s Digital Signature Standard (DSS). The DSS became Federal Information Processing Standard (FIPS) 186 on December 1, 1994. These standards are incorporated in different software programs. The agency does not seek to certify or otherwise approve of such programs, but expects people who use such programs to ensure that they are suitable for their intended use. FDA is aware that NIST provides certiÞcations regarding mathematical conformance to the DSS core algorithms, but does not formally evaluate the broader programs that contain those algorithms. The agency has revised the Þnal rule to clarify its intent that Þrms retain the ßexibility to use any appropriate digital signature as an additional system control for open systems. FDA is also including a deÞnition of digital signature under § 11.3(b)(5). The agency does not believe it necessary to codify the term ‘‘encryption’’ because, unlike the term digital signature, it has been in general use for many years and is generally understood to mean the transforming of a writing into a secret code or cipher. The agency is aware that there are several commercially available software programs that implement both digital signatures and encryption. 95. Two comments noted that use of digital signatures and encryption is not necessary in the context of PDMA, where access to an electronic record is limited once it is signed and stored. One of the comments suggested that proposed § 11.30 be revised to clarify this point. As discussed in comment 94 of this document, use of digital signatures and encryption would be an option when extra measures are necessary under the circumstances. In the case of PDMA records, such measures may be warranted in certain circumstances, and unnecessary in others. For example, if electronic records were to be transmitted by a Þrm’s representative by way of a public online service to a central location, additional measures would be necessary. On the other hand, where the representative’s records are hand delivered to that location, or transferred by direct connection between the representative and the central location, such additional measures to ensure record authenticity, conÞdentiality, and integrity may not be necessary. The agency does not believe that it is practical to revise § 11.30 to elaborate on every possible situation in which additional measures would or would not be needed. 96. One comment addressed encryption of submissions to FDA and asked if people making those submissions would have to give the agency the appropriate ‘‘keys’’ and, if so, how the agency would protect the security of such information. Copyright © 2004 CRC Press, LLC


188


The agency intends to develop appropriate procedures regarding the exchange of ‘‘keys’’ attendant to use of encryption and digital signatures, and will protect those keys that must remain conÞdential, in the same manner as the agency currently protects trade secrets. Where the agency and a submitter agree to use a system that calls for the exchange of secret keys, FDA will work with submitters to achieve mutually agreeable procedures. The agency notes, however, that not all encryption and digital signature systems require that enabling keys be secret. 97. One comment noted that proposed § 11.30 does not mention availability and nonrepudiation and requested clariÞcation of the term ‘‘point of receipt.’’ The comment noted that, where an electronic record is received at a person’s electronic mailbox (which resides on an open system), additional measures may be needed when the record is transferred to the person’s own local computer because such additional transfer entails additional security risks. The comment suggested wording that would extend open system controls to the point where records are ultimately retained. The agency agrees that, in the situation described by the comment, movement of the electronic record from an electronic mailbox to a person’s local computer may necessitate open system controls. However, situations may vary considerably as to the ultimate point of receipt, and FDA believes proposed § 11.30 offers greater ßexibility in determining open system controls than revisions suggested by the comment. The agency advises that the concept of nonrepudiation is part of record authenticity and integrity, as already covered by § 11.10(c). Therefore, FDA is not revising § 11.30 as suggested.

IX. ELECTRONIC RECORDS — SIGNATURE MANIFESTATIONS (§ 11.50) Proposed § 11.50 requires that electronic records that are electronically signed must display in clear text the printed name of the signer, and the date and time when the electronic signature was executed. This section also requires that electronic records clearly indicate the meaning (such as review, approval, responsibility, and authorship) associated with their attendant signatures. 98. Several comments suggested that the information required under proposed § 11.50 need not be contained in the electronic records themselves, but only in the human readable format (screen displays and printouts) of such records. The comments explained that the records themselves need only contain links, such as signature attribute codes, to such information to produce the displays of information required. The comments noted, for example, that, where electronic signatures consist of an identiÞcation code in combination with a password, the combined code and password itself would not be part of the display. Some comments suggested that proposed § 11.50 be revised to clarify what items are to be displayed. The agency agrees and has revised proposed § 11.50 accordingly. The intent of this section is to require that human readable forms of signed electronic records, such as computer screen displays and printouts bear: (1) The printed name of the signer (at the time the record is signed as well as whenever the record is read by humans); (2) the date and time of signing; and (3) the meaning of the signature. The



Appendix I

189

agency believes that revised § 11.50 will afford persons the ßexibility they need to implement the display of information appropriate for their own electronic records systems, consistent with other system controls in part 11, to ensure record integrity and prevent falsiÞcation. 99. One comment stated that the controls in proposed § 11.50 would not protect against inaccurate entries. FDA advises that the purpose of this section is not to protect against inaccurate entries, but to provide unambiguous documentation of the signer, when the signature was executed, and the signature’s meaning. The agency believes that such a record is necessary to document individual responsibility and actions. In a paper environment, the printed name of the individual is generally present in the signed record, frequently part of a traditional ‘‘signature block.’’ In an electronic environment, the person’s name may not be apparent, especially where the signature is based on identiÞcation codes combined with passwords. In addition, the meaning of a signature is generally apparent in a paper record by virtue of the context of the record or, more often, explicit phrases such as ‘‘approved by,’’ ‘‘reviewed by,’’ and ‘‘performed by.’’ Thus, the agency believes that for clear documentation purposes it is necessary to carry such meanings into the electronic record environment. 100. One comment suggested that proposed § 11.50 should apply only to those records that are required to be signed, and that the display of the date and time should be performed in a secure manner. The agency intends that this section apply to all signed electronic records regardless of whether other regulations require them to be signed. The agency believes that if it is important enough that a record be signed, human readable displays of such records must include the printed name of the signer, the date and time of signing, and the meaning of the signature. Such information is crucial to the agency’s ability to protect public health. For example, a message from a Þrm’s management to employees instructing them on a particular course of action may be critical in litigation. This requirement will help ensure clear documentation and deter falsiÞcation regardless of whether the signature is electronic or handwritten. The agency agrees that the display of information should be carried out in a secure manner that preserves the integrity of that information. The agency, however, does not believe it is necessary at this time to revise § 11.50 to add speciÞc security measures because other requirements of part 11 have the effect of ensuring appropriate security. Because signing information is important regardless of the type of signature used, the agency has revised § 11.50 to cover all types of signings. 101. Several comments objected to the requirement in proposed § 11.50(a) that the time of signing be displayed in addition to the date on the grounds that such information is: (1) Unnecessary, (2) costly to implement, (3) needed in the electronic record for auditing purposes, but not needed in the display of the record, and (4) only needed in critical applications. Some comments asserted that recording time should be optional. One comment asked whether the time should be local to the signer or to a central network when electronic record systems cross different time zones. The agency believes that it is vital to record the time when a signature is applied. Documenting the time when a signature was applied can be critical to demonstrating Copyright © 2004 CRC Press, LLC


190


that a given record was, or was not, falsiÞed. Regarding systems that may span different time zones, the agency advises that the signer’s local time is the one to be recorded. 102. One comment assumed that a person’s user identiÞcation code could be displayed instead of the user’s printed name, along with the date and time of signing. This assumption is incorrect. The agency intends that the printed name of the signer be displayed for purposes of unambiguous documentation and to emphasize the importance of the act of signing to the signer. The agency believes that because an identiÞcation code is not an actual name, it would not be a satisfactory substitute. 103. One comment suggested that the word ‘‘printed’’ in the phrase ‘‘printed name’’ be deleted because the word was superßuous. The comment also stated that the rule should state when the clear text must be created or displayed because some computer systems, in the context of electronic data interchange transactions, append digital signatures to records before, or in connection with, communication of the record. The agency disagrees that the word ‘‘printed’’ is superßuous because the intent of this section is to show the name of the person in an unambiguous manner that can be read by anyone. The agency believes that requiring the printed name of the signer instead of codes or other manifestations, more effectively provides clarity. The agency has revised this section to clarify the point at which the signer’s information must be displayed, namely, as part of any human readable form of the electronic record. The revision, in the agency’s view, addresses the comment’s concern regarding the application of digital signatures. The agency advises that under § 11.50, any time after an electronic record has been signed, individuals who see the human readable form of the record will be able to immediately tell who signed the record, when it was signed, and what the signature meant. This includes the signer who, as with a traditional signature to paper, will be able to review the signature instantly. 104. One comment asked if the operator would have to see the meaning of the signature, or if the information had to be stored on the physical electronic record. As discussed in comment 100 of this document, the information required by § 11.50(b) must be displayed in the human readable format of the electronic record. Persons may elect to store that information directly within the electronic record itself, or in logically associated records, as long as such information is displayed any time a person reads the record. 105. One comment noted that proposed § 11.50(b) could be interpreted to require lengthy explanations of the signatures and the credentials of the signers. The comment also stated that this information would more naturally be contained in standard operating procedures, manuals, or accompanying literature than in the electronic records themselves. The agency believes that the comment misinterprets the intent of this provision. Recording the meaning of the signature does not infer that the signer’s credentials or other lengthy explanations be part of that meaning. The statement must merely show what is meant by the act of signing (e.g., review, approval, responsibility, authorship). 106. One comment noted that the meaning of a signature may be included in a (digital signature) public key certiÞcate and asked if this would be acceptable. The comment also noted that the certiÞcate might be easily accessible by a record recipient from either a recognized database or one that might be part of, or associated with, the electronic record itself. The comment further suggested that FDA would Copyright © 2004 CRC Press, LLC


Appendix I

191

beneÞt from participating in developing rules of practice regarding certiÞcate-based public key cryptography and infrastructure with the Information Security Committee, Section of Science and Technology, of the American Bar Association (ABA). The intent of this provision is to clearly discern the meaning of the signature when the electronic record is displayed in human readable form. The agency does not expect such meaning to be contained in or displayed by a public key certiÞcate because the public key is generally a Þxed value associated with an individual. The certiÞcate is used by the recipient to authenticate a digital signature that may have different meanings, depending upon the record being signed. FDA acknowledges that it is possible for someone to establish different public keys, each of which may indicate a different signature meaning. Part 11 would not prohibit multiple ‘‘meaning’’ keys provided the meaning of the signature itself was still clear in the display of the record, a feature that could conceivably be implemented by software. Regarding work of the ABA and other standard-setting organizations, the agency welcomes an open dialogue with such organizations, for the mutual beneÞt of all parties, to establish and facilitate the use of electronic record/ electronic signature technologies. FDA’s participation in any such activities would be in accordance with the agency’s policy on standards stated in the Federal Register of October 11, 1995 (60 FR 53078). Revised § 11.50, signature manifestations, reads as follows: (a) Signed electronic records shall contain information associated with the signing that clearly indicates all of the following: (1) The printed name of the signer; (2) The date and time when the signature was executed; and (3) The meaning (such as review, approval, responsibility, or authorship) associated with the signature. (b) The items identiÞed in paragraphs (a)(1), (a)(2), and (a)(3) of this section shall be subject to the same controls as for electronic records and shall be included as part of any human readable form of the electronic record (such as electronic display or printout).

X. ELECTRONIC RECORDS — SIGNATURE/RECORD LINKING (§ 11.70) 107. Proposed § 11.70 states that electronic signatures and handwritten signatures executed to electronic records must be veriÞably bound to their respective records to ensure that signatures could not be excised, copied, or otherwise transferred to falsify another electronic record. Many comments objected to this provision as too prescriptive, unnecessary, unattainable, and excessive in comparison to paper-based records. Some comments asserted that the objectives of the section could be attained through appropriate procedural and administrative controls. The comments also suggested that objectives of the provision could be met by appropriate software (i.e., logical) links between the electronic signatures and electronic records, and that such links are common in Copyright © 2004 CRC Press, LLC


192


systems that use identiÞcation codes in combination with passwords. One Þrm expressed full support for the provision, and noted that its system implements such a feature and that signature-to-record binding is similar to the record-locking provision of the proposed PDMA regulations. The agency did not intend to mandate use of any particular technology by use of the word ‘‘binding.’’ FDA recognizes that, because it is relatively easy to copy an electronic signature to another electronic record and thus compromise or falsify that record, a technology based link is necessary. The agency does not believe that procedural or administrative controls alone are sufÞcient to ensure that objective because such controls could be more easily circumvented than a straightforward technology based approach. In addition, when electronic records are transferred from one party to another, the procedural controls used by the sender and recipient may be different. This could result in record falsiÞcation by signature transfer. The agency agrees that the word ‘‘link’’ would offer persons greater ßexibility in implementing the intent of this provision and in associating the names of individuals with their identiÞcation codes/passwords without actually recording the passwords themselves in electronic records. The agency has revised proposed § 11.70 to state that signatures shall be linked to their electronic records. 108. Several comments argued that proposed § 11.70 requires absolute protection of electronic records from falsiÞcation, an objective that is unrealistic to the extent that determined individuals could falsify records. The agency acknowledges that, despite elaborate system controls, certain determined individuals may Þnd a way to defeat antifalsiÞcation measures. FDA will pursue such illegal activities as vigorously as it does falsiÞcation of paper records. For purposes of part 11, the agency’s intent is to require measures that prevent electronic records falsiÞcation by ordinary means. Therefore, FDA has revised § 11.70 by adding the phrase ‘‘by ordinary means’’ at the end of this section. 109. Several comments suggested changing the phrase ‘‘another electronic record’’ to ‘‘an electronic record’’ to clarify that the antifalsiÞcation provision applies to the current record as well as any other record. The agency agrees and has revised § 11.70 accordingly. 110. Two comments argued that signature-to-record binding is unnecessary, in the context of PDMA, beyond the point of record creation (i.e., when records are transmitted to a point of receipt). The comments asserted that persons who might be in a position to separate a signature from a record (for purposes of falsiÞcation) are individuals responsible for record integrity and thus unlikely to falsify records. The comments also stated that signature-to-record binding is produced by software coding at the time the record is signed, and suggested that proposed § 11.70 clarify that binding would be necessary only up to the point of actual transmission of the electronic record to a central point of receipt. The agency disagrees with the comment’s premise that the need for binding to prevent falsiÞcation depends on the disposition of people to falsify records. The agency believes that reliance on individual tendencies is insufÞcient insurance against falsiÞcation. The agency also notes that in the traditional paper record, the signature remains bound to its corresponding record regardless of where the record may go. Copyright © 2004 CRC Press, LLC


Appendix I

193

111. One comment suggested that proposed § 11.70 be deleted because it appears to require that all records be kept on inalterable media. The comment also suggested that the phrase ‘‘otherwise transferred’’ be deleted on the basis that it should be permissible for copies of handwritten signatures (recorded electronically) to be made when used, in addition to another unique individual identiÞcation mechanism. The agency advises that neither § 11.70, nor other sections in part 11, requires that records be kept on inalterable media. What is required is that whenever revisions to a record are made, the original entries must not be obscured. In addition, this section does not prohibit copies of handwritten signatures recorded electronically from being made for legitimate reasons that do not relate to record falsiÞcation. Section 11.70 merely states that such copies must not be made that falsify electronic records. 112. One comment suggested that proposed § 11.70 be revised to require application of response cryptographic methods because only those methods could be used to comply with the regulation. The comment noted that, for certiÞcate based public key cryptographic methods, the agency should address veriÞable binding between the signer’s name and public key as well as binding between digital signatures and electronic records. The comment also suggested that the regulation should reference electronic signatures in the context of secure time and date stamping. The agency intends to permit maximum ßexibility in how organizations achieve the linking called for in § 11.70, and, as discussed above, has revised the regulation accordingly. Therefore, FDA does not believe that cryptographic and digital signature methods would be the only ways of linking an electronic signature to an electronic document. In fact, one Þrm commented that its system binds a person’s handwritten signature to an electronic record. The agency agrees that use of digital signatures accomplishes the same objective because, if a digital signature were to be copied from one record to another, the second record would fail the digital signature veriÞcation procedure. Furthermore, FDA notes that concerns regarding binding a person’s name with the person’s public key would be addressed in the context of § 11.100(b) because an organization must establish an individual’s identity before assigning or certifying an electronic signature (or any of the electronic signature components). 113. Two comments requested clariÞcation of the types of technologies that could be used to meet the requirements of proposed § 11.70. As discussed in comment 107 of this document, the agency is affording persons maximum ßexibility in using any appropriate method to link electronic signatures to their respective electronic records to prevent record falsiÞcation. Use of digital signatures is one such method, as is use of software locks to prevent sections of codes representing signatures from being copied or removed. Because this is an area of developing technology, it is likely that other linking methods will emerge.

XI. ELECTRONIC SIGNATURES—GENERAL REQUIREMENTS (§ 11.100) Proposed § 11.100(a) states that each electronic signature must be unique to one individual and not be reused or reassigned to anyone else.



194


114. One comment asserted that several people should be permitted to share a common identiÞcation code and password where access control is limited to inquiry only. Part 11 does not prohibit the establishment of a common group identiÞcation code/password for read only access purposes. However, such commonly shared codes and passwords would not be regarded, and must not be used, as electronic signatures. Shared access to a common database may nonetheless be implemented by granting appropriate common record access privileges to groups of people, each of whom has a unique electronic signature. 115. Several comments said proposed § 11.100(a) should permit identiÞcation codes to be reused and reassigned from one employee to another, as long as an audit trail exists to associate an identiÞcation code with a given individual at any one time, and different passwords are used. Several comments said the section should indicate if the agency intends to restrict authority delegation by the nonreassignment or nonreuse provision, or by the provision in § 11.200(a)(2) requiring electronic signatures to be used only by their genuine owners. The comments questioned whether reuse means restricting one noncryptographic based signature to only one record and argued that passwords need not be unique if the combined identiÞcation code and password are unique to one individual. One comment recommended caution in using the term ‘‘ownership’’ because of possible confusion with intellectual property rights or ownership of the computer systems themselves. The agency advises that, where an electronic signature consists of the combined identiÞcation code and password, § 11.100 would not prohibit the reassignment of the identiÞcation code provided the combined identiÞcation code and password remain unique to prevent record falsiÞcation. The agency believes that such reassignments are inadvisable, however, to the extent that they might be combined with an easily guessed password, thus increasing the chances that an individual might assume a signature belonging to someone else. The agency also advises that where people can read identiÞcation codes (e.g., printed numbers and letters that are typed at a keyboard or read from a card), the risks of someone obtaining that information as part of a falsiÞcation effort would be greatly increased as compared to an identiÞcation code that is not in human readable form (one that is, for example, encoded on a ‘‘secure card’’ or other device). Regarding the delegation of authority to use electronic signatures, FDA does not intend to restrict the ability of one individual to sign a record or otherwise act on behalf of another individual. However, the applied electronic signature must be the assignee’s and the record should clearly indicate the capacity in which the person is acting (e.g., on behalf of, or under the authority of, someone else). This is analogous to traditional paper records and handwritten signatures when person ‘‘A’’ signs his or her own name under the signature block of person ‘‘B,’’ with appropriate explanatory notations such as ‘‘for’’ or ‘‘as representative of’’ person B. In such cases, person A does notsimply sign the name of person B. The agency expects the same procedure to be used for electronic records and electronic signatures. The agency intends the term ‘‘reuse’’ to refer to an electronic signature used by a different person. The agency does not regard as ‘‘reuse’’ the replicate application of a noncryptographic based electronic signature (such as an identiÞcation code and Copyright © 2004 CRC Press, LLC


Appendix I

195

password) to different electronic records. For clarity, FDA has revised the phrase ‘‘not be reused or reassigned to’’ to state ‘‘not be reused by, or reassigned to,’’ in § 11.100(a). The reference in § 11.200(a) to ownership is made in the context of an individual owning or being assigned a particular electronic signature that no other individual may use. FDA believes this is clear and that concerns regarding ownership in the context of intellectual property rights or hardware are misplaced. 116. One comment suggested that proposed § 11.100(a) should accommodate electronic signatures assigned to organizations rather than individuals. The agency advises that, for purposes of part 11, electronic signatures are those of individual human beings and not organizations. For example, FDA does not regard a corporate seal as an individual’s signature. Humans may represent and obligate organizations by signing records, however. For clariÞcation, the agency is substituting the word ‘‘individual’’ for ‘‘person’’ in the deÞnition of electronic signature (§ 11.3(b)(7)) because the broader deÞnition of person within the act includes organizations. 117. Proposed § 11.100(b) states that, before an electronic signature is assigned to a person, the identity of the individual must be veriÞed by the assigning authority. Two comments noted that where people use identiÞcation codes in combination with passwords only the identiÞcation code portion of the electronic signature is assigned, not the password. Another comment argued that the word ‘‘assigned’’ is inappropriate in the context of electronic signatures based upon public key cryptography because the appropriate authority certiÞes the bind between the individual’s public key and identity, and not the electronic signature itself. The agency acknowledges that, for certain types of electronic signatures, the authorizing or certifying organization issues or approves only a portion of what eventually becomes an individual’s electronic signature. FDA wishes to accommodate a broad variety of electronic signatures and is therefore revising § 11.100(b) to require that an organization verify the identity of an individual before it establishes, assigns, certiÞes, or otherwise sanctions an individual’s electronic signature or any element of such electronic signature. 118. One comment suggested that the word ‘‘veriÞed’’ in proposed § 11.100(b) be changed to ‘‘conÞrmed.’’ Other comments addressed the method of verifying a person’s identity and suggested that the section specify acceptable veriÞcation methods, including high level procedures regarding the relative strength of that veriÞcation, and the need for personal appearances or supporting documentation such as birth certiÞcates. Two comments said the veriÞcation provision should be deleted because normal internal controls are adequate, and that it was impractical for multinational companies whose employees are globally dispersed. The agency does not believe that there is a sufÞcient difference between ‘‘veriÞed’’ and ‘‘conÞrmed’’ to warrant a change in this section. Both words indicate that organizations substantiate a person’s identity to prevent impersonations when an electronic signature, or any of its elements, is being established or certiÞed. The agency disagrees with the assertion that this requirement is unnecessary. Without verifying someone’s identity at the outset of establishing or certifying an individual’s electronic signature, or a portion thereof, an imposter might easily access and compromise many records. Moreover, an imposter could continue this activity for Copyright © 2004 CRC Press, LLC


196


a prolonged period of time despite other system controls, with potentially serious consequences. The agency does not believe that the size of an organization, or global dispersion of its employees, is reason to abandon this vital control. Such dispersion may, in fact, make it easier for an impostor to pose as someone else in the absence of such veriÞcation. Further, the agency does not accept the implication that multinational Þrms would not verify the identity of their employees as part of other routine procedures, such as when individuals are Þrst hired. In addition, in cases where an organization is widely dispersed and electronic signatures are established or certiÞed centrally, § 11.100(b) does not prohibit organizations from having their local units perform the veriÞcation and relaying this information to the central authority. Similarly, local units may conduct the electronic signature assignment or certiÞcation. FDA does not believe it is necessary at this time to specify methods of identity veriÞcation and expects that organizations will consider risks attendant to sanctioning an erroneously assigned electronic signature. 119. Proposed § 11.100(c) states that persons using electronic signatures must certify to the agency that their electronic signature system guarantees the authenticity, validity, and binding nature of any electronic signature. Persons utilizing electronic signatures would, upon agency request, provide additional certiÞcation or testimony that a speciÞc electronic signature is authentic, valid, and binding. Such certiÞcation would be submitted to the FDA district ofÞce in which territory the electronic signature system is in use. Many comments objected to the proposed requirement that persons provide FDA with certiÞcation regarding their electronic signature systems. The comments asserted that the requirement was: (1) Unprecedented, (2) unrealistic, (3) unnecessary, (4) contradictory to the principles and intent of system validation, (5) too burdensome for FDA to manage logistically, (6) apparently intended only to simplify FDA litigation, (7) impossible to meet regarding ‘‘guarantees’’ of authenticity, and (8) an apparent substitute for FDA inspections. FDA agrees in part with these comments. This Þnal rule reduces the scope and burden of certiÞcation to a statement of intent that electronic signatures are the legally binding equivalent of handwritten signatures. As noted previously, the agency believes it is important, within the context of its health protection activities, to ensure that persons who implement electronic signatures fully equate the legally binding nature of electronic signatures with the traditional handwritten paper-based signatures. The agency is concerned that individuals might disavow an electronic signature as something completely different from a traditional handwritten signature. Such contention could result in confusion and possibly extensive litigation. Moreover, a limited certiÞcation as provided in this Þnal rule is consistent with other legal, regulatory, and commercial practices. For example, electronic data exchange trading partner agreements are often written on paper and signed with traditional handwritten signatures to establish that certain electronic identiÞers are recognized as equivalent to traditional handwritten signatures.



Appendix I

197

FDA does not expect electronic signature systems to be guaranteed foolproof. The agency does not intend, under § 11.100(c), to establish a requirement that is unattainable. CertiÞcation of an electronic signature system as the legally binding equivalent of a traditional handwritten signature is separate and distinct from system validation. This provision is not intended as a substitute for FDA inspection and such inspection alone may not be able to determine in a conclusive manner an organization’s intent regarding electronic signature equivalency. The agency has revised proposed § 11.100(c) to clarify its intent. The agency wishes to emphasize that the Þnal rule dramatically curtails what FDA had proposed and is essential for the agency to be able to protect and promote the public health because FDA must be able to hold people to the commitments they make under their electronic signatures. The certiÞcation in the Þnal rule is merely a statement of intent that electronic signatures are the legally binding equivalent of traditional handwritten signatures. 120. Several comments questioned the procedures necessary for submitting the certiÞcation to FDA, including: (1) The scheduling of the certiÞcation; (2) whether to submit certiÞcates for each individual or for each electronic signature; (3) the meaning of ‘‘territory’’ in the context of wide area networks; (4) whether such certificates could be submitted electronically; and (5) whether organizations, after submitting a certiÞcate, had to wait for a response from FDA before implementing their electronic signature systems. Two comments suggested revising proposed § 11.100(c) to require that all certiÞcations be submitted to FDA only upon agency request. One comment suggested changing ‘‘should’’ to ‘‘shall’’ in the last sentence of § 11.100(c) if the agency’s intent is to require certiÞcates to be submitted to the respective FDA district ofÞce. The agency intends that certiÞcates be submitted once, in the form of a paper letter, bearing a traditional handwritten signature, at the time an organization Þrst establishes an electronic signature system after the effective date of part 11, or, where such systems have been used before the effective date, upon continued use of the electronic signature system. A separate certiÞcation is not needed for each electronic signature, although certiÞcation of a particular electronic signature is to be submitted if the agency requests it. The agency does not intend to establish certiÞcation as a review and approval function. In addition, organizations need not await FDA’s response before putting electronic signature systems into effect, or before continuing to use an existing system. A single certiÞcation may be stated in broad terms that encompass electronic signatures of all current and future employees, thus obviating the need for subsequent certiÞcations submitted on a preestablished schedule. To further simplify the process and to minimize the number of certiÞcations that persons would have to provide, the agency has revised § 11.100(c) to permit submission of a single certiÞcation that covers all electronic signatures used by an organization. The revised rule also simpliÞes the process by providing a single agency receiving unit. The Þnal rule instructs persons to send certiÞcations to FDA’s OfÞce of Regional Operations (HFC–100), 5600 Fishers Lane, Rockville, MD



198


20857. Persons outside the United States may send their certiÞcations to the same ofÞce. The agency offers, as guidance, an example of an acceptable § 11.100(c) certiÞcation: Pursuant to Section 11.100 of Title 21 of the Code of Federal Regulations, this is to certify that [name of organization] intends that all electronic signatures executed by our employees, agents, or representatives, located anywhere in the world, are the legally binding equivalent of traditional handwritten signatures.

The agency has revised § 11.100 to clarify where and when certiÞcates are to be submitted. The agency does not agree that the initial certiÞcation be provided only upon agency request because FDA believes it is vital to have such certiÞcates, as a matter of record, in advance of any possible litigation. This would clearly establish the intent of organizations to equate the legally binding nature of electronic signatures with traditional handwritten signatures. In addition, the agency believes that having the certiÞcation on Þle ahead of time will have the beneÞcial effect of reinforcing the gravity of electronic signatures by putting an organization’s employees on notice that the organization has gone on record with FDA as equating electronic signatures with handwritten signatures. 121. One comment suggested that proposed § 11.100(c) be revised to exclude from certiÞcation instances in which the purported signer claims that he or she did not create or authorize the signature. The agency declines to make this revision because a provision for nonrepudiation is already contained in § 11.10. As a result of the considerations discussed in comments 119 and 120 of this document, the agency has revised proposed § 11.100(c) to state that: (c) Persons using electronic signatures shall, prior to or at the time of such use, certify to the agency that the electronic signatures in their system, used on or after August 20, 1997, are intended to be the legally binding equivalent of traditional handwritten signatures. (1) The certiÞcation shall be submitted in paper form and signed with a traditional handwritten signature to the OfÞce of Regional Operations (HFC–100), 5600 Fishers Lane, Rockville, MD 20857. (2) Persons using electronic signatures shall, upon agency request, provide additional certiÞcation or testimony that a speciÞc electronic signature is the legally binding equivalent of the signer’s handwritten signature.

XII. ELECTRONIC SIGNATURE COMPONENTS AND CONTROLS (§ 11.200) 122. Proposed § 11.200 sets forth requirements for electronic signature identiÞcation mechanisms and controls. Two comments suggested that the term ‘‘identiÞcation



Appendix I

199

code’’ should be deÞned. Several comments suggested that the term ‘‘identiÞcation mechanisms’’ should be changed to ‘‘identiÞcation components’’ because each component of an electronic signature need not be executed by a different mechanism. The agency believes that the term ‘‘identiÞcation code’’ is sufÞciently broad and generally understood and does not need to be deÞned in these regulations. FDA agrees that the word ‘‘component’’ more accurately reßects the agency’s intent than the word ‘‘mechanism,’’ and has substituted ‘‘component’’ for ‘‘mechanism’’ in revised § 11.200. The agency has also revised the section heading to read ‘‘Electronic signature components and controls’’ to be consistent with the wording of the section. 123. Proposed § 11.200(a) states that electronic signatures not based upon biometric/behavioral links must: (1) Employ at least two distinct identiÞcation mechanisms (such as an identiÞcation code and password), each of which is contemporaneously executed at each signing; (2) be used only by their genuine owners; and (3) be administered and executed to ensure that attempted use of an individual’s electronic signature by anyone other than its genuine owner requires collaboration of two or more individuals. Two comments said that proposed § 11.200(a) should acknowledge that passwords may be known not only to their genuine owners, but also to system administrators in case people forget their passwords. The agency does not believe that system administrators would routinely need to know an individual’s password because they would have sufÞcient privileges to assist those individuals who forget passwords. 124. Several comments argued that the agency should accept a single password alone as an electronic signature because: (1) Combining the password with an identiÞcation code adds little security, (2) administrative controls and passwords are sufÞcient, (3) authorized access is more difÞcult when two components are needed, (4) people would not want to gain unauthorized entry into a manufacturing environment, and (5) changing current systems that use only a password would be costly. The comments generally addressed the need for two components in electronic signatures within the context of the requirement that all components be used each time an electronic signature is executed. Several comments suggested that, for purposes of system access, individuals should enter both a user identiÞcation code and password, but that, for subsequent signings during one period of access, a single element (such as a password) known only to, and usable by, the individual should be sufÞcient. The agency believes that it is very important to distinguish between those (nonbiometric) electronic signatures that are executed repetitively during a single, continuous controlled period of time (access session or logged-on period) and those that are not. The agency is concerned, from statements made in comments, that people might use passwords that are not always unique and are frequently words that are easily associated with an individual. Accordingly, where nonbiometric electronic signatures are not executed repetitively during a single, continuous controlled period, it would be extremely bad practice to use a password alone as an electronic signature. The agency believes that using a password alone in such cases would clearly increase the likelihood that one individual, by chance or deduction, could enter a password that belonged to someone else and thereby easily and readily impersonate that individual. This action could falsify electronic records. Copyright © 2004 CRC Press, LLC


200


The agency acknowledges that there are some situations involving repetitive signings in which it may not be necessary for an individual to execute each component of a nonbiometric electronic signature for every signing. The agency is persuaded by the comments that such situations generally involve certain conditions. For example, an individual performs an initial system access or ‘‘log on,’’ which is effectively the Þrst signing, by executing all components of the electronic signature (typically both an identiÞcation code and a password). The individual then performs subsequent signings by executing at least one component of the electronic signature, under controlled conditions that prevent another person from impersonating the legitimate signer. The agency’s concern here is the possibility that, if the person leaves the workstation, someone else could access the workstation (or other computer device used to execute the signing) and impersonate the legitimate signer by entering an identiÞcation code or password. The agency believes that, in such situations, it is vital to have stringent controls in place to prevent the impersonation. Such controls include: (1) Requiring an individual to remain in close proximity to the workstation throughout the signing session; (2) use of automatic inactivity disconnect measures that would ‘‘de-log’’ the Þrst individual if no entries or actions were taken within a Þxed short timeframe; and (3) requiring that the single component needed for subsequent signings be known to, and usable only by, the authorized individual. The agency’s objective in accepting the execution of fewer than all the components of a nonbiometric electronic signature for repetitive signings is to make it impractical to falsify records. The agency believes that this would be attained by complying with all of the following procedures where nonbiometric electronic signatures are executed more than once during a single, continuous controlled session: (1) All electronic signature components are executed for the Þrst signing; (2) at least one electronic signature component is executed at each subsequent signing; (3) the electronic signature component executed after the initial signing is only used by its genuine owner, and is designed to ensure it can only be used by its genuine owner; and (4) the electronic signatures are administered and executed to ensure that their attempted use by anyone other than their genuine owners requires collaboration of two or more individuals. Items 1 and 4 are already incorporated in proposed § 11.200(a). FDA has included items 2 and 3 in Þnal § 11.200(a). The agency cautions, however, that if its experience with enforcement of part 11 demonstrates that these controls are insufÞcient to deter falsiÞcations, FDA may propose more stringent controls. 125. One comment asserted that, if the agency intends the term ‘‘identiÞcation code’’ to mean the typical user identiÞcation, it should not characterize the term as a distinct mechanism because such codes do not necessarily exhibit security attributes. The comment also suggested that proposed § 11.200(a) address the appropriate application of each possible combination of a two-factor authentication method. The agency acknowledges that the identiÞcation code alone does not exhibit security attributes. Security derives from the totality of system controls used to prevent falsiÞcation. However, uniqueness of the identiÞcation code when combined with another electronic signature component, which may not be unique (such as a password), makes the combination unique and thereby enables a legitimate electronic Copyright © 2004 CRC Press, LLC


Appendix I

201

signature. FDA does not now believe it necessary to address, in § 11.200(a), the application of all possible combinations of multifactored authentication methods. 126. One comment requested clariÞcation of ‘‘each signing,’’ noting that a laboratory employee may enter a group of test results under one signing. The agency advises that each signing means each time an individual executes a signature. Particular requirements regarding what records need to be signed derive from other regulations, not part 11. For example, in the case of a laboratory employee who performs a number of analytical tests, within the context of drug CGMP regulations, it is permissible for one signature to indicate the performance of a group of tests (21 CFR 211.194(a)(7)). A separate signing is not required in this context for each separate test as long as the record clearly shows that the single signature means the signer performed all the tests. 127. One comment suggested that the proposed requirement, that collaboration of at least two individuals is needed to prevent attempts at electronic signature falsiÞcation, be deleted because a responsible person should be allowed to override the electronic signature of a subordinate. Several comments addressed the phrase ‘‘attempted use’’ and suggested that it be deleted or changed to ‘‘unauthorized use.’’ The comments said that willful breaking or circumvention of any security measure does not require two or more people to execute, and that the central question is whether collaboration is required to use the electronic signature. The agency advises that the intent of the collaboration provision is to require that the components of a nonbiometric electronic signature cannot be used by one individual without the prior knowledge of a second individual. One type of situation the agency seeks to prevent is the use of a component such as a card or token that a person may leave unattended. If an individual must collaborate with another individual by disclosing a password, the risks of betrayal and disclosure are greatly increased and this helps to deter such actions. Because the agency is not condoning such actions, § 11.200(a)(2) requires that electronic signatures be used only by the genuine owner. The agency disagrees with the comments that the term ‘‘attempted use’’ should be changed to ‘‘unauthorized uses,’’ because ‘‘unauthorized uses’’ could infer that use of someone else’s electronic signature is acceptable if it is authorized. Regarding electronic signature ‘‘overrides,’’ the agency would consider as falsiÞcation the act of substituting the signature of a supervisor for that of a subordinate. The electronic signature of the subordinate must remain inviolate for purposes of authentication and documentation. Although supervisors may overrule the actions of their staff, the electronic signatures of the subordinates must remain a permanent part of the record, and the supervisor’s own electronic signature must appear separately. The agency believes that such an approach is fully consistent with procedures for paper records. As a result of the revisions noted in comments 123 to 127 of this document, § 11.200(a) now reads as follows: (a) Electronic signatures that are not based upon biometrics shall: (1) Employ at least two distinct identiÞcation components such as an identiÞcation code and password. Copyright © 2004 CRC Press, LLC


202


(2) (3)

(i) When an individual executes a series of signings during a single, continuous period of controlled system access, the Þrst signing shall be executed using all electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual. (ii) When an individual executes one or more signings not performed during a single, continuous period of controlled system access, each signing shall be executed using all of the electronic signature components. Be used only by their genuine owners; and Be administered and executed to ensurethat attempted use of an individual’s electronic signature by anyone other than its genuine owner requires collaboration of two or more individuals.

128. Proposed § 11.200(b) states that electronic signatures based upon biometric/behavioral links be designed to ensure that they could not be used by anyone other than their genuine owners. placed too great an emphasis on biometrics, did not establish particular levels of assurance for biometrics, and did not provide for systems using mixtures of biometric and nonbiometric electronic signatures. The comment recommended revising the phrase ‘‘designed to ensure they cannot be used’’ to read ‘‘provide assurances that prevent their execution.’’ The agency’s experience with biometric electronic signatures is contained in the administrative record for this rulemaking, under docket no. 92N–0251, and includes recommendations from public comments to the ANPRM and the proposed rule. The agency has also gathered, and continues to gather, additional information from literature reviews, general press reports, meetings, and the agency’s experience with this technology. Interested persons have had extensive opportunity for input and comment regarding biometrics in part 11. In addition, interested persons may continue to contact the agency at any time regarding biometrics or any other relevant technologies. The agency notes that the rule does not require the use of biometricbased electronic signatures. As the agency’s experience with biometric electronic signatures increases, FDA will consider holding or participating in public workshops if that approach would be helpful to those wishing to adopt such technologies to comply with part 11. The agency does not believe that proposed § 11.200(b) places too much emphasis on biometric electronic signatures. As discussed above, the regulation makes a clear distinction between electronic signatures that are and are not based on biometrics, but treats their acceptance equally. The agency recognizes the inherent security advantages of biometrics, however, in that record falsiÞcation is more difÞcult to perform. System controls needed to make biometric-based electronic signatures reliable and trustworthy are thus different in certain respects from controls needed to make nonbiometric electronic signatures reliable and trustworthy. The requirements in part 11 reßect those differences.



Appendix I

203

The agency does not believe that it is necessary at this time to set numerical security assurance standards that any system would have to meet. The regulation does not prohibit individuals from using combinations of biometric and nonbiometric-based electronic signatures. However, when combinations are used, FDA advises that requirements for each element in the combination would also apply. For example, if passwords are used in combination with biometrics, then the beneÞts of using passwords would only be realized, in the agency’s view, by adhering to controls that ensure password integrity (see § 11.300). In addition, the agency believes that the phrase ‘‘designed to ensure that they cannot be used’’ more accurately reßects the agency’s intent than the suggested alternate wording, and is more consistent with the concept of systems validation. Under such validation, falsiÞcation preventive attributes would be designed into the biometric systems. To be consistent with the revised deÞnition of biometrics in § 11.3(b)(3), the agency has revised § 11.200(b) to read, ‘‘Electronic signatures based upon biometrics shall be designed to ensure that they cannot be used by anyone other than their genuine owners.’’

XIII. ELECTRONIC SIGNATURES — CONTROLS FOR IDENTIFICATION CODES/PASSWORDS (§ 11.300) The introductory paragraph of proposed § 11.300 states that electronic signatures based upon use of identiÞcation codes in combination with passwords must employ controls to ensure their security and integrity. To clarify the intent of this provision, the agency has added the words ‘‘[p]ersons who use’’ to the Þrst sentence of § 11.300. This change is consistent with §§ 11.10 and 11.30. The introductory paragraph now reads, ‘‘Persons who use electronic signatures based upon use of identiÞcation codes in combination with passwords shall employ controls to ensure their security and integrity. Such controls shall include: * * *.’’ 129. One comment suggested deletion of the phrase ‘‘in combination with passwords’’ from the Þrst sentence of this section. The agency disagrees with the suggested revision because the change is inconsistent with FDA’s intent to address controls for electronic signatures based on combinations of identiÞcation codes and passwords, and would, in effect, permit a single component nonbiometric-based electronic signature. 130. Proposed § 11.300(a) states that controls for identiÞcation codes/ passwords must include maintaining the uniqueness of each issuance of identiÞcation code and password. One comment alleged that most passwords are commonly used words, such as a child’s name, a State, city, street, month, holiday, or date, that are signiÞcant to the person who creates the password. Another stated that the rule should explain uniqueness and distinguish between issuance and use because identiÞcation code/password combinations generally do not change for each use. FDA does not intend to require that individuals use a completely different identiÞcation code/password combination each time they execute an electronic sig-



204


nature. For reasons explained in the response to comment 16, what is required to be unique is each combined password and identiÞcation code and FDA has revised the wording of § 11.300(a) to clarify this provision. The agency is aware, however, of identiÞcation devices that generate new passwords on a continuous basis in synchronization with a ‘‘host’’ computer. This results in unique passwords for each system access. Thus, it is possible in theory to generate a unique nonbiometric electronic signature for each signing. The agency cautions against using passwords that are common words easily associated with their originators because such a practice would make it relatively easy for someone to impersonate someone else by guessing the password and combining it with an unsecured (or even commonly known) identiÞcation code. 131. Proposed § 11.300(b) states that controls for identiÞcation codes/ passwords must ensure that code/password issuances are periodically checked, recalled, or revised. Several comments objected to this proposed requirement because: (1) It is unnecessary, (2) it excessively prescribes ‘‘how to,’’ (3) it duplicates the requirements in § 11.300(c), and (4) it is administratively impractical for larger organizations. However, the comments said individuals should be encouraged to change their passwords periodically. Several comments suggested that proposed § 11.300(b) include a clarifying example such as ‘‘to cover events such as password aging.’’ One comment said that the section should indicate who is to perform the periodic checking, recalling, or revising. The agency disagrees with the objections to this provision. FDA does not view the provision as a ‘‘how to’’ because organizations have full ßexibility in determining the frequency and methods of checking, recalling, or revising their code/password issuances. The agency does not believe that this paragraph duplicates the regulation in § 11.300(c) because paragraph (c) speciÞcally addresses followup to losses of electronic signature issuances, whereas § 11.300(b) addresses periodic issuance changes to ensure against their having been unknowingly compromised. This provision would be met by ensuring that people change their passwords periodically. FDA disagrees that this system control is unnecessary or impractical in large organizations because the presence of more people may increase the opportunities for compromising identiÞcation codes/passwords. The agency is conÞdent that larger organizations will be fully capable of handling periodic issuance checks, revisions, or recalls. FDA agrees with the comments that suggested a clarifying example and has revised § 11.300(b) to include password aging as such an example. The agency cautions, however, that the example should not be taken to mean that password expiration would be the only rationale for revising, recalling, and checking issuances. If, for example, identiÞcation codes and passwords have been copied or compromised, they should be changed. FDA does not believe it necessary at this time to specify who in an organization is to carry out this system control, although the agency expects that units that issue electronic signatures would likely have this duty. 132. Proposed § 11.300(c) states that controls for identiÞcation codes/ passwords must include the following of loss management procedures to electronically deCopyright © 2004 CRC Press, LLC


Appendix I

205

authorize lost tokens, cards, etc., and to issue temporary or permanent replacements using suitable, rigorous controls for substitutes. One comment suggested that this section be deleted because it excessively prescribes ‘‘how to.’’ Another comment argued that the proposal was not detailed enough and should distinguish among fundamental types of cards (e.g., magstripe, integrated circuit, and optical) and include separate sections that address their respective use. Two comments questioned why the proposal called for ‘‘rigorous controls’’ in this section as opposed to other sections. One of the comments recommended that this section should also apply to cards or devices that are stolen as well as lost. The agency believes that the requirement that organizations institute loss management procedures is neither too detailed nor too general. Organizations retain full ßexibility in establishing the details of such procedures. The agency does not believe it necessary at this time to offer speciÞc provisions relating to different types of cards or tokens. Organizations that use such devices retain full ßexibility to establish appropriate controls for their operations. To clarify the agency’s broad intent to cover all types of devices that contain or generate identiÞcation code or password information, FDA has revised § 11.300(c) to replace ‘‘etc.’’ with ‘‘and other devices that bear or generate identiÞcation code or password information.’’ The agency agrees that § 11.300(c) should cover loss management procedures regardless of how devices become potentially compromised, and has revised this section by adding, after the word ‘‘lost,’’ the phrase ‘‘stolen, missing, or otherwise potentially compromised.’’ FDA uses the term ‘‘rigorous’’ because device disappearance may be the result of inadequate controls over the issuance and management of the original cards or devices, thus necessitating more stringent measures to prevent problem recurrence. For example, personnel training on device safekeeping may need to be strengthened. 133. Proposed § 11.300(d) states that controls for identiÞcation codes/passwords must include the use of transaction safeguards to prevent unauthorized use of passwords and/or identiÞcation codes, and, detecting and reporting to the system security unit and organizational management in an emergent manner any attempts at their unauthorized use. Several comments suggested that the term ‘‘emergent’’ in proposed § 11.300(d) be replaced with ‘‘timely’’ to describe reports regarding attempted unauthorized use of identiÞcation codes/passwords because: (1) A timely report would be sufÞcient, (2) technology to report emergently is not available, and (3) timely is a more recognizable and common term. FDA agrees in part. The agency considers attempts at unauthorized use of identiÞcation codes and passwords to be extremely serious because such attempts signal potential electronic signature and electronic record falsiÞcation, data corruption, or worse — consequences that could also ultimately be very costly to organizations. In FDA’s view, the signiÞcance of such attempts requires the immediate and urgent attention of appropriate security personnel in the same manner that individuals would respond to a Þre alarm. To clarify its intent with a more widely recognized term, the agency is replacing ‘‘emergent’’ with ‘‘immediate and urgent’’ in the Þnal rule. The agency believes that the same technology that accepts or rejects an idenCopyright © 2004 CRC Press, LLC


206


tiÞcation code and password can be used to relay to security personnel an appropriate message regarding attempted misuse. 134. One comment suggested that the word ‘‘any’’ be deleted from the phrase ‘‘any attempts’’ in proposed § 11.300(d) because it is excessive. Another comment, noting that the question of attempts to enter a system or access a Þle by unauthorized personnel is very serious, urged the agency to substitute ‘‘all’’ for ‘‘any.’’ This comment added that there are devices on the market that can be used by unauthorized individuals to locate personal identiÞcation codes and passwords. The agency believes the word ‘‘any’’ is sufÞciently broad to cover all attempts at misuse of identiÞcation codes and passwords, and rejects the suggestion to delete the word. If the word ‘‘any’’ were deleted, laxity could result from any inference that persons are less likely to be caught in an essentially permissive, nonvigilant system. FDA is aware of the ‘‘snifÞng’’ devices referred to by one comment and cautions persons to establish suitable countermeasures against them. 135. One comment suggested that proposed § 11.300(d) be deleted because it is impractical, especially when simple typing errors are made. Another suggested that this section pertain to access to electronic records, not just the system, on the basis that simple miskeys may be typed when accessing a system. As discussed in comments 133 and 134 of this document, the agency believes this provision is necessary and reasonable. The agency’s security concerns extend to system as well as record access. Once having gained unauthorized system access, an individual could conceivably alter passwords to mask further intrusion and misdeeds. If this section were removed, falsiÞcations would be more probable to the extent that some establishments would not alert security personnel. However, the agency advises that a simple typing error may not indicate an unauthorized use attempt, although a pattern of such errors, especially in short succession, or such an apparent error executed when the individual who ‘‘owns’’ that identiÞcation code or password is deceased, absent, or otherwise known to be unavailable, could signal a security problem that should not be ignored. FDA notes that this section offers organizations maximum latitude in deciding what they perceive to be attempts at unauthorized use. 136. One comment suggested substituting the phrase ‘‘electronic signature’’ for ‘‘passwords and/or identiÞcation codes.’’ The agency disagrees with this comment because the net effect of the revision might be to ignore attempted misuse of important elements of an electronic signature such as a ‘‘password’’ attack on a system. 137. Several comments argued that: (1) It is not necessary to report misuse attempts simultaneously to management when reporting to the appropriate security unit, (2) security units would respond to management in accordance with their established procedures and lines of authority, and (3) management would not always be involved. The agency agrees that not every misuse attempt would have to be reported simultaneously to an organization’s management if the security unit that was alerted responded appropriately. FDA notes, however, that some apparent security breeches could be serious enough to warrant management’s immediate and urgent attention. The agency has revised proposed § 11.300(d) to give organizations maximum ßex-



Appendix I

207

ibility in establishing criteria for management notiÞcation. Accordingly, § 11.300(d) now states that controls for identiÞcation codes/passwords must include: Use of transaction safeguards to prevent unauthorized use of passwords and/or identiÞcation codes, and to detect and report in an immediate and urgent manner any attempts at their unauthorized use to the system security unit, and, as appropriate, to organizational management.

138. Proposed § 11.300(e) states that controls for identiÞcation codes/passwords must include initial and periodic testing of devices, such as tokens or cards, bearing identifying information, for proper function. Many comments objected to this proposed device testing requirement as unnecessary because it is part of system validation and because devices are access failsafe in that nonworking devices would deny rather than permit system access. The comments suggested revising this section to require that failed devices deny user access. One comment stated that § 11.300(e) is unclear on the meaning of ‘‘identifying information’’ and that the phrase ‘‘tokens or cards’’ is redundant because cards are a form of tokens. FDA wishes to clarify the reason for this proposed requirement, and to emphasize that proper device functioning includes, in addition to system access, the correctness of the identifying information and security performance attributes. Testing for system access alone could fail to discern signiÞcant unauthorized device alterations. If, for example, a device has been modiÞed to change the identifying information, system access may still be allowed, which would enable someone to assume the identity of another person. In addition, devices may have been changed to grant individuals additional system privileges and action authorizations beyond those granted by the organization. Of lesser signiÞcance would be simple wear and tear on such devices, which result in reduced performance. For instance, a bar code may not be read with the same consistent accuracy as intended if the code becomes marred, stained, or otherwise disÞgured. Access may be granted, but only after many more scannings than desired. The agency expects that device testing would detect such defects. Because validation of electronic signature systems would not cover unauthorized device modiÞcations, or subsequent wear and tear, validation would not obviate the need for periodic testing. The agency notes that § 11.300(e) does not limit the types of devices organizations may use. In addition, not all tokens may be cards, and identifying information is intended to include identiÞcation codes and passwords. Therefore, FDA has revised proposed § 11.300(e) to clarify the agency’s intent and to be consistent with § 11.300(c). Revised § 11.300(e) requires initial and periodic testing of devices, such as tokens or cards, that bear or generate identiÞcation code or password information to ensure that they function properly and have not been altered in an unauthorized manner.

XIV. PAPERWORK REDUCTION ACT OF 1995 This Þnal rule contains information collection provisions that are subject to review by the OfÞce of Management and Budget (OMB) under the Paperwork Reduction Copyright © 2004 CRC Press, LLC


208


Act of 1995 (44 U.S.C. 3501–3520). Therefore, in accordance with 5 CFR 1320, the title, description, and description of respondents of the collection of information requirements are shown below with an estimate of the annual reporting and recordkeeping burdens. Included in the estimate is the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Most of the burden created by the information collection provision of this Þnal rule will be a one-time burden associated with the creation of standard operating procedures, validation, and certiÞcation. The agency anticipates the use of electronic media will substantially reduce the paperwork burden associated with maintaining FDA-required records. Title: Electronic records; Electronic signatures. Description: FDA is issuing regulations that provide criteria for acceptance of electronic records, electronic signatures, and handwritten signatures executed to electronic records as equivalent to paper records. Rules apply to any FDA records requirements unless speciÞc restrictions are issued in the future. Records required to be submitted to FDA may be submitted electronically, provided the agency has stated its ability to accept the records electronically in an agency established public docket. Description of Respondents: Businesses and other for-proÞt organizations, state or local governments, Federal agencies, and nonproÞt institutions. Although the August 31, 1994, proposed rule (59 FR 45160) provided a 90-day comment period under the Paperwork Reduction Act of 1980, FDA is providing an additional opportunity for public comment under the Paperwork Reduction Act of 1995, which was enacted after the expiration of the comment period and applies to this Þnal rule. Therefore, FDA now invites comments on: (1) Whether the proposed collection of information is necessary for the proper performance of FDA’s functions, including whether the information will have practical utility; (2) the accuracy of FDA’s estimate of the burden of the proposed collection of information, including the validity of the methodology and assumptions used; (3) ways to enhance the quality, utility, and clarity of the information to be collected; and (4) ways to minimize the burden of the collection of information on respondents, including through the use of automated collection techniques, when appropriate, and other forms of information technology. Individuals and organizations may submit comments on the information collection provisions of this Þnal rule by May 19, 1997. Comments should be directed to the Dockets Management Branch (address above). At the close of the 60-day comment period, FDA will review the comments received, revise the information collection provisions as necessary, and submit these provisions to OMB for review and approval. FDA will publish a notice in the Federal Register when the information collection provisions are submitted to OMB, and an opportunity for public comment to OMB will be provided at that time. Prior to the effective date of this Þnal rule, FDA will publish a notice in the Federal Register of OMB’s decision to approve, modify, or disapprove the information collection provisions. An agency may not conduct or sponsor, and a person is not required to



Appendix I

209

TABLE 1 ESTIMATED ANNUAL RECORDKEEPING BURDEN 21 CFR Section

Annual No. of Recordkeepers

Hours per Recordkeeper

Total Hours

11.10

50

40

2,000

11.30 11.50 11.300 Total annual burden hours

50 50 5o

40 40 40

2,000 2,000 2,000 8,000

TABLE 2 ESTIMATED ANNUAL REPORTING BURDEN 21 CFR Section

Annual No. of Respondents

Hours per Response

11.100

1,000

1

Total annual burden hours

Total Burden Hours 1,000 1,000

respond to, a collection of information unless it displays a currently valid OMB control number.

XV. ENVIRONMENTAL IMPACT The agency has determined under 21 CFR 25.24(a)(8) that this action is of a type that does not individually or cumulatively have a signiÞcant effect on the human environment. Therefore, neither an environmental assessment nor an environmental impact statement is required.

XVI. ANALYSIS OF IMPACTS FDA has examined the impacts of the Þnal rule under Executive Order 12866, under the Regulatory Flexibility Act (5 U.S.C. 601–612), and under the Unfunded Mandates Reform Act (Pub. L. 104–4). Executive Order 12866 directs agencies to assess all costs and beneÞts of available regulatory alternatives and, when regulation is necessary, to select regulatory approaches that maximize net beneÞts (including potential economic, environmental, public health and safety, and other advantages; and distributive impacts and equity). Unless an agency certiÞes that a rule will not have a signiÞcant economic impact on a substantial number of small entities, the Regulatory Flexibility Act requires an analysis of regulatory options that would minimize any signiÞcant impact of a rule on small entities. The Unfunded Mandates Reform Copyright © 2004 CRC Press, LLC


210


Act requires that agencies prepare an assessment of anticipated costs and beneÞts before proposing any rule that may result in an annual expenditure by State, local and tribal governments, in the aggregate, or by the private sector, of $100 million (adjusted annually for inßation). The agency believes that this Þnal rule is consistent with the regulatory philosophy and principles identiÞed in the Executive Order. This rule permits persons to maintain any FDA required record or report in electronic format. It also permits FDA to accept electronic records, electronic signatures, and handwritten signatures executed to electronic records as equivalent to paper records and handwritten signatures executed on paper. The rule applies to any paper records required by statute or agency regulations. The rule was substantially inßuenced by comments to the ANPRM and the proposed rule. The provisions of this rule permit the use of electronic technology under conditions that the agency believes are necessary to ensure the integrity of electronic systems, records, and signatures, and the ability of the agency to protect and promote the public health. This rule is a signiÞcant regulatory action as deÞned by the Executive Order and is subject to review under the Executive Order. This rule does not impose any mandates on State, local, or tribal governments, nor is it a signiÞcant regulatory action under the Unfunded Mandates Reform Act. The activities regulated by this rule are voluntary; no entity is required by this rule to maintain or submit records electronically if it does not wish to do so. Presumably, no Þrm (or other regulated entity) will implement electronic recordkeeping unless the beneÞts to that Þrm are expected to exceed any costs (including capital and maintenance costs). Thus, the industry will incur no net costs as a result of this rule. Based on the fact that the activities regulated by this rule are entirely voluntary and will not have any net adverse effects on small entities, the Commissioner of Food and Drugs certiÞes that this rule will not have a signiÞcant economic impact on a substantial number of small entities. Therefore, under the Regulatory Flexibility Act, no further regulatory ßexibility analysis is required. Although no further analysis is required, in developing this rule, FDA has considered the impact of the rule on small entities. The agency has also considered various regulatory options to maximize the net beneÞts of the rule to small entities without compromising the integrity of electronic systems, records, and signatures, or the agency’s ability to protect and promote the public health. The following analysis brießy examines the potential impact of this rule on small businesses and other small entities, and describes the measures that FDA incorporated in this Þnal rule to reduce the costs of applying electronic record/signature systems consistent with the objectives of the rule. This analysis includes each of the elements required for a Þnal regulatory ßexibility analysis under 5 U.S.C. 604(a).

A. OBJECTIVES The purpose of this rule is to permit the use of a technology that was not contemplated when most existing FDA regulations were written, without undermining in any way the integrity of records and reports or the ability of FDA to carry out its statutory Copyright © 2004 CRC Press, LLC


Appendix I

211

health protection mandate. The rule will permit regulated industry and FDA to operate with greater ßexibility, in ways that will improve both the efÞciency and the speed of industry’s operations and the regulatory process. At the same time, it ensures that individuals will assign the same level of importance to afÞxing an electronic signature, and the records to which that signature attests, as they currently do to a handwritten signature.

B. SMALL ENTITIES AFFECTED This rule potentially affects all large and small entities that are required by any statute administered by FDA, or any FDA regulation, to keep records or make reports or other submissions to FDA, including small businesses, nonproÞt organizations, and small government entities. Because the rule affects such a broad range of industries, no data currently exist to estimate precisely the total number of small entities that will potentially beneÞt from the rule, but the number is substantial. For example, within the medical devices industry alone, the Small Business Administration (SBA) estimates that over 3,221 Þrms are small businesses (i.e., have fewer than 500 employees). SBA also estimates that 504 pharmaceutical Þrms are small businesses with fewer than 500 employees. Of the approximately 2,204 registered blood and plasma establishments that are neither government-owned nor part of the American Red Cross, most are nonproÞt establishments that are not nationally dominant and thus may be small entities as deÞned by the Regulatory Flexibility Act. Not all submissions will immediately be acceptable electronically, even if the submission and the electronic record conform to the criteria set forth in this rule. A particular required submission will be acceptable in electronic form only after it has been identiÞed to this effect in public docket 92S–0251. (The agency unit that can receive that electronic submission will also be identiÞed in the docket.) Thus, although all small entities subject to FDA regulations are potentially affected by this rule, the rule will actually only beneÞt those that: (1) Are required to submit records or other documents that have been identiÞed in the public docket as acceptable if submitted electronically, and (2) choose this method of submission, instead of traditional paper record submissions. The potential range of submissions includes such records as new drug applications, medical device premarket notiÞcations, food additive petitions, and medicated feed applications. These, and all other required submissions, will be considered by FDA as candidates for optional electronic format. Although the beneÞts of making electronic submissions to FDA will be phased in over time, as the agency accepts more submissions in electronic form, Þrms can, upon the rule’s effective date, immediately beneÞt from using electronic records/signatures for records they are required to keep, but not submit to FDA. Such records include, but are not limited to: Pharmaceutical and medical device batch production records, complaint records, and food processing records. Some small entities will be affected by this rule even if they are not among the industries regulated by FDA. Because it will increase the market demand for certain types of software (e.g., document management, signature, and encryption software) and services (e.g., digital notaries and digital signature certiÞcation authorities), this Copyright © 2004 CRC Press, LLC


212


rule will beneÞt some small Þrms engaged in developing and providing those products and services.

C. DESCRIPTION

OF THE IMPACT

For any paper record that an entity is required to keep under existing statutes or FDA regulations, FDA will now accept an electronic record instead of a paper one, as long as the electronic record conforms to the requirements of this rule. FDA will also consider an electronic signature to be equivalent to a handwritten signature if it meets the requirements of this rule. Thus, entities regulated by FDA may, if they choose, submit required records and authorizations to the agency electronically once those records have been listed in the docket as acceptable in electronic form. This action is voluntary; paper records and handwritten signatures are still fully acceptable. No entity will be required to change the way it is currently allowed to submit paper records to the agency. 1. Benefits and costs For any Þrm choosing to convert to electronic recordkeeping, the direct beneÞts are expected to include: (1) Improved ability for the Þrm to analyze trends, problems, etc., enhancing internal evaluation and quality control; (2) Reduced data entry errors, due to automated checks; (3) Reduced costs of storage space; (4) Reduced shipping costs for data transmission to FDA; and (5) More efÞcient FDA reviews and approvals of FDA-regulated products. No small entity will be required to convert to electronic submissions. Furthermore, it is expected that no individual Þrm, or other entity, will choose the electronic option unless that Þrm Þnds that the beneÞts to the Þrm from conversion will exceed any conversion costs. There may be some small entities that currently submit records on paper, but archive records electronically. These entities will need to ensure that their existing electronic systems conform to the requirements for electronic recordkeeping described in this rule. Once they have done so, however, they may also take advantage of all the other beneÞts of electronic recordkeeping. Therefore, no individual small entity is expected to experience direct costs that exceed beneÞts as a result of this rule. Furthermore, because almost all of the rule’s provisions reßect contemporary security measures and controls that respondents to the ANPRM identiÞed, most Þrms should have to make few, if any, modiÞcations to their systems. For entities that do choose electronic recordkeeping, the magnitude of the costs associated with doing so will depend on several factors, such as the level of appropriate computer hardware and software already in place in a given Þrm, the types of conforming technologies selected, and the size and dispersion of the Þrm. For example, biometric signature technologies may be more expensive than nonbiometric



Appendix I

213

technologies; Þrms that choose the former technology may encounter relatively higher costs. Large, geographically dispersed Þrms may need some institutional security procedures that smaller Þrms, with fewer persons in more geographically concentrated areas, may not need. Firms that require wholesale technology replacements in order to adopt electronic record/signature technology may face much higher costs than those that require only minor modiÞcations (e.g., because they already have similar technology for internal security and quality control purposes). Among the Þrms that must undertake major changes to implement electronic recordkeeping, costs will be lower for those able to undertake these changes simultaneously with other planned computer and security upgrades. New Þrms entering the market may have a slight advantage in implementing technologies that conform with this rule, because the technologies and associated procedures can be put in place as part of the general startup. 2. Compliance requirements If a small entity chooses to keep electronic records and/or make electronic submissions, it must do so in ways that conform to the requirements for electronic records and electronic signatures set forth in this rule. These requirements, described previously in section II. of this document, involve measures designed to ensure the integrity of system operations, of information stored in the system, and of the authorized signatures afÞxed to electronic records. The requirements apply to all small (and large) entities in all industry sectors regulated by FDA. The agency believes that because the rule is ßexible and reßects contemporary standards, Þrms should have no difÞculty in putting in place the needed systems and controls. However, to assist Þrms in meeting the provisions of this rule, FDA may hold public meetings and publish more detailed guidance. Firms may contact FDA’s Industry and Small Business Liaison Staff, HF–50, at 5600 Fishers Lane, Rockville, MD 20857 (301–827–3430) for more information. 3. Professional skills required If a Þrm elects electronic recordkeeping and submissions, it must take steps to ensure that all persons involved in developing, maintaining, and using electronic records and electronic signature systems have the education, training, and experience to perform the tasks involved. The level of training and experience that will be required depends on the tasks that the person performs. For example, an individual whose sole involvement with electronic records is infrequent might only need sufÞcient training to understand and use the required procedures. On the other hand, an individual involved in developing an electronic record system for a Þrm wishing to convert from a paper recordkeeping system would probably need more education or training in computer systems and software design and implementation. In addition, FDA expects that such a person would also have speciÞc on-the-job training and experience related to the particular type of records kept by that Þrm. The relevant education, training, and experience of each individual involved in developing, maintaining, or using electronic records/submissions must be docu-



214


mented. However, no speciÞc examinations or credentials for these individuals are required by the rule.

D. MINIMIZING

THE

BURDEN

ON

SMALL ENTITIES

This rule includes several conditions that an electronic record or signature must meet in order to be acceptable as an alternative to a paper record or handwritten signature. These conditions are necessary to permit the agency to protect and promote the public health. For example, FDA must retain the ability to audit records to detect unauthorized modiÞcations, simple errors, and to deter falsiÞcation. Whereas there are many scientiÞc techniques to show changes in paper records (e.g., analysis of the paper, signs of erasures, and handwriting analysis), these methods do not apply to electronic records. For electronic records and submissions to have the same integrity as paper records, they must be developed, maintained, and used under circumstances that make it difÞcult for them to be inappropriately modiÞed. Without these assurances, FDA’s objective of enabling electronic records and signatures to have standing equal to paper records and handwritten signatures, and to satisfy the requirements of existing statutes and regulations, cannot be met. Within these constraints, FDA has attempted to select alternatives that provide as much ßexibility as practicable without endangering the integrity of the electronic records. The agency decided not to make the required extent and stringency of controls dependent on the type of record or transactions, so that Þrms can decide for themselves what level of controls are worthwhile in each case. For example, FDA chose to give Þrms maximum ßexibility in determining: (1) The circumstances under which management would have to be notiÞed of security problems, (2) the means by which Þrms achieve the required link between an electronic signature and an electronic record, (3) the circumstances under which extra security and authentication measures are warranted in open systems, (4) when to use operational system checks to ensure proper event sequencing, and (5) when to use terminal checks to ensure that data and instructions originate from a valid source. Numerous other speciÞc considerations were addressed in the public comments to the proposed rule. A summary of the issues raised by those comments, the agency’s assessment of these issues, and any changes made in the proposed rule as a result of these comments is presented earlier in this preamble. FDA rejected alternatives for limiting potentially acceptable electronic submissions to a particular category, and for issuing different electronic submissions standards for small and large entities. The former alternative would unnecessarily limit the potential beneÞts of this rule; whereas the latter alternative would threaten the integrity of electronic records and submissions from small entities. As discussed previously in this preamble, FDA rejected comments that suggested a total of 17 additional more stringent controls that might be more expensive to implement. These include: (1) Examination and certiÞcation oÞndividuals who perform certain important tasks, (2) exclusive use of cryptographic methods to link electronic signatures to Copyright © 2004 CRC Press, LLC


Appendix I

215

electronic records, (3) controls for each possible combination of a two factored authentication method, (4) controls for each different type of identiÞcation card, and (5) recording in audit trails the reason why records were changed. List of Subjects in 21 CFR Part 11 Administrative practice and procedure, Electronic records, Electronic signatures, Reporting and recordkeeping requirements. Therefore, under the Federal Food, Drug, and Cosmetic Act, the Public Health Service Act, and under authority delegated to the Commissioner of Food and Drugs, Title 21, Chapter I of the Code of Federal Regulations is amended by adding part 11 to read as follows:

PART 11 — ELECTRONIC RECORDS; ELECTRONIC SIGNATURES SUBPART A — GENERAL PROVISIONS Sec. 11.1 Scope. 11.2 Implementation. 11.3 DeÞnitions.

SUBPART B — ELECTRONIC RECORDS 11.10 11.30 11.50 11.70

Controls for closed systems. Controls for open systems. Signature manifestations. Signature/record linking.

SUBPART C — ELECTRONIC SIGNATURES 11.100 General requirements. 11.200 Electronic signature components and controls. 11.300 Controls for identiÞcation codes/passwords. Authority: Secs. 201–903 of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 321–393); sec. 351 of the Public Health Service Act (42 U.S.C. 262).

SUBPART A — GENERAL PROVISIONS § 11.1 Scope. (a) The regulations in this part set forth the criteria under which the agency considers electronic records, electronic signatures, and handwritten signatures executed to electronic records to be trustworthy, reliable, and generally equivalent to paper records and handwritten signatures executed on paper. (b) This part applies to records inelectronic form that are created, modiÞed, maintained, archived, retrieved, or transmitted, under any records requireCopyright © 2004 CRC Press, LLC


216


ments set forth in agency regulations. This part also applies to electronic records submitted to the agency under requirements of the Federal Food, Drug, and Cosmetic Act and the Public Health Service Act, even if such records are not speciÞcally identiÞed in agency regulations. However, this part does not apply to paper records that are, or have been, transmitted by electronic means. (c) Where electronic signatures and their associated electronic records meet the requirements of this part, the agency will consider the electronic signatures to be equivalent to full handwritten signatures, initials, and other general signings as required by agency regulations, unless speciÞcally excepted by regulation(s) effective on or after August 20, 1997. (d) Electronic records that meet the requirements of this part may be used in lieu of paper records, in accordance with § 11.2, unless paper records are speciÞcally required. (e) Computer systems (includinghardware and software), controls, and attendant documentation maintained under this part shall be readily available for, and subject to, FDA inspection. § 11.2 Implementation. (a) For records required to be maintained but not submitted to the agency, persons may use electronic records in lieu of paper records or electronic signatures in lieu of traditional signatures, in whole or in part, provided that the requirements of this part are met. (b) For records submitted to the agency, persons may use electronic records in lieu of paper records or electronic signatures in lieu of traditional signatures, in whole or in part, provided that: (1) The requirements of this part are met; and (2) The document or parts of adocument to be submitted have been identiÞed in public docket No. 92S–0251 as being the type of submission the agency accepts in electronic form. This docket will identify speciÞcally what types of documents or parts of documents are acceptable for submission in electronic form without paper records and the agency receiving unit(s) (e.g., speciÞc center, ofÞce, division, branch) to which such submissions may be made. Documents to agency receiving unit(s) not speciÞed in the public docket will not be considered as ofÞcial if they are submitted in electronic form; paper forms of such documents will be considered as ofÞcial and must accompany any electronic records. Persons are expected to consult with the intended agency receiving unit for details on how (e.g., method of transmission, media, Þle formats, and technical protocols) and whether to proceed with the electronic submission.



Appendix I

217

§ 11.3 Definitions. (a) The deÞnitions and interpretations of terms contained in section 201 of the act apply to those terms when used in this part. (b) The following deÞnitions of terms also apply to this part: (1) Act means the Federal Food, Drug, and Cosmetic Act (secs. 201–903 (21 U.S.C. 321–393)). (2) Agency means the Food and Drug Administration. (3) Biometrics means a method of verifying an individual’s identity based on measurement of the individual’s physical feature(s) or repeatable action(s) where those features and/or actions are both unique to that individual and measurable. (4) Closed system means an environment in which system access is controlled by persons who are responsible for the content of electronic records that are on the system. (5) Digital signature means 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 veriÞed. (6) Electronic record means any combination of text, graphics, data, audio, pictorial, or other information representation in digital form that is created, modiÞed, maintained, archived, retrieved, or distributed by a computer system. (7) Electronic signature means a computer data compilation of any symbol or series of symbols executed, adopted, or authorized by an individual to be the legally binding equivalent of the individual’s handwritten signature. (8) Handwritten signature means the scripted name or legal mark of an individual handwritten by that individual and executed or adopted with the present intention to authenticate a writing in a permanent form. The act of signing with a writing or marking instrument such as a pen or stylus is preserved. The scripted name or legal mark, while conventionally applied to paper, may also be applied to other devices that capture the name or mark. (9) Open system means an environment in which system access is not controlled by persons who are responsible for the content of electronic records that are on the system.

SUBPART B — ELECTRONIC RECORDS § 11.10 Controls for closed systems. Persons who use closed systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, when appropriate, the conÞdentiality of electronic records, and to



218


ensure that the signer cannot readily repudiate the signed record as not genuine. Such procedures and controls shall include the following: (a) Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. (b) The ability to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency. Persons should contact the agency if there are any questions regarding the ability of the agency to perform such review and copying of the electronic records. (c) Protection of records to enable their accurate and ready retrieval throughout the records retention period. (d) Limiting system access to authorized individuals. (e) Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying. (f) Use of operational system checks to enforce permitted sequencing of steps and events, as appropriate. (g) Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand. (h) Use of device (e.g., terminal) checks to determine, as appropriate, the validity of the source of data input or operational instruction. (i) Determination that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks. (j) The establishment of, and adherence to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures, in order to deter record and signature falsiÞcation. (k) Use of appropriate controls over systems documentation including: (1)Adequate controls over the distribution of, access to, and use of documentation for system operation and maintenance. (2)Revision and change control procedures to maintain an audit trail that documents time-sequenced development and modiÞcation of systems documentation. § 11.30 Controls for open systems. Persons who use open systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, as appropriate, the conÞdentiality of electronic records from the point of their creation to the point of their receipt. Such procedures and controls shall Copyright © 2004 CRC Press, LLC


Appendix I

219

include those identiÞed in § 11.10, as appropriate, and additional measures such as document encryption and use of appropriate digital signature standards to ensure, as necessary under the circumstances, record authenticity, integrity, and conÞdentiality. § 11.50 Signature manifestations. (a Signed electronic records shall contain information associated with the signing that clearly indicates all of the following: (1) The printed name of the signer; (2) The date and time when the signature was executed; and (3) The meaning (such as review,approval, responsibility, or authorship) associated with the signature. (b) The items identiÞed in paragraphs (a)(1), (a)(2), and (a)(3) of this section shall be subject to the same controls as for electronic records and shall be included as part of any human readable form of the electronic record (such as electronic display or printout). § 11.70 Signature/record linking. Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means.

SUBPART C — ELECTRONIC SIGNATURES § 11.100 General requirements. (a) Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else. (b) Before an organization establishes, assigns, certiÞes, or otherwise sanctions an individual’s electronic signature, or any element of such electronic signature, the organization shall verify the identity of the individual. (c) Persons using electronic signatures shall, prior to or at the time of such use, certify to the agency that the electronic signatures in their system, used on or after August 20, 1997, are intended to be the legally binding equivalent of traditional handwritten signatures. (1) The certiÞcation shall be submitted in paper form and signed with a traditional handwritten signature, to the OfÞce of Regional Operations (HFC–100), 5600 Fishers Lane, Rockville, MD 20857. (2) Persons using electronic signatures shall, upon agency request, provide additional certiÞcation or testimony that a speciÞc electronic signature is the legally binding equivalent of the signer’s handwritten signature. Copyright © 2004 CRC Press, LLC


220


§ 11.200 Electronic signature components and controls. (a) Electronic signatures that are not based upon biometrics shall: (1) Employ at least two distinct identiÞcation components such as an identiÞcation code and password. (i) When an individual executes a series of signings during a single, continuous period of controlled system access, the Þrst signing shall be executed using all electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual. (ii) When an individual executes one or more signings not performed during a single, continuous period of controlled system access, each signing shall be executed using all of the electronic signature components. (2) Be used only by their genuine owners; and (3) Be administered and executed to ensure that attempted use of an individual’s electronic signature by anyone other than its genuine owner requires collaboration of two or more individuals. (b) Electronic signatures based upon biometrics shall be designed to ensure that they cannot be used by anyone other than their genuine owners. § 11.300 Controls for identification codes/passwords. Persons who use electronic signatures based upon use of identiÞcation codes in combination with passwords shall employ controls to ensure their security and integrity. Such controls shall include: (a) Maintaining the uniqueness of each combined identiÞcation code and password, such that no two individuals have the same combination of identiÞcation code and password. (b) Ensuring that identiÞcation code and password issuances are periodically checked, recalled, or revised (e.g., to cover such events as password aging). (c) Following loss management procedures to electronically deauthorize lost, stolen, missing, or otherwise potentially compromised tokens, cards, and other devices that bear or generate identiÞcation code or password information, and to issue temporary or permanent replacements using suitable, rigorous controls. (d) Use of transaction safeguards to prevent unauthorized use of passwords and/or identiÞcation codes, and to detect and report in an immediate and urgent manner any attempts at their unauthorized use to the system security unit, and, as appropriate, to organizational management. (e) Initial and periodic testing of devices, such as tokens or cards, that bear or generate identiÞcation code or password information to ensure that they function properly and have not been altered in an unauthorized manner.



Appendix I

221

Dated: March 11, 1997. William B. Schultz, Deputy Commissioner for Policy. [FR Doc. 97–6833 Filed 3–20–97; 8:45 am] BILLING CODE 4160–01–F

REFERENCES Electronic Records: Electronic Signatures; Final Rule. 21 CFR Part 11, Vol. 62, No. 54, 13429. March 20, 1997. Food and Drug Administration. Code of Federal Regulations. Washington D.C.: U.S. Government Printing OfÞce. Electronic Records: Electronic Signatures; Final Rule. 1997. Food and Drug Administration. Title 21 Code of Federal Regulations Part 11. Washington D.C.: U.S. Government Printing OfÞce. Federal Food and Drug Act. 1906. Bureau of Chemistry. General Principles of Software Validation, Draft Guidelines version 1.1. June 1997. Center for Devices and Radiological Health, Food and Drug Administration. Washington D.C.: U.S. Government Printing OfÞce. Glossary of Computerized System and Software Development Terminology August 1995. Code of Regulations Food and Drug Administration, Division of Field Investigations, OfÞce of Regional Operations, OfÞce of Regulatory Affairs. Good Manufacturing Practices for Finished Pharmaceuticals. 2000. Food and Drug Administration. Title 21 Code of Federal Regulations Parts 210 and 211. Washington D.C.: U.S. Government Printing OfÞce. Gough, Janet and David Nettleton. Commercial Off-the-Shelf Software Validation for 21 CFR Part 11 Compliance. 2003 Davis Horwood Interntional Publishing: Godalming, Surrey, UK and Parenteral Drug Association: Bethesda, Maryland, USA. Gough, Janet and Monica Grimali. 2001. The Internal Quality Audit. Davis Horwood International Publishing: Godalming, Surrey, UK and Parenteral Drug Association: Bethesda, Maryland, USA. Gough, Janet. Hosting the Compliance Inspection. 2001. Davis Horwood International Publishing: Godalming, Surrey, UK and Parenteral Drug Association: Bethesda, Maryland, USA. Guidance for Industry; Part 11, Electronic Records, Electronic Signatures Scope and Applicability. February 2003. Food and Drug Administration. Code of Federal Regulations. Washington D.C.: U.S. Government Printing OfÞce. Guidance for Industry and for FDA Staff: General Principles of Software Validation. Draft. June 1997. Center for Devices and Radiological Health, Food and Drug Administration. Code of Federal Regulations. Washington D.C.: U.S. Government Printing OfÞce. Guidance for Industry, Computerized Systems Used in Clinical Trials. April 1999. Food and Drug Administration. Guidelines for the Validation of Computer Controlled Systems. September 1995. Montreal: PMAC/POS-Montreal Technological Workgroup. Health Insurance Reform: Security Standards; Final Rule. United States Public Welfare and Human Services Title 45 Code of Federal Regulations Parts 160, 162, and 164. Washington D.C.: U.S. Government Printing OfÞce.



222


Good Clinical Practice: Consolidated Guideline. 1995. International Conference of Harmonisation. CPMP/ICH/135/95/Step 5. Geneva, Switzerland: International Conference on Harmonization. Medical Device Software Validation, Guidance for Industry, General Principles of Software Validation. Draft. June 9, 1997. Center for Devices and Radiological Health. Food and Drug Administration. Quality System Regulation. 1996. Food and Drug Adminisration. Title 21 Code of Federal Regulations Washington D.C.: U.S. Government Printing OfÞce. Security and Electronic Signature Standards; Proposed Rule. August 1998. United States Public Welfare and Human Services. Title 45 Code of Federal Regulations Part 142. Washington D.C.: U.S. Government Printing OfÞce. Software Development Activities Reference Materials and Training Aids for Investigators. 1996. Food and Drug Administration. Washington D.C.: U.S. Government Printing OfÞce.


PH2164_Appendix II.fm Page 235 Wednesday, November 19, 2003 11:36 AM

Appendix II

235



236




Appendix II


237


238




Appendix II


239


240




Appendix II


241


242




Appendix II


243


244




Appendix II


245


246



PH2164_Appendix III.fm Page 247 Monday, November 24, 2003 1:32 PM

Appendix III FEDERAL REGISTER Thursday, February 20, 2003

PART II DEPARTMENT OF HEALTH AND HUMAN SERVICES OFFICE

OF THE

SECRETARY

45 CFR PARTS 160, 162, AND 164 HEALTH INSURANCE REFORM: SECURITY STANDARDS; FINAL RULE DEPARTMENT OF HEALTH AND HUMAN SERVICES OFFICE

OF THE

SECRETARY

45 CFR Parts 160, 162, and 164 [CMS–0049–F] RIN 0938–AI57

HEALTH INSURANCE REFORM: SECURITY STANDARDS AGENCY: Centers for Medicare & Medicaid Services (CMS), HHS. ACTION: Final rule.

This Þnal rule adopts standards for the security of electronic protected health information to be implemented by health plans, health care clearinghouses, and certain health care providers. The use of the security standards will improve the Medicare and Medicaid programs, and other Federal health programs and private health programs, and the effectiveness and efÞciency of the health care industry in general by establishing a level of protection for certain electronic health information. This Þnal rule implements some of the requirements of the Administrative SimpliÞcation subtitle of the Health Insurance Portability and Accountability Act of 1996 (HIPAA).

SUMMARY:



248


DATES: Effective Date: These regulations are effective on April 21, 2003. Compliance Date: Covered entities, with the exception of small health plans, must comply with the requirements of this Þnal rule by April 21, 2005. Small health plans must comply with the requirements of this Þnal rule by April 21, 2006. FOR FURTHER INFORMATION CONTACT:

William Schooler, (410) 786–0089. SUPPLEMENTARY INFORMATION:

Availability of Copies and Electronic Access 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 $10. 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 OfÞce. The Web site address is http://www.access.gpo.gov/nara/index.html.

I. BACKGROUND The Department of Health and Human Services (HHS) Medicare Program, other Federal agencies operating health plans or providing health care, State Medicaid agencies, private health plans, health care providers, and health care clearinghouses must assure their customers (for example, patients, insured individuals, providers, and health plans) that the integrity, conÞdentiality, and availability of electronic protected health information they collect, maintain, use, or transmit is protected. The conÞdentiality of health information is threatened not only by the risk of improper access to stored information, but also by the risk of interception during electronic transmission of the information. The purpose of this Þnal rule is to adopt national standards for safeguards to protect the conÞdentiality, integrity, and availability of electronic protected health information. Currently, no standard measures exist in the health care industry that address all aspects of the security of electronic health information while it is being stored or during the exchange of that information between entities. This Þnal rule adopts standards as required under title II, subtitle F, sections 261 through 264 of the Health Insurance Portability and Accountability Act of 1996 (HIPAA), Pub. L. 104–191. These standards require measures to be taken to secure



Appendix III

249

this information while in the custody of entities covered by HIPAA (covered entities) as well as in transit between covered entities and from covered entities to others. The Congress included provisions to address the need for safeguarding electronic health information and other administrative simpliÞcation issues in HIPAA. In 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 SimpliÞcation’’ (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 subtitle F is to improve the Medicare program under title XVIII of the Act, the Medicaid program under title XIX of the Act, and the efÞciency and effectiveness of the health care system, by encouraging the development of a health information system through the establishment of standards and requirements to enable the electronic exchange of certain health information. Part C of title XI consists of sections 1171 through 1179 of the Act. These sections deÞne various terms and impose requirements on HHS, health plans, health care clearinghouses, and certain health care providers. These statutory sections are discussed in the Transactions Rule, at 65 FR 50312, on pages 50312 through 50313, and in the Þnal rules adopting Standards for Privacy of Individually IdentiÞable Health Information, published on December 28, 2000 at 65 FR 82462 (Privacy Rules), on pages 82470 through 82471, and on August 14, 2002 at 67 FR 53182. The reader is referred to those discussions. Section 1173(d) of the Act requires the Secretary of HHS to adopt security standards that take into account the technical capabilities of record systems used to maintain health information, the costs of security measures, the need to train persons who have access to health information, the value of audit trails in computerized record systems, and the needs and capabilities of small health care providers and rural health care providers. Section 1173(d) of the Act also requires that the standards ensure that a health care clearinghouse, if part of a larger organization, has policies and security procedures that isolate the activities of the clearinghouse with respect to processing information so as to prevent unauthorized access to health information by the larger organization. Section 1173(d) of the Act provides that covered entities that maintain or transmit health information are required to maintain reasonable and appropriate administrative, physical, and technical safeguards to ensure the integrity and conÞdentiality of the information and to protect against any reasonably anticipated threats or hazards to the security or integrity of the information and unauthorized use or disclosure of the information. These safeguards must also otherwise ensure compliance with the statute by the ofÞcers and employees of the covered entities.

II. GENERAL OVERVIEW OF THE PROVISIONS OF THE PROPOSED RULE On August 12, 1998, we published a proposed rule (63 FR 43242) to establish a minimum standard for security of electronic health information. We proposed that the standard would require the safeguarding of all electronic health information by covered entities. The proposed rule also proposed a standard for electronic signatures. This Þnal rule adopts only security standards. All comments concerning the



250


proposed electronic signature standard, responses to these comments, and a Þnal rule for electronic signatures will be published at a later date. A detailed discussion of the provisions of the August 12, 1998 proposed rule can be found at 63 FR 43245 through 43259. We originally proposed to add part 142, entitled ‘‘Administrative Requirements,’’ to title 45 of the Code of Federal Regulations (CFR). It has now been determined that this material will reside in subchapter C of title 45, consisting of parts 160, 162, and 164. Subpart A of part 160 contains the general provisions applicable to all the Administrative SimpliÞcation rules; other subparts of part 160 will contain other requirements applicable to all standards. Part 162 contains the standards for transactions and code sets and will contain the identiÞer standards. Part 164 contains the standards relating to privacy and security. Subpart A of part 164 contains general provisions applicable to part 164; subpart E contains the privacy standards. Subpart C of part 164, which is adopted in this Þnal rule, adopts standards for the security of electronic protected health information.

III. ANALYSIS OF, AND RESPONSES TO, PUBLIC COMMENTS ON THE PROPOSED RULE We received approximately 2,350 timely public comments on the August 12, 1998 proposed rule. The comments came from professional associations and societies, health care workers, law Þrms, health insurers, hospitals, and private individuals. We reviewed each commenter’s letter and grouped related comments. Some comments were identical. After associating like comments, we placed them in categories based on subject matter or based on the section(s) of the regulations affected and then reviewed the comments. In this section of the preamble, we summarize the provisions of the proposed regulations, summarize the related provisions in this Þnal rule, and respond to comments received concerning each area. It should be noted that the proposed Security Rule contained multiple proposed ‘‘requirements’’ and ‘‘implementation features.’’ In this Þnal rule, we replace the term ‘‘requirement’’ with ‘‘standard.’’ We also replace the phrase ‘‘implementation feature’’ with ‘‘implementation speciÞcation.’’ We do this to maintain consistency with the use of those terms as they appear in the statute, the Transactions Rule, and the Privacy Rule. Within the comment and response portion of this Þnal rule, for purposes of continuity, however, we use ‘‘requirement’’ and ‘‘implementation feature’’ when we are referring speciÞcally to matters from the proposed rule. In all other instances, we use ‘‘standard’’ and ‘‘implementation speciÞcation.’’ The proposed rule would require that each covered entity (as now described in § 160.102) engaged in the electronic maintenance or transmission of health information pertaining to individuals assess potential risks and vulnerabilities to such information in its possession in electronic form, and develop, implement, and maintain appropriate security measures to protect that information. Importantly, these measures would be required to be documented and kept current.



Appendix III

251

The proposed security standard was based on three basic concepts that were derived from the Administrative SimpliÞcation provisions of HIPAA. First, the standard should be comprehensive and coordinated to address all aspects of security. Second, it should be scalable, so that it can be effectively implemented by covered entities of all types and sizes. Third, it should not be linked to speciÞc technologies, allowing covered entities to make use of future technology advancements. The proposed standard consisted of four categories of requirements that a covered entity would have to address in order to safeguard the integrity, conÞdentiality, and availability of its electronic health information pertaining to individuals: administrative procedures, physical safeguards, technical security services, and technical mechanisms. The implementation features described the requirements in greater detail when that detail was needed. Within the four categories, the requirements and implementation features were presented in alphabetical order to convey that no one item was considered to be more important than another. The four proposed categories of requirements and implementation features were depicted in tabular form along with the electronic signature standard in a combined matrix located at Addendum 1. We also provided a glossary of terms, at Addendum 2, to facilitate a common understanding of the matrix entries, and at Addendum 3, we mapped available existing industry standards and guidelines to the proposed security requirements.

A. GENERAL ISSUES The comment process overwhelmingly validated our basic assumptions that the entities affected by this regulation are so varied in terms of installed technology, size, resources, and relative risk, that it would be impossible to dictate a speciÞc solution or set of solutions that would be useable by all covered entities. Many commenters also supported the concept of technological neutrality, which would afford them the ßexibility to select appropriate technology solutions and to adopt new technology over time. 1. Security Rule and Privacy Rule Distinctions As many commenters recognized, security and privacy are inextricably linked. The protection of the privacy of information depends in large part on the existence of security measures to protect that information. It is important that we note several distinct differences between the Privacy Rule and the Security Rule. The security standards below deÞne administrative, physical, and technical safeguards to protect the conÞdentiality, integrity, and availability of electronic protected health information. The standards require covered entities to implement basic safeguards to protect electronic protected health information from unauthorized access, alteration, deletion, and transmission. The Privacy Rule, by contrast, sets standards for how protected health information should be controlled by setting forth what uses and disclosures are authorized or required and what rights patients have with respect to their health information.



252


As is discussed more fully below, this rule narrows the scope of the information to which the safeguards must be applied from that proposed in the proposed rule, electronic health information pertaining to individuals, to protected health information in electronic form. Thus, the scope of information covered in this rule is consistent with the Privacy Rule, which addresses privacy protections for ‘‘protected health information.’’ However, the scope of the Security Rule is more limited than that of the Privacy Rule. The Privacy Rule applies to protected health information in any form, whereas this rule applies only to protected health information in electronic form. It is true that, under section 1173(d) of the Act, the Secretary has authority to cover ‘‘health information,’’ which, by statute, includes information in other than electronic form. However, because the proposed rule proposed to cover only health information in electronic form, we do not include security standards for health information in non-electronic form in this Þnal rule. We received a number of comments that pertained to privacy issues. These issues were considered in the development of the Privacy Rule and many of these comments were addressed in the preamble of the Privacy Rule. Therefore, we are referring the reader to that document for a discussion of those issues. 2. Level of Detail We solicited comments as to the level of detail expressed in the required implementation features; that is, we speciÞcally wanted to know whether commenters believe the level of detail of any proposed requirement went beyond what is necessary or appropriate. We received numerous comments expressing the view that the security standards should not be overly prescriptive because the speed with which technology is evolving could make speciÞc requirements obsolete and might in fact deter technological progress. We have accordingly written the Þnal rule to frame the standards in terms that are as generic as possible and which, generally speaking, may be met through various approaches or technologies. 3. Implementation Specifications In addition to adopting standards, this rule adopts implementation speciÞcations that provide instructions for implementing those standards. However, in some cases, the standard itself includes all the necessary instructions for implementation. In these instances, there may be no corresponding implementation speciÞcation for the standard speciÞcally set forth in the regulations text. In those instances, the standards themselves also serve as the implementation speciÞcation. In other words, in those instances, we are adopting one set of instructions as both the standard and the implementation speciÞcation. The implementation speciÞcation would, accordingly, in those instances be required. In this Þnal rule, we adopt both ‘‘required’’ and ‘‘addressable’’ implementation speciÞcations. We introduce the concept of ‘‘addressable implementation speciÞcations’’ to provide covered entities additional ßexibility with respect to compliance with the security standards. In meeting standards that contain addressable implementation speciÞcations, a covered entity will ultimately



Appendix III

253

do one of the following: (a) Implement one or more of the addressable implementation speciÞcations; (b) implement one or more alternative security measures; (c) implement a combination of both; or (d) not implement either an addressable implementation speciÞcation or an alternative security measure. In all cases, the covered entity must meet the standards, as explained below. The entity must decide whether a given addressable implementation speciÞcation is a reasonable and appropriate security measure to apply within its particular security framework. This decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. Based upon this decision the following applies: (a) If a given addressable implementation speciÞcation is determined to be reasonable and appropriate, the covered entity must implement it. (b) If a given addressable implementation speciÞcation is determined to be an inappropriate and/or unreasonable security measure for the covered entity, but the standard cannot be met without implementation of an additional security safeguard, the covered entity may implement an alternate measure that accomplishes the same end as the addressable implementation speciÞcation. An entity that meets a given standard through alternative measures must document the decision not to implement the addressable implementation speciÞcation, the rationale behind that decision, and the alternative safeguard implemented to meet the standard. For example, the addressable implementation speciÞcation for the integrity standard calls for electronic mechanisms to corroborate that data have not been altered or destroyed in an unauthorized manner (see 45 CFR 164.312(c)(2)). In a small provider’s ofÞce environment, it might well be unreasonable and inappropriate to make electronic copies of the data in question. Rather, it might well be more practical and afford a sufÞcient safeguard to make paper copies of the data. (c) A covered entity may also decide that a given implementation speciÞcation is simply not applicable (that is, neither reasonable nor appropriate) to its situation and that the standard can be met without implementation of an alternative measure in place of the addressable implementation speciÞcation. In this scenario, the covered entity must document the decision not to implement the addressable speciÞcation, the rationale behind that decision, and how the standard is being met. For example, under the information access management standard, an access establishment and modiÞcation implementation speciÞcation reads: ‘‘implement policies and procedures that, based upon the entity’s access authorization policies, establish, document, review, and modify a user’s right of access to a workstation, transaction, program, or process’’ (45 CFR 164.308(a)(4)(ii)(c)). It is possible that a small practice, with one or more individuals equally responsible for establishing and maintaining all automated patient records, will not need to establish policies and procedures



254


for granting access to that electronic protected health information because the access rights are equal for all of the individuals. a. Comment: A large number of commenters indicated that mandating 69 implementation features would result in a regulation that is too burdensome, intrusive, and difÞcult to implement. These commenters requested that the implementation features be made optional to meet the requirements. A number of other commenters requested that all implementation features be removed from the regulation. Response: Deleting the implementation speciÞcations would result in the standards being too general to understand, apply effectively, and enforce consistently. Moreover, a number of implementation speciÞcations are so basic that no covered entity could effectively protect electronic protected health information without implementing them. We selected 13 of these mandatory implementation speciÞcations based on (1) the expertise of Federal security experts and generally accepted industry practices and, (2) the recommendation for immediate implementation of certain technical and organizational practices and procedures described in Chapter 6 of For The Record: Protecting Electronic Health Information, a 1997 report by the National Research Council (NRC). These mandatory implementation speciÞcations are referred to as required implementation speciÞcations and are reßected in the NRC report’s recommendations. Risk Analysis and Risk management are found in the NRC recommendation title System Assessment; Sanction Policy is required in the Sanctions recommendation; Information system Activity Review is discussed in Audit Trails; Response and Reporting circumstances. In addition, a number of voluntary national and regional organizations have been formed to address HIPAA implementation issues and to facilitate communication among trading partners. These include the Strategic National Implementation Process (SNIP) developed under the auspices of the Workgroup for Electronic Data Interchange (WEDI), an organization named in the HIPAA statute to consult with the Secretary of HHS on HIPAA issues. Some of these organizations have developed white papers, tools, and recommended best practices addressing a number of HIPAA issues, including security. Covered entities may wish to examine these products to determine if they are relevant and useful in their own implementation efforts. A partial list of these organizations can be found at http://www.wedi/snip./org. We believe that these and other future industry-developed guidelines and/or models may provide valuable assistance to covered entities implementing these standards but must caution that HHS does not rate or endorse any such guidelines and/or models and the value of its content must be determine by the user. b. Comment: Many commenters asked us to develop guidelines and models to aid in complying with the Security Rule. Several commenters either offered to participate in the development of guidelines and models or suggested entities that should be invited to participate. Response: We agree that creation of compliance tools and guidelines for different business environments could assist covered entities to implement the HIPAA Security Rule. We plan to issue guidance documents after the publication of this Þnal rule. However, it is critical for each covered entity to establish policies and procedures that address its own unique risks and circumstances. Copyright © 2004 CRC Press, LLC


Appendix III

255

In addition, a number of voluntary national and regional organizations have been formed to address HIPAA implementation issues and to facilitate communication among trading partners. These include the Strategic National Implementation Process (SNIP) developed under the auspices of the Workgroup for Electronic Data Interchange (WEDI), an organization named in the HIPAA statute to consult with the Secretary of HHS on HIPAA issues. Some of these organizations have developed white papers, tools, and recommended best practices addressing a number of HIPAA issues, including security. Covered entities may wish to examine these products to determine if they are relevant and useful in their own implementation efforts. A partial list of these organizations can be found at http://www.snip.wedi.org.We believe that these and other future industry-developed guidelines and/or models may provide valuable assistance to covered entities implementing these standards but must caution that HHS does not rate or endorse any such guidelines and/or models and the value of its content must be determined by the user. 4. Examples Comment: We received a number of comments that demonstrated confusion regarding the purpose of the examples of security solutions that were included throughout the proposed rule. Commenters stated that they could not, or did not wish to, adopt various security measures suggested in examples. Other commenters asked that we include additional options within the examples. Some commenters referred specifically to the example provided in the proposed rule demonstrating how a small or rural provider might comply with the standards. One commenter asked for clariÞcation that the examples are not mandatory measures that are required to demonstrate compliance, but are merely meant as a guide when implementing the security standards. Another commenter expressed support for the use of examples to clarify the intent of text descriptions. Response: We wish to clarify that examples are used only as illustrations of possible approaches, and are included to serve as a springboard for ideas. The steps that a covered entity will actually need to take to comply with these regulations will be dependent upon its own particular environment and circumstances and risk assessment. The examples do not describe mandatory measures, nor do they represent the only, or even the best, way of achieving compliance. The most appropriate means of compliance for any covered entity can only be determined by that entity assessing its own risks and deciding upon the measures that would best mitigate those risks.

B. APPLICABILITY (§ 164.302) We proposed that the security standards would apply to health plans, health care clearinghouses, and to health care providers that maintain or transmit health information electronically. The proposed security standards would apply to all electronic health information maintained or transmitted, regardless of format (standard transaction or a proprietary format). No distinction would be made between internal corporate entity communication or communication external to the corporate entity. Copyright © 2004 CRC Press, LLC


256


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 other machine readable media. Transmissions over the Internet (wide-open), extranet (using Internet technology to link a business with information only accessible to collaborating parties), leased lines, dialup lines, and private networks would be included. We proposed that telephone voice response and ‘‘faxback’’ systems (a request for information made via voice using a fax machine and requested information returned via that same machine as a fax) would not be included but we solicited comments on this proposed exclusion. This Þnal rule simpliÞes the applicability statement greatly. Section 164.302 provides that the security standards apply to covered entities; the scope of the information covered is speciÞed in § 164.306 (see the discussion under that section below regarding the changes and revisions to the scope of information covered). 1. Comment: A number of commenters requested clariÞcation of who must comply with the standards. The preamble and proposed § 142.102 and § 142.302 stated: ‘‘Each person described in section 1172(a) of the Act who maintains or transmits health information shall maintain reasonable and appropriate administrative, technical, and physical safeguards.’’ Commenters suggested that this statement is in conßict with the law, which deÞnes a covered entity as a health plan, a clearinghouse, or a health care provider that conducts certain transactions electronically. The commentors apparently did not realize that section 1172(a) of the Act contains the deÞnition of covered entities. Response: Section 164.302 below makes the security standards applicable to ‘‘covered entities.’’ The term ‘‘covered entity’’ is deÞned at § 160.103 as one of the following: (1) A health plan; (2) a health care clearinghouse; (3) a health care provider who transmits any health information in electronic form in connection with a transaction covered by part 162 of title 45 of the Code of Federal Regulations (CFR). The rationale for the use and the meaning of the term ‘‘covered entity’’ is discussed in the preamble to the Privacy Rule (65 FR 82476 through 82477). As that discussion makes clear, the standards only apply to health care providers who engage electronically in the transactions for which standards have been adopted. 2. Comment: Several commenters recommended expansion of applicability, either to other speciÞc entities, or to all entities involved in health care. Others wanted to know whether the standards apply to entities such as employers, public health organizations, medical schools, universities, research organizations, plan brokers, or non-EDI providers. One commenter asked whether the standards apply to State data organizations operating in capacities other than as plans, clearinghouses, or providers. Still other commenters stated that it was inappropriate to include physicians and other health care professionals in the same category as plans and clearinghouses, arguing that providers should be subject to different, less burdensome requirements because they already protect health information. Response: The statute does not cover all health care entities that transmit or maintain individually identiÞable health information. Section 1172(a) of the Act provides that only health plans, health care clearinghouses, and certain health care providers (as discussed above) are covered. With respect to the comments regarding Copyright © 2004 CRC Press, LLC


Appendix III

257

the difference between providers and plans/clearinghouses, we have structured the Security Rule to be scalable and ßexible enough to allow different entities to implement the standards in a manner that is appropriate for their circumstances. Regarding the coverage of entities not within the jurisdiction of HIPAA, see the Privacy Rule at 82567 through 82571. 3. Comment: One commenter asked whether the standards would apply to research organizations, both to those afÞliated with health care providers and those that are not. Response: Only health plans, health care clearinghouses, and certain health care providers are required to comply with the security standards. Researchers who are members of a covered entity’s work force may be covered by the security standards as part of the covered entity. See the deÞnition of ‘‘workforce’’ at 45 CFR 160.103. Note, however, that a covered entity could, under appropriate circumstances, exclude a researcher or research division from its health care component or components (see § 164.105(a)). Researchers who are not part of the covered entity’s workforce and are not themselves covered entities are not subject to the standards. 4. Comment: Several commenters stated that internal networks and external networks should be treated differently. One commenter asked for further clariÞcation of the difference between what needs to be secured external to a corporation versus the security of data movement within an organization. Another stated that complying with the security standards for internal communications may prove difÞcult and costly to monitor and control. In contrast, one commenter stated that the existence of requirements should not depend on whether use of information is for internal or external purposes. Another commenter argued that the regulation goes beyond the intent of the law, and while communication of electronic information between entities should be covered, the law was never intended to mandate changes to an entity’s internal automated systems. One commenter requested that raw data that are only for the internal use of a facility be excluded, provided that reasonable safeguards are in place to keep the raw data under the control of the facility. Response: Section 1173(d)(2) of the Act states: Each person described in section 1172(a) who maintains or transmits health information shall maintain reasonable and appropriate administrative, technical, and physical safeguards — (A) to ensure the integrity and conÞdentiality of the information; (B) to protect against any reasonably anticipated — (i) threats or hazards to the security or integrity of the information; and (ii) unauthorized uses or disclosures of the information; and (C) otherwise to ensure compliance with this part by the ofÞcers and employees of such person. This language draws no distinction between internal and external data movement. Therefore, this Þnal rule covers electronic protected health information at rest (that is, in storage) as well as during transmission. Appropriate protections must be applied, regardless of whether the data are at rest or being transmitted. However, because each entity’s security needs are unique, the speciÞc protections determined appropriate to adequately protect information will vary and will be determined by each entity in complying with the standards (see the discussion below). Copyright © 2004 CRC Press, LLC


258


5. Comment: Several commenters found the following statement in the proposed rule (63 FR 43245) at section II.A. confusing and asked for clariÞcation: ‘‘With the exception of the security standard, transmission within a corporate entity would not be required to comply with the standards.’’ Response: In the Þnal Transactions Rule, we revised our approach concerning the transaction and code set exemptions, replacing this concept with other tests that determine whether a particular transaction is subject to those standards (see the discussion in the Transactions Rule at 65 FR 50316 through 50318). We also note that the Privacy Rule regulates a covered entity’s use, as well as disclosure, of protected health information. 6. Comment: One commenter stated that research would be hampered if proposed § 142.306(a) applied. The commenter believes that research uses of health information should be excluded or the standard should be revised to allow appropriate ßexibility for research depending on the risk to patients or subjects (for example, if the information is anonymous, there is no risk, and it would not be necessary to meet the security standards). Response: If electronic protected health information is de-identiÞed (as truly anonymous information would be), it is not covered by this rule because it is no longer electronic protected health information (see 45 CFR 164.502(d) and 164.514(a)). Electronic protected health information received, created, or maintained by a covered entity, or that is transmitted by covered entities, is covered by the security standards and must be protected. To the extent a researcher is a covered entity, the researcher must comply with these standards with respect to electronic protected health information. Otherwise, the conditions for release of such information to researchers is governed by the Privacy Rule. See, for example, 45 CFR 164.512(i), 164.514(e) and 164.502(d). These standards would not apply to the researchers as such in the latter circumstances. 7. Comment: One commenter asked to what extent individual patients are subject to the standards. For example, some telemedicine practices support the use of diagnostic systems in the patient’s home, which can be used to conduct tests and send results to a remote physician. In other cases, patients may be responsible for the Þling of insurance claims directly and will need the ability to verify facts, conÞrm receipt of claims, and so on. The commenter asked if it is the intent of the rule to include electronic transmission to or from the patient. Response: Patients are not covered entities and, thus, are not subject to these standards. With respect to transmissions from covered entities, covered entities must protect electronic protected health information when they transmit that information. See also the discussion of encryption in section III.G.

C. TRANSITION

TO THE

FINAL RULE

The proposed rule included deÞnitions for a number of terms that have now already been promulgated as part of the Transactions Rule or the Privacy Rule. Comments related to the deÞnitions of ‘‘code set,’’ ‘‘health care’’ clearinghouse,’’ ‘‘health plan,’’ ‘‘health care provider,’’ ‘‘small health plan,’’ ‘‘standard’’ and ‘‘transaction,’’ are addressed in the Transactions Rule at 65 FR 50319 through 50320. Comments Copyright © 2004 CRC Press, LLC


Appendix III

259

concerning the deÞnition of ‘‘individually identiÞable health information’’ are discussed below, but are also addressed in the Privacy Rule at 65 FR 82611 through 82613. In addition, a few terms were redeÞned in the Þnal Standards for Privacy of Individually IdentiÞable Health Information (67 FR 53182), issued on August 14, 2002 (Privacy ModiÞcations). Certain terms that were deÞned in the proposed rule are not used in the Þnal rule because they are no longer necessary. Other terms deÞned in the proposed rule are deÞned within the explanation of the standards in the Þnal rule and are discussed in the preamble discussions in § 164.308 through § 164.312. DeÞnitions of terms relevant to the security standards now appear in the regulations text provisions as indicated below: § 160.103: DeÞnitions of the following terms relevant to this rule appear in § 160.103: ‘‘business associate,’’ ‘‘covered entity,’’ ‘‘disclosure,’’ ‘‘electronic media,’’ ‘‘electronic protected health information,’’ ‘‘health care,’’ ‘‘health care clearinghouse,’’ ‘‘health care provider,’’ ‘‘health information,’’ ‘‘health plan,’’ ‘‘individual,’’ ‘‘individually identiÞable health information,’’ ‘‘implementation speciÞcation,’’ ‘‘organized health care arrangement,’’ ‘‘protected health information,’’ ‘‘standard,’’ ‘‘use,’’ and ‘‘workforce.’’ These terms were discussed in connection with the Transaction and Privacy Rules and with the exception of the terms ‘‘covered entity’’ ‘‘disclosure’’ ‘‘electronic protected health information,’’ ‘‘health information,’’ ‘‘individual,’’ ‘‘organized health care arrangement,’’ ‘‘protected health information,’’ and ‘‘use,’’ we will not discuss them in this document. We note that the deÞnition of those terms are not changed in the Þnal rule. § 162.103: We have moved the deÞnition of ‘‘electronic media’’ at § 162.103 to § 160.103 and have modiÞed it to clarify that the term includes storage of information. The term ‘‘electronic media’’ is used in the deÞnition of ‘‘protected health information.’’ Both the privacy and security standards apply to information ‘‘at rest’’ as well as to information being transmitted. We note that we have deleted the reference to § 162.103 in paragraph (1)(ii) of the deÞnition of ‘‘protected health information,’’ since both deÞnitions, ‘‘electronic media’’ and ‘‘protected health information,’’ have been moved to this section. Also, it is unnecessary, because the deÞnitions of § 160.103 apply to all of the rule in parts 160, 162, and 164. We have also clariÞed that the physical movement of electronic media from place to place is not limited to magnetic tape, disk, or compact disk. This clariÞcation removes a restriction as to what is considered to be physical electronic media, thereby allowing for future technological innovation. We further clariÞed that transmission of information not in electronic form before the transmission, for example, paper or voice, is not covered by this deÞnition. § 164.103: The following term ‘‘plan sponsor’’ now appears in the new § 164.103, which consists of deÞnitions of terms common to both subpart C and subpart E (the privacy standards). This deÞnition was moved, without substantive change, from § 164.501 and has the meaning given to it in that section, and comments relating to this deÞnition are discussed in connection with that section in the Privacy Rule at 65 FR 82607, 82611 through 82613, 82618 through 82622, and 82629. § 164.304: DeÞnitions speciÞcally applicable to the Security Rule appear in § 164.304, and these are discussed below. These deÞnitions are from, or derived from, Copyright © 2004 CRC Press, LLC


260


currently accepted deÞnitions in industry publications, such as, the International Organization for Standards (ISO) 7498–2 and the American Society for Testing and Materials (ASTM) E1762–95. The following terms in § 164.304 are taken from the proposed rule text or the glossary in Addendum 2 of the proposed rule (63 FR 43271), were not commented on, and/or are unchanged or have only minor technical changes for purposes of clariÞcation and are not discussed below: ‘‘access,’’ ‘‘authentication,’’ ‘‘availability,’’ ‘‘conÞdentiality,’’ ‘‘encryption,’’ ‘‘password,’’ and ‘‘security.’’ § 164.314: Four terms were deÞned in § 164.504(a) of the Privacy Rule (‘‘common control,’’ ‘‘common ownership,’’ ‘‘health care component,’’ and ‘‘hybrid entity’’). Because these terms apply to both security and privacy, their deÞnitions have been moved to § 164.103 without change. Those terms are discussed in the Privacy Rule at 65 FR 82502 through 82503 and at 67 FR 53203 through 53207. 1. Covered Entity (§ 160.103) Comment: One commenter asked if transcription services were covered entities. The question arose because transcription is often the Þrst electronic or printed source of clinical information. Concern was expressed about the application of physical safeguard standards to the transcribers working for transcription companies or health care providers, either as employees or as independent contractors. Another commenter expressed concern that scalability was limited to only small providers. The commenter explained that Third Party Administrators (TPAs) allow claim processors to work at home. Some TPAs have noted that it would be impossible to comply with the security standards for home-based claims processors. Response: A covered entity’s responsibility to implement security standards extends to the members of its workforce, whether they work at home or on-site. Because a covered entity is responsible for ensuring the security of the information in its care, the covered entity must include ‘‘at home’’ functions in its security process. While an independent transcription company or a TPA may not be covered entities, they will be a business associate of the covered entity because their activities fall under paragraph (1)(i)(a) of the deÞnition of that term. For business associate provisions see proposed preamble section III.E.8. and § 164.308(b)(1) and § 164.314(c) of this Þnal rule. 2. Health Care and Medical Care (§ 160.103) Comment: One commenter asked whether ‘‘medical care,’’ which is deÞned in the proposed rule, and ‘‘health care,’’ which is not, are synonymous. Response: The term ‘‘medical care,’’ as used in the proposed rule (63 FR 43242), was intended to be synonymous with ‘‘health care.’’ The term “medical care’’ is not included in this Þnal rule. It is, however, included in the deÞnition of ‘‘health plan,’’ where its meaning is not synonymous with ‘‘health care.’’ For a full discussion of this issue and its resolution, see the Privacy Rule (65 FR 82578).



Appendix III

261

3. Health Information and Individually Identifiable Health Information 160.103) We note that the deÞnitions of ‘‘health information’’ and ‘‘individually identiÞable health information’’ remain unchanged from those published in the Transactions and Privacy Rules. a. Comment: A number of commenters asked that the deÞnition of ‘‘health information’’ be expanded to include information collected by additional entities. Several commenters wanted the deÞnition to include health information collected, maintained, or transmitted by any entity, and one commenter suggested the inclusion of aggregated information not identiÞable to an individual. Several commenters asked that eligibility information be excluded from the deÞnition of information. Several commenters wanted the deÞnition broadened to include demographics. Response: Our deÞnition of health information is taken from the deÞnition in section 1171(4) of the Act, which provides that health information relates to the health or condition of an individual, the provision of health care to an individual, or payment for the provision of health care to an individual. The statutory deÞnition also speciÞes the entities by which health information is created or received. We note that, because ‘‘individually identiÞable health information’’ is a subset of ‘‘health information’’ and by statute includes demographic information, ‘‘health information’’ necessarily includes demographic information. We think this is clear as a matter of statutory construction and does not require further regulatory change. b. Comment: Several commenters asked that we clarify the difference between ‘‘health information’’ and ‘‘individually identiÞable’’ and ‘‘health information pertaining to an individual’’ as used in the August 12, 1998 proposed rule (63 FR 43242). Additionally, commenters asked that we be more consistent in the use of these terms and recommended use of the term ‘‘individually identiÞable health information.’’ Two commenters stated that it is important to distinguish between ‘‘health information pertaining to an individual’’ and ‘‘individually identiÞable health information,’’ as in reporting statistics at various levels there will always be a need to bring forth information pertaining to an individual. One commenter recommended that the standards apply only to individually identiÞable health information. Another stated that in § 142.306(b) of the proposed rule, ‘‘health information pertaining to an individual’’ should be changed to ‘‘individually identiÞable health information,’’ as nonidentiÞable information can be used for utilization review and other purposes. As written, the regulation text could limit the ability to use data, for example, from a clearinghouse for compliance monitoring. Response: In general, we agree with these commenters, and note that these comments are largely mooted by the decision, reßected in § 164.306 below and discussed in section III.D.1. of this Þnal rule, to cover only electronic protected health information in this Þnal rule. c. Comment: Several commenters stated that the deÞnition of ‘‘individually identiÞable health information’’ is not in the regulations and should be added. Response: We note that the deÞnition of ‘‘individually identiÞable health information’’ appears at § 160.103, which applies to this Þnal rule. Copyright © 2004 CRC Press, LLC


262


4. Protected Health Information (§ 160.103) This term is moved from § 164.501 to § 160.103 because it applies to both subparts C (security) and E (privacy). See 67 FR 53192 through 531936 regarding the deÞnition of ‘‘protected health information.’’ Also, the term ‘‘electronic media’’ is included in paragraphs (1)(i) and (ii) of the deÞnition of ‘‘protected health information,’’ as speciÞed in this section. In addition, we added the deÞnitions of ‘‘covered functions,’’ ‘‘plan sponsor,’’ and ‘‘Required by law’’ to § 164.103. 5. Breach (§ 164.304) Comment: One commenter asked that ‘‘breach’’ be deÞned. Response: The term ‘‘breach’’ has been deleted and therefore not deÞned. Instead, we deÞne the term ‘‘security incident,’’ which better describes the types of situations we were referring to as breaches. 6. Facility (§ 164.304) This new term has been added as a result of changing the name of the ‘‘physical access control’’ standard to ‘‘facility access control.’’ This change was made based on comments indicating that the original term was not descriptive. We have deÞned the term ‘‘facility’’ as the physical premises and interior and exterior of a building. 7. Security Incident (§ 164.304) Comment: We received comments asking that this term be deÞned. Response: This Þnal rule deÞnes ‘‘Security incident’’ in § 164.304 as ‘‘the attempted or successful unauthorized access, use, disclosure, modiÞcation, or destruction of information or interference with system operations in an information system.’’ 8. System (§ 164.304) Comment: One commenter asked that ‘‘system’’ be deÞned. Response: This Þnal rule deÞnes ‘‘system,’’ in the context of an information system, in § 164.304 as ‘‘an interconnected set of information resources under the same direct management control that shares common functionality. A system normally includes hardware, software, information, data, applications, communications, and people.’’ 9. Workstation (§ 164.304) Comment: One commenter expressed concern that the use of the term ‘‘workstation’’ implied limited applicability to Þxed devices (such as terminals), excluding laptops and other portable devices. Response: We have added a deÞnition of the term ‘‘workstation’’ to clarify that portable devices are also included. This Þnal rule deÞnes workstation as ‘‘an electronic computing device, for example, a laptop or desktop computer, or any other Copyright © 2004 CRC Press, LLC


Appendix III

263

device that performs similar functions, and electronic media stored in its immediate environment.’’ 10. Definitions Not Adopted Several deÞnitions in the proposed regulations text and glossary are not adopted as deÞnitions in the Þnal rule: ‘‘participant,’’ ‘‘contingency plan,’’ ‘‘risk,’’ ‘‘role-based access control,’’ and ‘‘user-based access control.’’ The terms ‘‘participant,’’ ‘‘rolebased access control,’’ and ‘‘user-based access control’’ are not used in this Þnal rule and thus are not deÞned. ‘‘Risk’’ is not deÞned as its meaning is generally understood. While we do not deÞne the term, we address ‘‘contingency plan’’ as a standard in § 164.308(a)(7) below. a. Comment: We received comments requesting that we deÞne the following terms: ‘‘token’’ and ‘‘documentation.’’ Response: These terms were deÞned in Addendum 2 of the proposed rule. In this Þnal rule, we do not adopt a deÞnition for ‘‘token’’ because it is not used in the Þnal rule. ‘‘Documentation’’ is discussed in § 164.316 below. b. Comment: We received several comments that ‘‘small’’ and ‘‘rural’’ should be deÞned as those terms apply to providers. We received an equal number of comments stating that there is no need to deÞne these terms. One commenter stated that deÞnitions for these terms would be necessary only if special exemptions existed for small and rural providers. Several commenters suggested initiation of a study to determine limitations and potential barriers small and rural providers will have in implementing these regulations. Response: The statute requires that we address the needs of small and rural providers. We believe that we have done this through the provisions, which require the risk assessment and the response to be assessment based on the needs and capabilities of the entity. This scalability concept takes the needs of those providers into account and eliminates any need to deÞne those terms. c. Comment: In the proposed rule, we proposed the following deÞnition for the term ‘‘Access control’’: ‘‘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, classiÞcation, and subjectobject separation.’’ One commenter believed the proposed deÞnition is too restrictive and requested revision of the deÞnition to read: ‘‘Access control refers to a method of restricting access to resources, allowing access to only those entities which have been speciÞcally granted the desired access rights.’’ Another commenter wanted the deÞnition expanded to include partitioned rule-based access control (PRBAC). Response: We agree with the commenter who suggested that the deÞnition as proposed seemed too restrictive. In this case, as in many others, a number of commenters believed the examples given in the proposed rule provided the only acceptable compliance actions. As previously noted, in order to clarify that the examples listed were not to be considered all-inclusive, we have generalized the proposed requirements in this Þnal rule. In this case, we have also generalized the requirements and placed the substantive provisions governing access control at § 164.308(a)(4), § 164.310(a)(1), and § 164.312(a)(1). With respect to PRBAC, the access control Copyright © 2004 CRC Press, LLC


264


standard does not exclude this control, and entities should adopt it if appropriate to their circumstances.

D. GENERAL RULES (§ 164.306) In the proposed rule, we proposed to cover all health information maintained or transmitted in electronic form by a covered entity. We proposed to adopt, in § 142.308, a nation-wide security standard that would require covered entities to implement security measures that would be technology-neutral and scalable, and yet integrate all the components of security (administrative procedures, physical safeguards, technical security services, and technical security mechanisms) that must be in place to preserve health information conÞdentiality, integrity, and availability (three basic elements of security). Since no comprehensive, scalable, and technologyneutral set of standards currently exists, we proposed to designate a new standard, which would deÞne the security requirements to be fulÞlled. The proposed rule proposed to deÞne the security standard as a set of scalable, technology-neutral requirements with implementation features that providers, plans, and clearinghouses would have to include in their operations to ensure that health information pertaining to an individual that is electronically maintained or electronically transmitted remains safeguarded. The proposed rule would have required that each affected entity assess its own security needs and risks and devise, implement, and maintain appropriate security to address its own unique security needs. How individual security requirements would be satisÞed and which technology to use would be business decisions that each entity would have to make. In the Þnal rule we adopt this basic framework. In § 164.306, we set forth general rules pertaining to the security standards. In paragraph (a), we describe the general requirements. Paragraph (a) generally reßects section 1173(d)(2) of the Act, but makes explicit the connection between the security standards and the privacy standards (see § 164.306(a)(3)). In § 164.306(a)(1), we provide that the security standards apply to all electronic protected health information the covered entity creates, receives, maintains, or transmits. In paragraph (b)(1), we provide explicitly for the scalability of this rule by discussing the ßexibility of the standards, and paragraph (b)(2) of § 164.306 discusses various factors covered entities must consider in complying with the standards. The provisions of § 164.306(c) provide the framework for the security standards, and establish the requirement that covered entities must comply with the standards. The administrative, physical, and technical safeguards a covered entity employs must be reasonable and appropriate to accomplish the tasks outlined in paragraphs (1) through (4) of § 164.306(a). Thus, an entity’s risk analysis and risk management measures required by § 164.308(a)(1) must be designed to lead to the implementation of security measures that will comply with § 164.306(a). It should be noted that the implementation of reasonable and appropriate security measures also supports compliance with the privacy standards, just as the lack of adequate security can increase the risk of violation of the privacy standards. If, for example, a particular safeguard is inadequate because it routinely permits reasonably anticipated uses or disclosures of electronic protected health information that are Copyright © 2004 CRC Press, LLC


Appendix III

265

not permitted by the Privacy Rule, and that could have been prevented by implementation of one or more security measures appropriate to the scale of the covered entity, the covered entity would not only be violating the Privacy Rule, but would also not be in compliance with § 164.306(a)(3) of this rule. Paragraph (d) of § 164.306 establishes two types of implementation speciÞcations, required and addressable. It provides that required implementation speciÞcations must be met. However, with respect to implementation speciÞcations that are addressable, § 164.306(d)(3) speciÞes that covered entities must assess whether an implementation speciÞcation is a reasonable and appropriate safeguard in its environment, which may include consideration of factors such as the size and capability of the organization as well as the risk. If the organization determines it is a reasonable and appropriate safeguard, it must implement the speciÞcation. If an addressable implementation speciÞcation is determined not to be a reasonable and appropriate answer to a covered entity’s security needs, the covered entity must do one of two things: implement another equivalent measure if reasonable and appropriate; or if the standard can otherwise be met, the covered entity may choose to not implement the implementation speciÞcation or any equivalent alternative measure at all. The covered entity must document the rationale behind not implementing the implementation speciÞcation. See the detailed discussion in section II.A.3. Paragraph (e) of § 164.306 addresses the requirement for covered entities to maintain the security measures implemented by reviewing and modifying the measures as needed to continue the provision of reasonable and appropriate protections, for example, as technology moves forward, and as new threats or vulnerabilities are discovered. 1. Scope of Health Information Covered by the Rule (§ 164.306(a)) We proposed to cover health information maintained or transmitted by a covered entity in electronic form. We have modiÞed, by narrowing, the scope of health information to be safeguarded under this rule from that which was proposed. The statute requires the privacy standards to cover individually identiÞable health information. The Privacy Rule covers all individually identiÞable information except for: (1) Education records covered by the Family and Educational Rights and Privacy Act (FERPA); (2) records described in 20 U.S.C. 1232g(a)(4)(B)(iv); and (3) employment records. (see the Privacy Rule at 65 FR 82496. See also 67 FR 53191 through 53193). The scope of information covered in the Privacy Rule is referred to as ‘‘protected health information.’’ Based upon the comments we received, we align the requirements of the Security and Privacy Rules with regard to the scope of information covered, in order to eliminate confusion and ease implementation. Thus, this Þnal rule requires protection of the same scope of information as that covered by the Privacy Rule, except that it only covers that information if it is in electronic form. We note that standards for the security of all health information or protected health information in nonelectronic form may be proposed at a later date. Copyright © 2004 CRC Press, LLC


266


a. Comment: One commenter stated that the rule should apply to aggregate information that is not identiÞable to an individual. In contrast, another commenter asked that health information used for statistical analysis be exempted if the covered entity may reasonably expect that the removed information cannot be used to reidentify an individual. Response: As a general proposition, any electronic protected health information received, created, maintained, or transmitted by a covered entity is covered by this Þnal rule. We agree with the second commenter that certain information, from which identiÞers have been stripped, does not come within the purview of this Þnal rule. Information that is de-identiÞed, as deÞned in the Privacy Rule at § 164.502(d) and § 164.514(a), is not ‘‘individually identiÞable’’ within the meaning of these rules and, thus, does not come within the deÞnition of ‘‘protected health information.’’ It accordingly is not covered by this Þnal rule. For a full discussion of the issues of de-identiÞcation and re-identiÞcation of individually identiÞable health information see 65 FR 82499 and 82708 through 82712 and 67 FR 53232 through 53234. b. Comment: Several commenters asked whether systems that determine eligibility of clients for insurance coverage under broad categories such as medical coverage groups are considered health information. One commenter asked that we speciÞcally exclude eligibility information from the standards. Response: We cannot accept the latter suggestion. Eligibility information will typically be individually identiÞable, and much eligibility information will also contain health information. If the information is ‘‘individually identiÞable’’ and is ‘‘health information,’’ (with three very speciÞc exceptions noted in the general discussion above) and it is in electronic form, it is covered by the security standards if maintained or transmitted by a covered entity. c. Comment: Several commenters requested clariÞcation as to whether the standards apply to identiÞable health information in paper form. Some commenters believed the rule should be applicable to paper; others argued that it should apply to all conÞdential, identiÞable health information. Response: While we agree that protected health information in paper or other form also should have appropriate security protections, the proposed rule proposing the security standards proposed to apply those standards to health information in electronic form only. We are, accordingly, not extending the scope in this Þnal rule. We may establish standards to secure protected health information in other media in a future rule, in accordance with our statutory authority to do so. See discussion, supra, responding to a comment on the deÞnition of ‘‘health information’’ and ‘‘individually identiÞable health information.’’ d. Comment: The proposed rule would have excluded ‘‘telephone voice response’’ and ‘‘faxback’’ systems from the security standards, and we speciÞcally solicited comments on that issue. A number of commenters agreed that telephone voice response and faxback should be excluded from the regulation, suggesting that the privacy standards rather than the security standards should apply. Others wanted those systems included, on the grounds that inclusion is necessary for consistency and in keeping with the intent of the Act. Still others speciÞcally wanted personal computer-fax transmissions included. One commenter asked for clariÞcation of when we would cover faxes, and another commenter asked why we were excluding them. Copyright © 2004 CRC Press, LLC


Appendix III

267

Several commenters suggested that the other security requirements provide for adequate security of these systems. Response: In light of these comments, we have decided that telephone voice response and ‘‘faxback’’ (that is, a request for information from a computer made via voice or telephone keypad input with the requested information returned as a fax) systems fall under this rule because they are used as input and output devices for computers, not because they have computers in them. Excluding these features would provide a huge loophole in any system concerned with security of the information contained and/or processed therein. It should be noted that employment of telephone voice response and/or faxback systems will generally require security protection by only one of the parties involved, and not the other. Information being transmitted via a telephone (either by voice or a DTMP tone pad) is not in electronic form (as deÞned in the Þrst paragraph of the deÞnition of ‘‘electronic media’’) before transmission and therefore is not subject to the Security Rule. Information being returned via a telephone voice response system in response to a telephone request is data that is already in electronic form and stored in a computer. This latter transmission does require protection under the Security Rule. Although most recently made electronic devices contain microprocessors (a form of computer) controlled by Þrmware (an unchangeable form of computer program), we intend the term ‘‘computer’’ to include only software programmable computers, for example, personal computers, minicomputers, and mainframes. Copy machines, fax machines, and telephones, even those that contain memory and can produce multiple copies for multiple people are not intended to be included in the term ‘‘computer.’’ Therefore, because ‘‘paper-to-paper’’ faxes, person-to-person telephone calls, video teleconferencing, or messages left on voice-mail were not in electronic form before the transmission, those activities are not covered by this rule. See also the deÞnition of ‘‘electronic media’’ at §160.103. We note that this guidance differs from the guidance regarding the applicability of the Transactions Rule to faxback and voice response systems. HHS has stated that faxback and voice response systems are not required to follow the standards mandated in the Transactions Rule. This new guidance refers only to this rule. e. Comment: One commenter asked whether there is a need to implement special security practices to address the shipping and receiving of health information and asked that we more fully explain our expectations and solutions in the Þnal rules. Response: If the handling of electronic protected health information involves shipping and receiving, appropriate measures must be taken to protect the information. However, speciÞc solutions are not provided within this rule, as discussed in section III.A.3 of this Þnal rule. The device and media controls standard under § 164.310(d)(1) addresses this situation. f. Comment: One commenter wanted the ‘‘HTML’’ statement reworded to eliminate a speciÞc exemption for HTML from the regulation. Response: The Transactions Rule did not adopt the proposed exemption for HTML. The use of HTML or any other electronic protocol is not exempt from the security standards. Generally, if protected health information is contained in any form of electronic transmission, it must be appropriately safeguarded. Copyright © 2004 CRC Press, LLC


268


g. Comment: One commenter asked to what degree ‘‘family history’’ is considered health information under this rule and what protections apply to family members included in a patient’s family history. Response: Any health-related ‘‘family history’’ contained in a patient’s record that identiÞes a patient, including a person other than the patient, is individually identiÞable health information and, to the extent it is also electronic protected health information, must be afforded the security protections. h. Comment: Two commenters asked that the rule prohibit re-identiÞcation of de-identiÞed data. In contrast, several commenters asked that we identify a minimum list or threshold of speciÞc re-identiÞcation data elements (for example, name, city, and ZIP) that would fall under this Þnal rule so that, for example, the rule would not affect numerous systems, for example, network adequacy and population-based clinical analysis databases. One commenter asked that we establish a means to use re-identiÞed information if the entity already has access to the information or is authorized to have access. Response: The issue of re-identiÞcation is addressed in the Privacy Rule at § 164.502(d) and § 164.514(c). The reader is referred to those sections and the related discussion in the preamble to the Privacy Rule (65 FR 82712) and the preamble to the Privacy ModiÞcations (67 FR 53232 through 53234) for a full discussion of the issues of re-identiÞcation. We note that once information in the possession (or constructive possession) of a covered entity is re-identiÞed and meets the deÞnition of electronic protected health information, the security standards apply. 2. Technology-Neutral Standards Comment: Many commenters expressed support for our efforts to develop standards for the security of health information. A number of comments were made in support of the technology-neutral approach of the proposed rule. For example, one commenter stated, ‘‘By avoiding prescription of the speciÞc technologies health care entities should use to meet the law’s requirements, you are opening the door for industry to apply innovation. Technologies that don’t currently exist or are impractical today could, in the near future, enhance health information security while minimizing the overall cost.’’ Several other commenters stated that the requirements should be general enough to withstand changes to technology without becoming obsolete. One commenter anticipates no problems with meeting the standards. In contrast, one commenter suggested that whenever possible, speciÞc technology recommendations should provide sufÞcient detail to promote systems interoperability and decrease the tendency toward adoption of multiple divergent standards. Several commenters stated that by letting each organization determine its own rules, the rules impose procedural burdens without any substantive beneÞt to security. Response: The overwhelming majority of comments supported our position. We do not believe it is appropriate to make the standards technology-speciÞc because technology is simply moving too fast, for example, the increased use and sophistication of internet-enabled hand held devices. We believe that the implementation of these rules will promote the security of electronic protected health information by (1) providing integrity and conÞdentiality; (2) allowing only authorized individuals Copyright © 2004 CRC Press, LLC


Appendix III

269

access to that information; and (3) ensuring its availability to those authorized to access the information. The standards do not allow organizations to make their own rules, only their own technology choices. 3. Miscellaneous Comments a. Comment: Some commenters stated that the requirements and implementation features set out in the proposed rule were not speciÞc enough to be considered standards, and that the actual standards are delegated to the discretion of the covered entities, at the expense of medical record privacy. Several commenters stated that it was inappropriate to balance the interests of those seeking to use identiÞable medical information without patient consent against the interest of patients. Several other commenters believe that allowing covered entities to make their own decisions about the adequacy and balance of security measures undermined patient conÞdentiality interests, and stated that the proposed rule did not appear to adequately consider patient concerns and viewpoints. Response: Again, the overwhelming majority of commenters supported our approach. This Þnal rule sets forth requirements with which covered entities must comply and labels those requirements as standards and implementation speciÞcations. Adequate implementation of this Þnal rule by covered entities will ensure that the electronic protected health information in a covered entity’s care will be as protected as is feasible for that entity. We disagree that covered entities are given complete discretion to determine their security polices under this rule, resulting in effect, in no standards. While cost is one factor a covered identity may consider in determining whether to implement a particular implementation speciÞcation, there is nonetheless a clear requirement that adequate security measures be implemented, see 45 CFR 164.306(b). Cost is not meant to free covered entities from this responsibility. b. Comment: Several commenters requested we withdraw the regulations, citing resource shortages due to Y2K preparation, upcoming privacy legislation, and/or the ‘‘excessive micromanagement’’ contained in the rules. One commenter stated that, to insurers, these rules were onerous, not necessary, and not justiÞed as cost-effective, as they already have effective practices for computer security and are subject to rigorous State laws for the safeguarding of health information. Another commenter stated that these rules would adversely affect a provider’s practice environment. Response: The HIPAA statute requires us to promulgate a rule adopting security standards for health information. Resource concerns due to Y2K should no longer be an issue. Covered entities will have 2 years (or, in the case of small health plans, 3 years) from the adoption of this Þnal rule in which to comply. Concerns relative to effective and compliance dates and the Privacy Rule are discussed under § 164.318, Compliance dates for initial implementation, below and at 65 FR 82751 through 82752. We disagree that these standards will adversely affect a provider’s practice environment. The scalability of the standards allows each covered entity to implement security protections that are appropriate to its speciÞc needs, risks, and environments. These protections are necessary to maintain the conÞdentiality, integrity, Copyright © 2004 CRC Press, LLC


270


and availability of patient data. A covered entity that lacks adequate protections risks inadvertent disclosure of patient data, with resulting loss of public trust, and potential legal action. For example, a covered entity with poor facility access controls and procedures would be susceptible to hacking of its databases. A provider with appropriate security protections already in place would only need to ensure that the protections are documented and are reassessed periodically to ensure that they continue to be appropriate and are actually being implemented. Our decision to classify many implementation speciÞcations as addressable, rather than mandatory, provides even more ßexibility to covered entities to develop cost-effective solutions. We believe that insurers who already have effective security programs in place will have met many of the requirements of this regulation. c. Comment: One commenter believes the rule is arbitrary and capricious in its requirements without any justiÞcation that they will signiÞcantly improve the security of medical records and with the likelihood that their implementation may actually increase the vulnerability of the data. The commenter noted that the data backup requirements increase access to data and that security awareness training provides more information to employees. Response: The standards are based on generally accepted security procedures, existing industry standards and guidelines, and recommendations contained in the National Research Council’s 1997 report For The Record: Protecting Electronic Health Information, Chapter 6. We also consulted extensively with experts in the Þeld of security throughout the health care industry. The standards are consistent with generally accepted security principles and practices that are already in widespread use. Data backup need not result in increased access to that data. Backups should be stored in a secure location with controlled access. The appropriate secure location and access control will vary, based upon the security needs of the covered entity. For example, a procedure as simple as locking backup diskettes in a safe place and restricting who has access to the key may be suitable for one entity, whereas another may need to store backed-up information off-site in a secure computer facility. The information provided in security awareness training heightens awareness of security anomalies and helps to prevent security incidents. d. Comment: Several commenters suggested that the proposed rule appears to reßect the Medicare program’s perspective on security risks and solutions, and that it should be noted that not all industry segments share all the same risks as Medicare. One commenter stated that as future proposed rules are drafted, we should solicit input from those most signiÞcantly affected, for example, providers, plans, and clearinghouses. Others stated that Medicaid agencies were not sufÞciently involved in the discussions and debate. Still another stated that States would be unable to perform some basic business functions if all the standards are not designed to meet their needs. Response: We believe that the standards are consistent with common industry practices and equitable, and that there has been adequate consultation with interested parties in the development of the standards. These standards are the result of an intensive process of public consultation. We consulted with the National Uniform Copyright © 2004 CRC Press, LLC


Appendix III

271

Billing Committee, the National Uniform Claim Committee, the American Dental Association, and the Workgroup for Electronic Data Interchange, in the course of developing the proposed rule. Those organizations were speciÞcally named in the Act to advise the Secretary, and their membership is drawn from the full spectrum of industry segments. In addition, the National Committee on Vital and Health Statistics (NCVHS), an independent advisory group to the Secretary, held numerous public hearings to obtain the views of interested parties. Again, many segments of the health care industry, including provider groups, health plans, clearinghouses, vendors, and government programs participated actively. The NCVHS developed recommendations to the Secretary, which were relied upon as we developed the proposed rule. Finally, we note that the opportunity to comment was available to all during the public comment period. e. Comment: One commenter stated that there is a need to ensure the conÞdentiality of risk analysis information that may contain sensitive information. Response: The information included in a risk analysis would not be subject to the security standards if it does not include electronic protected health information. We agree that risk analysis data could contain sensitive information, just as other business information can be sensitive. Covered entities may wish to develop their own business rules regarding access to and protections for risk analysis data. f. Comment: One commenter expressed concern over the statement in the preamble of the proposed rule (63 FR 43250) that read: ‘‘No one item is considered to be more important than another.’’ The commenter suggested that security management should be viewed as most critical and perhaps what forms the foundation for all other security actions. Response: The majority of comments received on this subject requested that we prioritize the standards. In response, we have regrouped the standards and implementation speciÞcations in what we believe is a logical order within each of three categories: ‘‘Administrative safeguards,’’ ‘‘Physical safeguards,’’ and ‘‘Technical safeguards.’’ In this Þnal rule, we order the standards in such a way that the ‘‘Security management process’’ is listed Þrst under the ‘‘Administrative safeguards’’ section, as we believe this forms the foundation on which all of the other standards depend. The determination of the speciÞc security measures to be implemented to comply with the standards will, in large part, be dependent upon completion of the implementation speciÞcations within the security management process standard (see § 164.308(a)(1)). We emphasize, however, that an entity implementing these standards may choose to implement them in any order, as long as the standards are met. g. Comment: One commenter stated that there is a need for requirements concerning organizational practices (for example, education, training, and security and conÞdentiality policies), as well as technical practices and procedures. Response: We agree. Section 164.308 of this Þnal rule describes administrative safeguards that address these topics. Section 164.308 requires covered entities to implement standards and required implementation speciÞcations, as well as consider and implement, when appropriate and reasonable, addressable implementation speciÞcations. For example, the security management process standard requires implementation of a risk analysis, risk management, a sanction policy, and an information Copyright © 2004 CRC Press, LLC


272


system activity review. The information access management standard requires consideration, and implementation where appropriate and reasonable, of access authorization and access establishment and modiÞcation policies and procedures. Other areas addressed are assigned security responsibility, workforce security, security awareness and training, security incident procedures, contingency planning, business associate contracts, and evaluation. h. Comment: One commenter stated that internal and external security requirements should be separated and dealt with independently. Response: The presentation of the standards within this Þnal rule could have been structured in numerous ways, including by addressing separate internal and external security standards. We chose the current structure as we considered it a logical breakout for purposes of display within this Þnal rule. Under our structure a covered entity may apply a given standard to internal activities and to external activities. Had we displayed separately the standards for internal security and the standards for external security, we would have needed to describe a number of the standards twice, as many apply to both internal and external security. However, a given entity may address the standards in whatever order it chooses, as long as the standards are met. i. Comment: Two commenters stated that the standards identiÞed in Addendum 3 of the proposed rule may not all have matured to implementation readiness. Response: Addendum 3 of the proposed rule cross-referred individual requirements on the matrix to existing industry standards of varying levels of maturity. Addendum 3 was intended to show what we evaluated in searching for existing industry standards that could be adopted on a national level. No one standard was found to be comprehensive enough to be adopted, and none were proposed as the standards to be met under the Security Rule. j. Comment: One commenter suggested we include a revised preamble in the Þnal publication. Another questioned how clariÞcation of points in the preamble will be handled if the preamble is not part of the Þnal regulation. Response: Preambles to proposed rules are not republished in the Þnal rule. The preamble in this Þnal rule contains summaries of the information presented in the preamble of the proposed rule, summaries of the comments received during the public comment period, and responses to questions and concerns raised in those comments and a summary of changes made. Additional clariÞcation will be provided by HHS on an ongoing basis through written documents and postings on HHS’s websites. k. Comment: One commenter asked that we clarify that no third party can require implementation of more security features than are required in the Þnal rule, for example, a third party could not require encryption but may choose to accept it if the other party so desires. Response: The security standards establish a minimum level of security to be met by covered entities. It is not our intent to limit the level of security that may be agreed to between trading partners or others above this ßoor. l. Comment: One commenter asked how privacy legislation would affect these rules. The commenter inquired whether covered entities will have to reassess and revise actions already taken in the spirit of compliance with the security regulations. Copyright © 2004 CRC Press, LLC


Appendix III

273

Response: We cannot predict if or how future legislation may affect the rules below. At present, the privacy standards at subpart E of 42 CFR part 164 have been adopted, and this Þnal rule is compatible with them. m. Comment: One commenter stated that a data classiÞcation policy, that is a method of assigning sensitivity ratings to speciÞc pieces of data, should be part of the Þnal regulations. Response: We did not adopt such a policy because this Þnal rule requires a ßoor of protection of all electronic protected health information. A covered entity has the option to exceed this ßoor. The sensitivity of information, the risks to and vulnerabilities of electronic protected health information and the means that should be employed to protect it are business determinations and decisions to be made by each covered entity. n. Comment: One commenter stated that this proposed rule conßicts with previously stated rules that acceptable ‘‘standards’’ must have been developed by ANSIrecognized Standards Development Organizations (SDOs). Response: In general, HHS is required to adopt standards developed by ANSIaccredited SDOs when such standards exist. The currently existing security standards developed by ANSI-recognized SDOs are targeted to speciÞc technologies and/or activities. No existing security standard, or group of standards, is technology-neutral, scaleable to the extent required by HIPAA, and broad enough to be adopted in this Þnal rule. Therefore, this Þnal rule adopts standards under section 1172(c)(2)(B) of the Act, which permits us to develop standards when no industry standards exist. o. Comment: One commenter stated that this regulation goes beyond the scope of the law, unjustiÞably extending into business practices, employee policies, and facility security. Response: We do not believe that this regulation goes beyond the scope of the law. The law requires HHS to adopt standards for reasonable and appropriate security safeguards concerning such matters as compliance by the ofÞcers and employees of covered entities, protection against reasonably anticipated unauthorized uses and disclosures of health information, and so on. Such standards will inevitably address the areas the commenter pointed to. The intent of this regulation is to provide standards for the protection of electronic protected health information in accordance with the Act. In order to do this, covered entities are required to implement administrative, physical, and technical safeguards. Those entities must ensure that data are protected, to the extent feasible, from inappropriate access, modiÞcation, dissemination, and destruction. As noted above, however, this Þnal rule has been modiÞed to increase ßexibility as to how this protection is accomplished. p. Comment: One commenter stated that all sections regarding conÞdentiality and privacy should be removed, since they do not belong in this regulation. Response: As the discussion in section III.A above of this Þnal rule makes clear, the privacy and security standards are very closely related. Section 1173(d)(2) of the Act speciÞcally mentions ‘‘conÞdentiality’’ and authorizes uses and disclosures of information as part of what security safeguards must address. Thus, we cannot omit all references to conÞdentiality and privacy in discussions of the security standards. Copyright © 2004 CRC Press, LLC


274


However, we have relocated material that relates to both security and privacy (including deÞnitions) to the general section of part 164. q. Comment: One commenter asked that data retention be addressed more speciÞcally, since this will become a signiÞcant issue over time. It is recommended that a national work group be convened to address this issue. Response: The commenter’s concern is noted. While the documentation relating to Security Rule implementation must be retained for a period of 6 years (see § 164.316(b)(2)), it is not within the scope of this Þnal rule to address data retention time frames for administrative or clinical records. r. Comment: One commenter stated that requiring provider practices to develop policies, procedures, and training programs and to implement record keeping and documentation systems would be tremendously resource-intensive and increase the costs of health care. Response: We expect that many of the standards of this Þnal rule are already being met in one form or another by covered entities. For example, as part of normal business operations, health care providers already take measures to protect the health information in their keeping. Health care providers already keep records, train their employees, and require employees to follow ofÞce policies and procedures. Similarly, health plans are already frequently required by State law to keep information conÞdential. While revisions to a practice’s or plan’s current activities may be necessary, the development of entirely new systems or procedures may not be necessary. s. Comment: One commenter stated that there is no system for which risk has been eliminated and expressed concern over phrases such as covered entities must ‘‘assure that electronic health information pertaining to an individual remains secure.’’ Response: We agree with the commenter that there is no such thing as a totally secure system that carries no risks to security. Furthermore, we believe the Congress’ intent in the use of the word ‘‘ensure’’ in section 1173(d) of the Act was to set an exceptionally high goal for the security of electronic protected health information. However, we note that the Congress also recognized that some trade-offs would be necessary, and that ‘‘ensuring’’ protection did not mean providing protection, no matter how expensive. See section 1173(d)(1)(A)(ii) of the Act. Therefore, when we state that a covered entity must ensure the safety of the information in its keeping, we intend that a covered entity take steps, to the best of its ability, to protect that information. This will involve establishing a balance between the information’s identiÞable risks and vulnerabilities, and the cost of various protective measures, and will also be dependent upon the size, complexity, and capabilities of the covered entity, as provided in § 164.306(b).

E. ADMINISTRATIVE SAFEGUARDS (§ 164.308) We proposed that measures taken to comply with the rule be appropriate to protect the health information in a covered entity’s care. Most importantly, we proposed to require that both the measures taken and documentation of those measures be kept current, that is, reviewed and updated periodically to continue appropriately to protect the health information in the care of covered entities. We would have required Copyright © 2004 CRC Press, LLC


Appendix III

275

the documentation to be made available to those individuals responsible for implementing the procedure. We proposed a number of administrative requirements and supporting implementation features, and required documentation for those administrative requirements and implementation features. In this Þnal rule, we have placed these administrative standards in § 164.308. We have reordered them, deleted much of the detail of the proposed requirements, as discussed below, and omitted two of the proposed sets of requirements (system conÞguration requirements and a requirement for a formal mechanism for processing records) as discussed in paragraph 10 of the discussion of § 164.308 of section III.E. of this preamble. Otherwise, the basic elements of the administrative safeguards are adopted in this Þnal rule as proposed. 1. Security Management Process (§ 164.308(a)(1)(i)) We proposed the establishment of a formal security management process to involve the creation, administration, and oversight of policies to address the full range of security issues and to ensure the prevention, detection, containment, and correction of security violations. This process would include implementation features consisting of a risk analysis, risk management, and sanction and security policies. We also proposed, in a separate requirement under administrative procedures, an internal audit, which would be an in-house review of the records of system activity (for example, logins, Þle accesses, and security incidents) maintained by an entity. In this Þnal rule, risk analysis, risk management, and sanction policy are adopted as required implementation speciÞcations although some of the details are changed, and the proposed internal audit requirement has been renamed as ‘‘information system activity review’’ and incorporated here as an additional implementation speciÞcation. a. Comment: Three commenters asked that this requirement be deleted. Two commenters cited this requirement as a possible burden. Several commenters asked that the implementation features be made optional. Response: This standard and its component implementation speciÞcations form the foundation upon which an entity’s necessary security activities are built. See NIST SP 800–30, ‘‘Risk Management Guide for Information Technology Systems,’’ chapters 3 and 4, January 2002. An entity must identify the risks to and vulnerabilities of the information in its care before it can take effective steps to eliminate or minimize those risks and vulnerabilities. Some form of sanction or punishment activity must be instituted for noncompliance. Indeed, we question how the statutory requirement for safeguards ‘‘to ensure compliance * * * by a [covered entity’s] ofÞcers and employees’’ could be met without a requirement for a sanction policy. See section 1176(d)(2)(C) of the Act. Accordingly, implementation of these speciÞcations remains mandatory. However, it is important to note that covered entities have the ßexibility to implement the standard in a manner consistent with numerous factors, including such things as, but not limited to, their size, degree of risk, and environment. We have deleted the implementation speciÞcation calling for an organizational security policy, as it duplicated requirements of the security management and training standard. Copyright © 2004 CRC Press, LLC


276


We note that the implementation speciÞcation for a risk analysis at § 164.308(a)(1)(ii)(A) does not speciÞcally require that a covered entity perform a risk analysis often enough to ensure that its security measures are adequate to provide the level of security required by § 164.306(a). In the proposed rule, an assurance of adequate security was framed as a requirement to keep security measures ‘‘current.’’ We continue to believe that security measures must remain current, and have added regulatory language in § 164.306(e) as a more precise way of communicating that security measures in general that must be periodically reassessed and updated as needed. The risk analysis implementation speciÞcation contains other terms that merit explanation. Under § 164.308(a)(1)(ii)(A), the risk analysis must look at risks to the covered entity’s electronic protected health information. A thorough and accurate risk analysis would consider ‘‘all relevant losses’’ that would be expected if the security measures were not in place. ‘‘Relevant losses’’ would include losses caused by unauthorized uses and disclosures and loss of data integrity that would be expected to occur absent the security measures. b. Comment: Relative to the development of an entity’s sanction policy, one commenter asked that we describe the sanction penalties for breach of security. Another suggested establishment of a standard to which one’s conduct could be held and adoption of mitigating circumstances so that the fact that a person acted in good faith would be a factor that could be used to reduce or otherwise minimize any sanction imposed. Another commenter suggested sanction activities not be implemented before the full implementation and testing of all electronic transaction standards. Response: The sanction policy is a required implementation speciÞcation because—(1) the statute requires covered entities to have safeguards to ensure compliance by ofÞcers and employees; (2) a negative consequence to noncompliance enhances the likelihood of compliance; and (3) sanction policies are recognized as a usual and necessary component of an adequate security program. The type and severity of sanctions imposed, and for what causes, must be determined by each covered entity based upon its security policy and the relative severity of the violation. c. Comment: Commenters requested the deÞnitions of ‘‘risk analysis’’ and ‘‘breach.’’ Response: ‘‘Risk analysis’’ is deÞned and described in the speciÞcation of the security management process standard, and is discussed in the preamble discussion of § 164.308(a)(1)(ii)(A) of this Þnal rule. The term breach is no longer used and is, therefore, not deÞned. d. Comment: One commenter asked whether all health information is considered equally ‘‘sensitive,’’ the thought being that, in determining risk, an entity may consider the loss of a smaller amount of extraordinarily sensitive data to be more signiÞcant than the loss of a larger amount of routinely collected data. The commenter stated that common reasoning would suggest that the smaller amount of data would be considered more sensitive. Response: All electronic protected health information must be protected at least to the degree provided by these standards. If an entity desires to protect the information to a greater degree than the risk analysis would indicate, it is free to do so. e. Comment: One commenter asked that we add ‘‘threat assessment’’ to this requirement. Copyright © 2004 CRC Press, LLC


Appendix III

277

Response: We have not done this because we view threat assessment as an inherent part of a risk analysis; adding it would be redundant. f. Comment: We proposed a requirement for internal audit, the inhouse review of the records of system activity (for example, logins, Þle accesses, and security incidents) maintained by an entity. Several commenters wanted this requirement deleted. One suggested the audit trail requirement should not be mandatory, while another stated that internal audits would be unnecessary if physical security requirements are implemented. A number of commenters asked that we clarify the nature and scope of what an internal audit covers and what the audit time frame should be. Several commenters offered further detail concerning what should and should not be required in an internal audit for security purposes. One commenter stated that ongoing intrusion detection should be included in this requirement. Another wanted us to specify the retention times for archived audit logs. Several commenters had difÞculty with the term ‘‘audit’’ and suggested we change the title of the requirement to ‘‘logging and violation monitoring.’’ A number of commenters stated this requirement could result in an undue burden and would be economically unfeasible. Response: Our intent for this requirement was to promote the periodic review of an entity’s internal security controls, for example, logs, access reports, and incident tracking. The extent, frequency, and nature of the reviews would be determined by the covered entity’s security environment. The term ‘‘internal audit’’ apparently, based on the comments received, has certain rigid formal connotations we did not intend. We agree that the implementation of formal internal audits could prove burdensome or even unfeasible, to some covered entities due to the cost and effort involved. However, we do not want to overlook the value of internal reviews. Based on our review of the comments and the text to which they refer, it is clear that this requirement should be renamed for clarity and that it should actually be an implementation speciÞcation of the security management process rather than an independent standard. We accordingly remove ‘‘internal audit’’ as a separate requirement and add ‘‘information system activity review’’ under the security management process standard as a mandatory implementation speciÞcation. 2. Assigned Security Responsibility (§ 164.308(a)(2)) We proposed that the responsibility for security be assigned to a speciÞc individual or organization to provide an organizational focus and importance to security, and that the assignment be documented. 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. In this Þnal rule, we clarify that the Þnal responsibility for a covered entity’s security must be assigned to one ofÞcial. The requirement for documentation is retained, but is made part of § 164.316 below. This policy is consistent with the analogous policy in the Privacy Rule, at 45 CFR 164.530(a), and the same considerations apply. See 65 FR 82744 through 87445. The same person could Þll the role for both security and privacy. Copyright © 2004 CRC Press, LLC


278


a. Comment: Commenters were concerned that delegation of assigned security responsibility, especially in large organizations, needs to be to more than a single individual. Commenters believe that a large health organization’s security concerns would likely cross many departmental boundaries requiring group responsibility. Response: The assigned security responsibility standard adopted in this Þnal rule speciÞes that Þnal security responsibility must rest with one individual to ensure accountability within each covered entity. More than one individual may be given speciÞc security responsibilities, especially within a large organization, but a single individual must be designated as having the overall Þnal responsibility for the security of the entity’s electronic protected health information. This decision also aligns this rule with the Þnal Privacy Rule provisions concerning the Privacy OfÞcial. b. Comment: One commenter disagreed with placing assigned security responsibility as part of physical safeguards. The commenter suggested that assigned security responsibility should be included under the Administrative Procedures. Response: Upon review of the matrix and regulations text, we agree with the commenter, because this requirement involves an administrative decision at the highest levels of who should be responsible for ensuring security measures are implemented and maintained. Assigned security responsibility has been removed from ‘‘Physical safeguards’’ and is now located under ‘‘Administrative safeguards’’ at § 164.308. 3. Workforce Security (§ 164.308(a)(3)(i)) We proposed implementation of a number of features for personnel security, including ensuring that maintenance personnel are supervised by a knowledgeable person, maintaining a record of access authorizations, ensuring that operating and maintenance personnel have proper access authorization, establishing personnel clearance procedures, establishing and maintaining personnel security policies and procedures, and ensuring that system users have proper training. In this Þnal rule, to provide clariÞcation and reduce duplication, we have combined the ‘‘Assure supervision of maintenance personnel by authorized, knowledgeable person’’ implementation feature and the ‘‘Operating, and in some cases, maintenance personnel have proper access authorization’’ feature into one addressable implementation speciÞcation titled ‘‘Authorization and/ or supervision.’’ In a related, but separate, requirement entitled ‘‘Termination procedures,’’ we proposed implementation features for the ending of an employee’s employment or an internal or external user’s access. These features would include things such as changing combination locks, removal from access lists, removal of user account(s), and the turning in of keys, tokens, or cards that allow access. In this Þnal rule, ‘‘Termination procedures’’ has been made an addressable implementation speciÞcation under ‘‘Workforce security.’’ This is addressable because in certain circumstances, for example, a solo physician practice whose staff consists only of the physician’s spouse, formal procedures may not be necessary. The proposed ‘‘Personnel security policy/procedure’’ and ‘‘record of access authorizations’’ implementation features have been removed from this Þnal rule, as they have been determined to be redundant. Implementation of the balance of the ‘‘Workforce security’’ implementation speciÞcations and the other standards Copyright © 2004 CRC Press, LLC


Appendix III

279

contained within this Þnal rule will result in assurance that all personnel with access to electronic protected health information have the required access authority as well as appropriate clearances. a. Comment: The majority of comments concerned the supervision of maintenance personnel by an authorized knowledgeable person. Commenters stated this would not be feasible in smaller settings. For example, the availability of technically knowledgeable persons to ensure this supervision would be an issue. We were asked to either reword this implementation feature or delete it. Response: We agree that a ‘‘knowledgeable’’ person may not be available to supervise maintenance personnel. We have accordingly modiÞed this implementation speciÞcation so that, in this Þnal rule, we are adopting an addressable implementation speciÞcation titled, ‘‘Authorization and/or supervision,’’ requiring that workforce members, for example, operations and maintenance personnel, must either be supervised or have authorization when working with electronic protected health information or in locations where it resides (see § 164.308(a)(3)(ii)(A)). Entities can decide on the feasibility of meeting this speciÞcation based on their risk analysis. b. Comment: The second largest group of comments requested assurance that, with regard to the proposed ‘‘Personnel clearance procedure’’ implementation feature, having appropriate clearances does not mean performing background checks on everyone. We were asked to delete references to ‘‘clearance’’ and use the term ‘‘authorization’’ in its place. Response: We agree with the commenters concerning background checks. This feature was not intended to be interpreted as an absolute requirement for background checks. We retain the use of the term ‘‘clearance,’’ however, because we believe that it more accurately conveys the screening process intended than does the term ‘‘authorization.’’ We have attempted to clarify our intent in the language of § 164.308(a)(3)(ii)(B), which now reads, ‘‘Implement procedures to determine that the access of a workforce member to electronic protected health information is appropriate.’’ The need for and extent of a screening process is normally based on an assessment of risk, cost, beneÞt, and feasibility as well as other protective measures in place. Effective personnel screening processes may be applied in a way to allow a range of implementation, from minimal procedures to more stringent procedures based on the risk analysis performed by the covered entity. So long as the standard is met and the underlying standard of § 164.306(a) is met, covered entities have choices in how they meet these standards. To clarify the intent of this provision, we retitle the implementation speciÞcation ‘‘Workforce clearance procedure.’’ c. Comment: One commenter asked that we expand the implementation features to include the identiÞcation of the restrictions that should be placed on members of the workforce and others. Response: We have not adopted this comment in the interest of maintaining ßexibility as discussed in § 164.306. Restrictions would be dependent upon job responsibilities, the amount and type of supervision required and other factors. We note that a covered entity should consider in this regard the applicable requirements of the Privacy Rule (see, for example, § 164.514(d)(2) (relating to minimum necessary requirements), and § 164.530(c) (relating to safeguards). Copyright © 2004 CRC Press, LLC


280


Comment: One commenter believes that the proposed ‘‘Personnel security’’ requirement was reasonable, since an administrative determination of trustworthiness is needed before allowing access to sensitive information. Two commenters asked that we delete the requirement entirely. A number of commenters requested that we delete the implementation features. Another commenter stated that all the implementation features may not be applicable or even appropriate to a given entity and should be so qualiÞed. Response: While we do not believe this requirement should be eliminated, we agree that all the implementation speciÞcations may not be applicable or even appropriate to a given entity. For example, a personal clearance may not be reasonable or appropriate for a small provider whose only assistant is his or her spouse. The implementation speciÞcations are not mandatory, but must be addressed. This Þnal rule has been changed to reßect this approach (see § 164.308(a)(3)(ii)(B)). e. Comment: The majority of commenters on the ‘‘Termination procedures’’ requirement asked that it be made optional, stating that it may not be applicable or even appropriate in all circumstances and should be so qualiÞed or posed as guidelines. A number of commenters stated that the requirement should be deleted. One commenter stated that much of the material covered under the ‘‘Termination procedures’’ requirement is already covered in ‘‘Information access control.’’ A number of commenters stated that this requirement was too detailed and some of the requirements excessive. Response: Based upon the comments received, we agree that termination procedures should not be a separate standard; however, consideration of termination procedures remains relevant for any covered entity with employees, because of the risks associated with the potential for unauthorized acts by former employees, such as acts of retribution or use of proprietary information for personal gain. We further agree with the reasoning of the commenters who asked that these procedures be made optional; therefore, ‘‘Termination procedures’’ is now reßected in this Þnal rule as an addressable implementation speciÞcation. We also removed reference to all speciÞc termination activities, for example, changing locks, because, although the activities may be considered appropriate for some covered entities, they may not be reasonable for others. f. Comment: One commenter asked whether human resource employee termination policies and procedures must be documented to show the types of security breaches that would result in termination. Response: Policies and procedures implemented to adhere to this standard must be documented (see § 164.316 below). The purpose of termination procedure documentation under this implementation speciÞcation is not to detail when or under which circumstances an employee should be terminated. This information would more appropriately be part of the entity’s sanction policy. The purpose of termination procedure documentation is to ensure that termination procedures include securityunique actions to be followed, for example, revoking passwords and retrieving keys when a termination occurs. 4. Information Access Management (§ 164.308(a)(4)) We proposed an ‘‘information access control’’ requirement for establishment and maintenance of formal, documented policies and procedures deÞning levels of access Copyright © 2004 CRC Press, LLC


Appendix III

281

for all personnel authorized to access health information, and how access is granted and modiÞed. In § 164.308(a)(4)(ii)(B) and (C) below, the proposed implementation features are made addressable speciÞcations. We have added in § 164.308(a)(4)(ii)(A), a required implementation speciÞcation to isolate health care clearinghouse functions to address the provisions of section 1173(d)(1)(B) of the Act which related to this area. a. Comment: One commenter asked that the requirement be deleted, expressing the opinion that this requirement goes beyond ‘‘reasonable boundaries’’ into regulating common business practices. In contrast, another asked that we expand this requirement to identify participating parties and access privileges relative to speciÞc data elements. Response: We disagree that this requirement improperly imposes upon business functions. Restricting access to those persons and entities with a need for access is a basic tenet of security. By this mechanism, the risk of inappropriate disclosure, alteration, or destruction of information is minimized. We cannot, however, specifically identify participating parties and access privileges relative to data elements within this regulation. These will vary depending upon the entity, the needs within the user community, the system in which the data resides, and the speciÞc data being accessed. This standard is consistent with § 164.514(d) in the Privacy Rule (minimum necessary requirements for use and disclosure of protected health information), and is, therefore, being retained. b. Comment: Several commenters asked that we not mandate the implementation features, but leave them as optional, a suggested means of compliance. The commenters noted that this might make the rules more scalable and ßexible, since this approach would allow providers to implement safeguards that best addressed their needs. Along this line, one commenter expressed the belief that each organization should implement features deemed necessary based on its own risk assessment. Response: While the information access management standard in this Þnal rule must be met, we agree that the implementation speciÞcations at § 164.308(a)(4)(ii)(B) and (C) should not be mandated but posed as a suggested means of compliance, which must be addressed. These speciÞcations may not be applicable to all entities based on their size and degree of automation. A fully automated covered entity spanning multiple locations and involving hundreds of employees may determine it has a need to adopt a formal policy for access authorization, while a small provider may decide that a desktop standard operating procedure will meet the speciÞcations. The Þnal rule has been revised accordingly. c. Comment: ClariÞcation was requested concerning the meaning of ’’formal.’’ Response: The word ‘‘formal’’ has caused considerable concern among commenters, as it was thought ‘‘formal’’ carried the connotation of a rigidly deÞned structure similar to what might be found in the Department of Defense instructions. As used in the proposed rule, this word was not intended to convey such a strict structure. Rather, it was meant to convey that documentation should be an ofÞcial organizational statement as opposed to word-of-mouth or cryptic notes scratched on a notepad. While documentation is still required (see § 164.316), to alleviate confusion, the word ‘‘formal’’ has been deleted. d. Comment: One commenter asked that we clarify that this requirement relates to both the establishment of policies for the access control function and to access control (the implementation of those policies). Copyright © 2004 CRC Press, LLC


282


Response: ‘‘Information access management’’ does address both the establishment of access control policies and their implementation. We use the term ‘‘implement’’ to clarify that the procedures must be in use, and we believe that the requirement to implement policies and procedures requires, as an antecedent condition, the establishment or adaptation of those policies and procedures. 5. Security Awareness and Training (§ 164.308(a)(5)(i)) We proposed, under the requirement ‘‘Training,’’ that security training be required for all staff, including management. Training would include awareness training for all personnel, periodic security reminders, user education concerning virus protection, user education in the importance of monitoring login success/failure, and how to report discrepancies, and user education in password management. In this Þnal rule, we adopt this proposed requirement in modiÞed form. For the standard ‘‘Security awareness and training,’’ in § 164.308(a)(5), we require training of the workforce as reasonable and appropriate to carry out their functions in the facility. All proposed training features have been combined as implementation speciÞcations under this standard. SpeciÞc implementation speciÞcations relative to content are addressable. The ‘‘Virus protection’’ implementation feature has been renamed ‘‘protection from malicious software,’’ because we did not intend by the nomenclature to exclude coverage of malicious acts that might not come within the prior term, such as worms. a. Comment: One commenter believes that security awareness training for all system users would be too difÞcult to do in a large organization. Response: We disagree with the commenter. Security awareness training is a critical activity, regardless of an organization’s size. This feature would typically become part of an entity’s overall training program (which would include privacy and other information technology items as well). For example, the Government Information Systems Reform ACT (GISRA) of 2000 requires security awareness training as part of Federal agencies’ information security programs, including Federal covered entities, such as the Medicare program. In addition, National Institute of Standards and Technology (NIST) SP 800–16, Information Technology Security Training Requirements, A role and performance base model, April 1998, provides an excellent source of information and guidance on this subject and is targeted at industry as well as government activities. We also note that covered entities must have discretion in how they implement the requirement, so they can incorporate this training in other existing activities. One approach would be to require this training as part of employee orientation. b. Comment: A number of commenters asked that this requirement be made optional or used as a guideline only. Several commenters stated that this requirement is too speciÞc and is burdensome. Several asked that the implementation features be removed. Several others stated that this requirement is not appropriate for agents or contractors. One commenter asked how to apply this requirement to outsiders having access to data. Another asked if this requirement included all subcontractor staff.



Appendix III

283

Others stated that contracts, signed by entities such as consultants, that address training should be sufÞcient. Response: Security training remains a requirement because of its criticality; however, we have revised the implementation speciÞcations to indicate that the amount and type of training needed will be dependent upon an entity’s conÞguration and security risks. Business associates must be made aware of security policies and procedures, whether through contract language or other means. Covered entities are not required to provide training to business associates or anyone else that is not a member of their workforce. c. Comment: Several commenters questioned why security awareness training appeared in two places, under ‘‘Physical safeguards’’ as well as ‘‘Administrative safeguards.’’ Others questioned the appropriateness of security awareness training under ‘‘Physical safeguards.’’ Response: We reviewed the deÞnitions of the proposed ‘‘Awareness training for all personnel’’ (‘‘Administrative safeguards’’) implementation feature and the proposed ‘‘Security awareness training’’ (‘‘Physical safeguards’’) requirement. We agree that, to avoid confusion and eliminate redundancy, security awareness and training should appear in only one place. We believe the appropriate location for it is under ‘‘Administrative safeguards,’’ as such training is essentially an administrative function. d. Comment: Several commenters objected to the blanket requirement for security awareness training of individuals who may be on site for a limited time period (for example, a single day). Response: Each individual who has access to electronic protected health information must be aware of the appropriate security measures to reduce the risk of improper access, uses, and disclosures. This requirement does not mean lengthy training is appropriate in every instance; there are alternative methods to inform individuals of security responsibilities (for example, provisions of pamphlets or copies of security policies, and procedures). e. Comment: One commenter asked that ‘‘training’’ be changed to ‘‘orientation.’’ Response: We believe the term ‘‘training,’’ as presented within this rule is the more appropriate term. The rule does not contemplate a one-time type of activity as connoted by ‘‘orientation,’’ but rather an on-going, evolving process as an entity’s security needs and procedures change. f. Comment: Several commenters asked how often training should be conducted and asked for a deÞnition of ‘‘periodic,’’ as it appears in the proposed implementation feature ‘‘Periodic security reminders.’’ One asked if the training should be tailored to job need. Response: Amount and timing of training should be determined by each covered entity; training should be an ongoing, evolving process in response to environmental and operational changes affecting the security of electronic protected health information. While initial training must be carried out by the compliance date, we provide ßexibility for covered entities to construct training programs. Training can be tailored to job need if the covered entity so desires.



284


6. Security Incident Procedures (§ 164.308(a)(6)) We proposed a requirement for implementation of accurate and current security incident procedures: formal, documented report and response procedures so that security violations would be reported and handled promptly. We adopt this standard in the Þnal rule, along with an implementation speciÞcation for response and reporting, since documenting and reporting incidents, as well as responding to incidents are an integral part of a security program. a. Comment: Several commenters asked that we further deÞne the scope of a breach of security. Along this same line, another commenter stated that the proposed security incident procedures were too vague as stated. We were asked to specify what a security incident would be, what the internal chain for reporting procedures would be, and what should be included in the documentation (for example, hardware/ software, personnel responses). Response: We deÞne a security incident in § 164.304. Whether a speciÞc action would be considered a security incident, the speciÞc process of documenting incidents, what information should be contained in the documentation, and what the appropriate response should be will be dependent upon an entity’s environment and the information involved. An entity should be able to rely upon the information gathered in complying with the other security standards, for example, its risk assessment and risk management procedures and the privacy standards, to determine what constitutes a security incident in the context of its business operations. b. Comment: One commenter asked what types of incidents must be reported to outside entities. Another commented that we clarify that incident reporting is internal. Response: Internal reporting is an inherent part of security incident procedures. This regulation does not speciÞcally require any incident reporting to outside entities. External incident reporting is dependent upon business and legal considerations. c. Comment: One commenter stated that network activity should be included here. Response: We see no reason to exclude network activity under this requirement. Improper network activity should be treated as a security incident, because, by deÞnition, it represents an improper instance of access to or use of information. d. Comment: One commenter stated that this requirement should address suspected misuse also. Response: We agree that security incidents include misuse of data; therefore, this requirement is addressed. e. Comment: Several commenters asked that this requirement be deleted. One commenter asked that we delete the implementation features. Response: As indicated above, we have adopted the proposed standard and combined the implementation speciÞcations. 7. Contingency Plan (§ 164.308(a)(7)(i)) We proposed that a contingency plan must be in effect for responding to system emergencies. The plan would include an applications and data criticality analysis,



Appendix III

285

a data backup plan, a disaster recovery plan, an emergency mode operation plan, and testing and revision procedures. In this Þnal rule, we make the implementation speciÞcations for testing and revision procedures and an applications and data criticality analysis addressable, but otherwise require that the contingency features proposed be met. a. Comment: Several commenters suggested the contingency plan requirement be deleted. Several thought that this aspect of the proposed regulation went beyond its intended scope. Another believed that more discussion and development is needed before developing regulatory guidance on contingency plans. Others wanted this to be an optional requirement. In contrast, one commenter requested more guidance concerning contingency planning. Still others wanted to require that a contingency plan be in place but stated that we should not regulate its contents. One comment stated that data backup, disaster recovery, and emergency mode operation should not be part of this requirement. Response: A contingency plan is the only way to protect the availability, integrity, and security of data during unexpected negative events. Data are often most exposed in these events, since the usual security measures may be disabled, ignored, or not observed. Each entity needs to determine its own risk in the event of an emergency that would result in a loss of operations. A contingency plan may involve highly complex processes in one processing site, or simple manual processes in another. The contents of any given contingency plan will depend upon the nature and conÞguration of the entity devising it. While the contingency plan standard must be met, we agree that the proposed testing and revision implementation feature should be an addressable implementation speciÞcation in this Þnal rule. Dependent upon the size, conÞguration, and environment of a given covered entity, the entity should decide if testing and revision of all parts of a contingency plan should be done or if there are more reasonable alternatives. The same is true for the proposed applications and data criticality analysis implementation feature. We have revised the Þnal rule to reßect this approach. b. Comment: One commenter believed that adhering to this requirement could prove burdensome. Another stated that testing of certain parts of a contingency plan would be burdensome, and even infeasible, for smaller entities. Response: Without contingency planning, a covered entity has no assurance that its critical data could survive an emergency situation. Recent events, such as September 11, 2001, illustrate the importance of such planning. Contingency planning will be scalable based upon, among other factors, ofÞce conÞguration, and risk assessment. However, in response to the scalability issue raised by the commenter, we have made the testing and revision implementation speciÞcation addressable (see §164.308(a)(7)(ii)). c. Comment: Two commenters considered a 2-year implementation time frame for this requirement inadequate for large health plans. Another commenter stated that implementation of measures against natural disaster would be too big an issue for this regulation.



286


Response: The statute sets forth the compliance dates for the initial standards. The statute requires that compliance with initial standards is not later than 2 years after adoption of the standards for all covered entities except small health plans for which the compliance date is not later than 3 years after adoption. The Þnal rule calls for covered entities to consider how natural disasters could damage systems that contain electronic protected health information and develop policies and procedures for responding to such situations. We consider this to be a reasonable precautionary step to take since in many cases the risk would be deemed to be low. d. Comment: A commenter requested clariÞcation of the term ‘‘Emergency mode’’ with regard to the proposed ‘‘Emergency mode operation plan’’ implementation feature. Response: We have clariÞed the ‘‘Emergency mode operations plan’’ to show that it only involves those critical business processes that must occur to protect the security of electronic protected health information during and immediately after a crisis situation. 8. Evaluation (§ 164.308(a)(8)) We proposed that certiÞcation would be required and could be performed internally or by an external accrediting agency. We solicited input on appropriate mechanisms to permit an independent assessment of compliance. We were particularly interested in input from those engaging in health care electronic data interchange (EDI), as well as independent certiÞcation and auditing organizations addressing issues of documentary evidence of steps taken for compliance; need for, or desirability of, independent veriÞcation, validation, and testing of system changes; and certiÞcations required for off-the-shelf products used to meet the requirements of this regulation. We also solicited comments on the extent to which obtaining external certiÞcation would create an undue burden on small or rural providers. In this Þnal rule, we require covered entities to periodically conduct an evaluation of their security safeguards to demonstrate and document their compliance with the entity’s security policy and the requirements of this subpart. Covered entities must assess the need for a new evaluation based on changes to their security environment since their last evaluation, for example, new technology adopted or responses to newly recognized risks to the security of their information. a. Comment: We received several comments that certiÞcation should be performed externally. A larger group of commenters preferred self-certiÞcation. The majority of the comments, however, were to the effect that external certiÞcation should be encouraged but not mandated. A number of commenters thought that mandating external certiÞcation would create an undue Þnancial burden, regardless of the size of the entity being certiÞed. One commenter stated that external certiÞcation would not place an undue burden on a small or rural provider. Response: Evaluation by an external entity is a business decision to be left to each covered entity. Evaluation is required under § 164.308(a)(8), but a covered entity may comply with this standard either by using its own workforce or an external Copyright © 2004 CRC Press, LLC


Appendix III

287

accreditation agency, which would be acting as a business associate. External evaluation may be too costly an option for small entities. b. Comment: Several commenters stated that the certiÞcation should cover all components of the proposed rule, not just the information systems. Response: We agree. We have revised this section to reßect that evaluation would be both technical and nontechnical components of security. c. Comment: A number of commenters expressed a desire for the creation of certiÞcation guides or models to complement the rule. Response: We agree that creation of compliance guidelines or models for different business environments would help in the implementation and evaluation of HIPAA security requirements and we encourage professional associations and others to do so. We may develop technical assistance materials, but do not intend to create certiÞcation criteria because we do not have the resources to address the large number of different business environments. d. Comment: Some commenters asked how certiÞcation is possible without specifying the level of risk that is permissible. Response: The level of risk that is permissible is speciÞed by § 164.306(a). How such risk is managed will be determined by a covered entity through its security risk analysis and the risk mitigation activities it implements in order to ensure that the level of security required by § 164.306 is provided. e. Comment: Several commenters requested creation of a list of Federally ‘‘certiÞed’’ security software and off-the-shelf products. Several others stated that this request was not feasible. Regarding certiÞcation of off-the-shelf products, one commenter thought this should be encouraged, but not mandated; several thought this would be an impractical endeavor. Response: While we will not assume the task of certifying software and off-theshelf products for the reason described above, we have noted with interest that other Government agencies such as the National Institute of Standards and Technology (NIST) are working towards that end. The health care industry is encouraged to monitor the activity of NIST and provide comments and suggestions when requested (see http://www.niap.nist.gov.). f. Comment: One commenter stated, ‘‘With HCFA’s publishing of these HIPAA standards, and their desire to retain the Þnal responsibility for determining violations and imposing penalties of the statute, it also seems appropriate for HCFA to also provide certifying services to ensure security compliance.’’ Response: In view of the enormous number and variety of covered entities, we believe that evaluation can best be handled through the marketplace, which can develop more usable and targeted evaluation instruments and processes. 8. Business Associate Contracts or Other Arrangements (§ 164.308(b)(1)) In the proposed rule § 142.308(a)(2) ‘‘Chain of trust’’ requirement, we proposed that covered entities be required to enter into a chain of trust partner agreement with their business partners, in which the partners would agree to electronically exchange data and protect the integrity, conÞdentiality, and availability of the data Copyright © 2004 CRC Press, LLC


288


exchanged. This standard has been modiÞed from the proposed requirement to reßect, in § 164.308(b)(1) ‘‘Business associate contracts and other arrangements,’’ the business associate structure put in place by the Privacy Rule. In this Þnal rule, covered entities must enter into a contract or other arrangement with persons that meet the deÞnition of business associate in § 160.103. The covered entity must obtain satisfactory assurances from the business associate that it will appropriately safeguard the information in accordance with these standards (see §164.314(a)(1)). The comments received on the proposed chain of trust partner agreements are discussed in section 2 ‘‘Business associate contracts and other arrangements’’ of the discussion of § 164.314 below. 9. Proposed Requirements Not Adopted in This Final Rule a. Security Configuration Management We proposed that an organization would be required to implement measures, practices, and procedures regarding security conÞguration management. They would be coordinated and integrated with other system conÞguration management practices for the security of information systems. These would include documentation, hardware and/or software installation and maintenance review and testing for security features, inventory procedures, security testing, and virus checking. Comment: Several commenters asked that the entire requirement be deleted. Several others asked that the inventory and virus checking implementation features be removed as they believe those features are not germane to security conÞguration management. A number of commenters requested that security testing be deleted because this implementation feature is too detailed, unreasonable, impractical, and beyond the scope of the legislation. Others stated that the testing would be very complex and expensive. Others wanted more clariÞcation of what we intend by security testing, and how much would be enough. A number of commenters asked that all of the implementation features be deleted. Others asked that the implementation features be made optional. Several commenters wanted to know the scope of organizational integration required. Several others asked if what we meant by Security ConÞguration Management was change or version control. Response: Upon review, this requirement appears unnecessary because it is redundant of other requirements we are adopting in this rule. A covered entity will have addressed the activities described by the features under this proposed requirement by virtue of having implemented the risk analysis, risk management measures, sanction policies, and information systems criticality review called for under the security management process. The proposed documentation implementation feature has been made a separate standard (see § 164.316). As a result, the Security ConÞguration Management requirement is not adopted in this Þnal rule. b. Formal Mechanism for Processing Records The proposed rule proposed requiring a formal mechanism for processing records, and documented policies and procedures for the routine and nonroutine receipt,



Appendix III

289

manipulation, storage, dissemination, transmission, and/or disposal of health information. This requirement has not been adopted in the Þnal rule. Comment: Several commenters thought this requirement concerned the regulation of formal procedures for how an entity does business and stated that such procedures should not be regulated. Others asked for additional clariÞcation of what is meant by this requirement. One commenter thought the requirement too ambiguous and asked for clariÞcation as to whether we meant such things as ‘‘the proper handling of storage media, databases, transmissions,’’ or ‘‘the clinical realm of processes.’’ Two commenters asked how extensive this requirement would be and whether systems’ user manuals and policies and procedures for handling health information would sufÞce and what level of detail would be expected. Several thought this requirement could result in a signiÞcant resource and monetary burden to develop and maintain formal procedures. Two asked for an explanation of the beneÞt to be derived from this requirement. One asked that covered entities be required to document processes that create a security risk only and suggested that a risk assessment would determine the need for this documentation. Response: We agree with the commenters that the standard is ambiguous, and upon review, is unnecessary because the remaining standards, for example, device and media controls, provide adequate safeguards. Accordingly, this requirement is not adopted in this Þnal rule.

F. PHYSICAL SAFEGUARDS (§ 164.310) We proposed requirements and implementation features for documented physical safeguards to guard data integrity, conÞdentiality, and availability. We proposed to require safeguards in the following areas: Assigned security responsibility; media controls; physical access controls; policies and guidelines on workstation use; a secure workstation location; and security awareness training. A number of speciÞc implementation features were proposed under the media controls and physical access controls requirements. In § 164.310 of this Þnal rule, most of the proposed implementation features are adopted as addressable implementation speciÞcations. The proposed requirements for the assigned security responsibility and security awareness training requirements are relocated in § 164.308. 1. General Comments a. Comment: Several commenters made suggestions to modify the language to more clearly describe ‘‘Physical safeguards.’’ Response: In response to comments, we have revised the deÞnition of ‘‘Physical safeguards’’ to read as follows: ‘‘Physical safeguards are security measures to protect a covered entity’s electronic information systems and related buildings and equipment, from natural and environmental hazards, and unauthorized intrusion.’’



290


b. Comment: One commenter was concerned that electronic security systems could not be used in lieu of physical security systems. Response: This Þnal rule does not preclude the use of electronic security systems in lieu of, or in combination with, physical security systems to meet a ‘‘Physical safeguard’’ standard. 2. Facility Access Controls (§ 164.310(a)(1)) We proposed, under the ‘‘Physical access controls’’ requirement, formal, documented policies and procedures for limiting physical access to an entity while ensuring that properly authorized access is allowed. These controls would include the following implementation features: disaster recovery, emergency mode operation, equipment control (into and out of site), a facility security plan, procedures for verifying access authorizations before physical access, maintenance records, needto-know procedures for personnel access, sign-in for visitors and escort, if appropriate, and testing and revision. In § 164.310(a)(2) below, we combine and restate these as addressable implementation speciÞcations. These are contingency operations, facility security plan, access control and validation procedures, and maintenance records. a. Comment: Many commenters were concerned because the proposed language would require implementation of all physical access control features. Other commenters were concerned that the language did not allow entities to use the results of their risk assessment and risk management process to arrive at the appropriate solutions for them. Response: We agree that implementation of all implementation speciÞcations may not be appropriate in all situations. While the facility access controls standard must be met, we agree that the implementation speciÞcations should not be required in all circumstances, but should be addressable. In this Þnal rule, all four implementation speciÞcations are addressable. We have also determined, based on ‘‘level of detail’’ comments requesting consolidation of the list of implementation features, that the proposed implementation feature ‘‘Equipment control (into and out of site)’’ was redundant. ‘‘Equipment control’’ is already covered under the ‘‘Device and media controls’’ standard at § 164.310(d)(1). Accordingly, we have eliminated it as a separate implementation speciÞcation. b. Comment: One commenter raised the issue of a potential conßict of authority between those having access to the data and those responsible for checking and maintaining access controls. Response: Any potential conßicts should be identiÞed, addressed, and resolved in the policies and procedures developed according to the standards under § 164.308. c. Comment: Several commenters questioned whether ‘‘Physical Access Controls’’ was a descriptive phrase to describe a technology to be used, or whether the phrase referred to a facility. Response: We agree that the term ‘‘Physical’’ may be misleading; to remove any confusion, the requirement is reßected in this Þnal rule as a standard titled ‘‘Facility access controls.’’ We believe this is a more precise term to describe that Copyright © 2004 CRC Press, LLC


Appendix III

291

the standard, and its associated implementation speciÞcations, is applicable to an entity’s business location or locations. d. Comment: Several commenters requested that the disaster recovery and emergency mode operations features be moved to ‘‘Administrative safeguards.’’ Other commenters recommended that disaster recovery and emergency mode operations should be replaced by, and included in, a ‘‘Contingency Operations’’ implementation feature. Response: The ‘‘Administrative safeguards’’ section addresses the contingency planning that must be done to contend with emergency situations. The placement of the disaster recovery and emergency mode operations implementation speciÞcations in the ‘‘Physical safeguards’’ section is also appropriate, however, because ‘‘Physical safeguards’’ deÞnes the physical operations (processes) that provide access to the facility to implement the associated plans, developed under § 164.308. We agree, however, that the term ‘‘contingency operations’’ better describes, and would include, disaster recovery and emergency mode operations, and have modiÞed the regulation text accordingly (see § 164.310(a)(1)). e. Comment: Commenters were concerned about having to address in their facility security plan the exterior/ interior security of a building when they are one of many occupants rather than the sole occupant. Additional commenters were concerned that the responsibility for physical security of the building could not be delegated to a third party when the covered entity shares the building with other ofÞces. Response: The facility security plan is an addressable implementation speciÞcation. However, the covered entity retains responsibility for considering facility security even where it shares space within a building with other organizations. Facility security measures taken by a third party must be considered and documented in the covered entity’s facility security plan, when appropriate. 3. Workstation Use (§ 164.310(b)) We proposed policy and guidelines on workstation use that included documented instructions/procedures delineating the proper functions to be performed and the manner in which those functions are to be performed (for example, logging off before leaving a workstation unattended) to maxim Comment: One commenter was concerned most people may be misled by the use of ‘‘terminal’’ as an example in the deÞnition of workstation. The concern was that the standard only addresses ‘‘Þxed location devices,’’ while in many instances the workstation has become a laptop computer. Response: For clarity, we have added the deÞnition of ‘‘workstation’’ to § 164.304 and deleted the word ‘‘terminal’’ from the description of workstation use in § 164.310(b). 4. Workstation Security (§ 164.310(c)) We proposed that each organization would be required to put in place physical safeguards to restrict access to information. In this Þnal rule, we retain the general requirement for a secure workstation.



292


Comment: Comments were directed toward the example proÞled in the deÞnition of a secure workstation location. It was believed that what constitutes a secure workstation location must be dependent upon the entity’s risk management process. Response: We agree that what constitutes an appropriate solution to a covered entity’s workstation security issues is dependent on the entity’s risk analysis and risk management process. Because many commenters incorrectly interpreted the examples as the required and only solution for securing the workstation location, we have modiÞed the regulations text description to generalize the requirement (see § 164.310(c)). Also, for clarity, the title ‘‘Secure workstation location’’ has been changed to ‘‘Workstation security’’ (see also the deÞnition of ‘‘Workstation’’ at §164.304). 5. Device and Media Controls (§164.310(d)(1)) We proposed that covered entities have media controls in the form of formal, documented policies and procedures that govern the receipt and removal of hardware and/or software (for example, diskettes and tapes) into and out of a facility. Implementation features would have included ‘‘Access control,’’ ‘‘Accountability’’ (tracking mechanism), ‘‘Data backup,’’ ‘‘Data storage,’’ and ‘‘Disposal.’’ In this Þnal rule, we adopt most of these provisions as addressable implementation speciÞcations and add a speciÞcation for media re-use. We change the name from ‘‘Media controls’’ to ‘‘Device and media controls’’ to more clearly reßect that this standard concerns hardware as well as electronic media. The proposed ‘‘Access control’’ implementation feature has been removed, as it is addressed as part of other standards (see section III.C.12.c of this preamble). a. Comment: One commenter was concerned about the exclusion of removable media devices from examples of physical types of hardware and/or software. Response: The media examples used were not intended to represent all possible physical types of hardware and/or software. Removable media devices, although not speciÞcally listed, are not intended to be excluded. b. Comment: Comments were made that the issue of equipment re-use or recycling of media containing mass storage was not addressed in ‘‘Media controls.’’ Response: We agree that equipment re-use or recycling should be addressed, since this equipment may contain electronic protected health information. The ‘‘Device and media controls’’ standard is accordingly expanded to include a required implementation speciÞcation that addresses the re-use of media (see § 164.310(d)(2)(ii)). c. Comment: Several commenters asked for a deÞnition of the term ‘‘facility,’’ as used in the proposed ‘‘Media controls’’ requirement description. Commenters were unclear whether we were talking about a corporate entity or the physical plant. Response: The term ‘‘facility’’ refers to the physical premises and the interior and exterior of a building(s). We have added this deÞnition to § 164.304. d. Comment: Several commenters believe the ‘‘Media controls’’ implementation features are too onerous and should be deleted. Response: While the ‘‘Device and media controls’’ standard must be met, we believe, based upon further review, that implementation of all speciÞcations would not be necessary in every situation, and might even be counterproductive in some Copyright © 2004 CRC Press, LLC


Appendix III

293

situations. For example, small providers would be unlikely to be involved in largescale moves of equipment that would require systematic tracking, unlike, for example, large health care providers or health plans. We have, therefore, reclassiÞed the ‘‘Accountability and data backup’’ implementation speciÞcation as addressable to provide more ßexibility in meeting the standard. e. Comment: One commenter was concerned about the accountability impact of audit trails on system resources and the pace of system services. Response: The proposed audit trail implementation feature appears as the addressable ‘‘Accountability’’ implementation speciÞcation. The name change better reßects the purpose and intended scope of the implementation speciÞcation. This implementation speciÞcation does not address audit trails within systems and/or software. Rather it requires a record of the actions of a person relative to the receipt and removal of hardware and/or software into and out of a facility that are traceable to that person. The impact of maintaining accountability on system resources and services will depend upon the complexity of the mechanism to establish accountability. For example, the appropriate mechanism for a given entity may be manual, such as receipt and removal restricted to speciÞc persons, with logs kept. Maintaining accountability in such a fashion should have a minimal, if any, effect on system resources and services. f. Comment: A commenter was concerned about the resource expenditure (system and Þscal) for total e-mail backup and wanted a clariÞcation of the extensiveness of data backup. Response: The data an entity needs to backup, and which operations should be used to carry out the backup, should be determined by the entity’s risk analysis and risk management process. The data backup plan, which is part of the required contingency plan (see § 164.308(a)(7)(ii)(A)), should deÞne exactly what information is needed to be retrievable to allow the entity to continue business ‘‘as usual’’ in the face of damage or destruction of data, hardware, or software. The extent to which e-mail backup would be needed would be determined through that analysis.

G. TECHNICAL SAFEGUARDS (§ 164.312) We proposed Þve technical security services requirements with supporting implementation features: Access control; Audit controls; Authorization control; Data authentication; and Entity authentication. We also proposed speciÞc technical security mechanisms for data transmitted over a communications network, Communications/network controls with supporting implementation features; Integrity controls; Message authentication; Access controls; Encryption; Alarm; Audit trails; Entity authentication; and Event reporting. In this Þnal rule, we consolidate these provisions into § 164.312. That section now includes standards regarding access controls, audit controls, integrity (previously titled data authentication), person or entity authentication, and transmission security. As discussed below, while certain implementation speciÞcations are required, many of the proposed security implementation features are now addressable implementation speciÞcations. The function of authorization control has been incorporated into the information access management standard under § 164.308, Administrative safeguards. Copyright © 2004 CRC Press, LLC


294


1. Access Control (§ 164.312(a)(1)) In the proposed rule, we proposed to require that the access controls requirement include features for emergency access procedures and provisions for context-based, role-based, and/or user-based access; we also proposed the optional use of encryption as a means of providing access control. In this Þnal rule, we require unique user identiÞcation and provision for emergency access procedures, and retain encryption as an addressable implementation speciÞcation. We also make ‘‘Automatic logoff’’ an addressable implementation speciÞcation. ‘‘Automatic logoff’’ and ‘‘Unique user identiÞcation’’ were formerly implementation features under the proposed ‘‘Entity authentication’’ (see §164.312(d)). a. Comment: Some commenters believe that in specifying ‘‘Context,’’ ‘‘Role,’’ and ‘‘User’’ based controls, use of other controls would effectively be excluded, for example, ‘‘Partition rule-based access controls,’’ and the development of new access control technology. Response: We agree with the commenters that other types of access controls should be allowed. There was no intent to limit the implementation features to the named technologies and this Þnal rule has been reworded to make it clear that use of any appropriate access control mechanism is allowed. Proposed implementation features titled ‘‘Context-based access,’’ ‘‘Role-based access,’’ and ‘‘User-based access’’ have been deleted and the access control standard at § 164.312(a)(1) states the general requirement. b. Comment: A large number of comments were received objecting to the identiÞcation of ‘‘Automatic logoff’’ as a mandatory implementation feature. Generally the comments asked that we not be so speciÞc and allow other forms of inactivity lockout, and that this type of feature be made optional, based more on the particular conÞguration in use and a risk assessment/analysis. Response: We agree with the comments that mandating an automatic logoff is too speciÞc. This Þnal rule has been written to clarify that the proposed implementation feature of automatic logoff now appears as an addressable access control implementation speciÞcation and also permits the use of an equivalent measure. c. Comment: We received comments asking that encryption be deleted as an implementation feature and stating that encryption is not required for ‘‘data at rest.’’ Response: The use of Þle encryption is an acceptable method of denying access to information in that Þle. Encryption provides conÞdentiality, which is a form of control. The use of encryption, for the purpose of access control of data at rest, should be based upon an entity’s risk analysis. Therefore, encryption has been adopted as an addressable implementation speciÞcation in this Þnal rule. d. Comment: We received one comment stating that the proposed implementation feature ‘‘Procedure for emergency access,’’ is not access control and recommending that emergency access be made a separate requirement. Response: We believe that emergency access is a necessary part of access controls and, therefore, is properly a required implementation speciÞcation of the ‘‘Access controls’’ standard. Access controls will still be necessary under emergency conditions, although they may be very different from those used in normal operational circumstances. For example, in a situation when normal environmental systems, including Copyright © 2004 CRC Press, LLC


Appendix III

295

electrical power, have been severely damaged or rendered inoperative due to a natural or man-made disaster, procedures should be established beforehand to provide guidance on possible ways to gain access to needed electronic protected health information. 2. Audit Controls (§ 164.312(b)) We proposed that audit control mechanisms be put in place to record and examine system activity. We adopt this requirement in this Þnal rule. a. Comment: We received a comment stating that ‘‘Audit controls’’ should be an implementation feature rather than the standard, and suggesting that we change the title of the standard to ‘‘Accountability,’’ and provide additional detail to the audit control implementation feature. Response: We do not adopt the term ‘‘Accountability’’ in this Þnal rule because it is not descriptive of the requirement, which is to have the capability to record and examine system activity. We believe that it is appropriate to specify audit controls as a type of technical safeguard. Entities have ßexibility to implement the standard in a manner appropriate to their needs as deemed necessary by their own risk analyses. For example, see NIST Special Publication 800–14, Generally Accepted Principles and Practices for Securing Information Technology Systems and NIST Special Publication 800–33, Underlying Technical Models for Information Technology Security. b. Comment: One commenter recommended that this Þnal rule state that audit control mechanisms should be implemented based on the Þndings of an entity’s risk assessment and risk analysis. The commenter asserted that audit control mechanisms should be utilized only when appropriate and necessary and should not adversely affect system performance. Response: We support the use of a risk assessment and risk analysis to determine how intensive any audit control function should be. We believe that the audit control requirement should remain mandatory, however, since it provides a means to assess activities regarding the electronic protected health information in an entity’s care. c. Comment: One commenter was concerned about the interplay of State and Federal requirements for auditing of privacy data and requested additional guidance on the interplay of privacy rights, laws, and the expectation for audits under the rule. Response: In general, the security standards will supercede any contrary provision of State law. Security standards in this Þnal rule establish a minimum level of security that covered entities must meet. We note that covered entities may be required by other Federal law to adhere to additional, or more stringent security measures. Section 1178(a)(2) of the statute provides several exceptions to this general rule. With regard to protected health information, the preemption of State laws and the relationship of the Privacy Rule to other Federal laws is discussed in the Privacy Rule beginning at 65 FR 82480; the preemption provisions of the rule are set out at 45 CFR part 160, subpart B. It should be noted that although the Privacy Rule does not incorporate a requirement for an ‘‘audit trail’’ function, it does call for providing an accounting of certain disclosures of protected health information to an individual upon request. There has Copyright © 2004 CRC Press, LLC


296


been a tendency to assume that this Privacy Rule requirement would be satisÞed via some sort of process involving audit trails. We caution against assuming that the Security Rule’s requirement for an audit capability will satisfy the Privacy Rule’s requirement regarding accounting for disclosures of protected health information. The two rules cover overlapping, but not identical information. Further, audit trails are typically used to record uses within an electronic information system, while the Privacy Rule requirement for accounting applies to certain disclosures outside of the covered entity (for example, to public health authorities). 3. Integrity (§ 164.312(c)(1)) We proposed under the ‘‘Data authentication’’ requirement, that each organization be required to corroborate that data in its possession have not been altered or destroyed in an unauthorized manner and provided examples of mechanisms that could be used to accomplish this task. We adopt the proposed requirement for data authentication in the Þnal rule as an addressable implementation speciÞcation ‘‘Mechanism to authenticate data,’’ under the ‘‘Integrity’’ standard. a. Comment: We received a large number of comments requesting clariÞcation of the ‘‘Data authentication’’ requirement. Many of these comments suggested that the requirement be called ‘‘Data integrity’’ instead of ‘‘Data authentication.’’ Others asked for guidance regarding just what ‘‘data’’ must be authenticated. A signiÞcant number of commenters indicated that this requirement would put an extraordinary burden on large segments of the health care industry, particularly when legacy systems are in use. Requests were received to make this an ‘‘optional’’ requirement, based on an entity’s risk assessment and analysis. Response: We adopt the suggested ‘‘integrity’’ terminology because it more clearly describes the intent of the standard. We retain the meaning of the term ‘‘Data authentication’’ under the addressable implementation speciÞcation ‘‘Mechanism to authenticate data,’’ and provide an example of a potential means to achieve data integrity. Error-correcting memory and magnetic disc storage are examples of the builtin data authentication mechanisms that are ubiquitous in hardware and operating systems today. The risk analysis process will address what data must be authenticated and should provide answers appropriate to the different situations faced by the various health care entities implementing this regulation. Further, we believe that this standard will not prove difÞcult to implement, since there are numerous techniques available, such as processes that employ digital signature or check sum technology to accomplish the task. b. Comment: We received numerous comments suggesting that ‘‘Double keying’’ be deleted as a viable ‘‘Data authentication’’ mechanism, since this practice was generally associated with the use of punched cards. Response: We agree that the process of ‘‘Double keying’’ is outdated. This Þnal rule omits any reference to ‘‘Double keying.’’ 4. Person or Entity Authentication (§ 164.312(d)) We proposed that an organization implement the requirement for ‘‘Entity authentication’’, the corroboration that an entity is who it claims to be. ‘‘Automatic logoff’’ Copyright © 2004 CRC Press, LLC


Appendix III

297

and ‘‘Unique user identiÞcation’’ were speciÞed as mandatory features, and were to be coupled with at least one of the following features: (1) A ‘‘biometric’’ identiÞcation system; (2) a ‘‘password’’ system; (3) a ‘‘personal identiÞcation number’’; and (4) ‘‘telephone callback,’’ or a ‘‘token’’ system that uses a physical device for user identiÞcation. In this Þnal rule, we provide a general requirement for person or entity authentication without the speciÞcs of the proposed rule. Comment: We received comments from a number of organizations requesting that the implementation features for entity authentication be either deleted in their entirety or at least be made optional. On the other hand, comments were received requesting that the use of digital signatures and soft tokens be added to the list of implementation features. Response: We agree with the commenters that many different mechanisms may be used to authenticate entities, and this Þnal rule now reßects this fact by not incorporating a list of implementation speciÞcations, in order to allow covered entities to use whatever is reasonable and appropriate. ‘‘Digital signatures’’ and ‘‘soft tokens’’ may be used, as well as many other mechanisms, to implement this standard. The proposed mandatory implementation feature, ‘‘Unique user identiÞcation,’’ has been moved from this standard and is now a required implementation speciÞcation under ‘‘Access control’’ at § 164.312(a)(1). ‘‘Automatic logoff’’ has also been moved from this standard to the ‘‘Access control’’ standard and is now an addressable implementation speciÞcation. 5. Transmission Security (§ 164.312(e)(1)) Under ‘‘Technical Security Mechanisms to Guard Against Unauthorized Access to Data that is Transmitted Over a Communications Network,’’ we proposed that ‘‘Communications/network controls’’ be required to protect the security of health information when being transmitted electronically from one point to another over open networks, along with a combination of mandatory and optional implementation features. We proposed that some form of encryption must be employed on ‘‘open’’ networks such as the Internet or dial-up lines. In this Þnal rule, we adopt integrity controls and encryption, as addressable implementation speciÞcations. a. Comment: We received a number of comments asking for overall clariÞcation as well as a deÞnition of terms used in this section. A deÞnition for the term ‘‘open networks’’ was the most requested action, but there was a general expression of dislike for the manner in which we approached this section, with some comments suggesting that the entire section be rewritten. A signiÞcant number of comments were received on the question of encryption requirements when dial-up lines were to be employed as a means of connectivity. The overwhelming majority strongly urged that encryption not be mandatory when using any transmission media other than the Internet, but rather be considered optional based on individual entity risk assessment/analysis. Many comments noted that there are very few known breaches of security over dial-up lines and that nonjudicious use of encryption can adversely affect processing times and become both Þnancially and technically burdensome. Only one commenter suggested that ‘‘most’’ external trafÞc should be encrypted. Copyright © 2004 CRC Press, LLC


298


Response: In general, we agree with the commenters who asked for clariÞcation and revision. This Þnal rule has been signiÞcantly revised to reßect a much simpler and more direct requirement. The term ‘‘Communications/network controls’’ has been replaced with ‘‘Transmission security’’ to better reßect the requirement that, when electronic protected health information is transmitted from one point to another, it must be protected in a manner commensurate with the associated risk. We agree with the commenters that switched, point-to-point connections, for example, dial-up lines, have a very small probability of interception. Thus, we agree that encryption should not be a mandatory requirement for transmission over dial-up lines. We also agree with commenters who mentioned the Þnancial and technical burdens associated with the employment of encryption tools. Particularly when considering situations faced by small and rural providers, it became clear that there is not yet available a simple and interoperable solution to encrypting e-mail communications with patients. As a result, we decided to make the use of encryption in the transmission process an addressable implementation speciÞcation. Covered entities are encouraged, however, to consider use of encryption technology for transmitting electronic protected health information, particularly over the internet. As business practices and technology change, there may arise situations where electronic protected health information being transmitted from a covered entity would be at signiÞcant risk of being accessed by unauthorized entities. Where risk analysis showed such risk to be signiÞcant, we would expect covered entities to encrypt those transmissions, if appropriate, under the addressable implementation speciÞcation for encryption. We do not use the term ‘‘open network’’ in this Þnal rule because its meaning is too broad. We include as an addressable implementation speciÞcation the requirement that transmissions be encrypted when appropriate based on the entity’s risk analysis. b. Comment: We received comments requesting that the implementation features be deleted or made optional. Three commenters asked that the requirement for an alarm be deleted. Response: This Þnal rule has been revised to reßect deletion of the following implementation features: (1) The alarm capability; (2) audit trail; (3) entity authentication; and (4) event reporting. These features were associated with a proposed requirement for ‘‘Communications/network controls’’ and have been deleted since they are normally incorporated by telecommunications providers as part of network management and control functions that are included with the provision of network services. A health care entity would not expect to be responsible for these technical telecommunications features. ‘‘Access controls’’ has also been deleted from the implementation features since the consideration of the use of encryption will satisfy the intent of this feature. We retain as addressable implementation speciÞcations two features: (1) ‘‘Integrity controls’’ and ‘‘encryption’’. ‘‘Message authentication’’ has been deleted as an implementation feature because the use of data authentication codes (called for in the ‘‘integrity controls’’ implementation speciÞcation) satisÞes the intent of ‘‘Message authentication.’’ c. Comment: A number of comments were received asking that this Þnal rule establish a speciÞc (or at least a minimum) cryptographic algorithm strength. Others Copyright © 2004 CRC Press, LLC


Appendix III

299

recommended that the rule not specify an encryption strength since technology is changing so rapidly. Several commenters requested guidelines and minimum encryption standards for the Internet. Another stated that, since an example was included (small or rural providers for example), the government should feel free to name a speciÞc encryption package. One commenter stated that the requirement for encryption on the Internet should reference the ‘‘CMS Internet Security Policy.’’ Response: We remain committed to the principle of technology neutrality and agree with the comment that rapidly changing technology makes it impractical and inappropriate to name a speciÞc technology. Consistent with this principle, speciÞcation of an algorithm strength or speciÞc products would be inappropriate. Moreover, rapid advances in the success of ‘‘brute force’’ cryptanalysis techniques suggest that any minimum speciÞcation would soon be outmoded. We maintain that it is much more appropriate for this Þnal rule to state a general requirement for encryption protection when necessary and depend on covered entities to specify technical details, such as algorithm types and strength. Because ‘‘CMS Internet Security Policy’’ is the policy of a single organization and applies only to information sent to CMS, and not between all covered entities, we have not referred to it here. d. Comment: The proposed deÞnition of ‘‘Integrity controls’’ generated comments that asked that the word ‘‘validity’’ be changed to ‘‘Integrity.’’ Commenters were concerned about the ability of an entity to ensure that information was ‘‘valid.’’ Response: We agree with the commenters about the meaning of the word ‘‘validity’’ in the context of the proposed deÞnition of ‘‘Integrity controls.’’ We have named ‘‘integrity controls’’ as an implementation speciÞcation in this Þnal rule to require mechanisms to ensure that electronically transmitted information is not improperly modiÞed without detection (see § 164.312(c)(1)). e. Comment: Three commenters asked for clariÞcation and guidance regarding the unsolicited electronic receipt of health information in an unsecured manner, for example, when the information was submitted by a patient via e-mail over the Internet. Commenters asked for guidance as to what was their obligation to protect data received in this manner. Response: The manner in which electronic protected health information is received by a covered entity does not affect the requirement that security protection must subsequently be afforded to that information by the covered entity once that information is in possession of the covered entity. 6. Proposed Requirements Not Adopted in This Final Rule a. Authorization Control We proposed, under ‘‘Technical Security Services to Guard Data Integrity, ConÞdentiality, and Availability,’’ that a mechanism be required for obtaining consent for the use and disclosure of health information using either ‘‘Role-based access’’ or ‘‘User-based access’’ controls. In this Þnal rule, we do not adopt this requirement. Comment: We received a large number of comments regarding use of the word ‘‘consent.’’ It was pointed out that this could be construed to mean patient consent to the use or disclosure of patient information, which would make this a privacy issue, rather than one of security. Other comments suggested deletion of the requireCopyright © 2004 CRC Press, LLC


300


ment in its entirety. We received a comment asking for clariÞcation about the distinction between ‘‘Access control’’ and ‘‘Authorizations.’’ Response: These requirements were intended to address authorization of workforce members and others for the use and disclosure of health information, not patient consent. Upon reviewing the differences between ‘‘Access control’’ and ‘‘Authorization control,’’ we found it to be unnecessary to retain ‘‘Authorization control’’ as a separate requirement. Both the access control and the authorization control proposed requirements involved implementation of types of automated access controls, that is, role-based access and user-based access. It can be argued that the process of managing access involves allowing and restricting access to those individuals that have been authorized to access the data. The intent of the proposed authorization control implementation feature is now incorporated in the access authorization implementation speciÞcation under the information access management standard in § 164.308(a)(4). Under the information access management standard, a covered entity must implement, if appropriate and reasonable to its situation, policies and procedures Þrst to authorize a person to access electronic protected health information and then to actually establish such access. These policies and procedures will enable entities to follow the Privacy Rule minimum necessary requirements, which provide when persons should have access to information.

H. ORGANIZATIONAL REQUIREMENTS (§ 164.314) We proposed that each health care clearinghouse must comply with the security standards to ensure all health information and activities are protected from unauthorized access. If the clearinghouse is part of a larger organization, then unauthorized access by the larger organization must be prevented. We also proposed that parties processing data through a third party would be required to enter into a chain of trust partner agreement, a contract in which the parties agree to electronically exchange data and to protect the transmitted data in accordance with the security standards. In this Þnal rule, we have adopted the concepts of hybrid and afÞliated entities, as previously deÞned in § 164.504, and now deÞned in § 164.103, and business associates as deÞned in § 160.103, to be consistent with the Privacy Rule. General organizational requirements related to afÞliated covered entities and hybrid entities are now contained in a new § 164.105. The proposed chain of trust partner agreement has been replaced by the standards for business associate contracts or other arrangements and the standards for group health plans. Consistent with the statute and the policy of the Privacy Rule, this Þnal rule does not require noncovered entities to comply with the security standards. 1. Health Care Clearinghouses The proposed rule proposed that if a health care clearinghouse were part of a larger organization, it would be required to ensure that all health information pertaining to an individual is protected from unauthorized access by the larger organization; this statement closely tracked the statutory language in section 1173(d)(1)(B) of the Act. Since the point of the statutory language is to ensure that health care information in the possession of a health care clearinghouse is not inappropriately accessed by the Copyright © 2004 CRC Press, LLC


Appendix III

301

larger organization of which it is a part, this Þnal rule implements the statutory language through the information access management provision of §164.308(a)(4)(ii)(A). The Þnal rule, at § 164.105, makes the health care component and afÞliated entity standards of the Privacy Rule applicable to the security standards. Therefore, we have not changed those standards substantively. In pertaining to the Privacy Rule, we have simply moved them to a new location in part 164. Any differences between § 164.105 and § 164.504(a) through (d) reßects the addition of requirements speciÞc to the security standards. The health care component approach was developed in response to extensive comment received principally on the Privacy Rule. See 65 FR 82502 through 82503 and 82637 through 82640 for a discussion of the policy concerns underlying the health care component approach. Since the security standards are intended to support the protection of electronic information protected by the Privacy Rule, it makes sense to incorporate organizational requirements that parallel those required of covered entities by the Privacy Rule. This policy will also minimize the burden of complying with both rules. a. Comment: Relative to the following preamble statement (63 FR 43258): ‘‘If the clearinghouse is part of a larger organization, then security must be imposed to prevent unauthorized access by the larger organization.’’ One commenter asked what is considered to be ‘‘the larger organization.’’ For example, if a clearinghouse function occurs in a department of a larger business entity, will the regulation cover all internal electronic communication, such as e-mail, within the larger business and all external electronic communication, such as e-mail with its owners? Response: The ‘‘larger organization’’ is the overall business entity that a clearinghouse would be part of. Under the Security Rule, the larger organization must assure that the health care clearinghouse function has instituted measures to ensure only that electronic protected health information that it processes is not improperly accessed by unauthorized persons or other entities, including the larger organization. Internal electronic communication within the larger organization will not be covered by the rule if it does not involve the clearinghouse, assuming that it has designated health care components, of which the health care clearinghouse is one. External communication must be protected as sent by the clearinghouse, but need not be protected once received. b. Comment: One commenter asked that the Þrst sentence in § 142.306(b) of the proposed rule, ‘‘If a health care clearinghouse is part of a larger organization, it must assure all health information is protected from unauthorized access by the larger organization’’ be expanded to read, ‘‘If a health care clearinghouse or any other health care entity is part of a larger organization . . .’’ Response: The Act speciÞcally provides, at section 1173(d)(1)(B), that the Secretary must adopt standards to ensure that a health care clearinghouse, if part of a larger organization, has policies and security procedures to protect information from unauthorized access by the larger organization. Health care providers and health plans are often part of larger organizations that are not themselves health care providers or health plans. The security measures implemented by health plans and covered health care providers should protect electronic protected health information in circumstances such as the one identiÞed by the comCopyright © 2004 CRC Press, LLC


302


menter. Therefore, we agree with the comment that the requirement should be expanded as suggested by the commenter. In this Þnal rule, those components of a hybrid entity that are designated as health care components must comply with the security standards and protect against unauthorized access with respect to the other components of the larger entity in the same way as they must deal with separate entities. 2. Business Associate Contracts and Other Arrangements We proposed that parties processing data through a third party would be required to enter into a chain of trust partner agreement, a contract in which the parties agree to electronically exchange data and to protect the transmitted data. This Þnal rule narrows the scope of agreements required. It essentially tracks the provisions in § 164.502(e) and § 164.504(e) of the Privacy Rule, although appropriate modiÞcations have been made in this rule to the required elements of the contract. In this Þnal rule, a contract between a covered entity and a business associate must provide that the business associate must—(1) implement safeguards that reasonably and appropriately protect the conÞdentiality, integrity, and availability of the electronic protected health information that it creates, receives, maintains, or transmits on behalf of the covered entity; (2) ensure that any agent, including a subcontractor, to whom it provides this information agrees to implement reasonable and appropriate safeguards; (3) report to the covered entity any security incident of which it becomes aware; (4) make its policies and procedures, and documentation required by this subpart relating to such safeguards, available to the Secretary for purposes of determining the covered entity’s compliance with this subpart; and (5) authorize termination of the contract by the covered entity if the covered entity determines that the business associate has violated a material term of the contract. When a covered entity and its business associate are both governmental entities, an ‘‘other arrangement’’ is sufÞcient. The covered entity is in compliance with this standard if it enters into a memorandum of understanding with the business associate that contains terms that accomplish the objectives of the above-described business associate contract. However, the covered entity may omit from this memorandum the termination authorization required by the business associate contract provisions if this authorization is inconsistent with the statutory obligations of the covered entity or its business associate. If other law (including regulations adopted by the covered entity or its business associate) contains requirements applicable to the business associate that accomplish the objectives of the above-described business associate contract, a contract or agreement is not required. If a covered entity enters into other arrangements with another governmental entity that is a business associate, such arrangements may omit provisions equivalent to the termination authorization required by the business associate contract, if inconsistent with the statutory obligation of the covered entity or its business associate. If a business associate is required by law to perform a function or activity on behalf of a covered entity or to provide a service described in the deÞnition of business associate in § 160.103 of this subchapter to a covered entity, the covered entity may permit the business associate to receive, create, maintain, or transmit Copyright © 2004 CRC Press, LLC


Appendix III

303

electronic protected health information on its behalf to the extent necessary to comply with the legal mandate without meeting the requirements of the abovedescribed business associate contract, provided that the covered entity attempts in good faith to obtain satisfactory assurances as required by the above described business associate contract and documents the attempt and the reasons that these assurances cannot be obtained. We have added a standard for group health plans that parallels the provisions of the Privacy Rule. It became apparent during the course of the security and privacy rulemaking that our original chain of trust approach was both overly broad in scope and failed to address appropriately the circumstances of certain covered entities, particularly the ERISA group health plans. These latter considerations and the solutions arrived at in the Privacy Rule are described in detail in the Privacy Rule at 65 FR 82507 through 82509. Because the purpose of the security standards is in part to reinforce privacy protections, it makes sense to align the organizational policies of the two rules. This decision should also make compliance less burdensome for covered entities than would a decision to have different organizational requirements for the two sets of rules. Thus, we have added at § 164.314(b) a standard for group health plan that tracks the standard at § 164.504(f) very closely. The purpose of these provisions is to ensure that, except when the electronic protected health information disclosed to a plan sponsor is summary health information or enrollment or disenrollment information as provided for by § 164.504(f), group health plan documents provide that the plan sponsor will reasonably and appropriately safeguard electronic protected health information created, received, maintained or transmitted to or by the plan sponsor on behalf of the group health plan. The plan documents of the group health plan must be amended to incorporate provisions to require the plan sponsor to implement reasonable and appropriate safeguards to protect the conÞdentiality, integrity, and availability of the electronic protected health information that it creates, receives, maintains, or transmits on behalf of the group health plan; ensure that the adequate separation required by § 164.504(f)(2)(iii) is supported by reasonable and appropriate security measures; ensure that any agents, including a subcontractor, to whom it provides this information agrees to implement reasonable and appropriate safeguards to protect the information; report to the group health plan any security incident of which it becomes aware; and make its policies and procedures and documentation relating to these safeguards available to the Secretary for purposes of determining the group health plan’s compliance with this subpart. a. Comment: Several commenters expressed confusion concerning the applicability of proposed § 142.104 to security. Response: The proposed preamble included language generally applicable to most of the proposed standards under HIPAA. Proposed § 142.104 concerned general requirements for health plans relative to processing transactions. We proposed that plans could not refuse to conduct a transaction as a standard transaction, or delay or otherwise adversely affect a transaction on the grounds that it was a standard transaction; health information transmitted and received in connection with a transaction must be in the form of standard data elements; and plans conducting transactions through an agent must ensure that the agent met all the requirements that Copyright © 2004 CRC Press, LLC


304


applied to the health plan. Except for the statement that a plan’s agent (‘‘business associate’’ in the Þnal rule) must meet the requirements (which would include security) that apply to the health plan, this proposed section did not pertain to the security standards and was addressed in the Transaction Rule. b. Comment: The majority of comments concerned proposed rule language stating ‘‘the same level of security will be maintained at all links in the chain * * *’’ Commenters believed the current language will have an adverse impact on one of the security standard’s basic premises, which is scalability. It was requested that the language be changed to indicate that, while appropriate security must be maintained, all partners do not need to maintain the same level of security. A number of commenters expressed some confusion concerning their responsibility for the security of information once it has passed from their control to their trading partner’s control, and so on down the trading partner chain. Requests were made that we clarify that chain of trust partner agreements were really between two parties, and that, if a trading partner agreement has been entered into, any given partner would not be responsible, or liable, for the security of data once it is out of his or her control. In line with this concern, several commenters were concerned that they would have some responsibility to ensure the level of security maintained by their trading partner. Several commenters believe a chain of trust partner agreement should not be a security requirement. One commenter stated that because covered entities must already conform to the regulation requirements, a ‘‘chain of trust’’ agreement does not add to overall security. Compliance with the regulation should be sufÞcient. Response: We believe the commenters are correct that the rule as proposed would — (1) not allow for scalability; and (2) would lead an entity to believe it is responsible, and liable, for making sure all entities down the line maintain the same level of security. The confusion here seems to come from the phrase ‘‘same level of security.’’ Our intention was that each trading partner would maintain reasonable and appropriate safeguards to protect the information. We did not mean that partners would need to implement the same security technology or measures and procedures. We have replaced the proposed ‘‘Chain of trust’’ standard with a standard for ‘‘Business associate contracts and other arrangements.’’ When another entity is acting as a business associate of a covered entity, we require the covered entity to require the other entity to protect the electronic protected health information that it creates, receives, maintains or transmits on the covered entity’s behalf. The level of security afforded particular electronic protected health information should not decrease just because the covered entity has made the business decision to entrust a business associate with using or disclosing that information in connection with the performance of certain functions instead of doing those functions itself. Thus, the rule below requires covered entities to require their business associates to implement certain safeguards and take other measures to ensure that the information is safeguarded (see § 164.308(b)(1) and §164.314(a)(1)). The speciÞc requirements of § 164.314(a)(1) are drawn from the analogous requirements at 45 CFR 164.504(e) of the Privacy Rule, although they have been adapted to reßect the objectives and context of the security standards. Compare, in Copyright © 2004 CRC Press, LLC


Appendix III

305

particular, 45 CFR 164.504(e)(2)(ii) with § 164.314(a)(1). We have not imported all of the requirements of 45 CFR 164.504(e), however, as many have no clear analog in the security context (see, for example, 45 CFR 164.504(e)(2)(i) regarding permitted and required uses and disclosures made by a business associate). HHS had previously committed to reconciling its security and privacy policies regarding business associates (see 65 FR 82643). The close relationship of many of the organizational requirements in section 164.314 with the analogous requirements of the Privacy Rule should facilitate the implementation and coordination of security and privacy policies and procedures by covered entities. In contrast, when another entity is not acting as a business associate for the covered entity, but rather is acting in the capacity of some other sort of trading partner, we do not require the covered entity to require the other entity to adopt particular security measures, as previously proposed. This policy is likewise consistent with the general approach of the Privacy Rule (see the discussion in the Privacy Rule at 65 FR 82476). The covered entity is free to negotiate security arrangements with its non-business associate trading partners, but this rule does not require it to do so. A similar approach underlies § 164.314(b) below. These provisions are likewise drawn from, and intended to support, the analogous privacy protections provided for by 45 CFR 164.504(f) (see the discussion of § 164.504(f) of the Privacy Rule at 65 FR 82507 through 82509, and 82646 through 82648). As with the business associate contract provisions, however, they are imported and adapted only to the extent they make sense in the security context. Thus, for example, the requirement at § 164.504(f)(2)(ii)(C) prohibits the plan documents from permitting disclosure of protected health information to the plan sponsor for employment-related purposes. As this prohibition goes entirely to the permissibility of a particular type of disclosure, it has no analog in §164.314(b). c. Comment: Several commenters stated that if security features are determined by agreements established between ‘‘trading partners,’’ as stated in the proposed regulations, there should be some guidelines or boundaries for those agreements so that extreme or unusual provisions are not permitted. Response: This Þnal rule sets a baseline, or minimum level, of security measures that must be taken by a covered entity and stipulates that a business associate must also implement reasonable and appropriate safeguards. This Þnal rule does not, however, prohibit a covered entity from employing more stringent security measures or from requiring a business associate to employ more stringent security measures. A covered entity may determine that, in order to do business with it, a business associate must also employ equivalent measures. This would be a business decision and would not be governed by the provisions of this rule. Security mechanisms relative to the transmission of electronic protected health information between entities may need to be agreed upon by both parties in order to successfully complete the transmission. However, the determination of the speciÞc transmission mechanisms and the speciÞc security features to be implemented remains a business decision. d. Comment: Several commenters asked whether existing contracts could be used to meet the requirement for a trading partner agreement, or does the rule require entry into a new contract speciÞc to this purpose. Also, the commenters want to know about those whose working agreements do not involve written contractual Copyright © 2004 CRC Press, LLC


306


agreement: Do they now need to set up formal agreements and incur the additional expense that would entail? Response: This Þnal rule requires written agreements between covered entities and business associates. New contracts do not have to be entered into speciÞcally for this purpose, if existing written contracts adequately address the applicable requirements (or can be amended to do so). e. Comment: Several commenters asked whether covered entities are responsible for the security of all individual health information sent to them, or only information sent by chain of trust partners. They also asked if they can refuse to process standard transactions sent to them in an unsecured fashion. In addition, they inquired if they can refuse to send secured information in standard transactions to entities not required by law to secure the information. One commenter asked if there is a formula for understanding in any particular set of relationships where the ultimate responsibility for compliance with the standards would lie. Response: Pursuant to the Transactions Rule, if a health plan receives an unsecured standard transaction, it may not refuse to process that transaction simply because it was sent in an unsecured manner. The health plan is not responsible under this rule, for how the transaction was sent to it (unless the transmission was made by a business associate, in which case different considerations apply); however, once electronic protected health information is in the possession of a covered entity, the covered entity is responsible for the security of the electronic protected health information received. The covered entity must implement technical security mechanisms to guard against unauthorized access to electronic protected health information that is transmitted over an electronic communication network. In addition, the rule requires the transmitting covered entity to obtain written assurance from a business associate receiving the transmission that it will provide an adequate level of protection to the information. For the business associate provisions, see § 164.308(b) and § 164.314(a) of this Þnal rule. f. Comment: One commenter asked what security standards a vendor having access to a covered entity’s health information during development, testing, and repair must meet and wanted to know whether the rule anticipates having a double layer of security compliance (one at the user level and one at the vendor level). If so, the commenter believes this will cause duplication of work. Response: In the situation described, the vendor would be acting as a business associate. The covered entity must require the business associate to implement reasonable and appropriate security protections of electronic protected health information. This requirement, however, does not impose detailed requirements for how that level of protection must be achieved. The resulting ßexibility should permit entities and their business associates to adapt their security safeguards in ways that make sense in their particular environments. g. Comment: A number of commenters requested sample contract language or models of contracts. We also received one comment that suggested that we should not dictate the contents of contracted agreements. Response: We will consider developing sample contract language as part of our guideline development.



Appendix III

307

I. POLICIES AND PROCEDURES AND DOCUMENTATION REQUIREMENTS (§ 164.316) We proposed requiring documented policies and procedures for the routine and nonroutine receipt, manipulation, storage, dissemination, transmission, and/or disposal of health information. We proposed that the documentation be reviewed and updated periodically. We have emphasized throughout this Þnal rule the scalability allowed by the security standards. This Þnal rule requires covered entities to implement policies and procedures that are reasonably designed, taking into account the size and type of activities of the covered entity that relate to electronic protected health information, and requires that the policies and procedures must be documented in written form, which may be in electronic form. This Þnal rule also provides that a covered entity may change its policies and procedures at any time, provided that it documents and implements the changes in accordance with the applicable requirements. Covered entities must also document designations, for example, of afÞliation between covered entities (see § 164.105(b)), and other actions, as required by other provisions of the subpart. 1. Comment: One commenter wanted development of written policies regarding such things as conÞdentiality and privacy rights for access to medical records, and approval of research by a review board when appropriate. Response: These issues are covered in the Privacy Rule (65 FR 82462) (see, in particular, § 164.512(i), § 164.524, and §164.530(i)). 2. Comment: One commenter asked if standards will override agreements that require others to maintain hardcopy documentation (for example, signature on Þle) and no longer require submitters to maintain hardcopy documentation. Response: The security standards will require a minimum level of documentation of security practices. Any agreements between trading partners for the exchange of electronic protected health information that impose additional documentation requirements will not be overridden by this Þnal rule. 3. Comment: One commenter stated that there should be a requirement to document only applications deemed necessary by an applications and data criticality assessment. Response: Electronic protected health information must be afforded security protection under this rule regardless of what application it resides in. The measures taken to protect that information must be documented. 4. Comment: One commenter asked how detailed the documentation must be. Another commenter asked what ‘‘kept current’’ meant. Response: Documentation must be detailed enough to communicate the security measures taken and to facilitate periodic evaluations pursuant to § 164.308(a)(8). While the term ‘‘current’’ is not in the Þnal rule, this concept has been adopted in the requirement that documentation must be updated as needed to reßect security measures currently in effect. 5. Comment: We received one comment concerning review and updating of implementing documentation suggesting that ‘‘periodically’’ be changed to ‘‘at least annually.’’



308


Response: We believe that the requirement should remain as written, in order to allow individual entities to establish review and update cycles as deemed necessary. The need for review and update will vary dependent upon a given entity’s size, conÞguration, environment, operational changes, and the security measures implemented.

J. COMPLIANCE DATES

FOR INITIAL IMPLEMENTATION

(§ 164.318)

We proposed that how the security standard would be implemented by each covered entity would be dependent upon industry trading partner agreements for electronic transmissions. Covered entities would be able to adapt the security matrix to meet business needs. We suggested that requirements of the security standard may be implemented earlier than the compliance date. However, we would require implementation to be complete by the applicable compliance date, which is 24 months after adoption of the standard, and 36 months after adoption of the standard for small health plans, as provided by the Act. In the proposed rule, we suggested that an entity choosing to convert from paper to standard EDI transactions, before the effective date of the security standard, consider implementing the security standard at the same time. In this Þnal rule the dates by which entities must be in compliance with the standards are called ‘‘compliance dates,’’ consistent with our practice in the Transactions, Privacy, and Employer IdentiÞer Rules. Section 164.318 in this Þnal rule is also organized consistent with the format of those rules. The substantive requirements, which are statutory, remain unchanged. Many of the comments received concerning effective dates and compliance dates, including the compliance dates for modiÞcations of standards, were addressed in the Transactions Rule. Those that were not addressed in that publication are presented below. 1. Comment: A number of commenters expressed support for the effective dates of the rules and stated that they should not be delayed. In contrast, one commenter stated that we should delay this rule to allow for an open consensus building debate to occur concerning security. One commenter asked that the rule be delayed until after implementation of the ICD-CM changes. A number of comments were received expressing the opinion that the security regulation should not be published until either the Congress has enacted legislation governing standards with respect to the privacy of individually identiÞable health information, or the Secretary of HHS has promulgated Þnal regulations containing these standards. One commenter stated, ‘‘we Þnd ourselves in the difÞcult position of reacting to proposed rules setting the standards for how information should be physically and electronically protected, without having reached agreement on the larger issues of consent for and disclosure of individual medical information.’’ Response: The effective date of the Þnal rule is 60 days after this Þnal rule is published in the Federal Register. The statute sets forth the compliance dates for the standards. Covered entities must comply with this Þnal rule no later than 24 months (36 months for small plans) after the effective date. The Þnal Privacy Rule has already been published. We note that numerous comments concerning the timing of the adoption of privacy and security standards Copyright © 2004 CRC Press, LLC


Appendix III

309

were also received in the privacy rulemaking and are discussed in the Privacy Rule at 65 FR 82752. 2. Comment: One commenter asked that proposed § 142.312 be rewritten to separate the effective dates for the Security Rule and the Transactions Rule. Response: The proposed rule incorporated general language applicable to all the proposed Administrative SimpliÞcation standards. Language concerning standards other than Security is not included in § 164.318. Because this Þnal rule is adopted after the Transactions Rule was adopted, the compliance dates for the security standards differ from those for the transactions standards. Comments concerning general effective dates were addressed in the Transactions Rule. Comments speciÞc to the security standards are addressed here. 3. Comment: Several commenters suggested that we not allow early implementation of the Security Rules. A number of others asked that we allow, but not require, early implementation by willing trading partners. Another commenter suggested that early implementation by willing trading partners be allowed as long as the data content transmitted is equal to that required by statute. Another commenter requested that it be stipulated that entities cannot implement less than 1 year from the date of this Þnal rule and then only after successful testing, and that a ‘‘start testing by’’ date be deÞned. Response: Whether or not to implement before the compliance date is a business decision that each covered entity must make. Moreover, the vast majority of the standards address internal policies and procedures that can be implemented at any time without any impact on trading partners. 4. Comment: One commenter asked us to establish a research site or test laboratory for a trial implementation. Response: The concept of a ‘‘trial implementation’’ that would have widespread relevance is inconsistent with our basic principles of ßexibility, scalability, and technology-neutrality. 5. Comment: One commenter stated that the 2-year time frame for implementation of a contingency plan is too short for health plans that serve multiple regions of the country. Response: The Congress mandated that entities must be in compliance 2 years from the initial standard’s adoption date (3 years for small plans).

K. APPENDIX The proposed rule contained three addenda. Addendum 1 set out in matrix form the proposed requirements and related implementation features of the proposed rule. Addendum 2 set out in list form a glossary of terms with citations to the sources of those terms. Addendum 3 identiÞed and mapped areas of overlap in the proposed security standard and implementation features. This Þnal rule retains only the Þrst proposed addendum, the matrix, as an appendix, that is modiÞed to reßect the changes in the administrative, physical, and technical safeguard portions of the rule below. Numerous terms in the glossary now appear in the rule below, typically (but not always) as deÞnitions. 1. Comment: Over two-thirds of the comments received on this topic asked that the matrix be incorporated into the Þnal rule. One commenter asked that a simpliÞed Copyright © 2004 CRC Press, LLC


310


version be made part of the Þnal rule. Six commenters wanted it kept in this Þnal rule as an addendum. One commenter stated that it should be in an appendix to the rule, while others stated that it should not be included in this Þnal rule. Response: Since a signiÞcant majority of commenters requested retention of the matrix, it has been incorporated into this Þnal rule as an appendix. The matrix displays, in tabular form, the administrative, physical, and technical safeguard standards and relating implementation speciÞcations described in this Þnal rule in § 164.308, § 164.310, and § 164.312. It should be noted that the requirements of § 164.105, § 164.314, and § 164.316 are not presented in the matrix. 2. Comment: A large majority of commenters stated that the glossary located in Addendum 2 of the proposed rule should be included as part of the Þnal rule. Several commenters asked that it be incorporated into the deÞnitions section of the Þnal rule. One commenter stated that the glossary should not be part of this Þnal rule. Response: The terms deÞned in the glossary in Addendum 2 of the proposed rule are found throughout this Þnal rule, either as part of the text of § 164.306 through § 164.312 or under § 164.304, as appropriate. We included only terms relevant to the particular standards and implementation speciÞcations being adopted. 3. Comment: Several commenters requested that the mapped matrix located in Addendum 3 of the proposed rule be included in this Þnal rule, either as part of the rule or as an addendum, while others stated that it should not be part of this Þnal rule. Several commenters cited items to be added to the mapped matrix. Response: The mapped matrix was merely a snapshot of current standards and guidelines that the implementation team was able to obtain for review during the development of the security and electronic signature requirements and was provided in the proposed rule as background material. Since this matrix has not been fully populated or kept up-to-date, it is not being published as part of this Þnal rule. Where relevant, we do reference various standards and guidelines indicated in the matrix in this preamble.

L. MISCELLANEOUS ISSUES 1. Preemption The statute requires generally that the security standards supersede contrary provisions of State law including State law requiring medical or health plan records to be maintained or transmitted in written rather than electronic formats. The statute provides certain exceptions to the general rule; section 1178(a)(2) of the Act identiÞes conditions under which an exception applies. The proposed rule did not provide for a process for making exception determinations; rather, a process was proposed in the privacy rulemaking and was adopted with the Privacy Rule (see part 160, subpart B). This process applies to exception determinations for all of the Administrative SimpliÞcation rules, including this rule. a. Comment: Several commenters stated that the proposed rule does not include substantive protections for the privacy rights of patients’ electronic medical records, while the rule attempts to preempt State privacy laws with respect to these records. Comments stated that, by omitting a clariÞcation of State privacy law applicability,



Appendix III

311

the proposed rule creates confusion. They believe that the rule must contain express and speciÞc exemptions of State laws with respect to medical privacy. Response: The Privacy Rule establishes standards for the rights of patients in regard to the privacy of their medical records and for the allowable uses and disclosures of protected health information. The identiÞed concerns were discussed in the Privacy Rule (see 65 FR 82587 through 82588). The security standards do not speciÞcally address privacy but will safeguard electronic protected health information against unauthorized access or modiÞcation. b. Comment: One commenter asked how these regulations relate to conÞdentiality laws, which vary from State to State. Response: It is difÞcult to respond to this question in the abstract without the beneÞt of reference to a speciÞc State statute. However, in general, these security standards will preempt contrary State laws. Per section 1178(a)(2) of the Act, this general rule would not hold if the Secretary determines that a contrary provision of State law is necessary for certain identiÞed purposes to prevent fraud and abuse; to ensure appropriate State regulation of insurance and health plans; for State reporting on health care delivery costs; or if it addresses controlled substances. See 45 CFR part 160 subpart B. In such case, the contrary provision of State law would preempt a Federal provision of these security standards. State laws that are related but not contrary to this Þnal rule, will not be affected. Section 1178 of the Act also limits the preemptive effect of the Federal requirements on certain State laws other than where the Secretary makes certain determinations. Section 1178(b) of the Act provides that State laws for reporting of disease and other conditions and for public health surveillance, investigation, or intervention are not invalidated or limited by the Administrative SimpliÞcation rules. Section 1178(c) of the Act provides that the Federal requirements do not limit States’ abilities to require that health plans report or provide access to certain information. c. Comment: Several commenters stated that allowing State law to establish additional security restrictions conßicts with the purpose of the Federal rule and/or would make implementation very difÞcult. One commenter asked for clariÞcation as to whether additional requirements tighter than the requirements outlined in the proposed rule may be imposed. Response: The general rule is that the security standards in this Þnal rule supersede contrary State law. Only where the Secretary has granted an exception under section 1178(a)(2)(A) of the Act, or in situations under section 1178(b) or (c) of the Act, will the general rule not hold true. Covered entities may be required to adhere to stricter State-imposed security measures that are not contrary to this Þnal rule.

2. ENFORCEMENT The proposed rule did not contain speciÞc enforcement provisions. This Þnal rule likewise does not contain speciÞc enforcement provisions; it is expected that enforcement provisions applicable to all Administrative SimpliÞcation rules will be proposed in a future rulemaking. a. Comment: One commenter voiced support for the proposed rule’s approach. Another stated that the process is poorly deÞned. One commenter stated that Þnes Copyright © 2004 CRC Press, LLC


312


should be eliminated, or the scope of activity subject to Þnes should be more narrowly deÞned. While a number of commenters were of the opinion that HHS must retain enforcement responsibility, stating that it would be unconstitutional to give it to a private entity, several others stated that it may not be practical for HHS to retain the responsibility for determining violations and imposing penalties speciÞed by the statute. A concern was voiced over HHS’s ability to fairly and consistently apply the rules due to budget constraints. Several commenters support industry solutions to enforcement with some level of government involvement. One commenter recommended a single audit process using accrediting bodies already in place. Another stated that entities providing accreditation services should not be involved in enforcement as this would result in a conßict of interest. ClariÞcation was requested, including the use of examples, concerning what constitutes a violation, and how a penalty applies to a ‘‘person.’’ Commenters asked if the term ‘‘person’’ referred to the people responsible for the system and how penalties would apply to corporations and other entities. Response: It is expected that enforcement of HIPAA standards will be addressed in regulations to be issued at a later date. b. Comment: Several commenters stated that enforcement of the security standards will be arbitrarily delegated to private businesses that compete with physicians and with each other. Response: These comments are premature for the reasons stated above.

3. COMMENT PERIOD The comment period on the proposed rule was 60 days. Comment: We received comments suggesting that signiÞcant changes to the standards could occur in the Þnal rule as a result of changes made in response to comments. The commenter believes such changes could adversely affect payers and providers, and suggested that the rule should be republished as a proposed rule with a new comment period to allow additional comments concerning any changes. A ‘‘work-in-progress’’ approach was also suggested, to give all stakeholders time to read, analyze, and comment upon evolving versions of a particular proposed rule. Response: We have not accepted these suggestions. The numerous comments received were thoughtful, analytical, detailed, and addressed every area of the proposed rule. This response to the proposed rule indicates that the public had ample time to read, analyze, and comment upon the proposed rule. If we were to treat the rule as a ‘‘work-in-progress’’ and issue evolving versions, allowing for comments to each version, we would never implement the statute and achieve administrative simpliÞcation as directed by the Congress.

M. PROPOSED IMPACT ANALYSIS The preamble to the Transactions Rule contains comments and responses on the impact of all the administrative simpliÞcation standards in general except privacy.



Appendix III

313

Comments and responses speciÞc to the relative impact of implementing this Þnal rule are presented below. a. Comment: Several commenters stated that the proposed security standards are complex, costly, administratively burdensome, and could result in decreased use of EDI. One commenter stated that this rule runs counter to the explicit intent of Administrative SimpliÞcation that requires, ‘‘any standard adopted under this part shall be consistent with the objective of reducing the administrative costs of providing and paying for health care.’’ Several commenters expressed concern that there was no cost beneÞt analysis provided for these proposed regulations, stating that, faced with increasingly limited resources, it is essential that a security standards cost/beneÞt analysis for all health care trading partners be provided. Another said an independent cost estimate by the General Accounting OfÞce (GAO) should be performed on these rules and HHS cost estimates should be publicized for comparison purposes. Still another commenter stated that HHS must provide accurate public sector implementation cost Þgures and provide funds to offset the cost burden. One commenter asked for cost beneÞt evaluations to understand the relationship between competing technologies, levels of security and potential threats to be guarded against. These would demonstrate the costs and the beneÞts to be gained for both large and small organizations and would provide an understanding of how the levels of security vary by organization size and what the inducements and support available to facilitate adoption are. One commenter suggested that we establish a workgroup to more fully assess the costs and provide Federal funds to offset implementation costs. One commenter noted a seeming disconnect between two statements in the preamble. Section A, Security standards, states, ‘‘no individual small entity is expected to experience direct costs that exceed beneÞts as a result of this rule.’’ In contrast, section E, Factors in establishing the security standards reads, ‘‘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 deÞcient.’’ Response: We are unable to estimate, of the nation’s 2 million-plus health plans and 1 million-plus providers that conduct electronic transactions, the number of entities that would require new or modiÞed security safeguards and procedures beyond what they currently have in place. Nor are we able to estimate the number of entities that neither conduct electronic transactions nor maintain individually identiÞable electronic health information but may become covered entities at some future time. As we are unable to estimate the number of entities and what measures are or are not already in place, or what speciÞc implementation will be chosen to meet the requirements of the regulation, we are also unable to estimate the cost to those entities. However, the use of electronic technology to maintain or transmit health information results in many new and potentially large risks. These risks represent expected costs, both monetary and social. Leaving risk assessment up to individual entities will minimize the impact and ensure that security effort is proportional to security risk.



314


As discussed earlier, the security requirements are both scalable and technically ßexible. We have made signiÞcant changes to this Þnal rule, reducing the number of required implementation features and providing for greater ßexibility in satisfaction of the requirements. In other words, we have focused more on what needs to be done and less on how it should be accomplished. We have removed the statement regarding the extent of costs versus beneÞts for small entities. b. Comment: One commenter stated that on page 43262 of the proposed rule, it indicate that complexity of conversion to the security standards would be affected by the choice to use a clearinghouse. The commenter stated that this choice would have little effect on implementation of security standards. Another commenter stated that the complexity (and cost) of the conversion to meet the security standards is affected by far more than just the ‘‘volume of claims health plans process electronically and the desire to transmit the claims or to use the services of a VAN or clearinghouse’’ as is stated on page 43262. Because the security standards apply to internal systems as well as to transactions between entities, a number of additional factors must be considered, for example, modiÞcation of existing security mechanisms, legacy systems, architecture, and culture. Response: We agree. We have modiÞed the Regulatory Impact Analysis section to take into account that there are other factors involved, such as the architecture and technology limitations of existing systems. c. Comment: One commenter stated that States will need 90 percent funding of development and implementation, without the burden of an advanced planning documents requirement, from us for this costly process to succeed. Any new operational obligation should be 100 percent funded. Also human resource obligations will be signiÞcant. Some States believe they will have difÞculty obtaining the budget funds for the State share of the costs. State Medicaid agencies, as purchasers, may also face paying the implementation costs of health care providers, clearinghouses, and health plans in the form of higher rates. Response: The statute does not authorize any new or special funding for implementation of the regulations. Medicaid system changes, simply because they are ‘‘HIPAA related’’ do not automatically qualify for 90 percent Federal funding participation. As with any systems request, the usual rules will be applied to determine funding eligibility for State HIPAA initiatives. Nevertheless, HHS recognizes that there are signiÞcant issues regarding the funding and implementation of HIPAA by Medicaid State agencies, and intends to address them through normal channels of communication with States. d. Comment: One commenter stated that the proposed rule does not establish how the security standards will contribute to reduced cost for providers. One commenter expected the unintended result of this regulation will be impediment of EDI growth and perhaps even a decline in EDI use by providers. Another stated that the proposed rule actively discourages physician EDI participation by suggesting a fallback to paper processing for those unable to meet the cost of highly complex security compliance. Response: Ensuring the integrity of an electronic message, its delivery to the correct person, and its conÞdentiality must be an integral part of conducting elecCopyright © 2004 CRC Press, LLC


Appendix III

315

tronic commerce. We believe that the consistent application of the measures provided in this rule will actually encourage use of EDI because it will provide increased conÞdence in the reliability and conÞdentiality of health information to all parties involved. Also, the implementation of these security requirements will reduce the potential overall cost of risk to a greater extent than additional security controls will increase costs. Put another way, the potential cost of not reasonably addressing security risks could substantially exceed the cost of compliance. e. Comment: One commenter stated that the implementation impact of the technical safeguards is clearly understated for physicians who use digitally-based equipment that has been in place for some time. The commenter believes that the rule will likely have greatest impact on the installed base of digital systems, including imaging modalities and other medical devices that store or transmit patient information because software for legacy systems will likely require retroÞtting or replacement to come into compliance. The commenter believes that this is a negative impact and would outweigh any beneÞts derived from the potential risk of security breaches. The commenter recommended compliance for digital imaging devices be extended by an additional 3 years to allow time to upgrade systems and defray the associated costs. Response: Compliance dates for the initial implementation of the initial standards are statutorily prescribed; therefore, we are unable to allow additional time outside of the statutory timeframes for compliance. f. Comment: A commenter stated that, as a new regulatory mandate, HIPAA costs must be factored into any base year calculations for the proposed prospective payment system. Without an adjustment, this will be another regulatory mandate that comes at the cost of patient care. Response: Costs included in the prospective payment system are legislatively mandated. The Congress did not direct the inclusion of HIPAA costs into the system, so they are not included. However, the Department believes that the HIPAA standards will provide savings to the provider community over the next 10 years. g. Comment: One commenter suggested that we include requirements for how a compliant business could dually operate — (1) in a HIPAA compliant manner; and (2) in their former noncompliant manner in order to accommodate doing business with other organizations that are not yet compliant. Response: The statute imposes a 2-year implementation period between the adoption of the initial standards and the date by which covered entities (except small health plans) must be in compliance. An entity may come into compliance at any point in time during the 2 years. Therefore, the rule does not require a covered entity to comply before the established compliance date. Those entities that come into compliance before the 2-year deadline should decide how best to deal with entities that are not yet compliant. Further, we note that, generally speaking, compliance by a covered entity with these security rules will not hinge on compliance by other entities. h. Comment: One commenter stated that privacy legislation could impose signiÞcant changes to written policies and procedures on authorization, access to health information, and how sensitive information is disclosed to others. The commenter believes these changes could mean the imposition of security requirements different Copyright © 2004 CRC Press, LLC


316


from those contained in the proposed rule, and money spent complying with the security provisions could be ill spent if signiÞcant new requirements result from the privacy legislation. Response: The privacy standards at subpart E of 42 CFR part 164 are now in effect, and this Þnal rule is compatible with them. If, in the future, the Congress passes a law whose provisions differ from these standards, the standards would have to be modiÞed. i. Comment: One commenter stated that the private sector should develop educational tools or models in order to assist physicians, other providers, and health plans to comply with the security regulations. Response: We agree. The health care industry is striving to do this. HHS is also considering provider outreach and education activities.

IV. PROVISIONS OF THE FINAL REGULATION We have made the following changes to the provisions of the August 12, 1998 proposed rule. SpeciÞcally, we have — • •

•

• • • • •

•

•

•

Changed the CFR part from 142 to 164. Removed information throughout the document pertaining to electronic signature standards. Electronic signature standards will be published in a separate Þnal rule. Replaced the word ‘‘requirement,’’ when referring to a standard, with ‘‘standard.’’ Replaced ‘‘Implementation feature’’ with ‘‘Implementation speciÞcation.’’ Made minor modiÞcations to the text throughout the document for purposes of clarity. ModiÞed numerous implementation features so that they are now addressable rather than mandatory. Removed the word ‘‘formal’’ when referring to documentation. Revised the phrase ‘‘health information pertaining to an individual’’ to ‘‘electronic protected health information.’’ Added the following deÞnitions to § 160.103: ‘‘Disclosure,’’ ‘‘Electronic protected health information,’’ ‘‘Electronic media,’’ ‘‘Organized health care arrangement,’’ and ‘‘Use.’’ Removed proposed § 142.101 as this information is conveyed in § 160.101 and § 160.102 of the Privacy Rule (65 FR 82798). Removed proposed § 142.102 as it is redundant. Removed the following deÞnitions from proposed § 142.103 since they are pertinent to other administrative simpliÞcation regulations and are deÞned elsewhere: code set, health care clearinghouse, health care provider, health information, health plan, medical care, small health plan, standard, and transaction. Moved the following deÞnitions from § 164.501 to § 164.103 (proposed § 142.103): ‘‘ ‘‘Plan sponsor’’ and ‘‘Protected health information.’’ Added deÞnitions of ‘‘Covered functions’’ and ‘‘Required by law.’’



Appendix III

•

•

•

•

•

•

•

• •

•

•

317

Removed proposed § 142.104, ‘‘General requirements for health plans,’’ and proposed § 142.105, ‘‘Compliance using a health care clearinghouse,’’ since these sections are not pertinent to the security standards. Removed proposed § 142.106, ‘‘Effective dates of a modiÞcation to a standard or implementation speciÞcation,’’ since this information is covered in the ‘‘Standards for Electronic Transactions’’ Þnal rule (65 FR 50312). Moved proposed § 142.302 to § 164.302. Changed the section heading from ‘‘Applicability and scope’’ to ‘‘Applicability.’’ ModiÞed language to state that covered entities must comply with the security standards. Moved proposed § 142.304 to § 164.304. ModiÞed language to remove deÞnitions of words and concepts not used in this Þnal rule: ‘‘Access control,’’ ‘‘Contingency plan,’’ ‘‘Participant,’’ ‘‘Role-based access control,’’ ‘‘Token,’’ and ‘‘User-based access.’’ Moved proposed § 142.304 to § 164.304. ModiÞed language to add deÞnitions requested by commenters; previously published in Addendum 2 but not in the draft regulation itself; or necessitated by the change of scope to electronic protected health information and alignment with the Privacy Rule to include: ‘‘Administrative safeguards,’’ ‘‘Availability,’’ ‘‘ConÞdentiality,’’ ‘‘Data,’’ ‘‘Data authentication Code,’’ ‘‘Integrity,’’ ‘‘Electronic protected health information,’’ ‘‘Facility,’’ ‘‘Information System,’’ ‘‘Security or security measures,’’ ‘‘Security incident,’’ ‘‘Technical safeguards,’’ ‘‘User,’’ and ‘‘Workstation.’’ Moved deÞnitions related to privacy from § 164.504 to new § 164.103: ‘‘Common control,’’ ‘‘Common ownership,’’ ‘‘Health care component,’’ ‘‘Hybrid entity.’’ Moved proposed § 142.306, ‘‘Rules for the security Standard,’’ to § 164.306. ModiÞed language to more clearly state the general requirements of the Þnal rule relative to the standards and implementation speciÞcations contained therein. Retitled the section as ‘‘Security standards: General Rules.’’ Moved proposed § 142.308 to § 164.308. Where this section was proposed to contain all of the security standards in paragraphs (a) through (d), it now encompasses the Administrative safeguards. Moved and reorganized proposed § 142.308 (a) through (d) requirements to § 164.308, § 164.310, and § 164.312. Moved proposed § 142.308(a)(1), ‘‘CertiÞcation,’’ to § 164.308(a)(8). ModiÞed language to indicate both technical and nontechnical evaluation is involved and renamed ‘‘Evaluation’’. Moved proposed § 142.308(a)(2), ‘‘Chain of trust,’’ to § 164.308(b)(1), renamed to ‘‘Business associate contracts and other arrangements,’’ and revised language to redeÞne who must enter into a contract under this rule for the protection of electronic protected health information. Moved proposed § 142.308(a)(3), ‘‘Contingency plan,’’ to § 164.308(a)(7)(i). ModiÞed language to state that two implementation speciÞcations, ‘‘Applications and data criticality analysis’’ and ‘‘Testing and revision procedures,’’ are addressable.



318


•

•

•

•

•

•

• •

•

•

• • • •

Removed ‘‘Formal mechanism for processing records’’ (proposed § 142.308(a)(4)) since this requirement was determined to be in part intrusive into business functions and in part redundant. Moved proposed § 142.308(a)(5), ‘‘Information access control,’’ to § 164.308(a)(4)(i) and renamed as ‘‘Information access management.’’ Removed the word ‘‘formal’’ from description. ModiÞed language to state that two implementation speciÞcations (‘‘Access Authorization’’ and Access Establishment and ModiÞcation’’) are addressable. Moved proposed § 142.308(a)(6), ‘‘Internal audit,’’ to § 164.308(a)(1)(ii)(D) as an implementation speciÞcation under the ‘‘Security management process’’ standard since this was determined to be a more logical placement of this item. Retitled, for clarity, ‘‘Information system activity review.’’ Moved proposed § 142.308(a)(7), ‘‘Personnel security,’’ to § 164.308(a)(3)(i) and retitled ‘‘Workforce security.’’ ModiÞed language to state that implementation speciÞcations are addressable. Combined proposed § 142.308(a)(7)(i), and § 142.308(a)(7)(iii) (‘‘Assuring supervision of maintenance personnel by an authorized, knowledgeable person’’ and ‘‘Assuring that operations and maintenance personnel have proper access authorization,’’) under § 164.308(a)(3)(ii)(A) and renamed to ‘‘Authorization and/or supervision.’’ ModiÞed description for clarity. Moved proposed § 142.308(a)(7)(iv), ‘‘Personnel clearance procedure,’’ to § 164.308(a)(3)(ii)(B), renamed to ‘‘Workforce clearance procedure,’’ and modiÞed description for clarity. Removed proposed § 142.308(a)(7)(v), ‘‘Personnel security policies and procedures,’’ as this feature was determined to require redundant effort. Removed proposed § 142.308(a)(7)(vi), ‘‘Security awareness training.’’ Information concerning this subject has been incorporated under § 164.308(a)(5)(i), ‘‘Security awareness and training.’’ Removed proposed § 142.308(a)(8), ‘‘Security conÞguration management,’’ and all implementation features, except ‘‘Documentation’’ (hardware and/or software installation, Inventory, Security testing, and Virus checking), since this requirement was determined to be redundant. ‘‘Documentation’’ has been made a discrete standard at §164.316. Moved proposed § 142.308(a)(9), ‘‘Security incident procedures,’’ to § 164.308(a)(6)(i) and reworded for clarity. Combined ‘‘Report procedures’’ and ‘‘Response procedures’’ features into a single required implementation speciÞcation, named ‘‘Response and Reporting’’ at § 164.308(a)(6)(ii). Moved proposed § 142.308(a)(10), ‘‘Security management process,’’ to §164.308(a)(1). Moved proposed § 142.308(a)(10)(i), ‘‘Risk analysis,’’ to § 164.308(a)(1)(ii)(A). Moved proposed § 142.308(a)(10)(ii), ‘‘Risk management,’’ to § 164.308(a)(1)(ii)(B). Moved proposed § 142.308(a)(10)(iii), ‘‘Sanction policy,’’ to § 164.308(a)(1)(ii)(C).



Appendix III

• •

•

•

•

•

• •

•

• •

•

•

•

319

Removed proposed § 142.308(a)(10)(iv), ‘‘Security policy,’’ since this requirement was determined to be redundant. Moved proposed § 142.308(a)(11), ‘‘Termination,’’ to § 164.308(a)(3)(ii)(C) as an addressable implementation speciÞcation under the ‘‘Workforce security’’ standard, and renamed as ‘‘Termination procedures’’. Removed ‘‘Termination’’ implementation features (changing locks, removal from access lists, removal of user accounts, turning in of keys, tokens, or cards) since these were determined to be too speciÞc. Moved proposed § 142.308(a)(12), ‘‘Training,’’ to § 164.308(a)(5)(i) and renamed as ‘‘Security awareness and training.’’ Language modiÞed to incorporate all training information under this one standard. Revised and made addressable all implementation speciÞcations under this standard. Moved proposed § 142.308(b), ‘‘Physical safeguards to guard data integrity, conÞdentiality and availability,’’ to § 164.310 and renamed as ‘‘Physical safeguards.’’ Removed speciÞc reference to locks and keys. Moved proposed § 142.308(b)(1), ‘‘Assigned security responsibility requirement,’’ to § 164.308(a)(2) since this has been determined to be an administrative procedure. ModiÞed language to clarify that responsibility could be assigned to more than one individual. Moved proposed § 142.308(b)(2), ‘‘Media controls,’’ to § 164.310(d)(1) and renamed as ‘‘Device and media controls.’’ Removed the word ‘‘formal.’’ Added ‘‘Media re-use’’ as a required implementation speciÞcation at §164.310(d)(2)(ii). Removed proposed § 142.308(b)(2)(i), ‘‘Access control,’’ implementation feature as it was determined to be redundant. Moved proposed § 142.308(b)(2)(ii), ‘‘Accountability’’ implementation feature to § 164.310(d)(2)(iii), and made it an addressable implementation speciÞcation. Combined proposed § 142.308(b)(2)(iii), ‘‘Data backup,’’ implementation feature with proposed § 142.308(b)(2)(iv), ‘‘Data storage’’ implementation feature, renamed as ‘‘Data backup and storage’’, moved to § 164.310(d)(2)(iv), and made it an addressable implementation speciÞcation. Moved proposed § 142.308(b)(2)(v), ‘‘Data disposal,’’ implementation feature to § 164.310(d)(2)(i) and made it a required implementation speciÞcation. Moved proposed § 142.308(b)(3),‘‘Physical access controls,’’ to § 164.310(a)(1) and renamed as ‘‘Facility access controls.’’ Removed word ‘‘formal.’’ Moved proposed § 142.308(b)(3)(i), ‘‘Disaster recovery,’’ implementation feature to § 164.310(a)(2)(i). It is now part of the ‘‘Contingency operations’’ implementation speciÞcation. Moved proposed § 142.308(b)(3)(ii), ‘‘Emergency mode operations,’’ implementation feature to § 164.310(a)(2)(i). It is now part of the ‘‘Contingency operations’’ implementation speciÞcation. Removed proposed § 142.308(b)(3)(iii), ‘‘Equipment control (into and out of site),’’ as this information is now covered under § 164.310(d)(1), ‘‘Device and media controls.’’



320


• •

• •

•

• • • •

•

• • • • •

• • •

•

Moved proposed § 142.308(b)(3)(iv), ‘‘A facility security plan,’’ to §164.310(a)(2)(ii). Moved proposed § 142.308(b)(3)(v), ‘‘Procedure for verifying access authorizations,’’ to § 164.310(a)(2)(iii) and renamed as ‘‘Access control and validation procedures.’’ Removed the word ‘‘formal’’ from text. Moved proposed § 142.308(b)(3)(vi), ‘‘Maintenance records,’’ to §164.310(a)(2)(iv). Moved proposed § 142.308(b)(3)(vii), ‘‘Need to know procedures for personnel access,’’ to sect; 164.310(a)(2)(iii) and renamed as ‘‘Access control and validation procedures.’’ Moved proposed § 142.308(b)(3)(viii), ‘‘Procedures to sign in visitors and provide escort, if apropriate,’’ to § 164.310(a)(2)(iii) and renamed as ‘‘Access control and validation procedures.’’ Moved proposed § 142.308(b)(3)(ix), ‘‘Testing and revision,’’ to § 164.310(a)(2)(iii) and renamed as ‘‘Access control and validation procedures.’’ Moved proposed § 142.308(b)(4), ‘‘Policy and guidelines on workstation use,’’ to § 164.310(b) and renamed as ‘‘Workstation use.’’ Moved proposed § 142.308(b)(5), ‘‘Secure work station location,’’ to § 164.310(c) and renamed as ‘‘Workstation security.’’ Removed proposed § 142.308(b)(6), ‘‘Security awareness training,’’ as a separate requirement. This requirement has been incorporated under § 164.308(a)(5)(i), ‘‘Security awareness and training.’’ Combined and moved proposed § 142.308(c) and § 142.308(d), ‘‘Technical security services to guard data integrity, conÞdentiality and availability’’ and ‘‘Technical security mechanisms,’’ to § 164.312 and renamed as ‘‘Technical safeguards.’’ Removed proposed § 142.308(c)(1) since it is no longer pertinent. Moved proposed § 142.308(c)(1)(i), ‘‘Access control,’’ to § 164.312(a)(1). Moved proposed § 142.308(c)(1)(i)(A), ‘‘Procedure for emergency access,’’ to § 164.312(a)(2)(ii), and renamed as ‘‘Emergency access procedures.’’ Removed proposed §142.308(c)(1)(i)(B). Removed proposed § 142.308(c)(1)(i)(B)(1), ‘‘Context-based access,’’ § 142.308(c)(1)(i)(B)(2), ‘‘Role-based access,’’ and § 142.308(c)(1)(i)(B)(3), ‘‘User-based access,’’ since these features were deemed too speciÞc and were perceived as the only options permissible. Moved proposed § 142.308(c)(1)(i)(C), ‘‘Optional use of encryption,’’ to § 164.312(a)(2)(iv) and retitled ‘‘Encryption and decryption.’’ Moved proposed § 142.308(c)(1)(ii), ‘‘Audit controls,’’ to § 164.312(b). Removed proposed § 142.308(c)(1)(iii), ‘‘Authorization control,’’ and all implementation features (Role-based access, User-based access) since this function has been incorporated into § 164.308(a)(4), ‘‘Information access management.’’ Moved proposed § 142.308(c)(1)(iv), ‘‘Data authentication,’’ to § 164.312(c)(1), and retitled as ‘‘Integrity.’’ Reworded part of description and placed in § 164.312(c)(2), ‘‘Mechanism to authenticate data,’’ a new, addressable implementation speciÞcation. Removed reference to double keying.



Appendix III

• • • • • • • • • • • • •

• • • •

• •

•

•

• •

•

321

Moved proposed § 142.308(c)(1)(v), ‘‘Entity authentication,’’ to § 164.312(d) and retitled as ‘‘Person or entity authentication.’’ Moved proposed § 142.308(c)(1)(v)(A), ‘‘Automatic logoff,’’ to § 164.312(a)(2)(iii). Moved proposed § 142.308(c)(1)(v)(B), ‘‘Unique user identiÞcation,’’ to § 164.312(a)(2)(i). Removed proposed § 142.308(c)(1)(v)(C) since text is no longer pertinent. Removed proposed § 142.308(c)(1)(v)(C)(2), ‘‘Password,’’ as too speciÞc. Removed proposed § 142.308(c)(1)(v)(C)(3), ‘‘PIN,’’ as too speciÞc. Removed proposed § 142.308(c)(1)(v)(C)(4), ‘‘Telephone callback,’’ as too speciÞc. Removed proposed § 142.308(c)(1)(v)(C)(5), ‘‘Token,’’ as too speciÞc. Removed proposed § 142.308(c)(2), as no longer relevant. Moved proposed § 142.308(d)(1), ‘‘Communications or network controls,’’ to § 164.312(e)(1) and renamed as ‘‘Transmission security.’’ Removed proposed § 142.308(d)(1)(i), since it is no longer pertinent. Moved proposed § 142.308(d)(1)(i)(A), ‘‘Integrity controls,’’ to § 164.312(e)(2)(i) and reworded for clarity. Removed proposed § 142.308(d)(1)(i)(B), ‘‘Message authentication,’’ since this subject is now covered under § 164.312(e)(2)(i), ‘‘Integrity controls.’’ Removed proposed § 142.308(d)(1)(ii) text since it is no longer pertinent. Removed proposed § 142.308(d)(1)(ii)(A), ‘‘Access controls.’’ Moved proposed § 142.308(d)(1)(ii)(B), ‘‘Encryption,’’ to § 164.312(e)(2)(ii) and reworded to enhance ßexibility and scalability. Removed proposed § 142.308(d)(2) text regarding: ‘‘Network controls,’’ and all implementation features (‘‘Alarm,’’ ‘‘Audio trail,’’ ‘‘Entity authentication,’’ ‘‘Event reporting’’). Removed proposed § 142.310, ‘‘Electronic signature,’’ and all subheadings. This section will be issued as a separate future regulation. Moved proposed § 142.310 ‘‘Electronic signature Standard,’’ to § 164.310. Where this section was proposed to contain the electronic signature standard, it now encompasses the ‘‘Physical safeguards.’’ Moved proposed § 142.312, ‘‘Effective date of the implementation of the security and electronic signature standards,’’ to § 164.318 and retitled as ‘‘Compliance dates for the initial implementation of the security standards.’’ Reworded and retitled subsections. Added § 164.105, ‘‘Organizational requirements,’’ with two standards, ‘‘Health care component and ‘‘AfÞliated covered entities’’ with related implementation speciÞcations. Added § 164.310(d)(2)(ii), ‘‘Media re-use procedures,’’ implementation speciÞcation. Added § 164.312, ‘‘Technical safeguards,’’ encompassing the combined technical services and technical mechanisms standards (proposed § 142.308(c) and (d)). Added § 164.314, ‘‘Organizational requirements.’’



322


• • • • • • • • •

Added § 164.314(a)(1), ‘‘Business associate contracts or other arrangements’’ standard and related implementation speciÞcations. Added § 164.314(b)(1), ‘‘Requirements for group health plans’’ standard and related implementation speciÞcations. Added § 164.316, ‘‘Policies and procedures and documentation requirements.’’ Added § 164.316(a), ‘‘Policies and procedures’’ standard. Added § 164.316(b)(1), ‘‘Documentation’’ standard and related implementation speciÞcations. Added § 164.318, ‘‘Compliance dates for the initial implementation of the security standards.’’ Renamed Addendum 1 as Appendix A. Removed Addendum 2. DeÞnitions of terms used in this Þnal rule are now incorporated into § 164.103 and § 164.304, or within the rule itself. Removed Addendum 3.

V. COLLECTION OF INFORMATION REQUIREMENTS Under the Paperwork Reduction Act of 1995 (PRA), we are required to provide 30day notice in the Federal Register and solicit public comment before a collection of information requirement is submitted to the OfÞce 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 (PRA) requires that we solicit comment on the following issues: • • • •

The need for the information collection and its usefulness in carrying out the proper functions of our agency. The accuracy of our estimate of the information collection burden. The quality, utility, and clarity of the information to be collected. 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 § 164.306, § 164.308, § 164.310, § 164.314, and § 164.316 of this document. Section 164.306 Security Standards: General Rules Under paragraph (d), a covered entity must, if implementing the implementation speciÞcation is not reasonable and appropriate, document why it would not be reasonable and appropriate to implement the implementation speciÞcation. We estimate that 75,000 entities will be affected by this requirement and that they will have to create documentation 3 times for this requirement. We estimate each instance of documentation will take .25 hours, for a one-time total burden of 56,250 hours.



Appendix III

323

Section 164.308 Administrative Safeguards Under this section, a covered entity must document known security incidents and their outcomes. We estimate that there will be 50 known incidents annually and that it will take 8 hours to document this requirement, for an annual burden of 400 hours. This section further requires that each entity have a contingency plan, with speciÞed components. We estimate that there will be 60,000 entities affected by this requirement and that it will take each entity 8 hours to comply, for a total one-time burden of 480,000 hours. This section also requires that the written contract or other arrangement with a business associate document the satisfactory assurances that the business associate will appropriately safeguard the information through a written contract or other arrangement with the business associate that meets the applicable requirements of § 164.314(a). We believe that the burden associated with this requirement is not subject to the PRA. It is good business practice for entities to document their arrangements via written contracts and as such is usual and customary among the entities subject to them. A burden associated with a requirement conducted in the normal course of business is exempt from the PRA as deÞned in 5 CFR 1320.3(b)(2). Section 164.310 Physical Safeguards This section requires that a covered entity implement policies and procedures to document repairs and modiÞcations to the physical components of a facility that are related to security (for example, hardware, walls, doors, and locks). We believe that 15,500 entities will have to repair or modify physical components, most of which will need to be done in the Þrst year of implementation. In the following years, we estimate that 500 entities will need to make repairs or modiÞcations. We estimate that it will take 10 minutes to document each repair or modiÞcation for a burden of 2,583 hours the Þrst year and 83 hours annually subsequently. This section requires that a covered entity create a retrievable, exact copy of electronic protected health information, where needed, before movement of equipment. We believe that the burden associated with this requirement is not subject to the PRA. It is good business practice for entities to backup their data Þles, and as such is usual and customary among the entities subject to them. A burden associated with a requirement conducted in the normal course of business is exempt from the PRA as deÞned in 5 CFR 1320.3(b)(2). Section 164.314 Organizational Requirements This section requires that a covered entity report to the Secretary problems with a business associate’s pattern of an activity or practice of the business associate that constitute a material breach or violation of the business associate’s obligation under the contract or other arrangement if it is not feasible to terminate the contract or arrangement.



324


We believe that 10 entities will need to comply with this reporting requirement and that it will take them 60 minutes to comply with this requirement for an annual burden of 10 hours. This section also requires that a covered entity may, if a business associate is required by law to perform a function or activity on behalf of a covered entity or to provide a service described in the deÞnition of business associate as speciÞed in § 160.103 of this subchapter to a covered entity, permit the business associate to create, receive, maintain, or transmit electronic protected health information on its behalf to the extent necessary to comply with the legal mandate without meeting the requirements of paragraph (a)(2)(i) of this section, provided that the covered entity attempts in good faith to obtain satisfactory assurances as required by paragraph (a)(2)(ii)(A) of this section, and documents the attempt and the reasons that these assurances cannot be obtained. We believe that this situation will affect 20 entities and that it will take 60 minutes to document attempts to obtain assurances and the reasons they cannot be obtained for an annual burden of 20 hours. This section further requires that business associate contracts or other arrangements and group health plans must require the business entity and plan sponsor, respectively, to report to the covered entity any security incident of which it becomes aware. We believe that the burden associated with this requirement is not subject to the PRA. It is good business practice for entities to document their agreements via written contracts, and as such is usual and customary among the entities subject to them. A burden associated with a requirement conducted in the normal course of business is exempt from the PRA as deÞned in 5 CFR 1320.3(b)(2). Section 164.316 Policies and Procedures and Documentation Requirements Paragraph (b)(1), Standard: Documentation, of this section requires a covered entity to — (i) Maintain the policies and procedures implemented to comply with this subpart in written (which may be electronic) form; and (ii) If an action, activity, assessment, or designation is required by this subpart to be documented, maintain a written (which may be electronic) record of the action, activity, assessment, or designation. We estimate that it will take the 4,000,000 entities covered by this Þnal rule 16 hours to document their policies and procedures, for a total one-time burden of 64,000,000 hours. The total annual burden of the information collection requirements contained in this Þnal rule is 64,539,264 hours. These information collection requirements will be submitted to OMB for review under the PRA and will not become effective until approved by OMB. If you comment on these information collection and recordkeeping requirements, please mail copies directly to the following: Copyright © 2004 CRC Press, LLC


Appendix III

325

Centers for Medicare and Medicaid Services, OfÞce of Strategic Operations and Regulatory Affairs, Regulations Development and Issuances Group, Attn: Reports Clearance OfÞcer, 7500 Security Boulevard, Baltimore, MD 21244–1850, Attn: Julie Brown, CMS–0049–F; and OfÞce of Information and Regulatory Affairs, OfÞce of Management and Budget, Room 10235, New Executive OfÞce Building, Washington, DC 20503, Attn: Brenda Aguilar, CMS Desk OfÞcer.

IV. REGULATORY IMPACT ANALYSIS A. OVERALL IMPACT We have examined the impacts of this rule as required by Executive Order 12866 (September 1993, Regulatory Planning and Review), the Regulatory Flexibility Act (RFA) (September 16, 1980, Pub. L. 96–354), section 1102(b) of the Social Security Act, the Unfunded Mandates Reform Act of 1995 (Pub. L. 104–4), and Executive Order 13132. Executive Order 12866 (as amended by Executive Order 13258, which merely reassigns responsibility of duties) directs agencies to assess all costs and beneÞts of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net beneÞts (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). A regulatory impact analysis (RIA) must be prepared for major rules with economically signiÞcant effects ($100 million or more in any 1 year). Although we cannot determine the speciÞc economic impact of the standards in this Þnal rule (and individually each standard may not have a signiÞcant impact), the overall impact analysis makes clear that, collectively, all the standards will have a signiÞcant impact of over $100 million on the economy. Because this rule affects over 2 million entities, a requirement as low as $50 per entity would render this rule economically signiÞcant. This rule requires each of these entities to engage in, for example, at least some risk assessment activity; thus, this rule is almost certainly economically signiÞcant even though we do not have an estimate of the marginal impact of the additional security standards. However, the standards adopted in this rule are considerably more ßexible than those anticipated in the overall impact analysis. Therefore, their implementation costs should be lower than those assumed in the impact analysis. The RFA requires agencies to analyze options for regulatory relief of small businesses. For purposes of the RFA, small entities include small businesses, nonproÞt organizations, and government agencies. Most hospitals and most other providers and suppliers are small entities, either by nonproÞt status or by having revenues of $6 million to $29 million in any 1 year. While each standard may not have a signiÞcant impact on a substantial number of small entities, the combined effects of all the standards are likely to have a signiÞcant effect on a substantial number of small entities. Although we have certiÞed this rule as having a signiÞcant impact, we have previously discussed the impact of small entities in the RFA published as part of the August 17, 2000 Þnal regulation for the Standards for Electronic Transactions (65 FR 50312), on pages 50359 through 50360. That analysis included the impact of the set of HIPAA standards regulations (transactions and Copyright © 2004 CRC Press, LLC


326


code sets, identiÞers, and security). Although we discussed the impact on small entities in the previous analysis, we would like to discuss how this Þnal rule has been structured to minimize the impact on small entities, compared to the proposed rule. The proposed rule mandated 69 implementation features for all entities. A large number of commenters indicated that mandating such a large number would be burdensome for all entities. As a result, we have restructured this Þnal rule to permit greater ßexibility. While all standards must be met, we are now only requiring 13 implementation speciÞcations. The remainder of the implementation speciÞcations is ‘‘addressable.’’ For addressable speciÞcations, an entity decides whether each speciÞcation is a reasonable and appropriate security measure to apply within its particular security framework. This decision is based on a variety of factors, for example, the entity’s risk analysis, what measures are already in place, the particular interest to small entities, and the cost of implementation. Based on the decision, an entity can — (1) implement the speciÞcation if reasonable and appropriate; (2) implement an alternative security measure to accomplish the purposes of the standard; or (3) not implement anything if the speciÞcation is not reasonable and appropriate and the standard can still be met. This approach will provide ßexibility for all entities, and especially small entities that would be most concerned about the cost and complexity of the security standards. Small entities can look at the addressable implementation speciÞcations and tailor their compliance based on their risks and capabilities of addressing those risks. The required risk analysis is also a tool to allow ßexibility for entities in meeting the requirements of this Þnal rule. The risk analysis requirement is designed to allow entities to look at their own operations and determine the security risks involved. The degree of response is determined by the risks identiÞed. We assume that smaller entities, who deal with smaller amounts of information would have smaller physical facilities, smaller work forces, and therefore, would assume less risk. The smaller amount of risk involved means that the response to that risk can be developed on a smaller scale than that for larger organizations. Individuals and States are not included in the deÞnition of a small entity. However, the security standards will affect small entities, such as providers and health plans, and vendors in much the same way as they affect any larger entities. Small providers who conduct electronic transactions and small health plans must meet the provisions of this regulation and implement the security standards. A more detailed analysis of the impact on small entities is part of the impact analysis published on August 17, 2000 (65 FR 50312), which provided the impact for all of the HIPAA standards, except privacy. As we discussed above, the scalability factor of the standards means that the requirements placed upon small providers and plans would be consistent with the complexity of their operations. Therefore, small providers and plans with appropriate security processes in place would need to do relatively little in order to comply with the standards. Moreover, small plans will have an additional year to come into compliance. In addition, section 1102(b) of the Act requires us to prepare a regulatory impact analysis if a rule may have a signiÞcant impact on the operations of a substantial number of small rural hospitals. This analysis must conform to the provisions of section 604 of the RFA. For purposes of section 1102(b) of the Act, Copyright © 2004 CRC Press, LLC


Appendix III

327

we deÞne a small rural hospital as a hospital that is located outside of a Metropolitan Statistical Area and has fewer than 100 beds. While this rule may have a signiÞcant impact on small rural hospitals, the impact should be minimized by the scalability factors of the standards, as discussed above in the impact on all small entities. In addition, we have previously discussed the impact of small entities in the RIA published as part of the August 17, 2000 Þnal regulation for the Standards for Electronic Transactions. Section 202 of the Unfunded Mandates Reform Act (UMRA) of 1995 also requires that agencies assess anticipated costs and beneÞts before issuing any rule that may result in expenditure in any 1 year by State, local, or tribal governments, in the aggregate, or by the private sector, of $110 million. We estimate that implementation of all the standards will require the expenditure of more than $110 million by the private sector. Therefore, the rule establishes a Federal private sector mandate and is a signiÞcant regulatory action within the meaning of section 202 of UMRA (2 U.S.C. 1532). We have included the statements to address the anticipated effects of these rules under section 202. These standards also apply to State and local governments in their roles as health plans or health care providers. Because these entities, in their roles as health plans or providers, must implement the requirements in these rules, the rules impose unfunded mandates on them. Further discussion of this issue can be found in the previously published impact analysis for all standards (65 FR 50360 through 50361). The anticipated beneÞts and costs of the security standards, and other issues raised in section 202 of the UMRA, are addressed in the analysis below, and in the combined impact analysis. In addition, as required 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, HHS has concluded that this Þnal rule is the most costeffective alternative for implementation of HHS’s statutory objective of administrative simpliÞcation. Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a proposed rule (and subsequent Þnal rule) that imposes substantial direct requirement costs on State and local governments, preempts State law, or otherwise has Federalism implications. The proposed rule was published before the enactment of Executive Order 13132 of August 4, 1999, Federalism (published in the Federal Register on August 10, 1999 (64 FR 43255)), which required meaningful and timely input by State and local ofÞcials in the development of rules that have Federalism implications). However, we received and considered comments on the proposed rule from State agencies and from entities who conduct transactions with State agencies. Several of the comments referred to the costs that will result from implementation of the HIPAA standards. As we stated in the impact analysis, we are unable to estimate the cost of implementing security features as implementation needs will vary dependent upon a risk assessment and upon what is already in place. However, the previously referenced impact analysis in the August 17, 2000 Þnal rule (65 FR 50312) showed that Administrative SimpliÞcation costs will be offset by future savings. In complying with the requirements of part C of title XI, the Secretary established interdepartmental implementation teams who consulted with appropriate State and Copyright © 2004 CRC Press, LLC


328


Federal agencies and private organizations. These external groups consisted of the National Committee on Vital and Health Statistics (NCVHS) Subcommittee on Standards and Security, the Workgroup for Electronic Data Interchange (WEDI), the National Uniform Claim Committee (NUCC), the National Uniform Billing Committee (NUBC), and the American Dental Association (ADA). The teams also received comments on the proposed regulation from a variety of organizations, including State Medicaid agencies and other Federal agencies.

B. ANTICIPATED EFFECTS The analysis in the August 2000, Transaction Rule included the expected costs and beneÞts of the administrative simpliÞcation regulations related to electronic systems for 10 years. Although only the electronic transaction standards were promulgated in the transaction rule, HHS expected affected parties to make systems compliance investments collectively because the regulations are so integrated. Moreover, the data available to us were also based on the collective requirements of this regulation. It is not feasible to identify the incremental technological and computer costs for each regulation. Although HHS is issuing rules under HIPAA sequentially, affected entities and vendors are bundling services, that is, they have been anticipating the various needs and are designing relatively comprehensive systems as they develop hardware and software. For example, a vendor developing a system for electronic billing would also anticipate and include security features, even in the absence of any regulation. Moreover, a draft of the security rule was Þrst published in 1998. Even though the Þnal is different (and less burdensome), vendors had a reasonable indication of the direction policy would go. Thus, in preparing the electronic transaction rule, we recognized and included costs that might theoretically be associated with security or other HIPPA rules. Hence, some of the ‘‘costs’’ of security have already been accounted for in the Standards for Electronic Transactions cost estimate (45 CFR parts 160 and 162), which was published in the Federal Register on August 17, 2000 (65 FR 50312). This analysis showed that the combined impact of the Administrative SimpliÞcation standards is expected to save the industry $29.9 billion over 10 years. We are including in each subsequent rule an impact analysis that is speciÞc to the standard or standards in that rule, but the impact analysis will assess only the incremental cost of implementing a given standard over another. Thus, the following discussion contains the impact analysis for the marginal costs of the security standards in this Þnal rule. The following describes the speciÞc impacts that relate to the security standards. The security of electronic protected health information is, and has been for some time, a basic business requirement that health care entities ignore at their peril. Instances of ‘‘hacking’’ and other security violations may be widely publicized, and can seriously damage an institution’s community standing. Appropriate security protections are crucial for encouraging the growth and use of electronic data interchange. The synergistic effect of the employment of the security standards will enhance all aspects of HIPAA’s Administrative SimpliÞcation requirements. In addition, it is important to recognize that security is not a one-time project, but rather an on-going, dynamic process. Copyright © 2004 CRC Press, LLC


Appendix III

C. CHANGES FROM

329 THE

1998 IMPACT ANALYSIS

The overall impact analysis for Administrative SimpliÞcation was Þrst published on May 7, 1998 (63 FR 25320) in the proposed rule for the National Provider IdentiÞer standard (45 CFR part 142), the Þrst of the proposed Administrative SimpliÞcation rules. That impact analysis was based on the industry situation at that time, used statistics which were current at that time, and assumed that all of the HIPAA standards would be implemented at roughly the same time, which would permit software changes to be made less expensively. While the original impact analysis represented our best information at that time, we realize that the state of the industry, and of security technology, has changed since 1998. We discuss several of those changes and how they affect the impact of this regulation. 1. Changes in Technology The state of technology for health care security has changed since 1998. New technologies to protect information have been developed over the past several years. As a result, HHS has consulted with the Gartner Group, a leading technology assessment organization, regarding what impact these changes in the industry might have on the expected impact of this regulation. The Gartner analysis indicated that the cost of meeting the requirements of a reasonable interpretation of the security rule in 2002 is probably less than 10 percent higher in 2002 than it was in 1998. This increase is mainly driven by more active threats and increased personnel costs offsetting decreases in technology costs over the past 4 years. However, spending by companies who have anticipated the security rule or who have independently made business decisions to implement security policies and procedures as good business practice(s) has already occurred, and probably will cancel out the increased costs of implementation. Therefore, Gartner expects the cost of complying with the HIPAA security standards to be about the same now as it was in 1998. 2. Synchronizing Standards The timelines for the implementation of the initial HIPAA standards (transactions, identiÞers, and security) are no longer closely synchronized. However, we do not believe that this lack of synchronization will have a signiÞcant impact on the cost of implementing security. The analysis provided by the Gartner group indicated that implementing security standards is being viewed by entities as a separate task from implementing the transaction standards, and that this is not having a signiÞcant impact on costs. As with other HIPAA standards, most current entities will have a 2-year implementation period before compliance with the standards is required. Covered entities will develop their own implementation schedules, and may phase in various security measures over that time period. 3. Relationship to Privacy Standards The publication of the Þnal Privacy Rules (45 CFR parts 160 and 164) on December 28, 2000 in the Federal Register (65 FR 82462) and on August 14, 2002 (67 FR Copyright © 2004 CRC Press, LLC


330


53182) has affected the impact of this regulation signiÞcantly. Covered entities must implement the privacy standards by April 14, 2003 (April 14, 2004 for small health plans). The implementation of privacy standards reduces the cost of implementing the security standards in two signiÞcant areas. First, we have made substantial efforts to ensure that the many requirements in the security standards parallel those for privacy, and can easily be satisÞed using the solutions for privacy. Administrative requirements like the need for written policies, responsible ofÞcers, and business associate agreements that are already required by the Privacy Rule can also serve to meet the security standards without signiÞcant additional cost. The analysis of data ßows and data uses that covered entities are doing so as to comply with the Privacy Rule should also serve as the starting point for parallel analysis required by this Þnal rule. Second, it is likely that covered entities will meet a number of the requirements in the security standards through the implementation of the privacy requirements. For example, in order to comply with the Privacy Rule requirements to make reasonable efforts to limit the access of members of the work force to speciÞed categories of protected health information, covered entities may implement some of the administrative, physical, and technical safeguards that the entity’s risk analysis and assessment would require under the Security Rule. E-mail authentication procedures put into place for privacy protection may also meet the security standards, thereby eliminating the need for additional investments to meet these standards. As a result, covered entities that have moved forward in implementing the privacy standards are also implementing security measures at the same time. Since the proposed security standards proposed rule represents the most authoritative guidance now available on the nature of these standards, some entities have been using them to develop their security measures. Those entities should face minimal incremental costs in implementing the Þnal version of these standards. We are unable to quantify these overlaps, but we believe they may reduce the cost of implementing these security standards. The analysis provided to the HHS by the Gartner Group also stated that compliance with the Privacy Rule will have a moderate effect on the cost of compliance with the Security Rule, reducing it slightly. 4. Sensitivity to Security Concerns as a Result of September 11, 2001 In our discussions with the Gartner Group, they indicated that they saw little evidence of increased security awareness in health care organizations as a result of the events of September 11, 2001. However, a survey conducted by Phoenix Health Systems in the winter of 2002 showed that 65 percent of the respondents to the survey (hospitals, payers, vendors, and clearinghouses) have moderately to greatly increased their attention on overall security. If these organizations have already made investments in security that meet some of the requirements of this rule, it will reduce their added costs of compliance. However, HHS can make no clear statement of the impact of this attention. Copyright © 2004 CRC Press, LLC


Appendix III

D. GUIDING PRINCIPLES

331 FOR

STANDARD SELECTION

The implementation teams charged with designating standards under the statute have deÞned, with signiÞcant input from the health care industry, a set of common criteria for evaluating potential standards. These criteria are based on direct speciÞcations in the HIPAA, the purpose of the law, and principles that support the regulatory philosophy set forth in the E.O. 12866 of September 30, 1993, and the Paperwork Reduction Act of 1995. In order to be designated as such, a standard should do the following: •

•

•

•

•

•

•

• •

•

Improve the efÞciency and effectiveness of the health care system by leading to cost reductions for or improvements in beneÞts from electronic health care transactions. This principle supports the regulatory goals of cost-effectiveness and avoidance of burden. 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. Be consistent and uniform with the other HIPAA standards (that is, their data element deÞnitions 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. Have low additional development and implementation costs relative to the beneÞts of using the standard. This principle supports the regulatory goals of cost-effectiveness and avoidance of burden. Be supported by an ANSI-accredited standards developing organization or other private or public organization that would ensure continuity and efÞcient updating of the standard over time. This principle supports the regulatory goal of predictability. Have timely development, testing, implementation, and updating procedures to achieve administrative simpliÞcation beneÞts faster. This principle establishes a performance objective for the standard. Be technologically independent of the computer platforms and transmission protocols used in 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 ßexibility. Be precise and unambiguous but as simple as possible. This principle supports the regulatory goals of predictability and simplicity. 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. Incorporate ßexibility to adapt more easily to changes in the health care infrastructure (for example, new services, organizations, and provider types) and information technology. This principle supports the regulatory goals of ßexibility and encouragement of innovation.



332


We assessed a wide variety of security standards and guidelines against the principles listed above, with the overall goal of achieving the maximum beneÞt for the least cost. As we stated in the proposed rule, we found that no single standard for security exists that encompasses all the requirements that were listed in the law. However, we believe that the standards we are adopting in this Þnal rule collectively accomplish these goals.

E. AFFECTED ENTITIES 1. Health Care Providers Covered health care providers may incur implementation costs for establishing or updating their security systems. The majority of costs to implement the security standard (purchase and installation of appropriate computer hardware and software, and physical safeguards) would generally be incurred in the initial implementation period for the speciÞc requirements of the security standard. Health care providers that do not conduct electronic transactions for which standards have been adopted are not affected by these regulations. 2. Health Plans All health plans, as the term is deÞned in regulation at 45 CFR 160.103, must comply with these security standards. In addition, health plans that engage in electronic health care transactions may have to modify their systems to meet the security standards. Health plans that maintain electronic health information may also have to modify their systems to meet the security standards. 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 standards and other standards in a way that best Þts their needs, as long as they meet the deadlines speciÞed in the HIPAA law and regulations. Moreover, small plans (many of which are employer-sponsored) will have an additional year in which to achieve compliance. Small health plans are deÞned at 45 CFR 160.103 as health plans with annual receipts of $5 million or less. 3. Clearinghouses All health care clearinghouses must meet the requirements of this regulation. Health care clearinghouses would face effects similar to those experienced by health care providers and health plans. However, because clearinghouses represent one way in which providers and plans can achieve compliance, the clearinghouses’ costs of complying with these standards would probably be passed along to those entities, to be shared over the entire customer base. 4. System Vendors Systems vendors that provide computer software applications to health care providers and other billers of health care services would likely be affected. These vendors Copyright © 2004 CRC Press, LLC


Appendix III

333

would have to develop software solutions that would allow health plans, providers, and other users of electronic transactions to protect these transactions and the information in their databases from unauthorized access to their systems. Their costs would also probably be passed along to their customer bases.

F. FACTORS

IN

ESTABLISHING

THE

SECURITY STANDARD

1. General Effect In assessing the impact of these standards, it is Þrst necessary to focus on the general nature of the standards, their scalability, and the fact that they are not dependent upon speciÞc technologies. These factors will make it possible for covered entities to implement them with the least possible impact on resources. 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 at least conduct an assessment of how their current security measures conform to the new standards. However, we assume that most, if not all, covered entities already have at least some rudimentary security measures in place. Covered entities that identify gaps in their current measures would need to establish or revise their security precautions. It is also important to note that the standards specify what goals are to be achieved, but give the covered entity some ßexibility to determine how to meet those goals. This is different from the transaction standards, where all covered entities must use the exact same implementation guide. With respect to security, covered entities will be able to blend security processes now in place with new processes. This should signiÞcantly reduce compliance costs. Based on our analysis and comments received, the security standards adopted in this rule do not impose a greater burden on the industry than the options we did not select, and they present signiÞcant advantages in terms of universality and ßexibility. We understand that some large health plans, health care providers, and health care clearinghouses that currently exchange health information among trading partners may already have security systems and procedures in place to protect the information from unauthorized access. These entities may not incur signiÞcant costs to meet the security standards. Large entities that have sophisticated security systems in place may only need minor revisions or updates to their systems to meet the security standards, or indeed, may not need to make any changes in their systems. While small providers are not likely to have implemented sophisticated security measures, they are also not as likely to need them as larger covered entities. The scalability principle allows providers to adopt measures that are appropriate to their own circumstances. 2. Complexity of Conversion The complexity of the conversion to the security standards could be signiÞcantly affected by the volume of transactions that covered entities transmit and process electronically and the desire to transmit directly or to use the services of a Value Added Network (VAN) or a clearinghouse. If a VAN or clearinghouse is used, some Copyright © 2004 CRC Press, LLC


334


of the conversion activities would be carried out by that organization, rather than by the covered entity. This would simplify conversion for the covered entity, but makes the covered entity dependent on the success of its business associate. The architecture, and speciÞc technology limitations of existing systems could also affect the complexity of the conversion (for example, certain practice management software that does not contain password protection will require a greater conversion effort than software that has a password protection option already built into it). 3. Cost of Conversion Virtually all providers, health plans, and clearinghouses that transmit or store data electronically have already implemented some security measures and will need to assess existing security, identify areas of risk, and implement additional measures in order to come into compliance with the standards adopted in this rule. 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 deÞcient. Moreover, some security solutions are almost cost-free to implement (for example, 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 use 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 and/or software purchases at the time they do routine equipment upgrades. The security standards we adopt in this rule were developed with considerable input from the health care industry, including providers, health plans, clearinghouses, vendors, and standards organizations. Industry members strongly advocated the ßexible approach we adopt in this rule, which permits each affected entity to develop costeffective security measures appropriate to their particular needs. We believe that this approach will yield the lowest implementation cost to industry while ensuring that electronic protected health information is safeguarded. All of the nation’s health plans (over 2 million) and providers (over 600,000) will need to conduct some level of gap analysis to assess current procedures against the standards. However, we cannot estimate the number of covered entities that would have to implement additional security systems and procedures to meet the adopted standards. Also, we are not able to estimate the number of providers that do not conduct electronic transactions today 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). We believe that the security standards represent the minimum necessary for adequate protection of health information in an electronic format and as such should be implemented by all covered entities. As discussed earlier in this preamble, the security requirements are both scalable and technically ßexible; 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 Þnal rule, small plans will be allowed an additional 12 months to comply. Copyright © 2004 CRC Press, LLC


Appendix III

335

Since we are unable to estimate the number of entities that may need to make changes to meet the security standards, we are also unable to estimate the cost for those entities. However, we believe that the cost of establishing security systems and procedures is a portion of the costs associated with converting to the administrative simpliÞcation standards that are required under HIPAA, which are estimated in the previously referenced impact analysis. This discussion on conversion costs relates only to health plans, health care providers, and health care clearinghouses that are required to implement the security standards. The cost of implementing security systems and procedures for entities that do not transmit, receive, or maintain health information electronically is not a cost imposed by the rule, and thus, is not included in our estimates.

G. ALTERNATIVES CONSIDERED In developing this Þnal rule, the Department considered some alternatives. One alternative was to not issue a Þnal rule. However, this would not meet the Department’s obligations under the HIPAA statute. It would also leave the health industry without a set of standards for protecting the security of health information. The vast majority of commenters supported our efforts in developing a set of standards. Thus, we concluded that not publishing a Þnal rule was not in the best interests of the industry and not in the best interests of persons whose medical information will be protected by these measures. A second alternative was to publish the Þnal rule basically unchanged from the proposed rule. Although most commenters supported the approach of the proposed rule, there were signiÞcant objections to the number of required speciÞcations, concerns about the scope of certain requirements, duplication and ambiguity of some requirements, and the overall complexity of the approach. Based on those comments, it was clear that revisions had to be made. In addition, the proposed rule was developed before the Privacy Rule requirements were developed. Thus, it did not allow for any alignment of requirements between the Privacy and Security standards. As a result, the Department determined that an approach that modiÞed the proposed rule and aligned the requirements with the Privacy standards was the preferred alternative.

V. FEDERALISM Executive Order 13132 of August 4, 1999, Federalism, published in the Federal Register on August 10, 1999 (64 FR 43255), requires us to ensure meaningful and timely input by State and local ofÞcials in the development of rules that have Federalism implications. Although the proposed rule for security standards was published before the enactment of this Executive Order, the Department consulted with State and local ofÞcials as part of an outreach program in the process of developing the proposed regulation. The Department received comments on the proposed rule from State agencies and from entities that conduct transactions with State agencies. Many of these comments were concerned with the burden that the proposed security standards would place on their organizations. In response to those Copyright © 2004 CRC Press, LLC


336


comments, we have modiÞed the security standards to make them more ßexible and less burdensome. In complying with the requirements of part C of Title XI, the Secretary established an interdepartmental team who consulted with appropriate State and Federal agencies and private organizations. These external groups included the NCVHS Workgroup on Standards and Security, the Workgroup for Electronic Data Interchange, the National Uniform Claim Committee, and the National Uniform Billing Committee. Most of these groups have State ofÞcials as members. We also received comments on the proposed regulation from these organizations. In accordance with the provisions of Executive Order 12866, this rule has been reviewed by the OfÞce of Management and Budget. List of Subjects 45 CFR Part 160 Electronic transactions, Employer beneÞt plan, Health, Health care, Health facilities, Health insurance, Health records, Medicaid, Medical research, Medicare, Privacy, Reporting and record keeping requirements. 45 CFR Part 162 Administrative practice and procedure, Health facilities, Health insurance, Hospitals, Medicaid, Medicare, report and recordkeeping requirement. 45 CFR Part 164 Administrative practice and procedure, Health facilities, Health insurance, Hospitals, Medicaid, Medicare, Electronic Information System, Security, Report and recordkeeping requirement. For the reasons set forth in the preamble, the Department of Health and Human Services amends title 45, subtitle A, subchapter C, parts 160, 162, and 164 as set forth below:

PART 160 — GENERAL ADMINISTRATIVE REQUIREMENTS 1. The authority citation for part 160 continues to read as follows: Authority: Sec. 1171 through 1179 of the Social Security Act, (42 U.S.C. 1320d– 1329d–8) as added by sec. 262 of Pub. L. 104–191, 110 Stat. 2021–2031 and sec. 264 of Pub. L. 104–191 (42 U.S.C. 1320d–2(note)). 2. In § 160.103, the deÞnitions of ‘‘disclosure’’, ‘‘electronic media’’, ‘‘electronic protected health information,’’ ‘‘individual,’’ ‘‘organized health care arrangement,’’ ‘‘protected health information,’’ and ‘‘use’’ are added in alphabetical order to read as follows: § 160.103 Definitions. ***** Disclosure means the release, transfer, provision of, access to, or divulging in any other manner of information outside the entity holding the information. ***** Copyright © 2004 CRC Press, LLC


Appendix III

337

Electronic media means: (1) Electronic storage media including memory devices in computers (hard drives) and any removable/transportable digital memory medium, such as magnetic tape or disk, optical disk, or digital memory card; or (2) Transmission media used to exchange information already in electronic storage media. Transmission media include, for example, the internet (wide-open), extranet (using internet technology to link a business with information accessible only to collaborating parties), leased lines, dialup lines, private networks, and the physical movement of removable/ transportable electronic storage media. Certain transmissions, including of paper, via facsimile, and of voice, via telephone, are not considered to be transmissions via electronic media, because the information being exchanged did not exist in electronic form before the transmission. Electronic protected health information means information that comes within paragraphs (1)(i) or (1)(ii) of the deÞnition of protected health information as speciÞed in this section. ***** Individual means the person who is the subject of protected health information. ***** Organized health care arrangement means: (1) A clinically integrated care setting in which individuals typically receive health care from more than one health care provider; (2) An organized system of health care in which more than one covered entity participates and in which the participating covered entities: (i) Hold themselves out to the public as participating in a joint arrangement; and (ii) Participate in joint activities that include at least one of the following: (A) Utilization review, in which health care decisions by participating covered entities are reviewed by other participating covered entities or by a third party on their behalf; (B) Quality assessment and improvement activities, in which treatment provided by participating covered entities is assessed by other participating covered entities or by a third party on their behalf; or (C) Payment activities, if the Þnancial risk for delivering health care is shared, in part or in whole, by participating covered entities through the joint arrangement and if protected health information created or received by a covered entity is reviewed by other participating covered entities or by a third party on their behalf for the purpose of administering the sharing of Þnancial risk. (3) A group health plan and a health insurance issuer or HMO with respect to such group health plan, but only with respect to protected health information created or received by such health insurance issuer or HMO that relates to individuals who are or who have been participants or beneÞciaries in such group health plan; (4) A group health plan and one or more other group health plans each of which are maintained by the same plan sponsor; or



338


(5) The group health plans described in paragraph (4) of this deÞnition and health insurance issuers or HMOs with respect to such group health plans, but only with respect to protected health information created or received by such health insurance issuers or HMOs that relates to individuals who are or have been participants or beneÞciaries in any of such group health plans. Protected health information means individually identiÞable health information: (1) Except as provided in paragraph (2) of this deÞnition, that is: (i) Transmitted by electronic media; (ii) Maintained in electronic media; or (iii) Transmitted or maintained in any other form or medium. (2) Protected health information excludes individually identiÞable health information in: (i) Education records covered by the Family Educational Rights and Privacy Act, as amended, 20 U.S.C. 1232g; (ii) Records described at 20 U.S.C. 1232g(a)(4)(B)(iv); and (iii) Employment records held by a covered entity in its role as employer. ***** Use means, with respect to individually identiÞable health information, the sharing, employment, application, utilization, examination, or analysis of such information within an entity that maintains such information. *****

PART 162 — ADMINISTRATIVE REQUIREMENTS 1. The authority citation for part 162 is revised to read as follows: Authority: Secs. 1171 through 1179 of the Social Security Act (42 U.S.C. 1320d–1320d– 8), as added by sec. 262 of Pub. L. 104–191, 110 Stat. 2021–2031, and sec. 264 of Pub. L. 104–191, 110 Stat. 2033–2034 (42 U.S.C. 1320d–2 (note)). § 162.103 [Amended] 2. In § 162.103, the deÞnition of ‘‘electronic media’’ is removed.

PART 164 — SECURITY AND PRIVACY 1. The authority citation for part 164 is revised to read as follows: Authority: Secs. 1171 through 1179 of the Social Security Act (42 U.S.C. 1320d–1320d– 8), as added by sec. 262 of Pub. L. 104–191, 110 Stat. 2021–2031, and 42 U.S.C. 1320d–2 and 1320d–4, sec. 264 of Pub. L. 104–191, 110 Stat. 2033–2034 (42 U.S.C. 1320d–2 (note)). 2. A new § 164.103 is added to read as follows: § 164.103 Definitions. As used in this part, the following terms have the following meanings: Common control exists if an entity has the power, directly or indirectly, significantly to inßuence or direct the actions or policies of another entity. Common ownership exists if an entity or entities possess an ownership or equity interest of 5 percent or more in another entity. Copyright © 2004 CRC Press, LLC


Appendix III

339

Covered functions means those functions of a covered entity the performance of which makes the entity a health plan, health care provider, or health care clearinghouse. Health care component means a component or combination of components of a hybrid entity designated by the hybrid entity in accordance with § 164.105(a)(2)(iii)(C). Hybrid entity means a single legal entity: (1) That is a covered entity; (2) Whose business activities include both covered and non-covered functions; and (3) That designates health care components in accordance with paragraph § 164.105(a)(2)(iii)(C). Plan sponsor is deÞned as deÞned at section 3(16)(B) of ERISA, 29 U.S.C. 1002(16)(B). Required by law means a mandate contained in law that compels an entity to make a use or disclosure of protected health information and that is enforceable in a court of law. Required by law includes, but is not limited to, court orders and court-ordered warrants; subpoenas or summons issued by a court, grand jury, a governmental or tribal inspector general, or an administrative body authorized to require the production of information; a civil or an authorized investigative demand; Medicare conditions of participation with respect to health care providers participating in the program; and statutes or regulations that require the production of information, including statutes or regulations that require such information if payment is sought under a government program providing public beneÞts. 3. Section 164.104 is revised to read as follows: § 164.104 Applicability. (a) Except as otherwise provided, the standards, requirements, and implementation speciÞcations adopted under this part apply to the following entities: (1) A health plan. (2) A health care clearinghouse. (3) A health care provider who transmits any health information in electronic form in connection with a transaction covered by this subchapter. (b) When a health care clearinghouse creates or receives protected health information as a business associate of another covered entity, or other than as a business associate of a covered entity, the clearinghouse must comply with § 164.105 relating to organizational requirements for covered entities, including the designation of health care components of a covered entity. 4. A new § 164.105 is added to read as follows: § 164.105 Organizational requirements. (a)(1) Standard: Health care component. If a covered entity is a hybrid entity, the requirements of subparts C and E of this part, other than the requirements of this section, § 164.314, and § 164.504, apply only to the health care component(s) of the entity, as speciÞed in this section. Copyright © 2004 CRC Press, LLC


340


(2) Implementation speciÞcations: (i) Application of other provisions. In applying a provision of subparts C and E of this part, other than the requirements of this section, § 164.314, and § 164.504, to a hybrid entity: (A) A reference in such provision to a ‘‘covered entity’’ refers to a health care component of the covered entity; (B) A reference in such provision to a ‘‘health plan,’’ ‘‘covered health care provider,’’ or ‘‘health care clearinghouse,’’ refers to a health care component of the covered entity if such health care component performs the functions of a health plan, health care provider, or health care clearinghouse, as applicable; (C) A reference in such provision to ‘‘protected health information’’ refers to protected health information that is created or received by or on behalf of the health care component of the covered entity; and (D) A reference in such provision to ‘‘electronic protected health information’’ refers to electronic protected health information that is created, received, maintained, or transmitted by or on behalf of the health care component of the covered entity. (ii) Safeguard requirements. The covered entity that is a hybrid entity must ensure that a health care component of the entity complies with the applicable requirements of this section and subparts C and E of this part. In particular, and without limiting this requirement, such covered entity must ensure that: (A) Its health care component does not disclose protected health information to another component of the covered entity in circumstances in which subpart E of this part would prohibit such disclosure if the health care component and the other component were separate and distinct legal entities; (B) Its health care component protects electronic protected health information with respect to another component of the covered entity to the same extent that it would be required under subpart C of this part to protect such information if the health care component and the other component were separate and distinct legal entities; (C) A component that is described by paragraph (a)(2)(iii)(C)(2) of this section does not use or disclose protected health information that it creates or receives from or on behalf of the health care component in a way prohibited by subpart E of this part; (D) A component that is described by paragraph (a)(2)(iii)(C)(2) of this section that creates, receives, maintains, or transmits electronic protected health information on behalf of the health care component is in compliance with subpart C of this part; and (E) If a person performs duties for both the health care component in the capacity of a member of the workforce of such component and for another component of the entity in the same capacity with respect to that component, such workforce member must not use or disclose protected health information created or received in the course of or Copyright © 2004 CRC Press, LLC


Appendix III

341

incident to the member’s work for the health care component in a way prohibited by subpart E of this part. (iii) Responsibilities of the covered entity. A covered entity that is a hybrid entity has the following responsibilities: (A) For purposes of subpart C of part 160 of this subchapter, pertaining to compliance and enforcement, the covered entity has the responsibility of complying with subpart E of this part. (B) The covered entity is responsible for complying with § 164.316(a) and § 164.530(i), pertaining to the implementation of policies and procedures to ensure compliance with applicable requirements of this section and subparts C and E of this part, including the safeguard requirements in paragraph (a)(2)(ii) of this section. (C) The covered entity is responsible for designating the components that are part of one or more health care components of the covered entity and documenting the designation in accordance with paragraph (c) of this section, provided that, if the covered entity designates a health care component or components, it must include any component that would meet the deÞnition of covered entity if it were a separate legal entity. Health care component(s) also may include a component only to the extent that it performs: (1) Covered functions; or (2) Activities that would make such component a business associate of a component that performs covered functions if the two components were separate legal entities. (b)(1) Standard: AfÞliated covered entities. Legally separate covered entities that are afÞliated may designate themselves as a single covered entity for purposes of subparts C and E of this part. (1) Implementation speciÞcations: (i) Requirements for designation of an afÞliated covered entity. (A) Legally separate covered entities may designate themselves (including any health care component of such covered entity) as a single afÞliated covered entity, for purposes of subparts C and E of this part, if all of the covered entities designated are under common ownership or control. (B) The designation of an afÞliated covered entity must be documented and the documentation maintained as required by paragraph (c) of this section. (ii) Safeguard requirements. An afÞliated covered entity must ensure that: (A) The afÞliated covered entity’s creation, receipt, maintenance, or transmission of electronic protected health information complies with the applicable requirements of subpart C of this part; (B) The afÞliated covered entity’s use and disclosure of protected health information comply with the applicable requirements of subpart E of this part; and (C) If the afÞliated covered entity combines the functions of a health plan, health care provider, or health care clearinghouse, the afÞliated covered entity complies with § 164.308(a)(4)(ii)(A) and § Copyright © 2004 CRC Press, LLC


342


164.504(g), as applicable. (c)(1) Standard: Documentation. A covered entity must maintain a written or electronic record of a designation as required by paragraphs (a) or (b) of this section. (2) Implementation speciÞcation: Retention period. A covered entity must retain the documentation as required by paragraph (c)(1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later. 5. A new subpart C is added to part 164 to read as follows: Subpart C—Security Standards for the Protection of Electronic Protected Health Information Sec. 164.302 Applicability. 164.304 DeÞnitions. 164.306 Security standards: General rules. 164.308 Administrative safeguard. 164.310 Physical safeguards. 164.312 Technical safeguards. 164.314 Organizational requirements. 164.316 Policies and procedures and documentation requirements. 164.318 Compliance dates for the initial implementation of the security standards. Appendix A to Subpart C of Part 164 — Security Standards: Matrix Authority: 42 U.S.C. 1320d–2 and 1320d– 4. § 164.302 Applicability. A covered entity must comply with the applicable standards, implementation speciÞcations, and requirements of this subpart with respect to electronic protected health information. § 164.304 Definitions. As used in this subpart, the following terms have the following meanings: Access means the ability or the means necessary to read, write, modify, or communicate data/information or otherwise use any system resource. (This deÞnition applies to ‘‘access’’ as used in this subpart, not as used in subpart E of this part.) Administrative safeguards are administrative actions, and policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect electronic protected health information and to manage the conduct of the covered entity’s workforce in relation to the protection of that information. Authentication means the corroboration that a person is the one claimed. Availability means the property that data or information is accessible and useable upon demand by an authorized person. Copyright © 2004 CRC Press, LLC


Appendix III

343

ConÞdentiality means the property that data or information is not made available or disclosed to unauthorized persons or processes. Encryption means the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a conÞdential process or key. Facility means the physical premises and the interior and exterior of a building(s). Information system means an interconnected set of information resources under the same direct management control that shares common functionality. A system normally includes hardware, software, information, data, applications, communications, and people. Integrity means the property that data or information have not been altered or destroyed in an unauthorized manner. Malicious software means software, for example, a virus, designed to damage or disrupt a system. Password means conÞdential authentication information composed of a string of characters. Physical safeguards are physical measures, policies, and procedures to protect a covered entity’s electronic information systems and related buildings and equipment, from natural and environmental hazards, and unauthorized intrusion. Security or Security measures encompass all of the administrative, physical, and technical safeguards in an information system. Security incident means the attempted or successful unauthorized access, use, disclosure, modiÞcation, or destruction of information or interference with system operations in an information system. Technical safeguards means the technology and the policy and procedures for its use that protect electronic protected health information and control access to it. User means a person or entity with authorized access. Workstation means an electronic computing device, for example, a laptop or desktop computer, or any other device that performs similar functions, and electronic media stored in its immediate environment.

§ 164.306 Security standards: General rules. (a) General requirements. Covered entities must do the following: (1) Ensure the conÞdentiality, integrity, and availability of all electronic protected health information the covered entity creates, receives, maintains, or transmits. (2) Protect against any reasonably anticipated threats or hazards to the security or integrity of such information. (3) Protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required under subpart E of this part. (4) Ensure compliance with this subpart by its workforce. (b) Flexibility of approach. (1) Covered entities may use any security measures that allow the covered entity to reasonably and appropriately implement the standards and implementation speciÞcations as speciÞed in this subpart. Copyright © 2004 CRC Press, LLC


344


(2) In deciding which security measures to use, a covered entity must take into account the following factors: (i) The size, complexity, and capabilities of the covered entity. (ii) The covered entity’s technical infrastructure, hardware, and software security capabilities. (iii) The costs of security measures. (iv) The probability and criticality of potential risks to electronic protected health information. (c) Standards. A covered entity must comply with the standards as provided in this section and in § 164.308, § 164.310, § 164.312, § 164.314, and § 164.316 with respect to all electronic protected health information. (d) Implementation speciÞcations. In this subpart: (1) Implementation speciÞcations are required or addressable. If an implementation speciÞcation is required, the word ‘‘Required’’ appears in parentheses after the title of the implementation speciÞcation. If an implementation speciÞcation is addressable, the word ‘‘Addressable’’ appears in parentheses after the title of the implementation speciÞcation. (2) When a standard adopted in § 164.308, § 164.310, § 164.312, § 164.314, or § 164.316 includes required implementation speciÞcations, a covered entity must implement the implementation speciÞcations. (1) When a standard adopted in § 164.308, § 164.310, § 164.312, § 164.314, or § 164.316 includes addressable implementation speciÞcations, a covered entity must— (i) Assess whether each implementation speciÞcation is a reasonable and appropriate safeguard in its environment, when analyzed with reference to the likely contribution to protecting the entity’s electronic protected health information; and (ii) As applicable to the entity — (A) Implement the implementation speciÞcation if reasonable and appropriate; or (B) If implementing the implementation speciÞcation is not reasonable and appropriate — (1) Document why it would not be reasonable and appropriate to implement the implementation speciÞcation; and (2) Implement an equivalent alternative measure if reasonable and appropriate. (e) Maintenance. Security measures implemented to comply with standards and implementation speciÞcations adopted under § 164.105 and this subpart must be reviewed and modiÞed as needed to continue provision of reasonable and appropriate protection of electronic protected health information as described at § 164.316. § 164.308 Administrative safeguards. (a) A covered entity must, in accordance with § 164.306: (1)(i) Standard: Security management process. Implement policies and procedures to prevent, detect, contain, and correct security violations. Copyright © 2004 CRC Press, LLC


Appendix III

345

(ii) Implementation speciÞcations: (A) Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the conÞdentiality, integrity, and availability of electronic protected health information held by the covered entity. (B) Risk management (Required). Implement security measures sufÞcient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with § 164.30 (C) Sanction policy (Required). Apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures of the covered entity. (D) Information system activity review (Required). Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports. (2) Standard: Assigned security responsibility. Identify the security ofÞcial who is responsible for the development and implementation of the policies and procedures required by this subpart for the entity. (3)(i) Standard: Workforce security. Implement policies and procedures to ensure that all members of its workforce have appropriate access to electronic protected health information, as provided under paragraph (a)(4) of this section, and to prevent those workforce members who do not have access under paragraph (a)(4) of this section from obtaining access to electronic protected health information. (ii) Implementation speciÞcations: (A) Authorization and/or supervision (Addressable). Implement procedures for the authorization and/or supervision of workforce members who work with electronic protected health information or in locations where it might be accessed. (B) Workforce clearance procedure (Addressable). Implement procedures to determine that the access of a workforce member to electronic protected health information is appropriate. (C) Termination procedures (Addressable). Implement procedures for terminating access to electronic protected health information when the employment of a workforce member ends or as required by determinations made as speciÞed in paragraph (a)(3)(ii)(B) of this section. (4)(i) Standard: Information access management. Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements of subpart E of this part. (ii) Implementation speciÞcations: (A) Isolating health care clearinghouse functions (Required). If a health care clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the electronic protected health information of the clearinghouse from unauthorized access by the larger organization.



346


(B) Access authorization (Addressable). Implement policies and procedures for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process, or other mechanism. (C) Access establishment and modiÞcation (Addressable). Implement policies and procedures that, based upon the entity’s access authorization policies, establish, document, review, and modify a user’s right of access to a workstation, transaction, program, or process. (5)(i) Standard: Security awareness and training. Implement a security awareness and training program for all members of its workforce (including management). (ii) Implementation speciÞcations. Implement: (A) Security reminders (Addressable). Periodic security updates. (B) Protection from malicious software (Addressable). Procedures for guarding against, detecting, and reporting malicious software. (C) Log-in monitoring (Addressable). Procedures for monitoring log-in attempts and reporting discrepancies. (D) Password management (Addressable). Procedures for creating, changing, and safeguarding passwords. (6)(i) Standard: Security incident procedures. Implement policies and procedures to address security incidents. (ii) Implementation speciÞcation: Response and Reporting (Required). Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity; and document security incidents and their outcomes. (7)(i) Standard: Contingency plan. Establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, Þre, vandalism, system failure, and natural disaster) that damages systems that contain electronic protected health information. (ii) Implementation speciÞcations: (A) Data backup plan (Required). Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information. (B) Disaster recovery plan (Required). Establish (and implement as needed) procedures to restore any loss of data. (C) Emergency mode operation plan (Required). Establish (and implement as needed) procedures to enable continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode. (D) Testing and revision procedures (Addressable). Implement procedures for periodic testing and revision of contingency plans. (E) Applications and data criticality analysis (Addressable). Assess the relative criticality of speciÞc applications and data in support of other contingency plan components. Copyright © 2004 CRC Press, LLC


Appendix III

347

(8) Standard: Evaluation. Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which an entity’s security policies and procedures meet the requirements of this subpart. (b)(1) Standard: Business associate contracts and other arrangements. A covered entity, in accordance with § 164.306, may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity’s behalf only if the covered entity obtains satisfactory assurances, in accordance with § 164.314(a) that the business associate will appropriately safeguard the information. (2) This standard does not apply with respect to— (i) The transmission by a covered entity of electronic protected health information to a health care provider concerning the treatment of an individual. (ii) The transmission of electronic protected health information by a group health plan or an HMO or health insurance issuer on behalf of a group health plan to a plan sponsor, to the extent that the requirements of § 164.314(b) and § 164.504(f) apply and are met; or (iii) The transmission of electronic protected health information from or to other agencies providing the services at § 164.502(e)(1)(ii)(C), when the covered entity is a health plan that is a government program providing public beneÞts, if the requirements of § 164.502(e)(1)(ii)(C) are met. (3) A covered entity that violates the satisfactory assurances it provided as a business associate of another covered entity will be in noncompliance with the standards, implementation speciÞcations, and requirements of this paragraph and § 164.314(a). (4) Implementation speciÞcations: Written contract or other arrangement (Required). Document the satisfactory assurances required by paragraph (b)(1) of this section through a written contract or other arrangement with the business associate that meets the applicable requirements of § 164.314(a). § 164.310 Physical safeguards. A covered entity must, in accordance with § 164.306: (a)(1) Standard: Facility access controls. Implement policies and procedures to limit physical access to its electronic information systems and the facility or facilities in which they are housed, while ensuring that properly authorized access is allowed. (2) Implementation speciÞcations: (i) Contingency operations (Addressable). Establish (and implement as needed) procedures that allow facility access in support of restoration of lost data under the disaster recovery plan and emergency mode operations plan in the event of an emergency. (ii) Facility security plan (Addressable). Implement policies and procedures to safeguard the facility and the equipment therein from unauthoCopyright © 2004 CRC Press, LLC


348


rized physical access, tampering, and theft. (iii) Access control and validation procedures (Addressable). Implement procedures to control and validate a person’s access to facilities based on their role or function, including visitor control, and control of access to software programs for testing and revision. (iv) Maintenance records (Addressable). Implement policies and procedures to document repairs and modiÞcations to the physical components of a facility which are related to security (for example, hardware, walls, doors, and locks). (b) Standard: Workstation use. Implement policies and procedures that specify 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 speciÞc workstation or class of workstation that can access electronic protected health information. (c) Standard: Workstation security. Implement physical safeguards for all workstations that access electronic protected health information, to restrict access to authorized users. (d)(1) Standard: Device and media controls. Implement policies and procedures that govern the receipt and removal of hardware and electronic media that contain electronic protected health information into and out of a facility, and the movement of these items within the facility. (2) Implementation speciÞcations: (i) Disposal (Required). Implement policies and procedures to address the Þnal disposition of electronic protected health information, and/or the hardware or electronic media on which it is stored. (ii) Media re-use (Required). Implement procedures for removal of electronic protected health information from electronic media before the media are made available for re-use. (iii) Accountability (Addressable). Maintain a record of the movements of hardware and electronic media and any person responsible therefore. (iv) Data backup and storage (Addressable). Create a retrievable, exact copy of electronic protected health information, when needed, before movement of equipment. § 164.312 Technical safeguards. A covered entity must, in accordance with § 164.306: (a)(1) Standard: Access control. Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as speciÞed in § 164.308(a)(4). (2) Implementation speciÞcations: (i) Unique user identiÞcation (Required). Assign a unique name and/ or number for identifying and tracking user identity. (ii) Emergency access procedure (Required). Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency. Copyright © 2004 CRC Press, LLC


Appendix III

349

(iii) Automatic logoff (Addressable). Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity. (iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information. (b) Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. (c)(1) Standard: Integrity. Implement policies and procedures to protect electronic protected health information from improper alteration or destruction. (2) Implementation speciÞcation: Mechanism to authenticate electronic protected health information (Addressable). Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner. (d) Standard: Person or entity authentication. Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed. (e)(1) Standard: Transmission security. Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network. (2) Implementation speciÞcations: (i) Integrity controls (Addressable). Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modiÞed without detection until disposed of. (ii) Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate. § 164.314 Organizational requirements. (a)(1) Standard: Business associate contracts or other arrangements. (i) The contract or other arrangement between the covered entity and its business associate required by § 164.308(b) must meet the requirements of paragraph (a)(2)(i) or (a)(2)(ii) of this section, as applicable. (ii) A covered entity is not in compliance with the standards in § 164.502(e) and paragraph (a) of this section if the covered entity knew of a pattern of an activity or practice of the business associate that constituted a material breach or violation of the business associate’s obligation under the contract or other arrangement, unless the covered entity took reasonable steps to cure the breach or end the violation, as applicable, and, if such steps were unsuccessful — (A) Terminated the contract or arrangement, if feasible; or (B) If termination is not feasible, reported the problem to the Secretary. (2) Implementation speciÞcations (Required). (i) Business associate contracts. The contract between a covered entity and a business associate must provide that the business associate will— (A) Implement administrative, physical, and technical safeguards that



350


reasonably and appropriately protect the conÞdentiality, integrity, and availability of the electronic protected health information that it creates, receives, maintains, or transmits on behalf of the covered entity as required by this subpart; (B) Ensure that any agent, including a subcontractor, to whom it provides such information agrees to implement reasonable and appropriate safeguards to protect it; (C) Report to the covered entity any security incident of which it becomes aware; (D) Authorize termination of the contract by the covered entity, if the covered entity determines that the business associate has violated a material term of the contract. (ii) Other arrangements. (A) When a covered entity and its business associate are both governmental entities, the covered entity is in compliance with paragraph (a)(1) of this section, if— (1) It enters into a memorandum of understanding with the business associate that contains terms that accomplish the objectives of paragraph (a)(2)(i) of this section; or (2) Other law (including regulations adopted by the covered entity or its business associate) contains requirements applicable to the business associate that accomplish the objectives of paragraph (a)(2)(i) of this section. (B) If a business associate is required by law to perform a function or activity on behalf of a covered entity or to provide a service described in the deÞnition of business associate as speciÞed in § 160.103 of this subchapter to a covered entity, the covered entity may permit the business associate to create, receive, maintain, or transmit electronic protected health information on its behalf to the extent necessary to comply with the legal mandate without meeting the requirements of paragraph (a)(2)(i) of this section, provided that the covered entity attempts in good faith to obtain satisfactory assurances as required by paragraph (a)(2)(ii)(A) of this section, and documents the attempt and the reasons that these assurances cannot be obtained. (C) The covered entity may omit from its other arrangements authorization of the termination of the contract by the covered entity, as required by paragraph (a)(2)(i)(D) of this section if such authorization is inconsistent with the statutory obligations of the covered entity or its business associate. (b)(1) Standard: Requirements for group health plans. Except when the only electronic protected health information disclosed to a plan sponsor is disclosed pursuant to § 164.504(f)(1)(ii) or (iii), or as authorized under § 164.508, a group health plan must ensure that its plan documents provide that the plan sponsor will reasonably and appropriately safeguard electronic protected health information cre-



Appendix III

351

ated, received, maintained, or transmitted to or by the plan sponsor on behalf of the group health plan. (2) Implementation speciÞcations (Required). The plan documents of the group health plan must be amended to incorporate provisions to require the plan sponsor to— (i) Implement administrative, physical, and technical safeguards that reasonably and appropriately protect the conÞdentiality, integrity, and availability of the electronic protected health information that it creates, receives, maintains, or transmits on behalf of the group health plan; (ii) Ensure that the adequate separation required by § 164.504(f)(2)(iii) is supported by reasonable and appropriate security measures; (iii) Ensure that any agent, including a subcontractor, to whom it provides this information agrees to implement reasonable and appropriate security measures to protect the information; and (iv) Report to the group health plan any security incident of which it becomes aware. § 164.316 Policies and procedures and documentation requirements. A covered entity must, in accordance with § 164.306: (a) Standard: Policies and procedures. Implement reasonable and appropriate policies and procedures to comply with the standards, implementation speciÞcations, or other requirements of this subpart, taking into account those factors speciÞed in § 164.306(b)(2)(i), (ii), (iii), and (iv). This standard is not to be construed to permit or excuse an action that violates any other standard, implementation speciÞcation, or other requirements of this subpart. A covered entity may change its policies and procedures at any time, provided that the changes are documented and are implemented in accordance with this subpart. (b)(1) Standard: Documentation. (i) Maintain the policies and procedures implemented to comply with this subpart in written (which may be electronic) form; and (ii) If an action, activity or assessment is required by this subpart to be documented, maintain a written (which may be electronic) record of the action, activity, or assessment. (2) Implementation speciÞcations: (i) Time limit (Required). Retain the documentation required by paragraph (b)(1) of this section for 6 years from the date of of its creation or the date when it last was in effect, whichever is later. (ii) Availability (Required). Make documentation available to those persons responsible for implementing the procedures to which the documentation pertains. (iii) Updates (Required). Review documentation periodically, and update as needed, in response to environmental or operational changes affecting the security of the electronic protected health information.



352


§ 164.318 Compliance dates for the initial implementation of the security standards. (a) Health plan (1) A health plan that is not a small health plan must comply with the applicable requirements of this subpart no later than April 20, 2005. (2) A small health plan must comply with the applicable requirements of this subpart no later than April 20, 2006. (b) Health care clearinghouse. A health care clearinghouse must comply with the applicable requirements of this subpart no later than April 20, 2005. (c) Health care provider. A covered health care provider must comply with the applicable requiements of this subpart no later than April 20, 2005. (§ 164.500 [Amended] 6. § In 164.500(b)(1)(iv), remove the words ‘‘including the designation of health care components of a covered entity’’. § 165.501 [Amended] 7. In §164.501, the deÞnitions of the following terms are removed: Covered functions, Disclosure, Individual, Organized health care arrangement, Plan sponsor Protected health information, Required by law, and Use. § 164.504 [Amended] 8. In §164.504, the following changes are made: a. The deÞnitions of the following terms are removed: Common control, Common ownership, Health care component, and Hybrid entity. b. Paragraphs (b) through (d) are removed and reserved. Authority: Sections 1173 and 1175 of the Social Security Act (42 U.S.C. 1329d–2 and 1320–4). Dated: January 13, 2003. Tommy G. Thompson, Secretary. [FR Doc. 03–3877 Filed 2–13–03; 8:45 am] BILLING CODE 4120–01–P

DEPARTMENT OF HEALTH AND HUMAN SERVICES OFFICE

OF THE

SECRETARY

45 CFR Part 162 [CMS–0003–F and CMS–0005–F] RINs 0938–AK64 and 0938–AK76



Appendix III

353

Appendix A to Subpart C of Part 164 — Security Standards: Matrix Standards

Sections

Implementation Specifications (R) = Required, (A) = Addressable

Administrative Safeguards Security Management Process ....................

164.308(a)(1)

Assigned Security Responsibility ............... Workforce Security .....................................

164.308(a)(2) 164.308(a)(3)

Information Access Management ..............

164.308(a)(4)

Security Awareness and Training ...............

164.308(a)(5)

Security Incident Procedures ..................... Contingency Plan .......................................

164.308(a)(6) 164.308(a)(7)

Evaluation ................................................... Business Associate Contracts and Other Arrangement.

164.308(a)(8) 164.308(b)(1)

Facility Access Controls .............................

Workstation Use .......................................... Workstation Security ................................... Device and Media Controls ........................

Risk Analysis (R) Risk Management (R) Sanction Policy (R) Information System Activity Review (R) (R) Authorization and/or Supervision (A) Workforce Clearance Procedure Termination Procedures (A) Isolating Health care Clearinghouse Function (R) Access Authorization (A) Access Establishment and ModiÞcation (A) Security Reminders (A) Protection from Malicious Software (A) Log-in Monitoring (A) Password Management (A) Response and Reporting (R) Data Backup Plan (R) Disaster Recovery Plan (R) Emergency Mode Operation Plan (R) Testing and Revision Procedure (A) Applications and Data Criticality Analysis (A) (R) Written Contract or Other Arrangement (R)

Physical Safeguards 164.310(a)(1) Contingency Operations (A) Facility Security Plan (A) Access Control and Validation Procedures (A) Maintenance Records (A) 164.310(b) (R) 164.310(c) (R) 164.310(d)(1) Disposal (R) Media Re-use (R Accountability (A) Data Backup and Storage (A)

Technical Safeguards (see § 164.312) Access Control ............................................ 164.312(a)(1) Unique User IdentiÞcation (R) Emergency Access Procedure (R) Automatic Logoff (A) Encryption and Decryption (A) Audit Controls ............................................. 164.312(b) (R) Integrity ....................................................... 164.312(c)(1) Mechanism to Authenticate Electronic Protected Health Information (A) Person or Entity Authentication ................. 164.312(d) (R) Transmission Security ................................ 164.312(e)(1) Integrity Controls (A) Encryption (A)



354


Health Insurance Reform: ModiÞcations to Electronic Data Transaction Standards and Code Sets AGENCY: OfÞce of the Secretary, HHS. ACTION: Final rule. SUMMARY: In this Þnal rule, we respond to public comments received and Þnalize provisions

applicable to electronic data transaction standards from two related proposed rules published in the May 31, 2002, Federal Register. We are also adopting proposed modiÞcations to implementation speciÞcations for health care entities and others. In addition, we are adopting modiÞcations to implementation speciÞcations for several electronic transaction standards that were omitted from the May 31, 2002, proposed rules. EFFECTIVE DATES: These regulations are effective on March 24, 2003. The incorporation by

reference of certain publications listed in this Þnal rule is approved by the Director of the Federal Register as of March 24, 2003. FOR FURTHER INFORMATION CONTACT:

Gladys Wheeler, (410) 786–0273. SUPPLEMENTARY INFORMATION:

Availability of 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 (toll-free at 1–888–293–6498) or by faxing to (202) 512–2250. The cost for each copy is $10. 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 OfÞce. The Web site address is: http:// www.access.gpo.gov/nara/index.html.

I. BACKGROUND A. ELECTRONIC DATA INTERCHANGE Electronic data interchange (EDI) refers to the electronic transfer of information in a standard format between trading partners. When compared with paper submissions, EDI can substantially lessen the time and costs associated with receiving, processing, and storing documents. The use of EDI can also eliminate inefÞciencies and streamline processing tasks, which can in turn result in less administrative burden, lower operating costs, and improved overall data quality. The health care industry recognizes the beneÞts of EDI, and many entities in the industry have developed proprietary EDI formats. However, with the increasing use of health care EDI standards, the lack of common, industry-wide standards has emerged as a major obstacle to realizing potential efÞciency and savings.



Appendix III

B. STATUTORY

355 AND

REGULATORY BACKGROUND

1. Statutory Background The Congress included provisions to address the need for developing a consistent framework for electronic transactions and other administrative simpliÞcation issues in the Health Insurance Portability and Accountability Act of 1996 (HIPAA), Pub. L. 104–191, which became law on August 21, 1996. Through subtitle F of title II of that statute, the Congress added to title XI of the Social Security Act (the Act) a new part C, titled ‘‘Administrative SimpliÞcation.’’ The purpose of this part is to improve the Medicare and Medicaid programs in particular and the efÞciency and effectiveness of the health care system in general, by encouraging the development of standards and requirements to enable the electronic exchange of certain health information. Part C of title XI consists of sections 1171 through 1179 of the Act. Section 1172 of the Act and the implementing regulations make any standard adopted under part C applicable to: (1) Health plans; (2) health care clearinghouses; and (3) health care providers who transmit any health information in electronic form in connection with a transaction covered by 45 CFR part 162. In general, section 1172 of the Act requires any standard adopted by the Secretary of Health and Human Services (the Secretary) under this part to be a standard that has been developed, adopted, or modiÞed by a standard setting organization (SSO). The Secretary may adopt a different standard if the standard will substantially reduce administrative costs to providers and health plans compared to the alternatives, and the standard is promulgated in accordance with the rulemaking procedures of subchapter III of chapter 5 of title 5, U.S.C. Section 1172 of the Act also sets forth consultation requirements that must be met before the Secretary may adopt standards. In the case of a standard that is developed, adopted, or modiÞed by an SSO, the SSO must consult with the following Data Content Committees (DCCs) in the course of the development, adoption, or modiÞcation of the standard: The National Uniform Billing Committee (NUBC), the National Uniform Claim Committee (NUCC), the Workgroup for Electronic Data Interchange (WEDI), and the American Dental Association (ADA). In the case of any other standard, the Secretary is required to consult with each of the above-named groups before adopting the standard and must also comply with the provisions of section 1172(f) of the Act regarding consultation with the National Committee on Vital and Health Statistics (NCVHS). Section 1173 of the Act requires the Secretary to adopt standards for transactions, and data elements for such transactions, to enable the electronic exchange of health information.


PH2164_refs.fm Page 357 Wednesday, November 19, 2003 2:54 PM

References Electronic Records: Electronic Signatures; Final Rule. 21 CFR Part 11, Vol. 62, No. 54, 13429. March 20, 1997. Food and Drug Administration. Code of Federal Regulations. Washington, D.C.: U.S. Government Printing OfÞce. Electronic Records; Electronic Signatures Final Rule. 1997. Food and Drug Administration. Title 21 Code of Federal Regulations Part 11. Washington, D.C.: U.S. Government Printing OfÞce. Federal Food and Drug Act. 1906. Bureau of Chemistry. General Principles of Software Validation, Draft Guidelines version 1.1. June 1997. Center for Devices and Radiological Health, Food and Drug Administration. Washington, D.C.: U.S. Government Printing OfÞce. Glossary of Computerized System and Software Development Terminology. August 1995. Code of Federal Regulations Food and Drug Administration, Division of Field Investigations, OfÞce of Regional Operations, OfÞce of Regulatory Affairs. Good Manufacturing Practices for Finished Pharmaceuticals. 2000. Food and Drug Administration. Title 21 Code of Federal Regulations Parts 210 and 211. Washington, D.C.: U.S. Government Printing OfÞce. Gough, Janet. 2000. Write It Down: Guidance for Preparing Documentation That Meets Regulatory Requirements. Denver, CO: Interpharm Press. Gough, Janet and David Nettleton. 2003. Commercial Off-the-Shelf Software Validation for 21 CFR Part 11 Compliance. Davis Horwood International Publishing: Godalming, Surrey, U.K. and Parenteral Drug Association: Bethesda, Maryland. Gough, Janet and Monica Grimaldi. 2001. The Internal Quality Audit. Davis Horwood International Publishing: Godalming, Surrey, U.K .and Parenteral Drug Association: Bethesda, Maryland. Gough, Janet. 2001. Hosting the Compliance Inspection. Davis Horwood International Publishing: Godalming, Surrey, U.K .and Parenteral Drug Association: Bethesda, Maryland. Guidance for Industry; Part 11, Electronic Records, Electronic Signatures Scope and Applicability. February 2003. Food and Drug Administration. Code of Federal Regulations. Washington, D.C.: U.S. Government Printing OfÞce. Guidance for Industry and for FDA Staff: General Principles of Software Validation. Draft. June 1997. Center for Devices and Radiological Health, Food and Drug Administration. Code of Federal Regulations. Washington, D.C.: U.S. Government Printing OfÞce. Guidance for Industry, Computerized Systems Used in Clinical Trials. April 1999. Food and Drug Administration. Guidelines for the Validation of Computer Controlled Systems. September 1995. Montreal: PMAC/POS-Montreal Technological Workgroup. Health Insurance Reform: Security Standards; Final Rule. United States Public Welfare and Human Services Title 45 Code of Federal Regulations Parts 160, 162, and 164. Washington, D.C.: U.S. Government Printing OfÞce. Good Clinical Practice: Consolidated Guideline. 1995. International Conference of Harmonization. CPMP/ICH/135/95/Step 5. Geneva, Switzerland: International Conference on Harmonization.


PH2164_refs.fm Page 358 Wednesday, November 19, 2003 2:54 PM

358


Medical Device Software Validation, Guidance for Industry, General Principles of Software Validation. Draft. June 9, 1997. Center for Devices and Radiological Health. Food and Drug Administration. Quality System Regulation. 1996. Food and Drug Administration. Title 21 Code of Federal Regulations Washington, D.C.: U.S. Government Printing OfÞce. Security and Electronic Signature Standards; Proposed Rule. August 1998. United States Public Welfare and Human Services. Title 45 Code of Federal Regulations Part 142. Washington, D.C.: U.S. Government Printing OfÞce. Software Development Activities Reference Materials and Training Aids for Investigators.1996. Food and Drug Administration. Washington, D.C.: U.S. Government Printing OfÞce.


Electronic Record Keeping: Achieving and Maintaining Compliance with 21 CFR Part 11 and 45 CFR Parts 160, 162, and 164

21 CFR 11: Complete Guide to International Computer Validation Compliance for the Pharmaceutical Industry

Compact Regs Parts 50, 54, 56, and 312: CFR 21 Parts 50, 56, and 312 Good Clinical Practices (10 Pack)

Cfr & Social Justice

Compact Regs Part 26: CFR 21 Part 26 Mutual Recognition: US and the European Community (10 Pack)

Interpharm Master Keyword Guide: 21 CFR Regulations of the Food and Drug Administration, 2002-2003 Edition

Implementing electronic document and record management systems

The CRC Master Keyword Guide for Food: 21 CFR Regulations of the Food and Drug Administration 2003–2004

Semiconductors and Semimetals (Vol. 21: Hydrogenated Amorphous Silicon, Part C: Electronic and Transport Properties)

Parts Selection and Management

Wholes, Parts, and Numbers

Learning and Teaching with Electronic Games

Parts and Principles

Persistence, Parts, and Presentism

SAP Governance, Risk and Compliance

Electronic and computer music

Electronic and Computer Music

Electronic Devices and Circuits

Evolution and the fossil record

Electronic and Computer Music

Morality and Politics: Volume 21, Part 1 (Social Philosophy and Policy) (v. 21)

Evolution and the Fossil Record

Evolution and the Fossil Record

Evolution and the Fossil Record

Evolution and the Fossil Record

160

Parts Fabrication: Principles and Process

Parts and Wholes in Semantics

Inn keeping with murder

Pro Active Record: Databuses with Ruby and Rails

Electronic Record Keeping: Achieving and Maintaining Compliance with 21 CFR Part 11 and 45 CFR Parts 160, 162, and 164

21 CFR 11: Complete Guide to International Computer Validation Compliance for the Pharmaceutical Industry

Compact Regs Parts 50, 54, 56, and 312: CFR 21 Parts 50, 56, and 312 Good Clinical Practices (10 Pack)

Cfr & Social Justice

Compact Regs Part 26: CFR 21 Part 26 Mutual Recognition: US and the European Community (10 Pack)

Interpharm Master Keyword Guide: 21 CFR Regulations of the Food and Drug Administration, 2002-2003 Edition

Implementing electronic document and record management systems

The CRC Master Keyword Guide for Food: 21 CFR Regulations of the Food and Drug Administration 2003–2004

Semiconductors and Semimetals (Vol. 21: Hydrogenated Amorphous Silicon, Part C: Electronic and Transport Properties)

Parts Selection and Management

Wholes, Parts, and Numbers

Learning and Teaching with Electronic Games

Parts and Principles

Persistence, Parts, and Presentism

SAP Governance, Risk and Compliance

Electronic and computer music

Electronic and Computer Music

Electronic Devices and Circuits

Evolution and the fossil record

Electronic and Computer Music

Morality and Politics: Volume 21, Part 1 (Social Philosophy and Policy) (v. 21)

Evolution and the Fossil Record

Evolution and the Fossil Record

Evolution and the Fossil Record

Evolution and the Fossil Record

160

Parts Fabrication: Principles and Process

Parts and Wholes in Semantics

Inn keeping with murder

Pro Active Record: Databuses with Ruby and Rails

Recommend Documents