ODDSCO's FDA 21 CFR 820.30 QSR Design Controls Introductory Tutorial


An introductory tutorial about US FDA 21 CRF PART 820 QSR (CGMP) Subpart C – Design Controls, from the practitioner's perspective.

Abstract. This introductory tutorial goes beyond explaining Design Controls within the Quality System Regulation (QSR) by outlining low cost, integrated product/process team (IPPT) methods to attain and maintain auditable compliance with its ten provisions while producing quality products to minimized schedules for new projects. (The general IPPT approach is described in the second ODDSCO tutorial in this set.) When the tutorial text is set off with double quote marks, it is a direct quotation from the Design Controls subpart of the QSR. When text is placed in brackets [like this], it is this Author's synopsis of the much lengthier QSR text.

Ongoing projects to design and manufacture complex embedded systems medical devices involve many employees. Obviously, Project Management and project team members from Engineering must be familiar with QSR design controls. Manufacturing, Purchasing, Field Service, Quality Assurance, Regulatory Affairs, Document Control, and Human Relations employees also perform tasks that must be compliant with the QSR provisions for Design Controls. Accordingly, understanding of Design Controls also must be relatively widespread throughout a medical device development organization.

At the end of this tutorial is your opportunity to pose question(s) on this subject to the Author.


QSR Subpart C—Sec. 820.30 Design Controls

TABLE OF CONTENTS (Return Links)

Return to Home Page [Use a Return Link after any of the listed subsections to quickly reach this option.]


(a) General.

(a) General (1) states, “Each manufacturer of any ... class III or class II device ... shall establish and maintain procedures to control the design of the device ... to ensure that specified design requirements are met.”

Typically, each medical device manufacturer provides Procedures and Instructions (P&Is) intended to ensure that work performed to develop their products is auditably compliant with the associated provisions of the QSR. Further, the P&Is must be maintained for continued correspondence to evolving and improving work processes. An IPPT approach is recommended for planning and controlling P&Is maintenance as well as for accomplishing new product development projects as described in the remainder of this training segment.

Nearly all of the remaining subsections (b) through (i) open with the requirement “Each manufacturer shall establish and maintain [plans or procedures to or for] ... [accomplishing provisions of that subsection].” The last subsection (j) requires a Design History File (DHF) as the formal record of accomplishing subsections (b) through (i).]

Return to Table of Contents


(b) Design and development planning.

Auditably Compliant Design Project Planning

The purpose of a Project Management Plan (PMP) is to “describe or reference the design and development activities and define responsibility for implementation”. The PMP is defined to encompass the scope, scale, and complexity of the project. “The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process.” The PMP sets forth the project milestones sequencing of most project documents. The PMP must be reviewed and approved (and updated with fresh approval when the project must be revised).

Scope and scale of design and implementation tasks can range from extremely simple to relatively complex. Accordingly, the PMP document design must support planning for conceptual worst case new or upgrade projects while avoiding inappropriate documentation burdens for intermediate to small projects. An IPPT solution is based on two powerful methods for managing project documentation:

1. Provide standardized, integrated templates for every project document type. That is, develop an outline for each document that can encompass the perceived worst case project need for its content while minimizing the information overlap with the other project documents. Further, provide instructions for general and specific content in the predefined sections and subsections of the outline.

2. Provide for tailoring the documents to evaluated scope and scale of the project, beginning with provision for a tailoring plan in the PMP document template. When tailoring is approved, the PMP contains instructions that enable it and the associated project documents to have their planned content reduced to match the need.

The PMP instructions for tailoring of each template enables the authors and document reviewers to ‘know’ the minimum information required for completing each project document and where therein to put it. This early knowledge of required deliverables content assists developing initial budget and schedule estimates that correlate well with intent of the approved project plan. Tailoring instructions must be specified with unambiguous clarity such that project plan fulfillment remains auditable.

Medical Device Manufacturers that understand and apply classical Systems Engineering have someone from that specialty develop most of the PMP and specific tailoring for the Project Manager. However, many (if not most) medical device manufacturers understnd that specialty function label as equivalent to engineering systems (which is what all good engineers in the ‘core competencies’ of electrical, mechanical, and software engineering automatically do as part of their jobs). Accordingly, see the also free seventh tutorial mentioned with the Tutorial Two link on the Home Page to learn the important differences.

Return to Table of Contents


(c) Design input.

Design input is defined in QSR 820.30 as “physical and performance requirements of a device that are used as the basis for a device design.” Design input therefore ranges from elicited customer inputs to requirements for addressing “the intended use of the device, including needs of the user and patient” to at least the top level software and hardware requirements specifications that drive detailed design. Further, “procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements.” [‘Intended use’ also is the statement of purpose and function, target patient population, intended environment of use, and medical safety and effectiveness claims for a device, as it is provided in the 510(k) premarket notifications to the FDA.]

Marketing surveys, Medical department clarification and User studies, predicate or competitor device features, Quality Function Deployment (with ‘House of Quality’) and other sources, if any, may be used to determine a set of economically prioritized customer needs and wants as inputs. These customer inputs to the medical device requirements are recorded for reference during project decision-making. A convenient label in this tutorial for this record of the customer inputs is Customer Requirements Document (CRD).

A highest level system specification sets forth selected customer inputs as development project functional, performance, and design qualification requirements in general engineering terms. The label used in this tutorial for that system specification is Product Requirements Document (PRD). To fulfill the QSR provisions for design controls, the CRD inputs to the PRD must be addressed formally. This does not mean that each CRD input becomes a system requirement for immediate project development. Addressing the specific customer inputs can be by notation of deferral or partial or optional implementation. The PRD requirements are derived into system level Hardware Requirements Specification(s) (HRS) as mechanical and electrical devices functional, performance, and design qualification requirements. Similarly, the PRD provides design inputs to the system level Software Requirements Specification(s) (SRS). The PRD and each HRS and SRS “shall be reviewed and approved by a designated individual(s). ... [and] documented.”

‘Requirements rule’ could be a suitable slogan for medical device development projects. The Requirements Management methods are a means to produce the auditable design inputs/outputs records that show compliance with the QSR provisions for Design Controls. Requirements are the formal means to describe a device or its software such that any competent entity could be contracted to design and develop it. A requirement in a specification is a natural language statement that sets forth a mandatory characteristic or functional behavior to be provided by the developed product or process. In fact, unambiguous and verifiable requirements become the single recipe that development teams are to follow for design, manufacture, and ‘testing’ of a specified item.

A requirement statement is correct and complete when it fully responds to its design input and is verifiable by one or more of the following methods: instrumented test, demonstration, inspection, and/or analysis. One method for writing such requirements text is consistently using a predefined standard sentence structure along with applying some simple rules for their wording.

PRD requirements translate customer input functions/performance into engineering terms as design input for development of the project deliverables by the hardware and software design teams. Requirements for functions and performance to be provided by the project output state what is needed and how well it must work. That is, except in limited situations, requirements do not specify how to fulfill the function. The PRD also lists various company and external (domestic and international) medical device safety standards and other design qualification criteria to which the design output often must be in accord. (Even when the standards are not mandatory for enabling foreign sales of the medical devices, it is often prudent to use them for design guidance.) Other features (the ‘...ilities’) may be required for qualification of the device design. Some common examples are Availability (Reliability and Maintainability), Feasibility (technological, economic, socio-political), Adaptability (future use), Producibility, Supportability, Usability (ergonomic suitability), Disposability, and Vulnerability/Survivability (harsh use).

In the simplest projects of small scope and scale, as defined by the PMP tailoring, the PRD can be combined with the CRD.

Most PRD requirements are allocated/derived into subsidiary system level hardware and software requirements specifications (HRS and SRS) based on functional subsystems of the conceptual system architectures. When a system is relatively complex, each major subsystem may have its separate HRS and SRS. Each system level hardware and software requirement results from deriving one or more portions of source PRD functional and performance requirement into their separate electrical, mechanical, and/or software requirements. Emphasizing the general rule, HRS and SRS requirements state what the system hardware and software must do but almost never how to do it. (The exception is that implementation can be specified in a system level requirement when interface with a preexisting or predefined separate system (that may be a specific user) is necessary.)

Unambiguous and verifiable requirements are the single recipe that development team members follow for design, manufacture, and ‘testing’ of the specified item, so they should be accurate as well as comprehensive. Finally, each requirement should specify a single function (or be the parent requirement to only closely affiliated functions). When well written, the requirements can describe a product such that its design and manufacture could be outsourced. Here, text stating a function to be fulfilled (and/or how well it must be done) is necessary but may not be sufficient to form a valid system requirement. Until fulfillment of a requirement statement may be unambiguously confirmed for a developed product or process (via one or more of test, demonstration, inspection, or analysis), it is not valid for use and must be rewritten.

Auditable evidence of compliance with the FDA Quality System Regulation provisions for design controls must be produced during every medical device development project. Requirements Management is a name for the set of activities that result in such evidence by providing trace from the PRD requirements (as selected customer inputs) to their validation. That traceability is provided by a project Requirements Verification/Validation Trace Matrix/Report (RVTM). Each PRD requirement related to some selected design qualification items (such as accelerated life testing, extreme environmental conditions, or electromagnetic compatibility) may be traced directly to a general validation procedure. Each PRD requirement that is to be implemented by hardware and/or software is traced to its derived requirement(s).

Because it displays the complete text as well as an identifier for each requirement, an RVTM enables inspecting each subsidiary hardware and software requirement for correct and complete response to its driving PRD requirement (and thereby is a “mechanism for addressing incomplete, ambiguous, or conflicting requirements”).

Each derived requirement also is traced to its formal verification procedure/test case, thus indicating where its driving PRD requirement is indirectly validated. Listing requirements being verified or validated in each cited procedure ultimately completes the tracing. Summary reports of verification and validation procedures performance cite their results as objective evidence of the requirements fulfillment.

Thus, a comprehensive RVTM provides each medical device development project with its ‘roadmap’ to the auditable evidence for proving design controls compliance.

Below that system requirement level, the design engineers provide implementation, design, test, and manufacturing ‘requirements’ that describe how the HRS or SRS requirements are to be fulfilled. In simple, small scope and scale projects, design or implementation detail may be included in an HRS or SRS using a lower paragraph header level than the driving system level requirements (for automatic tracing) or in a separate document section. Separate documents for this application are the Hardware or Software Design Descriptions (HDD or SDD). The design engineers determine what is needed for subsystems and components functions and performance and begin to develop the detailed drawings, schematics, and software modules for the described solutions. Where a complex or complicated firmware or software algorithm must be elaborated, a detailed design description (DDD) may be developed as a separate document referenced by the HDD or SDD. Verification of these lower level ‘requirements’ is informal (regardless of rigor) and is performed by the assigned design specialists (or their peers, when independence is desired).

As the PRD is developed, the project team develops a preliminary system concept architecture diagram with major subsystem blocks that show internal and external interconnections. This concept architecture is revised during derivation of system level requirements into the various system and/or subsystem specifications (HRS and SRS). With the system functions becoming well known, a Preliminary Hazard Analysis (PHA) is begun as the required first element in the project Risk Analysis portion of the design validation. Previous hazard analyses are a source of potentially applicable hazards for the new projects. The Hazard Analysis can be made partially compliant with ISO 14971, Medical Devices – Application of Risk Management to Medical Devices, by matching its hazard catalog organization. Further, with a minor change to the traditional project Hazard Analysis, the RVTM also can trace to the evidence of actual risk reduction for an initially unacceptable assessed hazard risk level. Simply append a citation of the PRD requirement that will be allocated into the HRS or SRS requirement that drives implementation of the proposed hazard risk level abatement action. Include a citation in the RVTM that identifies the hazard being abated (by the allocated HRD or SRS requirement for that PRD requirement. Because the RVTM shows trace to the test step(s) in the verification procedure for that HRS or SRS requirement, the evidence for each such hazard risk level reduction will be provided in the report of the procedure results.

However, for each identified hazard with residual risk (unacceptable risk level still existing after all reasonably practicable abatements have been required and implemented), ISO 14971 also requires the responsible executive management to affirm that benefit of device use for patient treatment exceeds the assessed risk (to take reaponsibility for such residual risk). Citation of this affirmation should be an annotation to each such hazard in the PHA to enable its release by document control.

Another top-down document, that may be developed in parallel with the PHA, is a Fault Tree Analysis (FTA) that begins with an Event of Serious Injury or Death for a patient or user and defines the categories of equipment or process (or human action) faults that could result in that top Event as logical OR gate inputs. The use described here is not traditional, with lack of fault probability estimates, but is very useful for evaluating and refining a concept architecture, as follows:

Each category is subdivided into the multiple faults that could lead to an event in that category. The subdivision of faults continues until one of two conditions is met.

1. Each subsystem or component fault is input to a logical AND gate along with an associated crosschecking process or component (that also must fail, to enable passage of the fault event to the point of causing the defined harm).

2. The fault is a single point failure item that must have adequate reliability for supporting intended use of the device over its projected lifetime (plus some prudent margin).

With subsystems implementation well defined, each is subjected to the bottom-up Failure Mode and Effects Analysis (FMEA) evaluation as the last element of the project Risk Analysis portion of its design validation. Each FTA identified single point failure must be included in an FMEA. Because FMEA is based upon a nearly completed design, likelihood of including the corrective actions stated for abating an unacceptable assessed risk level is high. Requiring citation of the drawing or software component (and engineering change notice for any retrofit) implementing that design correction within the FMEA helps to enforce its occurence.

As a design is further refined for the hardware, design specialists translate subsystem concepts into mechanical drawings and electrical schematics. When design and fabrication require specialty firms, procurement specifications are developed. Because commercial off-the-shelf (COTS) components with second sources are preferred, selection of these items is made. The electrical documents include interconnect diagrams, electrical crate and/or rack diagrams indicating individual chassis locations, cables drawings, and the Interface Control Document (ICD), as well as new design schematics. The implementation requirements in the HRS are updated to describe the developing design, so they can become theory of operation descriptions to accompany the drawings and schematics in the system service manual.

Return to Table of Contents


(d) Design output.

The definition for Design output in QSR 820.30 is “the results of a design effort at each phase and at the end of the total design effort. The finished design output is the basis for the device master record. The total finished design output consists of the device, its packaging and labeling, and the device master record.” Despite the association with the early development and the design review(s) implied by “each phase” in the first sentence of the definition, this subsection emphasizes a finished device: “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.”

In keeping with the definition for design output in QSR 820.30, many design inputs are outputs from previous stages in the “total design effort” and their use is further described in (e) Design review. Along with the device, total finished design output includes the device master record (DMR) that is associated closely with this subsection. Briefly, the DMR contains all the information that would be necessary to duplicate the device in its delivered configuration. QSR 820.181 states: “The DMR for each type of device shall include, or refer to the location of, the following information:
(a) Device specifications including appropriate drawings ... component specifications, and software specifications;
(b) Production process specifications including the appropriate equipment specifications, production methods, production procedures, and production environment specifications;
(c) Quality assurance procedures and specifications including acceptance criteria and the quality assurance equipment to be used;
(d) Packaging and labeling specifications, including methods and processes used; and
(e) Installation, maintenance, and servicing procedures and methods.”

As described in QSR 820.130, “packaging and shipping containers are ... to protect the device from alteration or damage ...” Labeling extends beyond the ordinary meaning for identifiers and warnings affixed to equipment and packaging to include Service Manuals and User/Operating Manuals because they are the means to ensure that the device will be “safe and effective” each time it is used.

Successful progression through each stage of device development requires applying the complementary process described next:

Return to Table of Contents


(e) Design review.

The definition for Design review in QSR 820.30 is “a documented, comprehensive, systematic evaluation of a design to evaluate adequacy of the design requirements, to evaluate the capability of the design to meet these requirements, and to identify problems.”

The output of each phase of the device development is subject to extensive design review procedures as defined in an associated instruction. A System Requirements Review (SRR) ensures that the PRD responds to the CRD outputs for the customer inputs to requirements that were accepted for implementing. The initial concept architectures, Preliminary Hazard Analysis and Preliminary Fault Tree Analysis may be included in the SRR.

The Preliminary Design Review (PDR) ensures that each HRS and SRS responds to the PRD outputs as its inputs. The Preliminary Hazard Analysis identifies the PRD requirements that ultimately are to drive implementation of means to abate previously unacceptable risk levels. Further, the Requirements Verification/Validation Trace Matrix/Report (RVTM) cites the risk analysis items being addressed. Systems Engineering or Quality Assurance teams can make initial assignment of the planned verification method(s) for the permutations for each requirement as instrumented test (T), demonstration (D), inspection (I), or analysis (A). (This method enables inclusion of the verification plan in the Project Management Plan and precludes development of a detailed verification specification that is named as the verificayion plan and duplicates work to develop the verification procedure. (Keep plans simple!)

Following the PDR, the hardware and software engineers begin developing designs intended to fulfill the HRS and SRS requirements for subsystems. Often, hardware and software design ‘requirements’ in separate subsidiary design descriptions (HDD or SDD) detail how the design is to be implemented. If care is taken to retain their subordinate status to the formal requirements, which prevents their mandated inclusion in the formal verification procedures, implementation descriptions may be included in the HRS and SRS instead of in separate HDD or SRS documents. Detailed drawings, schematics, and software module definitions then are developed by the mechanical, electrical and software design specialists. Systems Engineering or Quality Assurance teams begin development of the formal requirements verification procedures as initially defined by the verification plan assignments in the RVTM.

A Critical Design Review (CDR) ensures that proposed physical incarnation of the hardware design(s) along with the installed software will fulfill the HRS and SRS functional and performance requirements. Components are defined in preparation for their procurement.

A Production Readiness Review (PRR) ensures that the designs are suited for manufacture or purchase or issuance of a contract to an approved developer or supplier. User and Service Manuals are developed from the design information as part of the labeling.

Each document that is produced as part of the design output is reviewed by project team members and corrected until designated signatories approve its inclusion in the Document Control System as a formally released item.

The RVTM, developed throughout the stages of the device development, maps HRS and SRS requirements allocation/derivation from the PRD requirements and on to steps in their verification procedures. The easily accessed trace assists design engineers in ensuring correct design output results from the design input; that the implemented device will fulfill its functional and performance requirements (and hazard risk level abatements) when installed, reducing quantity and scope of the PDR and CDR Action Items.

Return to Table of Contents


(f) Design verification.

The definition for Verification in QSR 820.30 is “confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.” It is confirmation that the device was correctly built (that it is in conformance with its requirements). Design verification is complete when fulfillment of every permutation (meaningfully different use) of each derived HRS and SRS requirement has been confirmed by performance of the verifying procedure(s) and the captured results are reported. The verification procedures, results, and reports “shall be reviewed and approved by designated individuals.”

Along with the mapping from each HRS and SRS requirement to its subsequent verification procedure step(s), the RVTM identified the verification means to be employed in that procedure as one or more of: instrumented test, demonstration, inspection, or analysis. The thorough RVTM trace mapping assists System Engineering (or QA) and design engineers in developing formal verification and informal test cases to confirm (or deny) that an implemented subsystem will fulfill its functional and performance requirements as set forth in the HRS(s) and SRS(s). When the identified Verification Procedures are near release, the RVTM is updated to indicate the location therein (step) of each test case for verifying each requirement (and accompanying hazard risk level resuction).

Each Verification Procedure identified in the RVTM references its Verification Report as a sibling document. Each Verification Report has one-to-one section header correspondence with the test cases in its sibling Verification Procedure. Thus, the hazard requiring assessed risk level abatement in the Hazard Analysis can be traced to confirmation of its implementation via the RVTM. This approach to documenting verification provides trace to the auditable proof of compliance with Risk Analysis as well as with the Requirements Management aspects of QSR provisions for design controls.

Return to Table of Contents


(g) Design validation.

The definition for Design validation in QSR 820.30 is “establishing by objective evidence that device specifications conform with user needs and intended use(s).” It is confirmation that the correct medical device was built; that it will fulfill customer clinical and user requirements as fielded.

Functional and performance requirements in the PRD are derived from customer inputs to requirements (the CRD). Because most are further derived into system level requirements in the HRS and SRS documents and then into implementation and design requirements, their verification is the vast majority of the validation process. The remainder of validation involves confirming fulfillment of system design qualification requirements that cannot be measured with simple, one-time checks because cumulative assessments must be developed. Examples are deliberate use of erroneous inputs to user interfaces, accelerated life or use tests, electromagnetic compatibility testing, environmental stress screening, conformance to boyh domestic and international standards, and other such means to determine system suitability for its intended use(s). For lengthy predicted device use periods and other areas where test, demonstration, and inspection are less than directly applicable, analysis becomes the only practical validation method.

Along with mapping from each PRD requirement not derived into any subsidiary hardware or software requirement to its assigned validation procedure, the RVTM identifies validation means to be employed in that procedure. As for verification, the means is one or more of instrumented test, demonstration, inspection, or analysis assigned to each requirement. The RVTM trace assists Systems (or QA) Engineers in developing formal validation test cases that confirm (or deny) that the implemented and installed system fulfills its system design qualification requirements. The RVTM indicates location in Validation Procedures of each test case for validating each permutation of the associated top level requirement. Each project unique Validation Procedure references its Report as a sibling document. Because Validation Procedures often are broadly conceived standards common to all projects, the references to their project unique Validation Reports may accompany identification of such procedures in the RVTM. A hazard or fault requiring risk level abatement in the Hazard Analysis or FMEA may be traced in the RVTM to confirmation of its implementation via a directly validated design qualification requirement. This approach to validation documentation provides more trace to the auditable proof of compliance with the applicable QSR provisions for design controls.

Return to Table of Contents


(h) Design transfer.

Here, emphasis is on ensuring “that the device design is correctly translated into production specifications.” Depth and breadth of each translation depends entirely on which permutation of a make or buy decision applies to the system, subsystem, or component to be produced. Some of the device design may be contracted to an external entity that will do or arrange for the item fabrication and supply the design drawings and schematics in accordance with company standards for inclusion in a Device Master Record (DMR).

QSR 820.30 definition for the DMR is “a compilation of records containing the procedures and specifications for a finished device.” The DMR contents detail is provided in QSR 820.181 and listed above in (d) Design output. Repeating earlier mention, the DMR is a collection of all that it would take to precisely duplicate the product.

A recommended approach for the design transfer process is to go beyond ensuring auditable compliance by including Manufacturing Engineering early in the design process such that ease of fabrication and assembly join maintainability to become a concern of embedded systems hardware design specialists. Benefits may also apply to external producers and be realized as cost bid reductions.

Return to Table of Contents


(i) Design changes.

No substantive device design project will proceed from customer inputs through production and validation without at least minor design changes. Because they are likely to affect the finished device, a manufacturer must provide “procedures for the identification, documentation, validation, or where appropriate verification, review, and approval of design changes before their implementation.” All released documentation that must be revised due to the design change must be reviewed by their identified signatories and approved.

Whenever a requirement above implementation level is known to be (or might be) affected, the described RVTM becomes invaluable. Locating that requirement enables determining if one or more driving or responding requirement(s) also must be revised. Further, need for evaluation of effect upon implementation necessary to reduce the assessed risk level for an FMEA fault or Hazard Analysis item is plainly indicated. The Requirements Management and attention to Risk are maintained, as is auditable proof of compliance with the QSR provisions for design controls.

Return to Table of Contents


(j) Design history file.

The definition for Design History File in QSR 820.30 is “a compilation of records which describes the design history of a finished device.” This subsection of QSR provisions for design controls states that “The DHF shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part.”

Because “this part” means the entire QSR, work requested of and decisions made (by virtually anyone) that impact development and production of a medical device throughout the project are pertinent for such capture and retention in the DHF. This can affect any employee, as well as members of a project team and management representatives. Regardless, this provision highlights the value of clear minutes of meetings, especially regarding decisions and action items in wording that can be understood by those persons not in attendance or not extremely familiar with the topics.

Registered laboratory notebooks are basically an extension of the DHF. FDA Design Control Guidance (March 1997) states, “Design and development contracts should explicitly specify the manufacturer’s right to design information and establish standards for form and content of the design documentation.”

With pervasive use of email for company communications, maximizing automatic capture of project decisions and action items is enabled by establishing one company network email DHF alias with controlled team member access for each development project and instruction in the appropriate use by persons accomplishing any work on that project. The traditional Memo to File is simplified in its execution and vastly improved for project-wide team members notification.

When a company-wide electronic document management system exists, each project document can be put through a formal revision (check, review, and release) procedure and the latest version made available to all with access priveleges. Each project/product DHF then can be a spreadsheet with hyperlinked list of files for the documents produced during each phase of the development project. Listing the project produced risk analysis related documentation (including the formal requirements verification procedures and reports that together confirm implementation of hazard risk level abatement actions) constitutes much of the ISO 14971 required Risk Management File. (The missing part is the QA/RA maintained file for the post-production device records as well as hyperlinked list pointers to the project DHF spreadsheet files.)

Return to Table of Contents


IPPT Design Controls Compliance Tools

The IPPT related toolset providing the greatest increase in effectiveness and efficiency of device development project teams is comprehensive, integrated document templates that standardize their content and interrelationships. The earlier named project documents may be built from a document template base. Because the document templates are more than predefined outline formats of the named document types, authors are assisted in the rapid creation of new documents that are automatically compliant with Design Controls provisions of the QSR:

The Project Management Plan template provides detailed instructions for tailoring the project work to a reduced scope and scale as well as for providing the worst case of full-scale project plan content. A multi-use document template related to Requirements Management (Requirements Specifications) contains the detailed instructions, in early (sub)sections, which guide providing project information at an appropriate breadth and depth for the PRD and HRS/SRS (with inclusion of the HDD/SDD implementation/design ‘requirements’ when desired). The instructions show the formal specification language sentence structure along with requirements writing rules. Templates for ancillary documents also instruct providing the records necessary for fulfillment of internal, customer, and regulatory objectives beyond required QSR compliance, such as showing adherence to specified documentation standards. Thus, even initial draft versions of the work products provide auditable Design Controls compliance support for the project.

Predefined content descriptions help ensure that everything will be in its expected location, so project team members can learn quickly where information of interest should be placed. This standardization is especially helpful when upgrading poorly documented legacy systems that require extensive reverse engineering and capture of widely distributed and untraced requirements information.

Assisting Quality Assurance, detailed guidance in document templates describing what information belongs therein enables all reviewers to evaluate likely adequacy of provided content — even when it is outside their domains of expertise.

The integrated set of document templates relatively automate the 510(k) submittal package preparation and greatly helps estimating how much time will be required for development and review of each project document for project planning. Because documents preparation from instructions will be much closer to right the first time, the design information is available sooner and (when based on experience with developing similar documents) fewer of the project schedule estimates will be greatly exceeded.

Traditional status tracking, when using an earned value method for project management, is to assign a percent complete value for association with the hours expended relative to the hours bid for the task. For documents, an arbitrary percent complete is assigned to developing each of the initial outline format, the first draft completion proportion, the first submittal for general team review, and to the final release review. Estimates of percent complete for each document development task are improved with templates guidance for content. Alone, the stated benefits of document templates argue well for their adaptation and adoption wherever they can be applied.

But what is percent complete status of an overall project, with respect to Requirements Management (or end to end development phases) as represented by documents development? A previously unmentioned benefit of a spreadsheet based RVTM is accurate percent complete status metrics that can be based on actual task accomplishments for each requirement in the documents.

Commercial requirements management tools import requirements from specification documents into a database program and assign a project unique identifier (PUI) to each requirement. Attachment to the specifications is maintained by some of the tools, such that revision to requirements may be made in database program or the specification. Requirements in one document are assigned PUI to PUI linkages to requirements in other documents to establish source driver and responder relationships. For example, information necessary to output an RVTM can be imported or installed in the requirements management tool database. The steps are: Prepare appropriate documents for their importing, using rules that apply specific level(s) of paragraph header hierarchy to be part of the PUI, assign needed attribute/types, and assign the PUI code for each document (not document type).

A major feature of requirements management tools is that revision to a requirement produces automatic notification of which other requirement(s) possibly are affected (based on their PUIs linking).

Support for custom reports, such as an RVTM, is provided by most requirements management tools. The provided support ranges from fairly intuitive format layout and selection of sorting and inclusion/exclusion rules for populating the report to the next level up from pure programming of another utility to access the database.

Return to Table of Contents


This tutorial is presented by:

The ODDSCO Co. Logo<br> (A stylized duck).<br>

Optants Documented Decision Support Co.
(ODDSCO)
297 Casitas Bulevar
Los Gatos, CA 95032-1119
(408) 379-6448 FAX: (Same, by arrangement)



www.optants.com


E-mail:
Tutorial Author: jonesjh@optants.com
Other subjects: consult@optants.com