Transcript Regulations, Audits and DOORS

Regulations, Audits
and DOORS
Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
Please look at the ‘notes’ pages
as they give additional
information for this
presentation
!!!
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
2
© Telelogic AB
My experiences / Your situation
• 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)
• 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
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
3
© 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
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
4
© Telelogic AB
Processes, procedures, guidelines
Engineering
needs
Req Mgt
process
Req mgt / valid / verif
reqs
user level with valid wrt
process / guidelines
user level
FDA
reqs
ISO
ISO
reqs
EQPM
reqs
FDA
reqs
ISO
reqs
ISO
EQPM
reqs
DOORS
guidelines
with pilot
validation
DOORS
user reqs
user level with valid
sys level with verif wrt DOORS guidelines
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
5
© 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)
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
6
© 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, …):
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
7
© 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
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
8
© 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 !
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
9
© 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
© Dr. Bernd GRAHLMANN
the change becomes effective.
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
10
© 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.
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
11
© 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.
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
12
© 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.
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
13
© 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
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
14
© 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
DOORS
module
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)
DOORS
server
(Europe)
DOORS
server
(US)
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
15
© 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:
•
•
•
•
•
•
•
16
Contacts
Scope and traceability overview
Standards
New project set-up
Document life-cycle
Module templates
Various tasks in more detail
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
© 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.
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
17
© 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.
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
18
© 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)
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
19
© Telelogic AB
Software installations / upgrades
•
Telelogic’s DOORS install is not
‘perfect’. You may need to
develop your own installshield +
install guidelines from your
requirements and test it:
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
20
© Telelogic AB
Software installations / upgrades
• Precise installation
guidelines are important:
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
21
© 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
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
22
© Telelogic AB
Summary / Questions
•
•
•
•
•
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]
www.grahlmann.net
+33 (0) 6 82 86 68 03
•
•
•
•
•
•
•
•
•
•
•
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
© Dr. Bernd GRAHLMANN
[email protected]
www.grahlmann.net
+33 (0) 6 82 86 68 03
23
© Telelogic AB