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

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

Copyright © 2004 CRC Press, LLC

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

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

Copyright © 2004 CRC Press, LLC

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

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.

Copyright © 2004 CRC Press, LLC

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

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]

Copyright © 2004 CRC Press, LLC

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

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

Copyright © 2004 CRC Press, LLC

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

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

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

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

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

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

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

Copyright © 2004 CRC Press, LLC

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

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

Copyright © 2004 CRC Press, LLC

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

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

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

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

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

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

4

Achieving and Maintaining Compliance

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

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

Electronic Record Keeping: The Big Picture

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

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

6

Achieving and Maintaining Compliance

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

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

Electronic Record Keeping: The Big Picture

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

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

Achieving and Maintaining Compliance

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

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

Electronic Record Keeping: The Big Picture

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

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

Achieving and Maintaining Compliance

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

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

Electronic Record Keeping: The Big Picture

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

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

12

Achieving and Maintaining Compliance

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

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

Electronic Record Keeping: The Big Picture

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

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

14

Achieving and Maintaining Compliance

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

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

Electronic Record Keeping: The Big Picture

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

Copyright © 2004 CRC Press, LLC

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

16

Achieving and Maintaining Compliance

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

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

Electronic Record Keeping: The Big Picture

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.

Copyright © 2004 CRC Press, LLC

PH2164_C02.fm Page 19 Wednesday, November 19, 2003 9:41 AM

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-

19 Copyright © 2004 CRC Press, LLC

PH2164_C02.fm Page 20 Wednesday, November 19, 2003 9:41 AM

20

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

PH2164_C02.fm Page 21 Wednesday, November 19, 2003 9:41 AM

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.

Copyright © 2004 CRC Press, LLC

PH2164_C02.fm Page 22 Wednesday, November 19, 2003 9:41 AM

Achieving and Maintaining Compliance

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

Copyright © 2004 CRC Press, LLC

The HIPAA Parallel 164.306

160.103

N/A

PH2164_C02.fm Page 23 Wednesday, November 19, 2003 9:41 AM

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

What the Regulations Say

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

Copyright © 2004 CRC Press, LLC

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

PH2164_C02.fm Page 24 Wednesday, November 19, 2003 9:41 AM

Achieving and Maintaining Compliance

24

What the Regulations Say

What the Regulations Mean

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.

Copyright © 2004 CRC Press, LLC

The HIPAA Parallel

N/A

164.306, 164.308, 164.310, 164.312, 164.314, 164.316

164.310

N/A

PH2164_C02.fm Page 25 Wednesday, November 19, 2003 9:41 AM

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

What the Regulations Say

What the Regulations Mean

(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

Copyright © 2004 CRC Press, LLC

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

PH2164_C02.fm Page 26 Wednesday, November 19, 2003 9:41 AM

Achieving and Maintaining Compliance

26

What the Regulations Say

(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

Copyright © 2004 CRC Press, LLC

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

PH2164_C02.fm Page 27 Wednesday, November 19, 2003 9:41 AM

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

What the Regulations Say

What the Regulations Mean

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.

Copyright © 2004 CRC Press, LLC

27

The HIPAA Parallel

N/A

N/A

N/A

PH2164_C02.fm Page 28 Wednesday, November 19, 2003 9:41 AM

Achieving and Maintaining Compliance

28

What the Regulations Say

What the Regulations Mean

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

Copyright © 2004 CRC Press, LLC

The HIPAA Parallel N/A

N/A

N/A

N/A

N/A

N/A

N/A

PH2164_C02.fm Page 29 Wednesday, November 19, 2003 9:41 AM

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

What the Regulations Say

What the Regulations Mean

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.

Copyright © 2004 CRC Press, LLC

N/A

N/A

PH2164_C02.fm Page 30 Wednesday, November 19, 2003 9:41 AM

Achieving and Maintaining Compliance

30

What the Regulations Say

What the Regulations Mean

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

Copyright © 2004 CRC Press, LLC

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

PH2164_C02.fm Page 31 Wednesday, November 19, 2003 9:41 AM

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

What the Regulations Say

What the Regulations Mean

(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

PH2164_C02.fm Page 32 Wednesday, November 19, 2003 9:41 AM

32

Achieving and Maintaining Compliance

(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

PH2164_C02.fm Page 33 Wednesday, November 19, 2003 9:41 AM

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

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

PH2164_C02.fm Page 34 Wednesday, November 19, 2003 9:41 AM

34

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

PH2164_C02.fm Page 35 Wednesday, November 19, 2003 9:41 AM

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

(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

PH2164_C02.fm Page 36 Wednesday, November 19, 2003 9:41 AM

Achieving and Maintaining Compliance

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

PH2164_C02.fm Page 37 Wednesday, November 19, 2003 9:41 AM

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

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

PH2164_C02.fm Page 38 Wednesday, November 19, 2003 9:41 AM

38

Achieving and Maintaining Compliance

(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

PH2164_C02.fm Page 39 Wednesday, November 19, 2003 9:41 AM

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

(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

Copyright © 2004 CRC Press, LLC

39

PH2164_C02.fm Page 40 Wednesday, November 19, 2003 9:41 AM

Achieving and Maintaining Compliance

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

Copyright © 2004 CRC Press, LLC

PH2164_C02.fm Page 41 Wednesday, November 19, 2003 9:41 AM

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

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

PH2164_C02.fm Page 42 Wednesday, November 19, 2003 9:41 AM

42

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

PH2164_C03.fm Page 43 Wednesday, November 19, 2003 9:43 AM

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-

43 Copyright © 2004 CRC Press, LLC

PH2164_C03.fm Page 44 Wednesday, November 19, 2003 9:43 AM

44

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

PH2164_C03.fm Page 45 Wednesday, November 19, 2003 9:43 AM

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.

Copyright © 2004 CRC Press, LLC

PH2164_C03.fm Page 46 Wednesday, November 19, 2003 9:43 AM

Achieving and Maintaining Compliance

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-

Copyright © 2004 CRC Press, LLC

PH2164_C03.fm Page 47 Wednesday, November 19, 2003 9:43 AM

Going Electronic: What You Need to Know and Do

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:

Copyright © 2004 CRC Press, LLC

PH2164_C03.fm Page 48 Wednesday, November 19, 2003 9:43 AM

Achieving and Maintaining Compliance

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

PH2164_C03.fm Page 49 Wednesday, November 19, 2003 9:43 AM

Going Electronic: What You Need to Know and Do

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

Copyright © 2004 CRC Press, LLC

PH2164_C03.fm Page 50 Wednesday, November 19, 2003 9:43 AM

Achieving and Maintaining Compliance

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

PH2164_C03.fm Page 51 Wednesday, November 19, 2003 9:43 AM

Going Electronic: What You Need to Know and Do

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

Copyright © 2004 CRC Press, LLC

PH2164_C03.fm Page 52 Wednesday, November 19, 2003 9:43 AM

Achieving and Maintaining Compliance

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

PH2164_C03.fm Page 53 Wednesday, November 19, 2003 9:43 AM

Going Electronic: What You Need to Know and Do

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?

Copyright © 2004 CRC Press, LLC

PH2164_C03.fm Page 54 Wednesday, November 19, 2003 9:43 AM

Achieving and Maintaining Compliance

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?

Copyright © 2004 CRC Press, LLC

PH2164_C03.fm Page 55 Wednesday, November 19, 2003 9:43 AM

Going Electronic: What You Need to Know and Do

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

PH2164_C03.fm Page 56 Wednesday, November 19, 2003 9:43 AM

Achieving and Maintaining Compliance

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

PH2164_C03.fm Page 57 Wednesday, November 19, 2003 9:43 AM

Going Electronic: What You Need to Know and Do

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

PH2164_C03.fm Page 58 Wednesday, November 19, 2003 9:43 AM

Achieving and Maintaining Compliance

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

PH2164_C03.fm Page 59 Wednesday, November 19, 2003 9:43 AM

Going Electronic: What You Need to Know and Do

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

PH2164_C03.fm Page 60 Wednesday, November 19, 2003 9:43 AM

60

Achieving and Maintaining Compliance

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

PH2164_C03.fm Page 61 Wednesday, November 19, 2003 9:43 AM

Going Electronic: What You Need to Know and Do

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

PH2164_C03.fm Page 62 Wednesday, November 19, 2003 9:43 AM

Achieving and Maintaining Compliance

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-

Copyright © 2004 CRC Press, LLC

PH2164_C03.fm Page 63 Wednesday, November 19, 2003 9:43 AM

Going Electronic: What You Need to Know and Do

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.

Copyright © 2004 CRC Press, LLC

PH2164_C03.fm Page 64 Wednesday, November 19, 2003 9:43 AM

64

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

PH2164_C04.fm Page 65 Wednesday, November 19, 2003 9:44 AM

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.

65 Copyright © 2004 CRC Press, LLC

PH2164_C04.fm Page 66 Wednesday, November 19, 2003 9:44 AM

Achieving and Maintaining Compliance

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)

Copyright © 2004 CRC Press, LLC

PH2164_C04.fm Page 67 Wednesday, November 19, 2003 9:44 AM

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

PH2164_C04.fm Page 68 Wednesday, November 19, 2003 9:44 AM

Achieving and Maintaining Compliance

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)

Copyright © 2004 CRC Press, LLC

PH2164_C04.fm Page 69 Wednesday, November 19, 2003 9:44 AM

Documentation and Training

• •

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

Copyright © 2004 CRC Press, LLC

PH2164_C04.fm Page 70 Wednesday, November 19, 2003 9:44 AM

Achieving and Maintaining Compliance

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

Copyright © 2004 CRC Press, LLC

PH2164_C04.fm Page 71 Wednesday, November 19, 2003 9:44 AM

Documentation and Training

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

Copyright © 2004 CRC Press, LLC

PH2164_C04.fm Page 72 Wednesday, November 19, 2003 9:44 AM

72

Achieving and Maintaining Compliance

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

PH2164_C04.fm Page 73 Wednesday, November 19, 2003 9:44 AM

Documentation and Training

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

PH2164_C04.fm Page 74 Wednesday, November 19, 2003 9:44 AM

74

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

PH2164_C04.fm Page 75 Wednesday, November 19, 2003 9:44 AM

Documentation and Training

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.

Copyright © 2004 CRC Press, LLC

PH2164_C04.fm Page 76 Wednesday, November 19, 2003 9:44 AM

76

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

PH2164_C04.fm Page 77 Wednesday, November 19, 2003 9:44 AM

Documentation and Training

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

PH2164_C04.fm Page 78 Wednesday, November 19, 2003 9:44 AM

Achieving and Maintaining Compliance

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

PH2164_C04.fm Page 79 Wednesday, November 19, 2003 9:44 AM

Documentation and Training

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

Copyright © 2004 CRC Press, LLC

PH2164_C04.fm Page 80 Wednesday, November 19, 2003 9:44 AM

Achieving and Maintaining Compliance

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

PH2164_C04.fm Page 81 Wednesday, November 19, 2003 9:44 AM

Documentation and Training

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

PH2164_C04.fm Page 82 Wednesday, November 19, 2003 9:44 AM

82

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

PH2164_C05.fm Page 83 Wednesday, November 19, 2003 9:45 AM

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.

83 Copyright © 2004 CRC Press, LLC

PH2164_C05.fm Page 84 Wednesday, November 19, 2003 9:45 AM

84

Achieving and Maintaining Compliance

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

PH2164_C05.fm Page 85 Wednesday, November 19, 2003 9:45 AM

Security, Accountability and Change Management

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

PH2164_C05.fm Page 86 Wednesday, November 19, 2003 9:45 AM

86

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

PH2164_C05.fm Page 87 Wednesday, November 19, 2003 9:45 AM

Security, Accountability and Change Management

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

Copyright © 2004 CRC Press, LLC

PH2164_C05.fm Page 88 Wednesday, November 19, 2003 9:45 AM

88

Achieving and Maintaining Compliance

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

PH2164_C05.fm Page 89 Wednesday, November 19, 2003 9:45 AM

Security, Accountability and Change Management

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

PH2164_C05.fm Page 90 Wednesday, November 19, 2003 9:45 AM

90

Achieving and Maintaining Compliance

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

PH2164_C05.fm Page 91 Wednesday, November 19, 2003 9:45 AM

Security, Accountability and Change Management

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

Copyright © 2004 CRC Press, LLC

PH2164_C05.fm Page 92 Wednesday, November 19, 2003 9:45 AM

Achieving and Maintaining Compliance

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

Copyright © 2004 CRC Press, LLC

PH2164_C05.fm Page 93 Wednesday, November 19, 2003 9:45 AM

Security, Accountability and Change Management

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.

Copyright © 2004 CRC Press, LLC

PH2164_C05.fm Page 94 Wednesday, November 19, 2003 9:45 AM

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

PH2164_C05.fm Page 95 Wednesday, November 19, 2003 9:45 AM

Security, Accountability and Change Management

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.

Copyright © 2004 CRC Press, LLC

PH2164_C06.fm Page 97 Wednesday, November 19, 2003 9:47 AM

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.

97 Copyright © 2004 CRC Press, LLC

PH2164_C06.fm Page 98 Wednesday, November 19, 2003 9:47 AM

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

PH2164_C06.fm Page 99 Wednesday, November 19, 2003 9:47 AM

Auditing Electronic Record Keeping Systems

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.

Copyright © 2004 CRC Press, LLC

PH2164_C06.fm Page 100 Wednesday, November 19, 2003 9:47 AM

Achieving and Maintaining Compliance

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

PH2164_C06.fm Page 101 Wednesday, November 19, 2003 9:47 AM

Auditing Electronic Record Keeping Systems

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.

Copyright © 2004 CRC Press, LLC

PH2164_C06.fm Page 102 Wednesday, November 19, 2003 9:47 AM

Achieving and Maintaining Compliance

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

Copyright © 2004 CRC Press, LLC

PH2164_C06.fm Page 103 Wednesday, November 19, 2003 9:47 AM

Auditing Electronic Record Keeping Systems

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

PH2164_C06.fm Page 104 Wednesday, November 19, 2003 9:47 AM

Achieving and Maintaining Compliance

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

PH2164_C06.fm Page 105 Wednesday, November 19, 2003 9:47 AM

Auditing Electronic Record Keeping Systems

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

PH2164_C06.fm Page 106 Wednesday, November 19, 2003 9:47 AM

106

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

PH2164_C06.fm Page 107 Wednesday, November 19, 2003 9:47 AM

Auditing Electronic Record Keeping Systems

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

Copyright © 2004 CRC Press, LLC

PH2164_C06.fm Page 108 Wednesday, November 19, 2003 9:47 AM

108

Achieving and Maintaining Compliance

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

PH2164_C06.fm Page 109 Wednesday, November 19, 2003 9:47 AM

Auditing Electronic Record Keeping Systems

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

PH2164_C06.fm Page 110 Wednesday, November 19, 2003 9:47 AM

Achieving and Maintaining Compliance

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

PH2164_C06.fm Page 111 Wednesday, November 19, 2003 9:47 AM

Auditing Electronic Record Keeping Systems

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

PH2164_C06.fm Page 112 Wednesday, November 19, 2003 9:47 AM

112

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

PH2164_C07.fm Page 113 Wednesday, November 19, 2003 9:48 AM

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

PH2164_C07.fm Page 114 Wednesday, November 19, 2003 9:48 AM

Achieving and Maintaining Compliance

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

PH2164_C07.fm Page 115 Wednesday, November 19, 2003 9:48 AM

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

PH2164_C07.fm Page 116 Wednesday, November 19, 2003 9:48 AM

116

Achieving and Maintaining Compliance

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

PH2164_C07.fm Page 117 Wednesday, November 19, 2003 9:48 AM

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

PH2164_C07.fm Page 118 Wednesday, November 19, 2003 9:48 AM

118

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

PH2164_C07.fm Page 119 Wednesday, November 19, 2003 9:48 AM

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.

Copyright © 2004 CRC Press, LLC

PH2164_C08.fm Page 121 Wednesday, November 19, 2003 9:49 AM

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.

121 Copyright © 2004 CRC Press, LLC

PH2164_C08.fm Page 122 Wednesday, November 19, 2003 9:49 AM

122

Achieving and Maintaining Compliance

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

PH2164_C08.fm Page 123 Wednesday, November 19, 2003 9:49 AM

Frequently Asked Questions

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

PH2164_C08.fm Page 124 Wednesday, November 19, 2003 9:49 AM

124

Achieving and Maintaining Compliance

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

PH2164_C08.fm Page 125 Wednesday, November 19, 2003 9:49 AM

Frequently Asked Questions

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

PH2164_C08.fm Page 126 Wednesday, November 19, 2003 9:49 AM

126

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

PH2164_C08.fm Page 127 Wednesday, November 19, 2003 9:49 AM

Frequently Asked Questions

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.

Copyright © 2004 CRC Press, LLC

PH2164_C08.fm Page 128 Wednesday, November 19, 2003 9:49 AM

128

Achieving and Maintaining Compliance

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

PH2164_C08.fm Page 129 Wednesday, November 19, 2003 9:49 AM

Frequently Asked Questions

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

PH2164_C08.fm Page 130 Wednesday, November 19, 2003 9:49 AM

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

PH2164_C08.fm Page 131 Wednesday, November 19, 2003 9:49 AM

Frequently Asked Questions

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

Copyright © 2004 CRC Press, LLC

PH2164_C08.fm Page 132 Wednesday, November 19, 2003 9:49 AM

Achieving and Maintaining Compliance

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

PH2164_C08.fm Page 133 Wednesday, November 19, 2003 9:49 AM

Frequently Asked Questions

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

PH2164_C08.fm Page 134 Wednesday, November 19, 2003 9:49 AM

Achieving and Maintaining Compliance

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

PH2164_C08.fm Page 135 Wednesday, November 19, 2003 9:49 AM

Frequently Asked Questions

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

PH2164_C08.fm Page 136 Wednesday, November 19, 2003 9:49 AM

136

Achieving and Maintaining Compliance

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

PH2164_C08.fm Page 137 Wednesday, November 19, 2003 9:49 AM

Frequently Asked Questions

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]

Copyright © 2004 CRC Press, LLC

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

139 Copyright © 2004 CRC Press, LLC

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

140

Achieving and Maintaining Compliance

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

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

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

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

142

Achieving and Maintaining Compliance

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

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

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

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

144

Achieving and Maintaining Compliance

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

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

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

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

146

Achieving and Maintaining Compliance

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.

Copyright © 2004 CRC Press, LLC

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

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.

Copyright © 2004 CRC Press, LLC

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

148

Achieving and Maintaining Compliance

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

Copyright © 2004 CRC Press, LLC

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

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.

Copyright © 2004 CRC Press, LLC

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

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.

Copyright © 2004 CRC Press, LLC

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

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

Copyright © 2004 CRC Press, LLC

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

152

Achieving and Maintaining Compliance

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

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

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

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

154

Achieving and Maintaining Compliance

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

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

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

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

156

Achieving and Maintaining Compliance

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

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

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

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

158

Achieving and Maintaining Compliance

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

Copyright © 2004 CRC Press, LLC

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

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

Copyright © 2004 CRC Press, LLC

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

160

Achieving and Maintaining Compliance

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

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

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

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

162

Achieving and Maintaining Compliance

(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

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

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

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

164

Achieving and Maintaining Compliance

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

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

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

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

166

Achieving and Maintaining Compliance

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

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

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

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

168

Achieving and Maintaining Compliance

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

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

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

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

170

Achieving and Maintaining Compliance

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

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

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

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

172

Achieving and Maintaining Compliance

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

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

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