AT3 Session 6/6/2013 10:15 AM 

       

"Agile Development in a Regulated Environment"

   

Presented by:

Chris Ampenberger PHT Corporation

         

Brought to you by:  

  

340 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

Chris Ampenberger PHT Corporation

Chris Ampenberger is a development manager at PHT Corporation, the leading provider of innovative systems used to collect patient-driven eData for clinical research. Chris manages three agile development teams which maintain PHT’s back-end systems that receive and process all acquired data. He has several years of experience managing software development teams in a number of industries. Chris started practicing agile seven years ago and managed its complete implementations in two companies. He has brought PHT’s Scrum implementation to a new level by: shortening sprints; measuring team and stakeholder satisfaction; and focusing on automating unit tests, functional testing, and release documentation.

 

Agile Development in a Regulated EnvironmentChris Ampenberger,

Directory Engineer, PHT

Trust your Patient-Driven eData with PHT

y g ,

June 2013

Discussion Topics

1 Background

22 Say what you do and do as you say!

3 Audit Readiness is a Deliverable

4 Practice, practice, practice

22

5 Contact Info

Background

• About Me

― Chris Ampenberger

― ~27 years in IT

― Working with Agile/Scrum since 2006

― Since 2011 with PHT Corporation

• About PHT

― Develops trials to capture patient reported outcomes (ePRO) through mobile devices

― Class 1 medical device manufacturer

― Over 540 trials in 14 therapeutic areas

3

p

― >70,000 mobile devices

― Fulfillment in 68 countries, supporting 97 languages

Say what you do and do as you say!

44

US Regulations & Guidance

• 21CFR Part11 Electronic Records and Electronic Signatures Rule (Mar 1997)

• FDA Guidance for Industry: General Principles of Software Validation (Jan 2002)2002)

• FDA Guidance for Industry: Computerized Systems Used in Clinical Investigations (May 2007)

• FDA Guidance for Industry: Patient-Reported Outcome Measures: Use in Medical Product Development to Support Labeling Claims (Dec 2009)

• FDA Guidance for Industry: Electronic Source Documentation in Clinical Investigations (Dec 2010)

5

Investigations (Dec 2010)

• 21CFR880 Medical Devices; Medical Device Data Systems (Feb 2011)

• FDA Guidance for Industry: Mobile Medical Applications (DRAFT Jul 2011)

European Regulations & Guidance

• DIRECTIVE 1999/93/EC … on a Community framework for electronic signatures (Dec 1999)

• Reflection paper on expectations for electronic source data and data transcribed to electronic data collection tools in clinical trials (Feb 2011)

• Annex 11: Computerized Systems (June 2011)

• Reflection paper on the Use of Interactive Response Technologies (Interactive Voice/Web Response Systems) in Clinical Trials (DRAFT Aug 2011

6

Regulatory Environment

• General distrust of electronic systems

• Regulators lag far behind technology

• US: Field inspectors are not always familiar with software• US: Field inspectors are not always familiar with software

• EU: EC’s and GCP Inspectors may include one or more software experts on the team

7

Consequences:

Plan

Our processes and standard operating procedures used to look like the following:

Plan

Execute

D li

=

88

Deliver

Process Evolution

ExecuteDeliver

Now they look more like the following:

Plan

AnalyzeAdjust

― Documented in a framework of policies, standard operating procedures work instructions etc

99

http://en.wikipedia.org/wiki/File:Scrum_process.svg

procedures, work instructions etc

― The framework undergoes periodic reviews to stay up to date

― Execution is documented in a paper trail that accompanies every release.

Then & Now

Product Requirements Specification ► Epics & User Stories

Software Requirements Specification ► User Stories

Software Design Specification ► Functional Specification Task & Wiki

1.5 year release cycle ► 6 month

Varying length phases ► 2 week sprints

Phases for requirements, design etc ► Weekly grooming

10

Audit Readiness is a Deliverable

• Christmas every year is not a surprise, neither are Audits!

• Plan for it:

― Break it downBreak it down

▸ Every story, every bug

▸ Every sprint

▸ Every release

― Enforce it

▸ Mini audits

11

▸ Checklists

▸ “Nagging” scripts

Invest in Automation

― Use an electronic system to support your SDLC that produces an audit trail and offers an API

― For every piece you have to produce, ask your self:

▸ Is it necessary?

▸ What is the minimum I have to produce?

▸ When is the earliest I can get it done and when is it due?

▸ How can I automate it?

12

Do it the Agile Way

― Start small!

― Pick highest value target first

▸ For example patch paper trail

▸ StudyWorks 4.16.0.2: 7 documents, 2 weeks, 240 person hours

▸ StudyWorks 4.16.0.4: 1 document, 2 days, 32 person hours

― Audit Trail automation and process improvements become part of the backlog

▸ Scrum the Scrum

Learn from audits and incorporate it in the backlog

13

― Learn from audits and incorporate it in the backlog

Where we are today• We use

― Rally▸ User Stories, Defects, Tasks▸ Test Cases, Test Results, Test Sets

― AccuRev with the GitCentricJ ki

• From that we generate― Validation Plan

― Test Plan

― Build Plan― Jenkins― Robot Test Framework― Skytap cloud

― Product Requirements Report

― Functional Specifications Report

― Traceability Matrix

― Unit Test Report

― Code Review Report

1414

― Test Case Results Report

― Test Case Results Review Report

― Defect Summary

Example: Patch Audit Trail

• We needed a report for patches that showed that we follow our procedures

• It needs to contain:

― Plan date

― Planned release date

― Actual release date

― Defects to be fixed

― Plan for defect validation

15

― Plan for regression testing

― Documentation of unit testing

― Documentation of code reviews

― Test results

Example: Patch Audit Trail

• Plan date -> Release.CreationDate

• Planned release date ->Release.ReleaseDate

• Actual release date -> Release.RevisionHistory[].Date

16

Example: Patch Audit Trail

• Defects to be fixed -> Defects per iteration

• Plan for defect validation -> Owner of Tasks with prefix [SQE-EXE]

17

Example: Patch Audit Trail• Plan for regression testing

• -> TestSets per release or iteration

• -> TestCases per TestSet

18

TestSet

Example: Patch Audit Trail

• Documentation of unit testing

• -> Task with prefix [DEV-UT] per defect or story

• -> Owner is engineeer

• -> Description contains result of test, or name of automated test

• -> Test results from Jenkins

19

Example: Patch Audit Trail

• Documentation of code reviews

• - > Record of promotions in AccuRev from the review stream to the integration stream

• -> Contains list of changed files & timestamp

• -> Notes with names of member participating in the code review

20

Example: Patch Audit Trail• Test results

• -> TestSets per release or iteration

• -> most recent TestCaseResult per TestSet with build belonging to release

21

TestSet

Practice, Practice, Practice

• Manager audits scrum team

• Have another group audit your group: Development audits Quality

• Quality Management & Compliance• Quality Management & Compliance

• External consultant

22

A Word of Caution

• Safety is paramount

• Second is the value of the overall product to the customer

• Nobody buys your product because you have perfect paperwork • Nobody buys your product, because you have perfect paperwork and processes

• Sometimes that means to set boundaries

23

Take Away

• Main Point

― Audit Readiness is a deliverable that needs to be integrated in every step of the scrum process

• Key Ideas

― Invest in automation

― Start Small

― Scrum the scrum and continuously improve your process

― Practice

24