Presentation on theme: "IPCMF & ISPE Conference Global Pharma Networks Tom Farmer"— Presentation transcript:
1GMP Inspections – A Global Perspective Auditing of Computerised System Suppliers IPCMF & ISPE ConferenceGlobal Pharma Networks Tom Farmer25th June 2004
2Overview of Presentation Reasons to Audit Computerised System SuppliersOutline Procedure for AuditCase Studies/ExamplesOverview of Audit Repository Centre (ARC)Typical Issues/ObservationsSummary and Conclusions
3Reasons to Audit Suppliers Business ReasonsRisk ManagementGood PracticeCost/Schedule/Quality BenefitsRegulatoryRequirements and Expectations
4Business Reasons Risk Assessment Regulatory ImpactData IntegritySecurityProduct QualityBusiness RiskRisk To manufacturing/process equipmentCorporate ReputationSafety ConcernsPatient SafetyEnvironmental SafetySupplier Audit is not part of Risk Assessment as such, but an integral part of the overall Project Management process which includes Risk Management.
5Business Reasons (Cont.) Good PracticeCommunication/Develop RelationshipsHelps identify misunderstandings and risksSet or clarify expectations and intentions with regard to documentation & other deliverablesIdentify potential gaps in procedures (eg: change control, configuration management) at an early stage, so they can be addressed with minimal impact.Cost/Schedule/Quality BenefitsReduce ReworkOn-Time DeliveryAim for “Right First Time”
6GMP Regulations EU Vol 4 Annex 11 21 CFR Part 210, 211 (Drugs) 21 CFR Part 820 (Medical Devices)21 CFR Part 11 (Electronic Records & Signatures)ICH Q7A (Active Pharmaceutical Ingredients)
7EU Regulations ICH EC Guide to GMP for Medicinal Products Vol 4, Annex 11“5. The software is a critical component of a computerised system. The user of such software should take all reasonable steps to ensure that it has been produced in accordance with a system of Quality Assurance.” (emphasis supplied)ICHQ7A (API Manufacturing)Not explicit regarding requirement for supplier audits (ie: Supplier audits/assessments not stated as mandatory)
8FDA RegulationsDo not explicitly mandate computerised system supplier audits, with possible exception for Medical Devices (21 CFR 820)But note that for Medical Devices, computer system supplier could be providing components that are part of the finished product.
9FDA Regulations (Cont.) 21 CFR (a)“Each manufacturer shall establish and maintain procedures to ensure that all purchased or otherwise received product and services conform to specified requirements. (a) Evaluation of suppliers, contractors, and consultants. Each manufacturer shall establish and maintain the requirements, including quality requirements, that must be met by suppliers, contractors, and consultants.Each manufacturer shall:(1) Evaluate and select potential suppliers, contractors, and consultants on the basis of their ability to meet specified requirements, including quality requirements. The evaluation shall be documented. (emphasis supplied)(2) Define the type and extent of control to be exercised over the product, services, suppliers, contractors, and consultants, based on the evaluation results.(3) Establish and maintain records of acceptable suppliers, contractors, and consultants. “
10FDA Warning Letter – Oct 2003 “4. Your firm failed to evaluate and select potential suppliers on the basis of their ability to meet specified requirements, including quality requirements with all evaluations documented as required by 21 CFR (a)(1). You failed to document supplier audits and your audit procedure (PUR-0200) fails to describe supplier audit procedures [FDA 483, Item #7].”
11FDA Regulations 21 CFR Part 11 Again, not explicit on supplier audits, but implied by the Validation and Training requirementsNeed to look to FDA guidance documents
12FDA GuidelinesFor validation, Scope and Application guideline specifically referencesFDA’s guidance for industry and FDA staff General Principles of Software Validation (CDRH - Medical Device guidance)GAMP 4 GuideGuidance for Industry - Part 11, Electronic Records; Electronic Signatures — Scope and Application“We recommend that you base your approach on a justified and documented risk assessment and a determination of the potential of the system to affect product quality and safety, and record integrity.”Convergence in approach to computerised systems across the different regulatory groups (CDER, CBER, CDRH)
13General Principles of Software Validation; Final Guidance for Industry and FDA Staff (CDRH - Jan 2002)6.3. VALIDATION OF OFF-THE-SHELF SOFTWARE AND AUTOMATED EQUIPMENTWhere possible and depending upon the device risk involved, the device manufacturer should consider auditing the vendor’s design and development methodologies (empasis supplied) used in the construction of the OTS software and should assess the development and validation documentation generated for the OTS software. Such audits can be conducted by the device manufacturer or by a qualified third party. The audit should demonstrate that the vendor’s procedures for and results of the verification and validation activities performed the OTS software are appropriate and sufficient for the safety and effectiveness requirements of the medical device to be produced using that software.
14GAMP Guideline Section 7.1 - Determining Validation Strategy “Suppliers should be formally assessed as part of the process of selecting a supplier and planning for validation. The decision whether to perform a Supplier Audit should be documented and based on a Risk Assessment and categorisation of the system components.”Also highlights role of end-user in assisting and educating suppliersAppendix M2 – Audit Guideline and Checklist
15Other Industry Guidelines PIC/S : GOOD PRACTICES FOR COMPUTERISED SYSTEMS IN REGULATED “GXP” ENVIRONMENTS (Aug 03)The assurance of the reliability of a Supplier’s software products is attributable to the quality of the software engineering processes followed during development. This should include design, coding, verification testing, integration, and change control features of the development life cycle, (including after sales support). In order for customers to have confidence in the reliability of the products, they should evaluate the quality methodology of the supplier for the design, construction, supply and maintenance of the software.(emphasis supplied) A formal, extensive review of the history of the Supply Company and the software package may be an option to consider where an additional degree of assurance of the reliability of the software is needed. This should be documented in a Supplier Audit Report.
16Other Industry Guidelines (Cont.) PDA TR 32 “Auditing of Suppliers providing Computer Products and Services for Regulated Pharmaceutical Operations”Includes a very detailed procedure and checklist for supplier auditsBasis of audit procedure for Audit Repository Centre (ARC) shared audits
17Summary – Reasons to Audit Suppliers If Predicate Rules do not explicity mandate Supplier Audits, why conduct them?Business BenefitsRisk ManagementGood PracticeCost/Schedule/QualityRegulatory expectationsFDA Guidelines & Requirements for System ValidationImplication of Industry Guidelines (GAMP, PIC/S, PDA etc)Audits are not mandatory but are considered ‘good practice’, and it is for the regulated user to determine any auditing needs, scope and standards. Recommend that the need for supplier audit/assessment be linked to Risk Assessments (and GAMP Categorisation)
18Summary – Reasons to Audit Suppliers Organisations are expected to demonstrate control of the processes and systems that affect data integrity, product quality, and patient safetyQuality cannot be inspected or tested into the finished product – it needs to be designed and built inFor software, one method to help achieve this is to follow a formal software development lifecycle (SDLC).Audit of suppliers helps ensure that a SDLC is in place and is followed.
20Approach to Supplier Audits Pharma Industry has not yet formally embraced a single standard method for supplier audit, in spite of regulatory expectation to evaluate suppliers as part of the technical acquisition process.Possible sourcesGAMP 4 & VPCS Best Practice GuidePDA TR32PIC/SISO Guidelines for auditing quality systems Part 1: AuditingOther industry guidelinesHave procedure/SOP in place, and ensure personnel are trained accordingly.
23Approach to Audits - Initiation Determine Need for AuditBased on Risk AssessmentSystem CategorisationSystem Scale and ComplexityDefine appropriate Audit TypeDocument justification for Audit (or otherwise)As part of Risk Assessment and/or within Validation Master Plan
27Audit types Postal Audits / Assessments System Audit / Detailed Audit Surveillance Audit / Monitoring AuditJoint AuditsShared Audits
28Approach to Audits – Planning End User inputsRisk Assessment & System CategorisationSupplier Audit Procedure and Standard ChecklistValidation Master PlanSystem Specifications/User Requirements/Project BriefSupplier Inputs (If available)Supplier ProfileOrganisation ChartProduct/Service DetailsDevelopment MethodologyProposal/Quotation
29Approach to Audits – Planning (Cont.) PreparationAudit AgendaAudit Specific ChecklistContact SupplierAgree date and timescales with SupplierCopy Supplier with agenda and checklistConfirm resource availability with Supplier
30Approach to Audits - Conduct Typical AgendaIntroductionsCompany Overview Presentation (including Quality System Overview/Workflow Methodology)Office/Facility TourInspection of selected Audit AreasInclude QMS and Procedures, Project Documentation, Maintenance etcReview Findings/ObservationsPresent Findings to Supplier
31Approach to Audits – Checklist/Audit Areas GAMPCompany OverviewOrganisation and Quality ManagementPlanning and Product/Project ManagementSpecificationsImplementationTestingCompletion and ReleaseSupport/MaintenanceSupporting Processes and ActivitiesPDA TR 32Quality SystemProject ManagementMethodologyTestingConfiguration ManagementManufacturingDocument and Records ManagementSecurityTraining and EducationMaintenance
32Comment on use of checklists Need to be careful with use of standard checklistsKey is in preparation for auditTailor audit criteria and checklist based on supplier product and/or servicesTry to ensure that audit criteria is suitably descriptive within checklistWhen documenting audit executionTry to avoid simple yes/no type responsesInclude comments as appropriate to elaborate on and explain answers and observationsInclude objective evidence, by unambiguous reference, or attachment
33Approach to Audits – Observations Communicate observations back to Supplier for responseConsider categorisation of observations (eg: Critical, Major, Minor, Comment only)Helps to set priorities for actionsHelps justification of decisionHighlight positives also – ie: where supplier meets or exceeds industry best practices
34Approach to Audits – Report Audit Report to be issued for approvalInclude completed “checklist”, not just observations/findingsInclude positive observations alsoFormal Response on observations required from Supplier
35Approach to Audits – Follow Up Need to ensure close out of observations by supplierRemember, past performance is a good indicator of future performance (but not a guarantee)Continuous monitoring is important, particularly for larger projects and customised systemsUse audit as an opportunity to establish open dialog and collaboration with your suppliers
37Case Study/Example # 1“Operations” identify need for new automated system“Projects Group” prepare equipment specificationProjects Group select Vendor/SupplierMain Criteria UsedCost (Cheapest!)TechnologyAt FAT stage, Projects Group request input from Quality Unit / Validation
38Case Study/Example # 1 (Cont.) Assessment/Audit planned & executedFindings:No Quality Systems/Procedures in place at supplierPoor Design Documentation (No Functional Specification, etc)Poor Change management/configuration managementPlanned FAT Testing of limited benefit from Validation perspective – additional testing required.
39Case Study/Example # 1 (Cont.) ActionsDQ developed and executedDevelop additional detailed test procedures for FAT, Site testing & qualificationImpactProject Schedule Impact (Project Delayed)Cost Impact (Internal costs as well as Supplier)
40Case Study / Example #2Project Group include Quality Unit /Validation at project definition phase.Postal Assessment of all prospective suppliers, followed by conference call with each supplier (ie: Quality issues addressed as part of bid analysis, as well as technical and commercial issues)Prefered Supplier agreed by all parties (Operations, Projects, Quality)
41Case Study / Example #2 (cont.) Detailed systems audit conducted in selected suppliers premises at start of projectLimited/minor issues only raised at auditOn-going monitoring of supplier during project, up to system delivery to siteOn time, within budget – no surprises
42Case Study / Example #3 Replacement of Laboratory Analysers Categorised as GAMP Category 3 (Standard Software), but systems considered GxP criticalSupplier Audit indicated by company SOPIssues:Multiple Suppliers (> 6)Local Supplier location not the same as System Development location.
43Case Study / Example #3 (Cont.) Following consultation with end-user, decided on Postal Audit (GAMP VPCS Good Practice Guide used as template).Review of responses followed up by conference call with supplier to clarify written replies and request additional informationReserved right to request “face-to-face” detailed audit, if deemed necessaryMain Benefits - Cost Saving.Also, get involvement/feedback from system development group, as well as local distribution and support groups.
44Case Study / Example #4 Manufacturing Control System Categorised as GAMP 4/5, and system considered GMP CriticalChallengesScale of projectMultiple locations involvedQuality Unit an integral part of project process.Aim to instill a culture of “Right First Time”
45Case Study / Example #4 (Cont.) Supplier Audit conducted as part of selection processFollow-up surveillance audits/reviews during implementation (monthly) to supplement suppliers internal quality group.BenefitsIdentified issues at an earlier stage, and helped minimise impactReduced Rework/Retesting on siteHelped ensure overall schedule targets met
47ARC (Audit Repository Centre) Centralised repository for audit reports, available to subscribing end-user companies. Not strictly limited to computerised system suppliers.Statistics (as at June 2004)Audits Available – 28Audits Scheduled - 13Audits under consideration – 18Links
48ARC (Cont)Probably more appropriate as part of corporate system selection, may not be fully suitable for local (smaller) system implementations.Access to ARC report does not absolve end-user from responsibility – need to analyse audit results and observations, and make decision on supplier acceptability.For project based systems, will still require on-going monitoring of supplier/implementer
50Considerations – Client side Timing of Audit/AssessmentScope / Intent of AuditSupplier Preparation (for Audit)Follow up on Audit Observations/FindingsOverall business benefits of Quality (and Operations) input at the design and procurement stages
51Typical Issues – Supplier Side TrainingIn-House Quality ProceduresRegulatory Issues/GAMP/21 CFR Part 11Technical TrainingChange ControlTypical focus on cost and schedule impact, lacking definition of re-test requirements and traceabilityConfiguration ManagementUncertainty as to requirements, Procedures and Baselines not clearly defined
53SummarySupplier Audit does not solve all problems, and is not a standalone process, but is a integral part of the overall project management process to help ensure sucessful system implementationUse Risk Assessment to determine need for Audit/AssessmentFocus on Business Benefits, as well as Regulatory NeedsImprove quality of delivered systemsSchedule Impact/Delivery to MarketCost Reduction (Minimise Rework)Teamwork & PartnershipEnhance co-operation between Quality, Projects & OperationsDevelop relationship and Improve communication with supplier
54Questions? Contact: Tom Farmer Mobile: 087-299 5454