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 comp