Medical Device PLM – Design Control

Posted on August 24, 2016


Medical device makers have to comply with many FDA and ISO regulations.  These regulations include CFR Part 820, Part 11 as well as ISO 13485 and ISO 14971 for risk management. PLM can enable compliance to these regulations in the areas of Record Control, Corrective and preventative actions (CAPA), Design History Files (DHF) and Material Control.  This post focuses on the challenges regarding Design Control.

med device in field graphic

Goal of Design Control

The goal of design control regulations is to prove that you have designed a safe product and that it meets user needs and fulfils all the requirements. The specific FDA regulation that talks about design control is 21 CFR 820.30 and ISO 13485 section 7.3 Design and Development. Both expect documentation and records of design though-out the product development process.


Design Control uses some specific terminology of which I will cover here:

  • Intended Use – is the stated general purpose or function of the device.
  • Indications for use – is the stated disease or condition the device will diagnose, treat, prevent.  It is also good practice to state the unintended uses of the device.
  • User needs – are requirements from the users’ perspective, typically broad statements that are difficult to qualify and measure. They use works like easy, simple, friendly or better. For example: “the device must be easy and simple to operate. “ To get user needs questions like: How will the user or patient use the device, what is the use procedure, what is the device use environment and more.
  • Design Input – defines all the requirements, features and functions of the device. Unlike user needs, design input need to be objective and measurable. Some of the design inputs are typically derived from user needs. Design inputs don’t all need to be device specific since they can also come from regulations, industry standards and even market and competitive needs. When defining design inputs always keep in mind how you will verify them, since verification is an important step in design control.
  • Design Output – is a compilation of records containing the procedure and specifications for the finished device. In other words, it’s a recipe on how to build the device. This is also known as the Device Master Record (DMR). If you gave someone the device master record they should be able to build the device. The design output and DMR includes things like the bill or material, drawings of the parts and assemblies, instructions on how to assemble and build the device, standard operating procedures and much more.
  • Verification and Validation – Although they sound similar and are often misused, verifications relate to design input while validation typically relate to user needs. Regardless, they both need plans proving that the design input or user need is met. Careful consideration of how to validate and verify should be done as early as possible. The results of the validation and verification should be captured, stored and belong in the DHF.

Typical Industry Practice

Since it is a regulation to have a DHF and DMR the typical industry practice is to “design and print”, meaning do the design and then print to paper and store in a binder. Some “design and file” meaning that they store the file onto a electronic file system that is structured to look like a DHF binder. Other that use PLM’s systems create structured document records, mimicking a DHF binder and managing the files in the PLM document vault.

file cab

To keep track and traceability of the user needs, design inputs and outputs and their verification and validation plans along with the results a common industry practice is to use utilize Excel spreadsheet. In all cases this is a manual process that is very labor intensive and error prone. Even if the product is correct, having data that is incomplete or referencing a wrong version can trigger problems with audits.


Picture of Design Control Risk

Unfortunately, this is the landscape of many companies; file system, spreadsheet and silo systems. Anyone can very easily see the inefficiencies, data duplication, lack of traceability and opportunities for error. This is a picture of a design control full of risk.

chaos slide



Minerva’s Medical Device PLM running on Innovator can be used to reduce risk and improve design control. As part of a larger solution two elements are described here. The DHF/DMR and the Traceability Matrix. The structures of the DHF and DMR are created as a template. For a device all the deliverables are defined. The deliverables include things like documents, requirements, test specification, parts, Bom’s,etc. Each deliverable is then mapped to a location in the DHF and/or DMR along with a rule that states when that deliverable is complete. This can be based on workflow completion such as a release, user action or phase/gate completion. The combination of these two items allow the DHF and DMR to be created automatically as a result of users work. Baselines, complete DHF and DMR structures are created as a result of any change to a project or deliverable as well as a completion of a phase/gate.

Screen shot DHR-DMR

Traceability Matrix

The traceability matrix from Minerva is an unified view of the design control.  It utilizes Aras’ Content Modeling Framework (CMF) in an Excel like format to map the user needs, design inputs and outputs to their validation, verification results. The key differentiator to Excel spreadsheet is that the traceability matrix is a structured document with relationships to the Innovator business objects. As these business objects change the traceability matrix can receive alerts and updates. For example, when a requirement that is a design input changes, the change will be highlight in the traceability matrix notifying the users to review the verification plans and design output.

This is a summery of the DHF and DMR in the Medical Device solution. Template structures are created for the DHF and DMR. Deliverables and their corresponding closing rules as well as where they need to be placed in the DHF and DMR are created. A project is used to instantiated the deliverables and as work competes on the deliverables they are automatically placed in the DHF and DMR. When looking at the device product the DHF and DMR can be reviewed.

Instead of managing requirements as one big Word document Innovator can manage each detailed requirement separately. This is important since requirements can come from many different sources. Requirements can also be classified by type and can be used for user needs and design inputs.

traceability matrix screen shot

This is a depiction of how the traceability matrix is modeled as a structured document in the content modeling framework of Innovator. An user need can have many design inputs both of which are represented as the requirement business object of Innovator. A design input can have one or more design outputs where the output is represented as many different type of business objects. A typical design output will be a part, assembly or document but can also be FMEA or Risk Analysis. A user need and design input can have one or more validation and verification plans respectively. The verification plans are represented by test specifications business objects. A verification or validation plan can produce one or more results.

As always I’m interested in your experience and feedback.  If you would like to know more or would like a product demonstration contact Minerva at or me directly sjo(at)


Demo of Design Control – DHF and DMR

Demo of Design Control – Traceability Matrix

Download Aras Innovator