1. Regulations, Audits and DOORS
Dr. Bernd GRAHLMANN
+33 (0)

2. Please look at the ‘notes’ pages as they give additional information for this presentation !!!

3. 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)
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
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
Little poll: How many medical device industry? How many aircraft, military, …? How many notified bodies (FDA, FAA, …)?
Say: more directly for medical device, FDA, … but the rules are the same for FAA, …
Stress that FDA, FAA, can profit a lot from DOORS.

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
Give outline of the presentation.

5. Processes, procedures, guidelines
Engineering needs
Req mgt / valid / verif reqs
user level with valid wrt process / guidelines
ISO
user level
Req Mgt process
FDA reqs
ISO reqs
EQPM reqs
with pilot validation
DOORS guidelines
Give the top-level picture.
Start explaining the overall concept before going in some details on next slide.
EQPM = Engineering Quality Procedure Manual
ISO
FDA reqs
ISO reqs
EQPM reqs
user level with valid
DOORS user reqs
sys level with verif wrt DOORS guidelines

6. 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)
Present idea of Center of Excellence
Explain discussions around multi-tier (advantages, disadvantages, risks, position of engineering managers and project leaders versus responsible requirement management)
Aspect of multi-tier versus different levels
Be precise on ‘no DOORS commitment’
Details of ‘not wanted’ attributes (priority, status, owner, …)
Details of discussion on verification/validation results in DOORS (time estimations + large scale examples, automatized testing, present ‘web’ project, …)
Details of discussion on ‘up to which level’ (positions, system team, subsystem team, …)
Details of SRE template + its pilot validation

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, …):
Discuss backup as an example.
Requirements on different levels:
Possibility to backup and restore data, must reflect status at a given point in time, …
Yields lower-level detailed requirements / guidelines
Principal validation is important + regular tests
Restore of module, project, baseline, …
As always there are two aspects:
Convince yourselves, ensure that backup / restore works
2. Document, prove it.
Extraction from 21 CFR 820 (Quality System Regulation):
Sec General requirements.
Those records stored in automated data processing systems shall be backed up.[[Page 149]]
(b) Record retention period. All records required by this part shall be retained for a period of time equivalent to the design and expected life of the device, but in no case less than 2 years from the date of release for commercial distribution by the manufacturer.

8. 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
Traceability and in particular history of traceability are FDA, FAA, … requirements.
Give examples (link with verification results, links between subsystem and system requirements, …).
DOORS still has limitations (history of links, links and baselines, …).
Intelligent processes need to overcome those limitations (until DOORS improves).

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 => 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
Present discussions at GE Medical:
40 years (for safety), M9
Change/revision control (rational for changes must be kept)
Data integrity, impossible to change after approval
Electronic signatures later (DOORS 6.0 SR1 ??? – great step !!! - remains 40 years DOORS server maintenance problem ;-)
Type of approval must be identified (approval is linked with purpose of document)
eDOCs, eMatrix, print into PDF
Archive, backup (differences, limitations, efforts)
Heavy processes may overcome limitations
Protection issues
Money (licenses/availability) issues
Extraction from 21 CFR 820 (Quality System Regulation):
Document controls: (Quality System Regulation)
(a) Document approval and distribution. Each manufacturer shall designate an individual(s) to review for adequacy and approve prior to issuance all documents established to meet the requirements of this part. The approval, including the date and signature of the individual(s) approving the document, shall be documented. Documents established to meet the requirements of this part shall be available at all locations for which they are designated, used, or otherwise necessary, and all obsolete documents shall be promptly removed from all points of use or otherwise prevented from unintended use.
(b) Document changes. Changes to documents shall be reviewed and approved by an individual(s) in the same function or organization that performed the original review and approval, unless specifically designated otherwise. Approved changes shall be communicated to the appropriate personnel in a timely manner. 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.
You need to identify, validate, approve and then follow process !

10. Document control (approval / change)
Document controls: (FDA Quality System Regulation) (see
(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.
Give FDA 21 CFR (Code of Federal Regulations) Document control as example

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.
Highlight some of the FDA regulations (from the Quality system regulation = 21 CFR 820).
If time permits, explain some in detail.
Anyway: emphasize that you need guidelines, prove that they work (once for all ;-), enforce, document, …
820.3
(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.
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.

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.
Just if time permits: show some of the regulations from 21 CFR 820 (Quality System Regulation):

13. Some more extraction from FDA 21 CFR 820
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.
Just if time permits: show some of the regulations from 21 CFR 820 (Quality System Regulation):

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
If time permits go into some details of examples of problems.
What are the ones with direct relation to regulations (rev. history, approvals, rational for changes, was editor trained, have traceability … analyses been done, does the engineer know about baselining and archival, …)
Again: on the one hand this is a check to ensure good requirement management, on the other hand regulations enforce certain reviews, … => document reviews, …
Maybe cite some paragraphs of FDA regulations.

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
DOORS server (Europe)
DOORS module
DXL
DOORS server (US)
Training is a requirement (FDA, FAA, …) and your own interest.
You need training records.
You need to control (at least editing) access to DOORS.
DOORS user administration is tedious. Reference Joe’s paper. Maybe give my DXL scripts (creation of module with all users information from the DOORS DB + creation / update of DOORS user DB from such a DOORS module) to interested people.
Maybe present scripts to extract from DOORS DB which users have edited in the DB, in a project in certain modules. Highlight importance (for the company – because they don’t want un-trained users to mess up their requirements, and for FDA, FAA, … audits = easy check for FDA, FAA …).
Present some numbers for trainings done within GE Medical Systems in 2001 to give an idea.
Reference regulations from 21 CFR 820 (Quality System Regulation):
820.25: (b) Training. Each manufacturer shall establish procedures for identifying training needs and ensure that all personnel are trained to adequately perform their assigned responsibilities. Training shall be documented.
with: Name, , 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
If time permits: Show template example
If time permits: Show guideline example

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.
If time permits: show traceability on-line.
Explain that this ensures that the training covers everything which is necessary, not more, and that for each feature the relevant tasks are cited from the guidelines.
Same is possible for expert level trainings, …

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 Paul’s demo)
Electronic signatures (and thus also ‘baselines’ ;-) in DOORSNet would be even greater!
Problem: long-term archival …
Processes / guidelines are important.
Ideas:
Start: with DOORS 6.0 SR1 everything may get real better 
Talk about status DOORS 5.x
Present importance of process/guideline.
Present some of the most important 21 CFR 11 requirements.
Talk about long-term requirements (maintain DOORS server for 40 years, …).
Stress advantages, opportunities! Not having electronic signatures let’s plenty of people give up altogether on DOORS.
Mention importance of electronic signatures in DOORSNet (for managers) => baselines visible in DOORSNet ;-)

19. Software installations / upgrades
DOORS upgrades are cumbersome:
Clients and multiple servers may have to be upgraded simultaneously:
DOORS 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)
Explain a bit what that means by giving the GE Medical example (different poles, different Windows versions, different languages, different installed DOORS versions, more than 1000 client installations, users are no computer experts, …)
Highlight opportunities of new Citrix compliance 

20. 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:
Discuss installshield details (limitations, issues, …)
Present requirements for installshield (if time permits show module with requirements)
Present test plan for installshield client install (if time permits show module with tests + results)

21. Software installations / upgrades
Precise installation guidelines are important:
Explain importance of guidelines and their testing.
Show at least parts of the install guideline as example (if time permits show web page).

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->folder->project->module->object) to eMatrix translation is needed
Handling of DOORS attributes
Update of published information after update/deletion in DOORS
Reference MatrixOne and vdR group.
Stress the huge opportunities.
Stress complications by the interplay of different disciplines.
Make sure that people understand the consequences resulting from regulations, auditing environment, …

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:
+33 (0)
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:
+33 (0)
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
Highlight that FDA, FAA are just asking for things that are in our interest.
Better should only ask for those things.
Bring a bit skeptical remark on ‘being to demanding = everything needs to be 150%’ may result in ‘hindering the progress’
Thanks + questions.