Document Hierarchy
Design Controls, Design Input, Design Output, Design Review, Design Validation, Design Verification, Project Document Hierarchy, QSR, Risk Analysis
The hierarchy of product documents during design a development project is not only a key factor in supporting traceability, but can also save a tremendous amount of time and money in product development.
The QSR requires at minimum, the following product document types to be created under Design Controls:
- Design Input
- Design Output
- Design Review
- Design Verification
- Design Validation
- Risk Analysis
Other documents are required under Design Controls, such as Design and Development Planning, Design Transfer, and Design Changes, but these are not generally part of the product document hierarchy.
I find it helpful to think of the product document hierarchy as a set of Parent:Child relationships, where in each relationship, one document (the Parent) is the source of requirements/specifications, and the other (the Child) is the recipient of those requirements/specifications. For example, a hardware specification may have a specification for maximum power consumption, and a hardware test procedure contain a test for maximum power consumption. In this case, the hardware specification is the Parent and the hardware test procedure is the Child.
So here’s what I’ve found extremely helpful in this area, to do near the beginning of a project:
- Decide what the main documents will be for the product you’re going to develop, including the required documents listed above
- Establish names for these documents
- Establish the Parent:Child relationships between all documents
- Create a diagram of the document hierarchy, much like an organizational chart for a company
Taking the time to decide what the main documents will be will not only support traceability, but will also save huge amounts of time (and money) trying to figure this out later (after several documents have been started or even finished).
I’ve found that establishing names for these documents allows everyone on the project to use common terminology that reduces the potential for confusion and errors. I find it helpful to write 2 or 3 sentences to describe the document and what it will contain (this will likely stay on as the Purpose and Scope sections of the eventual completed document).
Establishing the Parent:Child relationships between all documents allows everyone on the project to know which documents are “higher” (in the hierarchy) than others. This is the key to creating clear and straightforward traceability, with minimal (or no) convolution.
I find it helpful to create a diagram of the document hierarchy, much like an organizational chart for a company. It’s amazing how easy it is to visualize the organization of documents with a diagram. Creating the diagram helps clarify the Parent:Child relationships between all documents, and helps reveal convoluted relationships. Resolving these at the beginning prevents lots of problems later.
More Details on Document Hierarchy
As I’ve mentioned in previous Device Tips, it’s generally a good idea to incorporate all the design input into a single document, let’s say is called the Product Requirements and Specifications (PRS) document. This would include product requirements stemming from Regulatory Bodies (i.e. FDA), the Customer (i.e. Users and Patients), Compliance Standards (i.e. IEC 60601-1) and the Market (i.e. competitors). For a relatively simple product, the design output could be completely developed from the PRS, where each design output document is a child of the PRS. One could develop design verification documents that cover the design output, thus the design verification documents would be children of the design output documents. If the device includes software, Software Requirements Specifications (SRS), Software Design Specifications (SDS), and Software Validation documents would also be created. Since design validation needs to demonstrate that device specifications conform to user needs and intended use(s), the design validation documents would be children of the PRS. Risk analysis could include both a top-down analysis of risks associated with the use of the product (even in the absence of device failure), as well as risks associated with failures of individual components or subsystems of the product (Failure Modes Effects Analysis). In this case, the Risk Analysis would define mitigations that would become product requirements, to reduce residual risks to acceptable levels. Thus, the Risk Analysis is the Parent document and the PRS the Child. A diagram of this hierarchy is shown below.
In a more complex hierarchy, let’s say the Customer needs and expectations are documented in a Customer Requirements Document (CRD), and the Market/Competitive needs documented in a Marketing Requirements Document (MRD). Then, let’s say the input from the CRD and MRD, along with requirements stemming from Regulatory Bodies and Compliance Standards is incorporated into a single Product Requirements and Specifications (PRS).
Then, let’s say a Product Design Specification (PDS) is created that describes the overall product design, and describes the implementation modality (i.e. electronic hardware, software, mechanical, labeling, process) for each PRS requirement/specification. (As a side note, this type of document can be the overall most useful document to the development team, but sadly is often not ever written). Then let’s say a set of Electronic Hardware Specifications, Mechanical Specifications, Software Requirements Specifications (SRS), and a Labeling Specification are created that describe the specific design that achieves each assigned PDS specification.
From these documents would follow Electronic Hardware design(s), Mechanical design(s), Software Design Specifications (SDS), and Labeling design(s), all combining to form the Design Output. Likewise, Electronic Hardware design Verification, Mechanical design Verification, Software Verification and Labeling design Verification would be conducted, together comprising the Design Verification for the product.
A diagram of this hierarchy is shown below.
