Regulations,%20Audits%20and%20DOORS

1
Regulations, Audits and DOORS

• Dr. Bernd GRAHLMANN
• Bernd_at_Grahlmann.net
• www.grahlmann.net
• 33 (0) 6 82 86 68 03

2

• Please look at the notes pages as they give
  additional information for this presentation!!!

3
My experiences / Your situation
My experiences / Your situation

• 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)

4
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
Processes, procedures, guidelines
Engineeringneeds
ISO
user level
Req Mgtprocess
FDAreqs
ISOreqs
EQPMreqs
with pilotvalidation
DOORSguidelines
ISO
FDAreqs
ISOreqs
EQPMreqs
sys level with verif wrt DOORS guidelines
6
Discussions around processes,

• Not following processes yields non-conformities
  gt
• 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 gt
• Requirements management is a complicated task
• Cannot separate DOORS from tasks
• Developing processes, guidelines, templates is
  engineering project gt start from needs /
  requirements, finish with (pilot) validation /
  verification (example SRE)

7
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
Regulations and software limitations

• There is no history on links
• Baselines have problems with links (see Pauls
  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
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 gt 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
Document control (approval / change)

• 820.40 Document controls (FDA Quality System
  Regulation)(see http//www.access.gpo.gov/nara/cf
  r/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
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
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
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
  designPage 143input 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
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
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

DOORSserver(Europe)
DOORSmodule
DXL
DOORSserver(US)
with Name, e-mail, system login, permissions,
training status, version, DOORS account infos
to create / update users and to extract user
information (which users who edited)
16
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
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
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 Pauls demo)
• Electronic signatures (and thus also baselines
  -) in DOORSNet would be even greater!
• Problem long-term archival
• Processes / guidelines are important.

19
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
Software installations / upgrades

• Telelogics DOORS install is not perfect. You
  may need to develop your own installshield
  install guidelines from your requirements and
  test it

21
Software installations / upgrades

• Precise installation guidelines are important

22
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-gtfolder-gtproject-gtmodule-gtobjec
  t) to eMatrix translation is needed
• Handling of DOORS attributes
• Update of published information after
  update/deletion in DOORS

23
Summary / Questions
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
• Bernd_at_Grahlmann.net
• www.grahlmann.net
• 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
• Bernd_at_Grahlmann.net
• 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

• 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