This is the first part of a two part article.
The impetus to go electronic may well have been FDA's mandate that as of June 2009 the agency will only accept electronic submissions. Even though the last day to file a paper submission was 31 Dec 2007, many companies managed to get waivers. So the new mandate has spurred the decision to go fully electronic for more than one firm. With that decision comes a whole spate of issues.
Electronic systems require four essentials: validation, security, audit trails, and accountability. None of these is clear-cut, and companies still struggle to make sense of the very vague Part 11 regulation - which itself was slated for revision by 2006 to focus on risk, but industry has yet to see it. The current, original final rule provides little help in the actual "how to" for bringing a system on board, and more than one company has found itself mired in the transition process after having selected a suitable vendor, agreed to contractual terms, and purchased a configurable off-the-shelf (COTS) software program.
If the company has thought through the requirements it needs in an electronic document management system, it has done its homework and selected a system that is optimum for its business needs. Yet such a foundation does not guarantee that the company will implement the system efficiently.
The transition can be a torment, or it can be efficient, depending on several factors. The first is getting people on board and actively involved in the process. The second is being systematic in validating for "intended performance." The third is training. And the fourth is building the repository for documents and records within the system.
With an electronic system, the company has entered into a relationship with the vendor. It is important that the workforce knows this. Enthusiasm from the top down from the start of the process - ideally when the decision to purchase an e-system is made - helps bring people on board. The knowledge that the system will be easy to use, save time, and pay for itself in short order are benefits the users need to know and understand. The people who made the decision to purchase a software program are the ones who need to communicate with the workforce. That means the upper management personnel who authorized the purchase must be vocal and visible in endorsing the system. Those who participated in selecting it and those who understand its features should be advocates as well. In fact, those people who participated in the process are the ideal people to form a validation team, because they will understand "intended performance" best and can drive the transition.
An ideal validation team has a validation lead (typically from the unit that will administrate the system), team members representing every area of the company that will use the system, and an IT representative. The team may include other members, such as consultants and part-time employees. These people, however, should not serve as the validation lead, nor should IT. IT is important because a validation is not just for software, but for the entire system (i.e., software plus hardware) and IT is vital for total-system support. IT thus provides an essential service, but doesn't have to know how the software works. It can be disastrous if IT dictates how the system will work, when in fact, IT will not use the system on a day-to-day basis.
An important task of the validation team is to communicate with their respective departments as to the progress of the project. The responsibility of the validation team is also to drive the validation process systematically and deliver validation documents which go into a validation packet. This process verifies security, audit trails, and user accountability, and ensures that system users undergo training. The team itself needs to understand the system and be trained on it; such training is documented as part of the process. Next they need to ensure that enough users are trained so that they can test and verify that the system does what it's supposed to as they proceed through the validation activities. To produce the validation packet and the other documents and records the system requires a document management separate from the one undergoing validation. This system is frequently the one that will phase out over time once the validation is complete.
Another essential piece of validation is ensuring that SOPs that support the system and the validation activities are in place before the system goes live. That means the team has to look at SOPs already in place and see if they need to revise them to accommodate the new system. They will also have to create new SOPs to support the new system--and perhaps--the transition phase. SOPs to think about include the following:
Training is the next important component. Before anyone can use the system, there must be training. The validation team must train enough users initially so that they can test and verify system function during the validation process. Often the validation process itself flags issues that new users have with a system, and there may be retraining as the validation progresses.
Once the system goes into production, training must occur in earnest. Again, maintaining a level of enthusiasm is important for a fluid transition. Users need to know that their electronic signature is the legally binding equivalent of their handwritten signature, and that whatever they enter into the system becomes part of the audit trail for the system. Training also needs to spell out privileges (e.g., which users have access to which files and which users can perform certain functions). Once trained, people can use the system, even in its fledgling state to generate new documents and records, and access other documents as the system builds.
Next month, Part Two of this article will discuss how to build the system once it is live.
Part 11 Washington, D.C.: U.S. Government Printing Office.Nettleton, David and Janet Gough. Electronic Record Keeping: Achieving and Maintaining Compliance
with 21 CFR Part 11 and 45 CFR Parts 160, 162, and 164.2004. CRC Press: Boca Raton, FL. Nettleton, David and Janet Gough. Risk Based Software Validation: 10 Easy Steps. Second Edition,
2006, DHI and PDA Publishers: Baltimore, MD and Moore, Oklahoma
Janet Gough is a consultant to the industry specializing in document management, standard operating procedures, and technical and medical writing. She is a course director for the Center for Professional Innovation and Education. She is the author of 11 industry books, including Risk-Based Software Validation: 10 Easy Steps, and Write It Down: Guidance for Preparing Compliant and Effective Documentation (CRC Press). She and co-author David Nettleton are currently working on a Q&A book on Document Management for John Wiley & Sons. She can be reached at firstname.lastname@example.org or www.gxpdocumentation.com.
Watch Related Videos