Regulations, Audits and DOORS Dr. Bernd GRAHLMANN [email protected] +33 (0) 6 82 86 68 03.

Regulations, Audits and DOORS

Dr. Bernd [email protected]

www.grahlmann.net+33 (0) 6 82 86 68 03

mailto:[email protected]

http://www.grahlmann.net/

2 © Telelogic AB

Dr. Bernd [email protected]+33 (0) 6 82 86 68 03

©

Please look at the ‘notes’ pages as they give additional

information for this presentation!!!

3 © Telelogic AB


©

• Company with a considerable engineering percentage

• Faced by FDA, MHW, GMED, FAA, … audits

• Opportunities for improvements in the area of requirements management

• Open for or (better) already using DOORS

or• Auditing organism

• Company with a considerable engineering percentage

• Faced by FDA, MHW, GMED, FAA, … audits

• Opportunities for improvements in the area of requirements management

• Open for or (better) already using DOORS

or• Auditing organism

• Today: Independent Requirements Management and DOORS consultant / trainer

• Last 3 years: Global manager for Requirements Management (in particular, DOORS) for GE Medical Systems (involving about 2000 engineers worldwide, cross modalities).

• Before: Ph. D. + 6 years project manager (software development: 500 kloc, 30 programmers)

• Today: Independent Requirements Management and DOORS consultant / trainer

• Last 3 years: Global manager for Requirements Management (in particular, DOORS) for GE Medical Systems (involving about 2000 engineers worldwide, cross modalities).

• Before: Ph. D. + 6 years project manager (software development: 500 kloc, 30 programmers)

My experiences / Your situationMy experiences / Your situation

4 © Telelogic AB


©

Overview

• Intro + situation• Process, procedures, guidelines• Validation / Verification• Regulations and software limitations• Linking and their analyses• Coaching / checking• Training• Electronic signatures & FDA 21 CFR 11• Software installations / upgrades• Integrations with other software• Summary / Questions

5 © Telelogic AB


©

Processes, procedures, guidelines

with pilotvalidation

Engineeringneeds

Req Mgtprocess

user level with valid

DOORSuser reqs

DOORSguidelines

ISOFDAreqs

ISOreqs

EQPMreqs

user level

ISOFDAreqs

ISOreqs

EQPMreqs

sys level with verif wrt DOORS guidelines

Req mgt / valid / verifreqs

user level with valid wrtprocess / guidelines

6 © Telelogic AB


©

Discussions around processes, …

• Not following processes yields non-conformities =>– Some prefer multi-tier (processes, procedures, guidelines) with

critical issues handled in less ‘official/mandatory’ guidelines– Some prefer to leave alternatives (not even committing to

DOORS)– Some prefer not to ask for too much (less attributes, no

verification/validation results, only ‘high-level’ requirements

• More than just simple software =>– Requirements management is a complicated task– Cannot separate DOORS from tasks

• Developing processes, guidelines, templates is engineering project => start from needs / requirements, finish with (pilot) validation / verification (example SRE)

7 © Telelogic AB


©

Backup as an example

• DOORS server backups and restores are an example for requirements, yielding to guidelines, with validation needs (timeliness of backup, tests of continue working and data integrity, possibility of restores, regular restore tests, …):

8 © Telelogic AB


©

Regulations and software limitations

• There is no history on links• Baselines have problems with links (see Paul’s

outlook on next DOORS versions):– Only the info on ID of object which is linked not on object

text, attribute values, … is saved– Need to baseline all modules simultaneously (does not

reflect correct project status)– For look up: only open one module, look up info on IDs of

linked objects, then open corresponding baseline of linked module

– Alternative: Print out (paper or PDF) traceability column with relevant information of linked objects

9 © Telelogic AB


©

Regulations and software limitations

• Print-out and archival (alternatives: paper + scan, DOORS archives for milestones on CD, export to Word/PDF + archive, DOORS server + backups is archival)

– Long-term requirement (if electronic, then need to maintain software for decades => feasible for PDF but not for DOORS archives)

– Change/revision control issues (rationales for change)– Data integrity issue– Electronic signatures (see DOORS 6.0 SR1)– Productivity issue (print-out, scan, archive, baseline, integration in

archival system, …)– Protection (fire, deletion, …)– Money (DOORS licenses/availability, …) issues

You need to identify, validate, approve and then follow process !

10 © Telelogic AB


©

Document control (approval / change)

820.40 Document controls: (FDA Quality System Regulation)(see http://www.access.gpo.gov/nara/cfr/index.html)

(a) Document approval and distribution. Each manufacturer shall designate an individual(s) to review for adequacy and approve prior to ... The approval, including the date and signature of the individual(s) approving the document, shall be documented. ...

(b) Document changes. Changes to documents shall be reviewed and approved by an individual(s) ... Each manufacturer shall maintain records of changes to documents. Change records shall include a description of the change, identification of the affected documents, the signature of the approving individual(s), the approval date, and when the change becomes effective.

11 © Telelogic AB


©

Linking and their analyses

• There are plenty of analyses related to links / traceability which are enforced by regulations:

– Validation / verification coverage

– Design coverage

– Analysis of ‘impact’ of a change (flow-down, flow-up)

– Change analysis (suspect links)

– …

• You need ‘guidelines’ on when / how to do those reviews / analyses; you need to prove that they work; you need to enforce them; and you need to document them.

12 © Telelogic AB


©

Some extraction from FDA 21 CFR 820

820.3 Definitions

(h) Design review means a documented, comprehensive, systematic examination of a design to evaluate the adequacy of the design requirements, to evaluate the capability of the design to meet these requirements, and to identify problems.

(t) Quality audit means a systematic, independent examination of a manufacturer's quality system that is performed at defined intervals and at sufficient frequency to determine whether both quality system activities and the results of such activities comply with quality system procedures, that these procedures are implemented effectively, and that these procedures are suitable to achieve quality system objectives.

(u) Quality policy means the overall intentions and direction of an organization with respect to quality, as established by management with executive responsibility.

(v) Quality system means the organizational structure, responsibilities, procedures, processes, and resources for implementing quality management.

(2) Design validation means establishing by objective evidence that device specifications conform with user needs and intended use(s).

(aa) Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.

13 © Telelogic AB


©

Some more extraction from FDA 21 CFR 820

820.30 Design control

(c) Design input. Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements. The design input requirements shall be documented and shall be reviewed and approved by a designated individual(s). The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.

(d) Design output. Each manufacturer shall establish and maintain procedures for defining and documenting design output in terms that allow an adequate evaluation of conformance to design input requirements. Design output procedures shall contain or make reference to acceptance criteria and shall ensure that those design outputs that are essential for the proper functioning of the device are identified. Design output shall be documented, reviewed, and approved before release. The approval, including the date and signature of the individual(s) approving the output, shall be documented.

(e) Design review. Each manufacturer shall establish and maintain procedures to ensure that formal documented reviews of the design results are planned and conducted at appropriate stages of the device's design development. The procedures shall ensure that participants at each design review include representatives of all functions concerned with the design stage being reviewed and an individual(s) who does not have direct responsibility for the design stage being reviewed, as well as any specialists needed. The results of a design review, including identification of the design, the date, and the individual(s) performing the review, shall be documented in the design history file (the DHF).

(f) Design verification. Each manufacturer shall establish and maintain procedures for verifying the device design. Design verification shall confirm that the design output meets the design[[Page 143]]input requirements. The results of the design verification, including identification of the design, method(s), the date, and the individual(s) performing the verification, shall be documented in the DHF.

(g) Design validation. Each manufacturer shall establish and maintain procedures for validating the device design. Design validation shall be performed under defined operating conditions on initial production units, lots, or batches, or their equivalents. Design validation shall ensure that devices conform to defined user needs and intended uses and shall include testing of production units under actual or simulated use conditions. Design validation shall include software validation and risk analysis, where appropriate. The results of the design validation, including identification of the design, method(s), the date, and the individual(s) performing the validation, shall be documented in the DHF.

(i) Design changes. Each manufacturer shall establish and maintain procedures for the identification, documentation, validation or where appropriate verification, review, and approval of design changes before their implementation.

14 © Telelogic AB


©

Coaching / validation

• Continuous coaching and validation are important:– Provide general ‘get started’ help– Quick routine checks (general structure, revision history,

approvals, permissions, …) to catch standard errors / problems

– Regular more detailed one-on-one checks (detailed structure, link set-up, OLEs, attributes, views, analyses, detailed permissions, DOORSNet publishing, baselines, deleted objects, printing, …)

– Real internal audits

15 © Telelogic AB


©

Training

• FDA requirement: Engineers need to be trained on the tool (i.e. DOORS) AND the tasks (i.e. processes, procedures, guidelines)

• Training needs to be documented

DOORSmodule

DOORSserver

(Europe)

DOORSserver(US)

with: Name, e-mail, system login,

permissions, training status, version,

DOORS account infos

DXL

to create / update users and to extract user information (which

users + who edited)

16 © Telelogic AB


©

Training (pre work)

• Develop templates and guidelines– Templates (with sections, standard text, attributes and

attribute types, views, link set up, help, guiding, …) for:• user requirements• system requirements• subsystem requirements• various test plans/results• use cases• …

– Guidelines including:• Contacts• Scope and traceability overview• Standards• New project set-up• Document life-cycle• Module templates• Various tasks in more detail

17 © Telelogic AB


©

Traceability: Guidelines - Training

• Training curriculum based on DOORS guidelines ensured by links between both DOORS modules.

• Training uses specific tasks from the guidelines as examples.

18 © Telelogic AB


©

Electronic signatures (FDA 21 CFR 11)

• Not having electronic signatures is for a lot of teams a real ‘show stopper’.

• This is not only ‘medical device industry’ relevant.

• DOORS 6.0 SR1 is a great step in the right direction(electronic sign-off for baselines – see Paul’s demo)

• Electronic signatures (and thus also ‘baselines’ ;-) in DOORSNet would be even greater!

• Problem: long-term archival …

• Processes / guidelines are important.

19 © Telelogic AB


©

Software installations / upgrades

• DOORS upgrades are cumbersome:– Clients and multiple servers may have to be upgraded

simultaneously:• DOORS 4.1.4 SR2 to DOORS 5 can basically be done project by

project

• DOORS 5 to DOORS 6 need to be done for all projects on a server simultaneously

• It may be necessary to have different DOORS clients installed

– Data may have to be migrated and migration requirements have to be identified, guidelines written and migration validated

– New version has to be re-validated (deficiencies need to be treated)

20 © Telelogic AB


©


• Telelogic’s DOORS install is not ‘perfect’. You may need to develop your own installshield + install guidelines from your requirements and test it:

21 © Telelogic AB


©


• Precise installation guidelines are important:

22 © Telelogic AB


©

Integrations with other software

• DOORS is only one part of the puzzle!– Interface with configuration management (ClearCase, …)

– Interface with defect tracking (DDTS, ClearQuest, …)

– Interface with modeling tools (Tau, Rose, …)

– Embedded in Product Data Management (e.g. eMatrix):• Huge opportunities:

– Traceability among all product related data

– Web-view on baselines

– …

• Issues:– Permissions

– 1-1 DOORS (project->folder->project->module->object) to eMatrix translation is needed

– Handling of DOORS attributes

– Update of published information after update/deletion in DOORS

23 © Telelogic AB


©

• DOORS is a great tool!• But, requirements management (in

particular) in big, distributed (maybe, multi-national) companies is not easy.

• Regulations, audits, … impose additional burdens, …

• FDA, FAA, … are just acting in your interest !!!

• Do not hesitate to contact me on details, trainings, consultancy:

[email protected]

+33 (0) 6 82 86 68 03

• DOORS is a great tool!• But, requirements management (in

particular) in big, distributed (maybe, multi-national) companies is not easy.

• Regulations, audits, … impose additional burdens, …

• FDA, FAA, … are just acting in your interest !!!

• Do not hesitate to contact me on details, trainings, consultancy:

[email protected]

+33 (0) 6 82 86 68 03

Summary / Questions

• Intro + situation• Process, procedures, guidelines• Validation / Verification• Regulations and software limitations• Linking and their analyses• Coaching / checking• Training• Electronic signatures• Software installations / upgrades• Integrations with other software• Summary / Questions

• Intro + situation• Process, procedures, guidelines• Validation / Verification• Regulations and software limitations• Linking and their analyses• Coaching / checking• Training• Electronic signatures• Software installations / upgrades• Integrations with other software• Summary / Questions

Summary / Questions

Regulations, Audits and DOORS Dr. Bernd GRAHLMANN [email protected] +33 (0) 6 82 86 68 03.

Documents

doors versions

bernd grahlmann

telelogic ab

doors consultant trainer

example doors server

needs requirements

highlevel requirements

situation slide