webinar: how to ace your saas-based edc system validation for sponsors and cros
TRANSCRIPT
How to Ace Your SaaS-based EDC System ValidationFor Sponsors and CROs
PRESENTED BY: AND
Webinar Housekeeping
Slides and recording will be distributed to all registrants Use mic & speakers or call in Submit questions via chat Poll throughout presentation
Introductions
Chris Wubbolt, Principal, QACV Consulting 25+ years specializing in
Data integrity, computer system validation, compliance GCP audits and training Quality system development
Quan Doan, Associate Director, EDC Solutions, SDC 15+ years specializing in
Clinical data management and clinical programming CDMS selection, implementation, and software validation
Agenda
What auditors want to see in your validation documentation Focus on intended use validation Best practices for implementing EDC validation Key takeaways to ace your audit Q&A
What Auditors Want To See in Your Validation
Documentation
Data Integrity & Data Quality
Data integrity refers to the completeness, consistency, and accuracy of data
The fundamental elements of data quality are ALCOA:ALCOA+EnduringCompleteConsistentAvailable
ALCOAAttributableLegibleContemporaneousOriginal (or a true copy)Accurate
What is Computer System Validation?Why Validate? What?
Documented evidence which provides a high degree of assurance that a system consistently performs according to its predetermined specifications and quality attributes.
Why? 21 CFR Part 11.10: “to ensure accuracy, reliability, consistent intended
performance, and the ability to discern invalid or altered records.”
Identify intended
use
Specify, Design,
Implement SystemSystem
Specifications
Electronic Data Capture
Study Setup
Verify Edit Checks
DataEntry
Data Reconciliation
Database Lock
Test Plans / Scripts
Test/Verify that the System
Meets Specifications
Manual System > Automate
User Requirements Specification
What is Computer System Validation
SaaS-based vs. Internal Validation
Validation PlanRequirementsFunctional SpecificationsConfiguration SpecificationInstallation QualificationSystem TestingUser Acceptance TestingTraceability MatrixValidation Summary ReportStandard Operating Procedures
Internal Validation Vendor
SDLC Deliverables
Software
SaaS-based vs. Internal ValidationSaaS Validation Vendor
SDLC Deliverables
Software
Validation PlanRequirementsUser Acceptance TestingTraceability MatrixValidation Summary ReportSOPs
Functional SpecificationsConfiguration SpecificationInstallation QualificationSystem TestingTraceability MatrixSOPsRelease Management
Quality Agreement
Focus on Intended Use Validation
Perception vs. Reality
Perception Reality
Validation is vendor driven Intended use validation must be completed by the user
Business processes are not validatedValidation is based on business
processes, including the use of the computerized system
Focus is on functional testing Focus is on risk to data integrity and the ability to meet user needs
VS.
Regulatory Guidance: FDA
A workflow is an intended use of a computer system to be checked through validation
If you validate the computer system, but you do not validate it for its intended use, you cannot know if your workflow runs correctly
Validation of “Workflows”
Regulatory Guidance: MHRA
Requires an understanding of the computerized system’s function within a process For this reason, the acceptance of vendor-supplied validation data in isolation of
system configuration and intended use is not acceptable In isolation from the intended process or end user IT infrastructure, vendor
testing is likely to be limited to functional verification only, and may not fulfill the requirements for performance qualification (or UAT)
Validation
Best Practices for Implementing EDC
Validation
Case Study: SDC’s Intended Use Validation of iMedNet eClinical
Four Phases of Validation
Validation Phase Deliverable
Validation Planning Validation Plan Validation Training Materials
Requirements Analysis System Requirement Specification
User Acceptance Testing Test Scripts Traceability Matrix Detailed Test Results, Objective Evidence, & Test Incident
Reports
Release and Implementation
Validation Summary Report Final Test Incident and Resolution Logs System Release Memo
1. Validation Planning
Determine the scope of the validation Which components will you be using? Can all components be validated by an end user?
Determine key stakeholders & participants Process Owners End Users Quality Assurance
Risk-BasedMonitoring
Reporting
InventoryRandomization
Dashboards CTMS
ePRO
Medical Coding
EDC
CEC Role-Based Security
z
IRB Tracking
2. Requirements Analysis
Develop clear, verifiable, concise and discrete requirements
State “what” not “how”Business Requirements
User Requirements
System Requirements
High-level
Detailed
Ensure regulatory requirements are included
2. Requirements Analysis
The system shall prevent users from accessing the system upon 3 failed logon attempts
The system shall complete CRF saves within 2 minutes.
The system shall provide an audit trail with timestamps for inserts, updates and deletions.
The system shall prevent users from accessing the system upon multiple failed logon attempts
The system shall complete CRF saves quickly.
The system shall provide an audit trail.
3. User Acceptance Testing (UAT)
Develop robust test cases for each requirement Include positive and negative testing, if applicable Test cases should be written in a manner such that a person who has never used the system
before would be able to complete Create traceability matrix between test cases and system requirements Ensure testers are properly trained in GDP and Validation Plan Ensure objective evidence is captured Failures should undergo root cause analysis
Develop mitigation plan(s) depending on risk level
4. Release and Implementation
Validation Summary Report should summarize UAT results and all incidents Processes developed for use of the system should be implemented at this time Build a standard regression suite to test high risk items for system updates
4. Release and Implementation (for future releases)
Does vendor allow you to opt out of new
versions?
Validation is unaffected when
opting out; no need to re-validate
You must upgrade and evaluate re-
validation
Does vendor provide time and
environment for proactive testing of
changes?
Try to do re-validation within test
window
Consider a timeframe post-release for re-
validation
YES
NO YESNO
Key Takeaways to Ace Your Audit
Key Takeaways
Intended Use Validation User-driven Based on business processes Focused on risk to data integrity Required per FDA and MHRA
industry guidance
Best Practices for Implementation Only validate what you plan to use Ensure your requirements are
verifiable Review new releases for validation
impact
Additional Resources
MHRA GxP Data Integrity Definitions and Guidance for Industry
FDA Guidance for Industry Data Integrity and Compliance With CGMP
FDA Draft Guidance for Industry Use of Electronic Health Record Data in Clinical Investigations
Thank YouChris Wubbolt
Principal, QACV [email protected]
Q&A
Quan DoanAssociate Director, EDC Solutions,