This presentation reviews the regulatory requirements for intended use validation of SaaS-based EDC systems from the Sponsor and CRO perspective and provides best practices for implementing the proper validation in your organization.

1. How to Ace Your SaaS-based EDC
System Validation
For Sponsors and CROs
PRESENTED BY: AND

2. Webinar Housekeeping
 Slides and recording will be distributed to all registrants
 Use mic & speakers or call in
 Submit questions via chat
 Poll throughout presentation

3. 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

4. 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

5. What Auditors Want To
See in Your Validation
Documentation

6. Data Integrity & Data Quality
 Data integrity refers to the completeness, consistency, and accuracy of data
 The fundamental elements of data quality are ALCOA:
ALCOA+
Enduring
Complete
Consistent
Available
ALCOA
Attributable
Legible
Contemporaneous
Original (or a true copy)
Accurate

7. 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.”

8. Identify
intended use
Specify, Design,
Implement
System
System
Specifications
Electronic Data Capture
Study
Setup
Verify Edit
Checks
Data
Entry
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

9. SaaS-based vs. Internal Validation
Validation Plan
Requirements
Functional Specifications
Configuration Specification
Installation Qualification
System Testing
User Acceptance Testing
Traceability Matrix
Validation Summary Report
Standard Operating Procedures
Internal Validation Vendor
SDLC Deliverables
Software

10. SaaS-based vs. Internal Validation
SaaS Validation Vendor
SDLC Deliverables
Software
Validation Plan
Requirements
User Acceptance Testing
Traceability Matrix
Validation Summary Report
SOPs
Functional Specifications
Configuration Specification
Installation Qualification
System Testing
Traceability Matrix
SOPs
Release Management
Quality Agreement

11. Focus on Intended Use
Validation

12. Perception vs. Reality
Perception Reality
Validation is vendor driven
Intended use validation must be completed
by the user
Business processes are not validated
Validation 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.

13. 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”

14. 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

15. Best Practices for
Implementing EDC
Validation
Case Study: SDC’s Intended Use Validation of iMedNet eClinical

16. 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

17. 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-Based
Monitoring
Reporting
InventoryRandomization
Dashboards CTMS
ePRO
Medical
Coding
EDC
CEC Role-Based
Security
z
IRB Tracking

18. 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

19. 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.

20. 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

21. 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

22. 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

23. Key Takeaways to Ace
Your Audit

24. 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

25. 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

26. Thank You
Chris Wubbolt
Principal, QACV Consulting
contact@QACVConsulting.com
Q&A
Quan Doan
Associate Director, EDC Solutions, SDC
data@sdcclinical.com