Personalized medicine seems to be a potential solution to the known challenges facing clinical research and drug development. To be employed in clinical research, software tools must undergo a process called Computer System Validation (CSV) for compliance with legal requirements and Good Clinical Practice (GCP). Four academic developer groups of the EU project p-medicine were surveyed to evaluate the readiness of their developed software products to be used for clinical research. The analysis of the survey showed that considerable gaps exist in tool maintenance, quality management and compliance documentation. Because all developer groups use agile development methods, recommendations for agile quality assurance were developed as well as for using agile methods to establish “compliance by design”. We show how agile validation can be established by small modifications of sprint processes.

1. Agile approach for Computer System
Validation (CSV) of software products
for personalized medicine clinical trial
support
Wolfgang KUCHINKE
Heinrich-Heine University Düsseldorf, Germany
Presentation: 30. October 2014, eChallenges e-2014, Belfast, Northern Ireland

2. Introduction
p-medicine project
19 partners from 9 European countries
and Japan are using innovative
technologies to overcome current
problems in clinical research and pave the
way for more and better individualized
therapies
Aim
Development of an infrastructure with a
number of embedded tools that facilitate
the translation of conventional care to
personalized medicine therapies
More info on the personalized medicine project: http://p-medicine.eu/
2
At the centre: data sharing and integration
p-medicine (From data sharing and integration via VPH models to personalized medicine) is
a 4-year Integrated Project cofunded under the European Community’s 7th Framework
Programme aiming at developing new tools, IT infrastructure and VPH models to accelerate
personalized medicine
In p-medicine 19 partners from 9 European countries and Japan have dedicated themselves
to create support and sustain new knowledge and innovative technologies to overcome
current problems in clinical research and pave the way for a more individualized and
personalized medical therapies

3. W. Kuchinke (2015)
The personal medicine
infrastructure of p-medicine
3
Everything is
embedded into
a security
framework

4. W. Kuchinke (2015)
Software for
personalised medicine1

5. W. Kuchinke (2015)
Software for personalised
medicine

For personal medicine advancement, the key is
suitable software

Need for new software and software with new
capabilities

Tools must be flexible, scalable and adaptable to new
requirements that result from research on
personalised medicine

Often developed by small groups in academic
institutions as part of research projects

The question is: Can the quality and sustainability of
the software be guaranteed?
5

6. W. Kuchinke (2015)
Personalised medicine
 Personalized medicine is in general understood as a
medical approach in which patients are stratified
based on their disease subtype, risk, prognosis, or
treatment response
 The key idea is to base medical decisions on
individual patient characteristics (including
biomarkers) rather than on averages over a whole
population
 Therefore, in the center of personalised medicine are
the generation and sharing of personalized, medical
data
6

7. W. Kuchinke (2015)
Software as enabler
 Need for new tools and new ways of interoperability
between tools for personalized medicine
 Example:
 Next generation sequencing for genomic diagnostics
 Machine learning for expert knowledge
 The implementing of personalized medicine approaches
are almost always complex with the political commitment
as an important success factor
 The production of data by international consortia
need to integrate diverse stakeholders, requires the
standardization of protocols / processes
 Fast and flexible reaction to regulatory policies
7

8. W. Kuchinke (2015)
Software with highest
quality standard
 Because these tools support patient treatment and
care, they must meet highest quality standards
 Software used in clinical trials must be compliant with
“Good Clinical Practice” (GCP)
 Software may be regarded as Medical Device, when
used for diagnosis, prevention, or treatment of
diseases or other medical conditions
8

9. W. Kuchinke (2015)
Software as medical
device
 Often a case-by-case assessment is required to decide
whether software can be properly classified as a
medical device according to its characteristics and
functionalities
 FDA has created the guide “Software as a Medical
Device: Possible Framework for Risk Categorization
and Corresponding Considerations”
 Categorization must account for the risks associated
with implementing software as a medical device in
various clinical contexts, along with appropriate
considerations of its entire software lifecycle,
including requirements, design, development, testing,
maintenance, and use
9

10. W. Kuchinke (2015)
Validation2

11. W. Kuchinke (2015)
Computer System
Validation (CSV)
 The documented process of assuring that a
computerized system does exactly what it is designed
to do in a consistent and reproducible manner
 Validation begins with the system specifications /
requirements definition and continues until system
retirement and retention of the e-records
 Validation activities follow the V model
11

12. W. Kuchinke (2015)
Three step
process
Installation
Qualification (IQ)
Operational
Qualification
(OQ)
Performance
Qualification
(PQ)
12

13. W. Kuchinke (2015)
Computer System
Validation (CSV)
 Establishing documented evidence, which provides a high
degree of assurance that a Computer System will
consistently produce results that meet its predetermined
specification and quality attributes
 A “Computer System” is hardware and software; and
includes linked instruments, trained staff and Standard
Operating Procedures (SOPs) / manuals
 Developing software for the regulated area
 GCP compliance is important
 Quality system used by the developer
 Developer assessment (developers follow a clearly defined
and documented software development life cycle and
ensure quality)
 The most important aspect is to ensure traceability
13

14. W. Kuchinke (2015)
The V
model of
Computer
System
Validation
14

15. W. Kuchinke (2015)
The V
model of
Computer
System
Validation
15
START
It begins with the
planning, software
specifications and
software
requirements

16. W. Kuchinke (2015)
The V
model of
Computer
System
Validation
16
The tests
The PQ was changed
into Operations
performance by
user to account for
the necessary
security when used
by real users

17. W. Kuchinke (2015)
Going inside the
regulated domain
Are software tools developed in
academic centres able to fulfil
regulatory requirements and be
employed in a regulatory
domain?
17
The key question

18. W. Kuchinke (2015)
Project
3

19. W. Kuchinke (2015)
Research Objectives
 Analysis of four academic developer groups in p-
medicine, their software development methodology
and their kind of quality management
 FORTH (Foundation for Research and Technology
Hellas), King's College London, Fraunhofer
Institute, USAAR (Saarland University)
 Assessment of documentation and procedures needed
to achieve GCP compliance
 Assessment of how to improve quality management
to support CSV
 Recommendations for an improved CSV process that
takes into consideration the special conditions of
academic software development
19

20. W. Kuchinke (2015)
Research approach /
Methodology
 Survey based on questionnaires for self-assessment by
developers
 Topics addressed:
 Level of GCP compliance, quality management, testing,
sustainability and process compliance
 Development practices, availability of standard operating
procedures (SOPs), existence of a development plan,
functional specifications, documented procedures for
testing, …
 Existence of audit trails, data protection measures,
policies, ...
 Compliance of 4 tools: ObTiMA, Dr.Eye and Biosample
Manager, Imaging
 Gap analysis20

21. W. Kuchinke (2015)
Results of survey
 All four developer sites are using an agile
methodology for their software development
 Requirement engineering was variable
 Software requirements specifications not complete
 Alignment with GCP criteria and risk assessment for
safety was not complete
 Quality assurance was not fully implemented and
rather informal
 Lack of written plans and documentation, separate
review process, policies for deviation handling, written
testing policies, …
Need for an improved quality management
considering CSV demands
21

22. W. Kuchinke (2015)
Agile development
Approaches to software development emphasizing
incremental delivery, team collaboration, continual
planning, continual learning
Each sprint with it‘s own define, build, and test activities
Scrum uses an iterative, incremental approach to
optimizing future predictions and managing risk
Scrum helps to create an organization’s ability to respond
to changes in agility to achieve better results
Product development backlog is used to manage the
product’s needs
List of requirements sorted by value
In each iteration, the Scrum team selects the highest
priority requirements from the Product Backlog for work
22

23. W. Kuchinke (2015)
Quality
managemen
t and agile
development
23
Built-in
usability
and system
validation

24. W. Kuchinke (2015)
Agile development and
system validation
 The problem: agility in the regulated domain
 An agile development process does not fit easily into
the conventional waterfall approach of CSV
 Requires a complete set of user requirement
specifications (URS) in the early development phase
and the validation of the completed product
 Regulatory authorities require distinct and
comprehensive documented evidence that a quality
product is produced
24

25. W. Kuchinke (2015)
Agile development and
system validation
 Good automated manufacturing practice (GAMP)
covers a multitude of regulations and guidelines
 According to GAMP, software and computer systems
should be validated and qualified during the entire
duration of the software life cycle
 Maintenance, updates, sustainability
 In agile testing, the tests and verifications are part of
each iteration step
 Here it is possible to enter into the agile development
process additional steps for system validation
 Possibilities to automate documentation processes
25
Good automated
manufacturing practice
(GAMP) is a set of
guidelines for
manufacturers and
other automation users
follow to maintain
operational efficiency
and reliability.

26. W. Kuchinke (2015)
Built-In Verification and
Validation
 Computer System Validation includes both computer
hardware and computer software
 Computer System Validation largely corresponds to Software
Validation in standard computer systems
 FDA Software Validation Guidance Document requires to
document the complete development process, such as
 Software Requirements
 Verification of software requirements including traceability to
stakeholder requirements
 Verification of software architecture and detailed design
including traceability to software requirements
 Software usability by users
 Build the compliance into the system during agile development
26

27. W. Kuchinke (2015)
Possibilities to consider CSV
exists in the agile process
 Scrum emphasizes empirical feedback and team self-
management to build properly tested product
increments and in this way the basis for efficient
testing procedures and validation processes is
provided
 Tools allowing the automatic documentation of tests
and verifications may support developers in obtaining
the necessary documentary evidence in an agile
environment
 For the development team, it should be possible to
integrate CSV validation activities into the sprints with
occasional formal verification / validation activities
 Use of risk based approach for testing and validation
27

28. W. Kuchinke (2015)
Conduct
validation
preparation
during
development
Incremental, iterative and
team based system validation
Automatic
development of
process
descriptions and
documentation
(requirements, SW
specifications,
traceability matrix,
validation plans, ...)
Team and risk
based and
incremental
testing and
analysis for
quality
improvement
28

29. W. Kuchinke (2015)
Using tools for documentation
 Tools may be adapted and extended to include capture of
compliance documentation and quality activities
 For example
 JIRA, an issue tracking application that can be used for bug
tracking and project management
 Flyspray, a web-based bug tracking system with many functions
to assist software development
 Git, an open source version control system
 GitLab, a Git repository management, code review, issue tracking,
activity feeds system
 Git generates a log about all changes in the code, but can also be
used for issue tracking and software version control visualization
 Software projects may be displayed by Gource as animation
 Jenkins provides continuous integration services and monitors job
execution
29

30. W. Kuchinke (2015)
Build-in Compliance
 Support of the user (e.g. trial sponsor) of the software,
who must guarantee that the software has been
verified / validated during development and is “Fit-for-
purpose”
 GCP and regulatory requirements are already being
considered during the development process
 Complemented by risk-based approach of validation
 The agile way to document quality activities is that
the documentation is done incrementally and
automatically as short, electronic documentation
 Employment of an incremental, iterative and team
based approach to CSV and for the production of the
necessary validation evidence
30

31. W. Kuchinke (2015)
Integration of
computer
system
validation
activities into
sprints
31

32. W. Kuchinke (2015)
Recommendations
4

33. W. Kuchinke (2015)
Recommendations for agile
validation
 Build-in-Compliance
 Considering GCP and regulatory compliance issues already
during iterations
 Integrated Risk Assessment
 Deal with the increased demands for documented evidence
 Training of compliance requirements (e.g. GCP, PIC/S,
GAMP) for developers
 Development of short written policies for development,
reviewing and testing
 Re-use of documentation generated during development
for validation purposes; preparation for maintenance phase
 Use of tools to automate documentation
 Identification of modules that are high in GCP risk, have
low test coverage, show high error rate, … for deep testing
33

34. W. Kuchinke (2015)
References
W. Kuchinke, C. Krauth and T. Karakoyun, "Agile software development
requires an agile approach for computer system validation of clinical
trials software products," eChallenges e-2014 Conference Proceedings,
Belfast, 2014, pp. 1-8
https://ieeexplore.ieee.org/document/7058150/authors#authors
https://www.semanticscholar.org/paper/Agile-software-development-req
uires-an-agile-for-of-Kuchinke-Krauth/9ddc72cce3fe0fe36e9ca0a653e926
ba073b7b9f
http://p-medicine.eu/fileadmin/p-medicine/public_website/news/p-medici
ne_newsletter_issue4.pdf
34

35. W. Kuchinke (2015)
Thanks!
Wolfgang Kuchinke
◇ Heinrich-Heine University Duesseldorf, Germany
◇ phone: + 49 (0) 211 81 16142
◇ e-mail: wolfgang.kuchinke@uni-duesseldorf.de
wokuchinke@outlook.de
35
This presentation contains some additional material for a
accompanying workshop.