1. Data Flow in Clinical Trials and Systems
Frank Henrichmann
Director Technology Quality Management PAREXEL
7-May-2015

2. Disclaimer
The views and opinions expressed in the following PowerPoint presentation represent the opinions of the author / speaker and should not be construed as the position of PAREXEL Or Alcedis.

3. FDA When the FDA comes in and asks….
How can you be sure that your Data integrity is still intact when the data have been collected and processed by multiple CRO’s using several “Software as a Service” providers?
FDA

4. The Challenge of validating GCP systems
different IMPs
various indications
individual Endpoints
specific patient groups
Every study is a Project…
Sponsor
CROs
IT service providers
Every study may have several Key Players…
Every study is a project…
Investigating different IMPs for various indications with individual Endpoints in specific patient groups.
So every study may require specific solutions to address the project nature
Study Projects may have a high number of key players
Sponsor
CRO(s)
IT service provider(s) 4

5. Everything interacts with everything else
Key Players
Sponsor
CRO
IT Provider
Systems
EDC
CTMS
Study
Setup & Configuration
Systems supporting Study Projects often require a high level of integration
Interfaces
Between all key players
Between computerized systems
Often require Study specific setup or configuration 5

6. Many Players – Many Plans!
Protocol
Clinical Study Report
Medical Review Plan
Medical Review Report
Monitoring Plan
Monitoring Report
Statistical Analysis Plan
Statistical Analysis Report
die gleichen Risiken, die gleichen Ziele – aber alle Pläne entstehen parallel; risk based fehlt oder wird ‚als Ausrede‘ genutzt, um zu reduzieren, aber ohne System!
 besser – sie bauen aufeinander auf!
Data Management Plan
Data Management Report
Data Validation Plan
„Clean Data“
CRF
Data

7. Key Quality Aspects to be considered
Safety of the Patient participating in a Study
The Integrity of the Data collected in a Study
Systems supporting Study Projects often require a high level of integration
Interfaces
Between all key players
Between computerized systems
Often require Study specific setup or configuration
As new Medical products are investigated the
Safety of the Patient participating in a Study and
The Integrity of the Data collected in a Study
are the Key Quality Aspects to be considered! 7

8. Closer look at the potential complexity8

9. Aspects to be considered in the Quality approach
Software Products that are
installed on a qualified Infrastructure form
individual configured Computer Systems
General eClinical Platform
System
System
System
System
System
System
Integration
System
System
System
System
System
System
Configuration
Software
Software
Software
Software
Software
SaaS
Installation
Infrastructure
Infrastructure 9

10. Aspects to be considered in the Quality approach
A Study Specific eClinical Platform must be established for each study
Study-Specific eClinical Platform
System
System
Setup / Install & Configuration
System
Configuration
Configuration
System
Configuration
System
Setup / Install
Setup / Install
General eClinical Platform
System
System
System
System
System
System
Integration
System
System
System
System
System
System
Configuration
Software
Software
Software
Software
Software
SaaS
Installation
Infrastructure
Infrastructure 10

11. Interfaces, interfaces….
Interfaces are key to the implementation of an eClinical platform
Interfaces in such platforms may be:
Static: exchange of information between systems independent of the Study / Sponsor
Configurable: exchange of information between systems dependent on the Study / Sponsor requirements but using a configurable “interface platform” e.g. interfaces between EDC and CTMS systems
Custom: Interfaces created for one particular study or client with bespoke code

12. Aspects to be considered in the Quality approach
To make things worse the complexity increases even more if the platform reaches across multiple
Parties like Sponsors, CROs, EDC providers
Geographic areas, as local requirements must be considered
Can this complexity still be addressed by GAMP principles? 12

13. Break it down into chunks…
A breakdown into several Life Cycles is needed:
System Life Cycle
Platform Life Cycle
Study Life Cycle
Should apply the same principles
The GAMP Principles can be applied to all layers 13

14. How to make it work with GAMP
System Life Cycle
Validation planning
Validation Reporting
General System Requirements:
eCRF design functions
Query functions
Standard Interfaces
General System Requirements
Verification of System Requirements
Validation General Users Requirements:
Design a pure vanilla eCRF
Verify Query functions
Transfer dummy data through Interfaces
Validation of all non-Study specific functions
General functionally
Design/Setup functionally for Studies
Likely to include the setup of a demo study
Verifies System User Requirements that are based on overall business needs and the Business Process for Study Setup for the system.
System Training Plans
Mostly training of internal Staff like Administrators and internal End Users (e.g. CRAs)
Verification of robust Structures for Support, Back-up…
Verification of adequate Processes documentation
Design Development Configuration
Example: EDC 14

15. Break it down into chunks…
A breakdown into several Life Cycles is needed:
System Life Cycle
Platform Life Cycle
Study Life Cycle
Should apply the same principles
The GAMP Principles can be applied to all layers 15

16. How to make it work with GAMP
Validation Study Requirements:
Process data in the “real” eCRF
Transfer realistic data through Study-Specific Interfaces
Study Requirements:
eCRF design based on Study protocol
Study-Specific Interfaces (e.g. ePRO, IVRS)
Study Life Cycle
Validation planning
Validation Reporting
Study Requirements
Verification of Study Requirements
Design Development Configuration
System Life Cycle
Validation planning
General System Requirements
Design Development Configuration
Verification of System Requirements
Validation Reporting
Installation
Example: EDC 16

17. Break it down into chunks…
A breakdown into several Life Cycles is needed:
System Life Cycle
Platform Life Cycle
Study Life Cycle
Should apply the same principles
The GAMP Principles can be applied to all layers 17

18. How to make it work with GAMP
Study Life Cycle
Validation planning
Study Requirements
Design Development Configuration
Verification of Study Requirements
Validation Reporting
Installation
Study 1
Study 2
Validation planning
Study Requirements
Design Development Configuration
Verification of Study Requirements
Validation Reporting
Installation
Validation of all Study specific functions
Study-specific functionally (eCRF, workflows, Interfaces etc)
Correct Study Configuration/Setup
Verifies Study User/Functional Requirements that are based on the Study-specific needs (e.g. as documented in Study protocols, IBs, CRF designs).
Study specific training
May include significant parts of external training (e.g. PIs)
Study-specific deviations or additions to the general processes
System Life Cycle
Validation planning
General System Requirements
Design Development Configuration
Verification of System Requirements
Validation Reporting 18

19. Break it down into chunks…
A breakdown into several Life Cycles is needed:
System Life Cycle
Platform Life Cycle
Study Life Cycle
Should apply the same principles
The GAMP Principles can be applied to all layers 19

20. All clear so far...but why do we need a Platform Validation?
“The whole is more than the sum of its parts.” (Aristotle)
Meaning: Even if we have looked at the general and the Study- specific interfaces, we have not looked at the flow of data across all involved systems.
Example:
An approval of a site in a Study Startup tool leads to the creation of the site in the EDC system (3rd party SaaS) which hands that piece of data to the CTMS system (CRO) and the IVRS (Sponsor) who feeds it into a Logistic system (other CRO).
Data are generally flowing from Study Planning to Study Start- up to Study Conduct to Statistical Analysis to Study Reporting
How can we be sure that the data remain integer throughout the Study? 20

21. Closer look at the potential complexity
Site data
Supplier 1
Supplier 2
Site data
Site data
Site data
CRO
Site data
Sponsor
Site data 21

22. Case: ‚Critical Data Item(s)‘: Serious Adverse Events
Was bedeutet es, wenn der Wert sich nicht verändert
AE/SAE
Übersetzungen / Coding
Fluss in CTMS oder in SAS
Das wäre der Datenflow
Validation
Verification  wer macht da was, was wird codiert; Risk Tolerance 
ISPE Concept-Paper: Validation and Data Integrity in eClinical Platforms, peer reviewed

23. Focus in the Platform Validation
Verifies Quality expectations that are based on e.g. MSAs, SLAs,….
Processes/Agreements and harmonized approaches across all partners
Hand-overs and interactions between several partners including Change control
Platform specific training and processes/agreements and harmonized approaches across all partners
May include significant parts of partner training
Validation of dataflow and integrations across all systems and partners
Focusing on end-to-end Data integrity
Consistent validation approach across the platform and all parties involved
Software
Process
Requirements
Communication 23

24. Challenges in the Platform Validation
How can the verification of the handovers and integrations be done?
Via a “dummy study” that is processed using all parts of the General Platform
Analyzing the critical Data Flows for a Study and verification of those with tests
Review of communication e.g. for Change control and escalation plans
Challenges in the Platform Validation 24

25. Challenges in the Platform Validation
Individual parties may have used individual validation approaches for systems and integrations.
A mapping of the individual Validation deliverables and terminology to the GAMP 5® Guide can establish transparency and identify gaps 25

26. Challenges in the Platform Validation
Any approach to a Platform Validation across several parties must respect the protection of the intellectual property of the parties!
Should be done by an empowered and trusted party
The activity should be agreed already in contracts, SLAs, MSAs,…
This might require the development of a Dataflow-oriented quality approach to supplement the current “System-by-System” approach including
Manual Handovers
covered by Processes
Not covered by processes (ad-hoc communications, e.g. s)
Automated transfers (Interfaces) 26

27. Challenges in the Platform Validation
With the increase of SaaS offerings and Cloud services the validation of a platform will become even more challenging in the future.
Changes to the involved systems
Changes in the Study setup / configuration (Midstudy changes)
Changes to the involved partners across several Studies 27

28. Thank you For further information, please contact: Frank Henrichmann
Head of System Quality & Compliance
PAREXEL
Dr. Marina Mangold Head of eClinical Solutions
Alcedis GmbH
Thank you 28 28