Document Control in FDA Regulated Environments - When and how to automate
Download as PPTX, PDF1 like1,143 views
The document provides a comprehensive overview of document control within FDA-regulated environments, focusing on the use of electronic systems for compliance and efficiency. It outlines key predicate rules, recordkeeping standards, project considerations, and common implementation mistakes in e-systems, emphasizing the importance of careful planning and understanding regulations. Additionally, it details the necessary team structure, software validation processes, and best practices to avoid pitfalls during implementation.
Document Control in FDA Regulated Environments - When and how to automate
- 1. Document Control in FDA Regulated Environments: When and how to automate
- 2. Deb Groskreutz, MA Biology Bioinformatics Clinical Trials Databases R&D Biotech/Pharma Oracle DBA Certified Oracle Developer Web Development • Principal Engineer and Consultant, DEBYRA, LLC • Molecular Biology, Bioinformatics, Genome Databases • 20+ years working in Software Development • 10+ years in FDA regulated environments 21 CFR Part 11 SDLC and Quality Systems Software Implementation Software Validation Custom Systems Cloud Internal
- 3. Melita Ball Regulatory & Quality Training Remediation Warning Letter mitigation Quality System Development 21 CFR Part 11 Software Validation Supplier Qualification & Management Auditing Document Control Production & Process Control CAPA Complaint Handling Management Controls Project Management • Principal Consultant, MBC & Affiliates, LLC (MBCA) • 25+ years working in FDA regulated environments • Global Consulting Firm specializing in regulatory compliance and quality system
- 4. Agenda Overview of Predicate Rules Why E-Systems make life easier Why E-Systems are complex Considerations for an electronic environment Checklist for success 9 major implementation mistakes and how to avoid them
- 5. Predicate Rules Summarized What are they?
- 6. Predicate Rules: Summarized Documents 1. Approvals with date and signature 2. Documents must be available at the point of use 3. Obsolete documents must be prevented from unintended use 4. Changes must be reviewed approved with date & signature 5. Approved changes must be communicated to the people who need them in a timely manner 6. Must maintain change history of each document that includes a description of the change, a list of affected document, signature/date of approval, & when change becomes effective.
- 7. Predicate Rules: Summarized Records 1. Maintained at the location of use or reasonable accessible during an inspection. 2. All records must be made readily available for review and copying by the FDA 3. Must be stored to minimize deterioration and prevent loss 4. Must be legible 5. Must be retained for appropriate period of time according to individual regulations.
- 8. 8 Rules of Recordkeeping 1. Always use ink to create a permanent record. 2. Provide all requested information. Never leave unexplained blank spaces. 3. Always correct mistakes by drawing a single line through your error insert the correct information, initial and date the correction. 4. Never use whiteout or anything else to hide the original entry. You must be able to read the original entry.
- 9. 8 Rules of Recordkeeping 5. Always sign and date any Quality System Record. 6. Always write neatly and legibly. 7. When recording data, always copy information directly to the data sheet or notebook. Never record data on scrap paper or post-it-notes. 8. Always record ALL data. Never be selective. You must be able to explain & justify any data not recorded
- 10. Why E-Systems make life easier o Reduce human error o Better decisions based on real data (not opinion) o Better process visibility – know where documents are and how long they’ve been there o Automated escalations to help timeliness o Reduce amount of paper o Increased efficiency
- 11. Why E-Systems are complex o Requires high level of knowledge of predicate rules as they translate into E-Systems o Need to know how to assess and evaluate E-Systems to ensure they are designed for compliance before you buy o Need to know how to configure E-Systems to support your processes without compromising the system design o Implementation can take some time especially if you are interfacing with other systems like ERP or CRM
- 12. Considerations: E-Systems Project Considerations (Team, requirements gathering) System Access, Security, & Data Integrity (Part 11) E-Record Controls (Part 11 & Predicate Rules) E-Signature Controls (Part 11 & Predicate Rules) Business Process Considerations & Additional Functionality Software Validation (Part 11) & Training (Part 11 & Predicate Rules) Maintenance & Monitoring (Part 11)
- 13. E-Systems
- 14. Project Considerations - The Team o Quality / Regulatory o Management Representative o Senior Management o Heads of all Stakeholder Areas o Validation and Testing Group o Support o IT o External Help
- 15. Project Considerations - Requirements o Areas Required o What do you need? o Records & Electronic Signatures? o All at once or start with one area? o Whatever area(s) you choose, make all considerations for it.
- 16. Project Considerations –Workflow o Does the system match your process out of the box? o How much custom configuration do you need (if any)? o How much Workflow Control does it have? o Does the vendor have Best Practices? o Is external implementation guidance required?
- 17. Project Considerations –Workflow o Is there an Example out-of-the box implementation you can use? o Or start with as a template for building new workflows o Always considering… o Validation o Compliance o Compliant Reporting o Ease of use and Training
- 18. System Access, Security, & Data Integrity o Cloud o Sign On & Security o What controls are in place? o Data Transfer o Integration o Printing
- 19. System Access, Security, & Data Integrity o On-Site o Sign On & Security o What controls are in place o OS / Database to maximize internal resources o Transaction Controlled? o Personnel and equipment Readers, Printers, Devices, Laptops, Mobile Phones, Tablets
- 20. E-Record Controls - Reporting o What is available out of the box? Compliant Audit Trails Archiving Required Fields Permanent Unchangeable Records o Are records printable in a readable format? Are signatures printed with the record? o Integration considerations o Can you e-sign records in the system?
- 21. E-Signature Controls o E-Signatures are NOT o Sign-on or procedures for accessing the system o Audit Trails o Must have 2-Part Authentication for 1st Signing o At least 1-Part Authentication for subsequent signings o Indelibly linked to record – signature cannot be separated from record without collaboration of two or more people
- 22. E-Signature Controls o E-Sigs must contain all of the following information: 1) The printed name of the signer 2) The date and time when the signature was executed 3) The meaning (such as review, approval, responsibility, or authorship) associated with the signature o All information must display with the record both in the system and when printed.
- 23. Business Process Considerations o Current Systems? o Replace or Include o Tools to bring Existing Data into New System? o Cloud or Internal or Combo o Reports o Secure dumps o Web Services
- 24. Additional Functionality o Internal Company Integration o Database Links o Pull in values from Other (ERP, Customer, Custom) o Automated loads from files placed onto a server o Integration Testing and Validation o Partial release of functional areas
- 25. Software Validation o Vendor Audit for Compliant Processes o Validation Package / Support Available o IQ/OQ/PQ Guidance or packages o How are new releases, or configuration changes brought into Production from TEST?
- 26. Training o Cloud o Access to a Sand Box /Test System? o On Site o PROD, TEST, DEV o Training Schedule Automatically Created
- 27. Maintenance & Monitoring o Cloud o Your own redundancy o Data Dumps / Reports o Internal o Normal IT functionality o Database Backups + Testing, Exports, Secure file dumps o Archiving Needs based on predicate rules for document & records retention
- 28. Upgrade Paths o Software Upgrades from Vendor (Process + Validation needs) o Software Release cycle o Software Release Procedures and Testing o Integration with other components Validation and Testing o Configuration Changes o Release o Validation
- 30. Checklist for Success The Right Team In Place & Ready to Go Project Plan and Coordinator Software Master Documents & Processes Software Development Life Cycle (SDLC) Software Validation
- 31. Checklist for Success System Provides Needed Functionality and Workflow System is Secure and Capable of being Compliant with regulations Make Sure! Demand Demo on the Actual System Challenge all critical functionality and compliance elements System Access and Availability
- 32. Checklist for Success References Checked for Vendor Software Company Implementation Plan Configuration Customization (think hard before doing this!) Support Data Access
- 33. Checklist for Success Reporting Out of box, Ad Hoc, Custom Uptime + Backup and Recovery Upgrade Cycles Known and tested All Super Users Trained End Users Trained
- 34. Implementation Mistakes: How to Avoid Them
- 35. Implementation Mistakes: How to Avoid Them 1. System isn’t Really compliant o Thorough Vendor Audit o Full understanding of Regulations by Project Team 2. User Resistance o User Involvement: Decisions, Flow, Fields, Reports o Supportive Company leadership
- 36. Implementation Mistakes: How to Avoid Them 3. Delays o Project Manager and Representative clear and have authority o Commitment for timely support, implementation and training from Software Vendor or Internal 4. System won’t do what you thought it would o Sand box & testing all use-cases from key stakeholders o Pre-planning that it follows your processes o Clear Requirements, including Integration
- 37. Implementation Mistakes: How to Avoid Them 5. User Errors and misunderstandings o Training and Documentation o Clear workflow requirements and testing 6. Major player left the company o Redundancy 7. Contracts Not Clear or Complete o Data ownership is clear from beginning
- 38. Implementation Mistakes: How to Avoid Them 8. Changes made in Production that “Break” functionality o Quality System SOPs and SDLC process in place 9. Can’t find what you Need o Ad Hoc Reports o Training o Time for workflows and testing o “Ping” end-users for input during the whole process
- 39. THANK YOU! DEB GROSKREUTZ, Principal Software Engineer, Database Engineers Bringing You Real Answers, LLC MELITA BALL, Principal Consultant, MBC & Affiliates, LLC & ZenQMS [email protected] (541) 482-4274 www.mbcaconsulting.com [email protected] (520) 665-9081 www.zenqms.com (267) 670 8999
Editor's Notes
- #11: Reduce Human Error with functionality such as Table driven select fields Enforced non-blank fields Signatures at point of change Decisions based on data, not on what it “seems”…
- #15: The first thing to do is put your team together. Buy-in and representation from all the relevant groups is key to a successful and on-time implementation, so make sure to include them up front as you gather requirements, view the demos and make decisions. Of course the Quality and Regulatory groups and the management representative will be involved as possibly the main owners and over-seers of the system. Senior Management and Heads of Stakeholder Areas are important in both getting and helping all of the end users understand the priority of the project as well as freeing up the time for members of their teams to participate. Give a head’s up to the testing and validation folks. For IT Designate Software/IT owner(s) from start Understands Quality Needs Understands IT Needs Communicator…is able to meet and understand each stakeholder area Is willing to be trained to understand and configure/control the new system The Software lead must understand the needs of every component to adequately configure workflows, create succinct and relative select list values, understand compliance and required fields. If you don’t have internal resources that meet these requirements, consider a reputable consultant to get you going, up to speed, and be sure to include training and transfer of knowledge as part of the contract, as well as providing ongoing help when needed. Based on our experience, we also recommend an IT backup that has all of the documentation, training materials, …we came into a site where the IT lead was a consultant…took off with all the materials, documentation, training materials… So that internal resource is maybe another person on the main team, that can readily access their area and can be a backup for IT as needed.
- #16: Areas Required: All at once or start with one area? -Document Control, Design Control, Prod. and Process Controls, CAPA, Investigations, Complaints, Audits (Team Consensus) -Records with E Signatures: To maximize your investment, you shouldn’t be afraid of using e-signatures because it will add a lot of value… Finish last points on the slide…
- #17: -Does the system match your process out of the box? -Review this both to understand the system better, and to determine the parts that fit and don’t fit into your company’s needs. -How much custom configuration do you need? How much and how easy is it to do? How much Workflow Control? Required Fields Select Fields (table-source driven and maintained) Sign-off and Flow Management Concurrent or sequential Collaboration and Approvals -Does the company have Best Practices? If so, get them and determine if their best practices meet your regulatory and business needs? Look at them closely with the team and modify as needed. -External Guidance If you have never completed a project like this before, then an external implementation expert, especially one with a regulatory and Quality System Expertise can save you both time and money in the long run. Often times we have been called in after an implementation has stalled or failed completely due to inadequate guidance and background knowledge early in the process.
- #19: If you choose a Cloud – based system It can saves a lot of headache in terms of database maintenance and backups, IT staff you need on site, but you also lose some control In terms of sign on and security: Is data entered by the right people that can only access and modify records in the system appropriate for their job, with the right security? User Groups and Roles based on Login accounts What types of Encryption, Masking, Time-outs are provided or able to be set up? Verify that any fields that are entered by any user remain as permanent records, and the fields have been validated for what user can read or modify them. Other examples of controls include the population of select list fields that depend on selected values in other fields. Validate that only the correct values are displayed when the parent fields are populated. For instance, if you have a Product line that is made up of 7 Unique Part Numbers, then when you select that product line value in the driving field, then the Part Number sub-field values are populated with, and only with those 7 relevant part numbers. Another common control is to be able to specify what fields are required before the record can be saved or signed? Data Transfer: What do you own and what do you always have access to? What happens if you have to move to another system down the road? Or you need to dump out large amounts of data to bring into another system? What kinds of your data can you access and at what cost? Do you need to integrate to any other systems and what is supported in that respect? Part 11: FDA requires that those electronic records be able to be printed for FDA inspections in human readable format.
- #20: On-Site – Do you have multiple sites to consider? -How is access for each site grouped? Are there separate flows to consider? -How does that affect the roll-out of any configuration or software updates? -What are you sign-on Requirements. Many sites use a single sign on system, where you can use one username and password, controlled in a central repository (Active Directory/LDAP) for access to all systems? Is SSO required? -If so see how it is enabled and / or integrated with your system - Is the Operating System, Database, and technology available on the systems your company already has? -If there will be functionality added on, is the system able to use your current resources in terms of servers or in-house expertise? -Transaction Controlled DB: Access examples – JUST SAY NO! -Check all printers and linking to any other devices that you might need. Personnel and equipment: Does the system need to support other devices like smart phones or tablets If you’re using some combination of the Cloud and On-Site systems, consider the security and controls of the interactions and transfers of data between systems.
- #21: -People often think of reporting only as viewing and charting trends, searching and reporting on multiple systems perhaps grouped by product or month, and that type of thing. And that’s useful and you want to give that some thought as you figure out your business reporting needs. -But with an Electronic system, YOU MUST be able to pull out and print the data in a single record format! And that is what we’re referring to in this slide! -Part of the complexity in implementing these systems is making sure that you can print out these single record reports -And so what is available out of the box with these single reports? -Are there audit trails? -What types of archiving of older data is available? Remember, you are required to keep records for a certain period of time depending on the regulations you are adhering to. Some systems allow for archiving of the older data for meeting the data retention requirements -Does the single record report include all required fields? -And remember the predicate rules of having Permanent, unchangeable records -Are the records clearly printable and including the signatures? This part of functionality is critical especially when you’re capturing e-Signatures: You Can’t separate the signature from the associated data…And the signatures and the correlated data must all be reported as one record. Integration ability for Reporting? Links to other systems? Customers or ERP – For example, one thing that we’ve done is to link to a view in the ERP system to pull in the Part numbers and then be able to select all of the associated lot numbers depending on the Part number selected, So we could then associate these ERP numbers with a customer complaint and follow up investigation. We could also populate the customer name and contact information by accessing another view into the Customer Database. With any links, or table-driven select lists, you need to make sure and validate that they are available and being properly populated and NOT changed if they’ve been selected, but later the underlying source tables change. Can you e-sign records in the system? So let’s talk a little bit about E-Signatures… --------------------------------------- With this type of report, you might consider: a) Ad hoc functionality if it’s there. With some systems, it’s there, and then already validated for general use, so that can save time and validation efforts as it’s done on an Ad Hoc basis b) Those often have limitation, so if you need more sophisticated reports Consider finding out if specify reports you want can be developed internally with in-house expertise or if they have to be custom work done by the vendor $$. Many systems will integrate with reporting tools such as Crystal Reports, or even more programmatic interfaces and web services d) Remember, the reports need to be validated following your internal Software Validation SOPs and Software Dev. Life Cycle processes
- #22: We want to start talking about E-Signatures by talking about what they are not: The are not sign-on, or log in procedures for accessing the system And they are not Audit Trails E-signatures cannot be system access because during system access the user is not signing off on anything – they are simply authenticating that they have privileges to the system. E-signatures cannot be audit trails because audit trails must be recorded independently from the user without the users knowledge. Whereas Signatures must be applies under the FULL CONTROL and KNOWLEDGE of the user. Audit Trails…what changed and by whom… Required for Audit Record: Date/time/person logged in/Field changing/old value/new value/ (can add other things such as reason for change, etc.) 2 part authentication: For example, when approving a document with an e-signature Pop-up: First time…both username and Password…can’t autopopulation (Type in username and password…the first time in the system…) Second time you can autopopulate the password… Indelibly linked to record…to quote the reg: You have to have enough controls in your system so people can’t go in and move signatures from one signature to another…(legal terminology) Test and validate to the fact that you can’t accidentally sign the wrong document or show up on a different record…Tested…validation…
- #23: These 3 items must be collected and printed on the records, too. Use this as LITMUS test for if the system is going to be compliant or not… During a live system demo…ask to see a printed signature on a document’s record. If it’s not there, they’re not compliant…move to the next vendor… Similar thing can be said for the audit trails…old value/new value…if it’s not there…they’re not compliant…look at the audit trail for the transaction and see what it shows…already in trouble if they can’t find it or pull it up…before and after values… Make sure it’s capable of being compliant and capable of being validated Test it in your situation to make sure it is compliant in your environment! Before committing to buying a system, Demand that demo be done on the Real system so you can check for compliant capability
- #24: Do you have Complex Internal requirements or Integrations to consider Current Systems: Do you have any existing systems to consider? Will you be replacing or keeping them? If you’re replacing, do you need access to the data long term? Are there tools to bring the existing data into the new System
- #25: What additional functionality might you have to consider? There are so many ways to integrate with a variety of systems, and I’ve listed a few common ones here… Always with an eye on Integration Testing and Validation And whether you’re integrating to internal systems, or just different modules of functionality that you plan to release over time, how is each validated with respect to the others with each new upgrade or configuration change?
- #28: Whether you use a system that is on the cloud, or internal, consider backups of your data. Cloud: Can you do secure dumps? What procedures are in the contract? Or should be in the contract? Are the reports sufficient for dump outs that you can use as your own backup or to update periodic internal reports? Cloud – Recent Health Care client, spent thousands of dollars to bring their data into the Cloud-Based system based on Sales Promises and demos. Tried for over a year to make it work…2 failed “go-lives” Then called me in…worked with them to determine it wasn’t what they need. Tried to terminate Waited for 3 months, had to pay thousands more dollars to get the promised CSV file of all their patient data… Changed terminations…over 3 months…”Found” more charges… Just got the file on Friday. Call in a person up front as a guide if you don’t have internal expertise. Archiving: Don’t forget archiving needs: Find out how long do you need, for the regs you’re following, to keep records available
- #29: Make Sure! On a Real System. Testing all functionality including test upgrades. Demand that demo be done on the Real system so you can check for compliant capability
- #33: Check references. Preferably a longer term customer as well as a new one. Asking things such as: How did the implementation go? Were they provided an implementer with knowledge in the field as well as communicative skills to cater the system to them? Fully understand the customer-specific implementation needs. How was support? Both in terms of understanding and timeliness? Is there is there a user group? Is there a forum that customers can access? It might by worth asking, and perusing comments in the forum or other online user groups. Have they had any issues accessing data (if on a cloud)
- #34: Reporting Multiple Single!! Printing out all required fields and signatures
- #36: 1. System isn’t really compliant: (Reminder of quick checks for E-sigs and Audit reports) 2. User Resistance Involvement Supportive Company leadership and that includes a commitment to free up time for the users involved in the implementation, which also prevents the next mistake…
- #37: Delays: Resource time committed for the implementation. One of the main reasons for delay I’ve seen is that people were chosen for the team, and their other workload wasn’t adjusted. Make the time in team member’s schedules and relieve of other duties if over-booked.
- #38: Contracts: What do you own and have access to vs. what the company owns (Cloud) Health care company I’ve worked with held hostage once decided it was a bad choice and needed to move to another system (implementation failure,etc.)
- #39: We have witnessed the horror stories of software changes being “pushed” into production…and it brings the site down for 2 weeks… Everyone is trained to Quality System and understands and respects what that means for their daily work.
- #40: We hope these talks have given you some background information, so that, when the time is right, you can implement a Quality Electronic system that keeps your company compliant and enables you to efficiently run your business. Thank you for your time and attention and now I’ll open it up for any questions you might have for us.