Implementing an Electronic System for CAPA and Complaints: Challenges and Opportunities

Transcription

1 Implementing an Electronic System for CAPA and Complaints: Challenges and Opportunities 119th AFDO Annual Educational Conference Michael Viscido Director, Global Quality Compliance June 22, 2015

2 Implementing an Electronic System for CAPA and Complaints: Challenges and Opportunities What are you talking about? Whose Idea Was This Anyway? Show Me The Money Twice! We Need A Plan: Normandy Revisited Requirements Risk: Bomb Our Position! IQ, OQ, PQ: Der Hexenkessel Training AKA You Run 6.2 Miles! Go Live! There are only 2 kinds of people Final Thoughts: It Was The Best Of Times, it Was The Worst Of Times 2 June 2015

3 What are you (am I) talking about? For the following topics Challenges Why are these items a potential problem? Opportunities: How can the problems be avoided? 3 June 2015 Bottom Line: Polarities are in the nature of things. How we act, how we respond to those polarities that is where we separate greatness from mediocrity. Polly LaBarre

4 Whose Idea Was This Anyway? Owner The person who really owns the system; has responsibility for its implementation Administrator The person who designs and runs the day to day operation of the system Sponsor The person(s), usually more senior, who has ultimate responsibility for the funding and usually human resources for the implementation and operation of the system Stakeholders Users Key users required to design and implement the system because of their role in its use; usually implementation team members The persons who utilize the system to get work done 4 June 2015 Bottom Line: Lack of commitment or buy in from anyone of these roles can decrease system use and acceptance

5 5 June 2015 Organizational Awareness

6 6 June 2015 Show Me The Money Twice! How Much Does it Cost? Hardware Software Maintenance SAS Consultants Other: Travel Audits Internal employees How Much Does it Save? Maybe nothing Compliance Issue? Do the analysis it is worth the cost Bonus Question: How Much Faster Can You Get It Done? Bottom Line: Be prepared for financial discussions they matter and you can avoid issues later if you do your homework! Its always better if you can show that the solution you are implementing can not ONLY improve compliance, but improve efficiency and/or decrease expenses as well and if you can do it sooner rather than later.

7 Cost Analysis Example Data extracted from LMS for the year 2013 Task Eliminated by Integration Hours Average Hourly Rate Cost/1 Year Plant #1 Add Course 588 Add Course to Org 79 Add Item to Curriculum 455 Add New Course Version 78 Attach uploaded file 770 Retire or Permanently disable old course version 71 Upload new file 13 Subtotal 2,053 $ $ 63, Plant #2 Add Course 22 Add Course to Org 6 Add Item to Curriculum 198 Add New Course Version 104 Attach uploaded file 50 Retire or Permanently disable old course version 107 Upload new file 46 Subtotal 533 $ $ 13, Plant #3 Add Course 41 Add Course to Org 11 Add Item to Curriculum 346 Add New Course Version 47 Attach uploaded file 31 Retire or Permanently disable old course version 16 Upload new file 30 Subtotal 521 $ $ 13, Total 3,107 $ 90, Project Budget $ 100, ROI months 7 June 2015

8 We Need A Plan: Normandy Revisited How? It depends on the project, the organization and the team It may be simple or complex Why? It helps the project manager It helps the team members It helps sponsors/management In short, it is one tool for communication Bottom Line: A plan is one of the best ways to ensure others that the effort is ontrack, for real and that they should pay attention 8 June 2015

9 9 June 2015 Plan Example 1 # Task Due Date Status Completion Date 1 Meet with the team to gather inputs 03/31/2014 Complete 04/01/ Meet with the team to introduce the differences of out 04/15/2014 Complete 04/08/2014 of box versus what is the current process 3 Create mock SOPs and WIs 04/30/2014 Complete 05/07/ Install new system on the DEV server 05/15/2014 Complete 05/05/ Set up users 05/20/2014 Complete 05/09/ Demo the new system 05/30/2014 Complete 05/29/ Revisit inputs 06/15/2014 Complete 05/29/ Final Decision as to go-no-go for OOB 06/15/2014 Complete 07/02/ Work with MC Architects to design form with Minor TBD: Changes (DEV environment) 10 Schedule multiple play and learn sessions in DEV ORIG: 07/30/2014 CURR: 30 days after Task 9 is completed 11 Tweak SOPs and WIs as needed ORIG: 08/15/2014 CURR: 45 days after Task 9 is completed 12 Install into QA ORIG: 08/15/2014 CURR: 45 days after Task 9 is completed 13 Set up users in QA ORIG: 08/20/2014 CURR: 5 days after Task 12 is completed 14 Create/Approve PQs ORIG: 08/20/2014 CURR: 25 days after Task 12 is completed 15 Run PQs ORIG: 08/31/2014 CURR: 5 days after Task 14 is completed 16 Perform trainings ORIG: 09/15/2014 CURR: 10 days after Task 15 is completed 17 Install into PROD and set up users ORIG: 09/20/2014 CURR: 10 days after Task 15 is completed 18 Issue procedures ORIG: 09/20/2014 CURR: 1-2 days after Task 17 is completed 19 Go live ORIG: 09/20/2014 CURR: 1-2 days after Task 17 is completed

10 AT Remote Support Integration Prep Int Test 1 Int Test 2 Int Test 3 Day in Life 17-Dec 24-Dec 31-Dec 7-Jan 14-Jan 21-Jan 28-Jan 4-Feb 11-Feb 18-Feb 25-Feb 4-Mar 11-Mar 18-Mar 25-Mar 1-Apr 8-Apr 15-Apr 22-Apr 29-Apr 6-May 13-May 20-May 27-May 3-Jun 10-Jun 17-Jun 24-Jun 1-Jul 8-Jul 15-Jul 22-Jul 29-Jul 5-Aug 12-Aug 19-Aug 26-Aug 2-Sep 9-Sep 16-Sep 23-Sep 30-Sep 7-Oct 14-Oct 21-Oct 28-Oct 4-Nov 11-Nov 18-Nov 25-Nov 2-Dec 9-Dec 16-Dec 23-Dec 21-Dec 28-Dec 4-Jan 11-Jan 18-Jan 25-Jan 1-Feb 8-Feb 15-Feb 22-Feb 1-Mar 8-Mar 15-Mar 22-Mar 29-Mar 5-Apr 12-Apr 19-Apr 26-Apr 3-May 10-May 17-May 24-May 31-May 7-Jun 14-Jun 21-Jun 28-Jun 5-Jul 12-Jul 19-Jul 26-Jul 2-Aug 9-Aug 16-Aug 23-Aug 30-Aug 6-Sep 13-Sep 20-Sep 27-Sep 4-Oct 11-Oct 18-Oct 25-Oct 1-Nov 8-Nov 15-Nov 22-Nov 29-Nov 6-Dec 13-Dec 20-Dec 27-Dec Plan Example 2 Week End Week Start Blueprint Realization MS 1 MS 2 MS 3 Final Prep Go-Live & Support MS 4 MS 5 MS 6 MS 7 MS 8 Prjct Prep SD/CR M Blueprint Realization P1 P1 P2 P2 P2 P3 P3 IP I1 I2 I3 DIL Non-Validn Rev Vali dati Pre-Validn Rev on Validn Support Fin al Pre p Prep Int Scripts Dry Runs 10 June 2015

11 Requirements: User Requirement Specifications (URS) should be simply stated (in the user s words so users can understand them) High level Descriptive Testable Clear Simple Traceable Necessary Good URS documents ensure user expectations are met Others: 11 June 2015 Functional Requirements Detailed Design Requirements Trace matrix Ensures that all items are tested when done correctly Bottom Line: Clear, testable requirements that state/confirm user needs will help ensure the final product is what was intended and works! All requirements must be complete and should be verified to mean the same things to all stakeholders.

12 12 June 2015 Requirements Document Example

13 13 June 2015 Trace Matrix Example

14 Risk: Bomb Our Position! Risk must be assessed Project This assessment focuses on overall project risk and mitigations, e.g. money, people, timing, external issues, etc. Application This assessment focuses on the actual software application, e.g. what issues might be caused by software problems, 21 CFR part 11, QSR/GMP compliance, functional failures, etc. Formal or Informal Sorry, no such thing! Bottom Line: A good risk assessment will not only ensure that potential problems are review and mitigated as needed, BUT will help to ensure and communicate to others that the solution/tool developed has been appropriately vetted for use. 14 June 2015

15 15 June 2015 Risk Assessment Example

16 16 June 2015 Risk Assessment Example 2

17 IQ, OQ, PQ: Der Hexenkessel Qualifications Installation Qualification Ensures proper installation of software Ensures proper hardware is available Operational Qualification To ensure software meets design/functional requirements Typically done by developer/vendor; review by customer Process Qualification Primary check to ensure software works and meets user requirements This is where you ensure the thing works!! Different environments Development QA Production 17 June 2015 Bottom Line: Make sure you perform qualifications in QA and Production and use people from different areas who are not protocol authors.

18 18 June 2015 PQ Example

19 Training AKA You Run 6.2 Miles! Training Needs to be planned Needs to be organized Needs to be supported Needs to be attended Training Elements Plan, forethought Materials Location(s)/venue Trainers Materials Follow-up Bottom Line: Don t make this an afterthought plan, develop, pilot and train (hands on) users at various levels and roles. 19 June 2015

20 20 June 2015 Sample Work Instruction

21 Go Live! There are 2 kinds of people The moment of truth Ensure IT support Ensure SME support Ensure back-out plan in place Bottom Line: Now that you are live, don t let off the gas support and troubleshooting here are essential to a well received roll out that will lead to long term acceptance by users and an implementation that is deemed successful by management. 21 June 2015

22 Final Thoughts: It Was The Best Of Times, it Was The Worst Of Times Communicate, communicate, communicate Within Without Up Down Across Potential Results Better consistency Improved data access Improved metrics transparency Bottom Line: There are no secrets to success. It is the result of preparation, hard work, and learning from failure. Colin Powell Don t expect miracles without hard work. Unfortunately, if it is your team s first go-around, it might not be pretty! 22 June 2015

23 23 June 2015 Questions