English
Français
Deutsch
日本語Join us at a 2026 Aras Connect event near you!
Introduction
Medical device makers have to comply with multiple FDA and ISO regulations.
These regulations include CFR 21 Part 820, Part 11, as well as ISO 13485 and ISO 14971 for risk management and more. PLM can enable compliance with these regulations for record control, corrective and preventative actions (CAPA), design control with design history files (DHF), and material control.
This white paper focuses on the challenges regarding design control.
Goal of Design Control for the Medical Device Industry
The goal of medical device design control regulations is to prove you have designed a safe product that meets user needs while fulfilling each requirement.
The specific FDA regulations that detail design control are CFR 21 Part 820.30 and ISO 13485 section 7.3 Design and Development. Both expect documentation and records of design throughout the product development process.
Typical Medical Device Industry Practice
Because it is a regulatory requirement to have both DHF and device master records (DMR), the typical medical device design control industry practice is to “design and print”; do the design, then print to paper and store in a binder. Some “design and file”, meaning they store the electronic file in a file system or shared folder that is structured to look like a physical DHF binder.
Another common industry practice is to use spreadsheets to track and trace user needs, design inputs and outputs, along with verification and validation plans and results.
Frequently, the documents are printed, signed and scanned, and stored both electronically in file folder structures as well as physically in binders.
In all cases this is a manual process that is labor intensive and error prone. Even if the product is correct, having data that is incomplete or the wrong version can trigger problems with audits or delay go-to-market plans.
Medical Device Design Control Risk
Unfortunately, this is the landscape seen in many companies. File systems, spreadsheets and siloed point systems. The inefficiencies, data duplication, lack of traceability, and opportunities for error are clear. This provides an environment where design control is full of risk.
Design Control — DHF & DMR
The Aras Medical Device PLM solution can be used to reduce risk and improve design control.
The structures of the DHF and DMR are created as templates. Deliverables are defined for the device. The deliverables include documents, requirements, test specification, parts, BOMs, 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 a workflow status such as release, user actions, or phase/gate completions to name a few.
This allows the regulatory structures, such as the DHF and the DMR, to be created automatically as a result of users’ work. Design control data becomes a living structure, completely searchable and traceable across the entire product lifecycle. Baselines, complete DHF and DMR structures, are created automatically as a result of any change to a project or deliverable as well as a completion of a phase/gate.
Traceability Matrix
The traceability matrix included in Aras Medical Device is a unified view of the design control. It utilizes the Aras Innovator low-code platform and digital thread technology in an Excel-like format to map user needs, design inputs and outputs to their validation, and verification results.
One key differentiator to an Excel spreadsheet is the traceability matrix, which is a structured record with relationships to business objects. As these business objects change the traceability matrix can receive alerts and updates. For example, when a design input requirement changes, the change is highlighted in the traceability matrix, automatically notifying users to review the verification plans and design output.
Instead of managing requirements as one big Word or Excel document, Aras Medical Device manages each detailed requirement separately. This is important because requirements can come from many different sources. Requirements can also be classified by type and used for user needs and design inputs.
Below is a depiction of how the traceability matrix is modeled, as a structured document in the content modeling framework. A user need can have multiple design inputs represented as the requirements business object. A design input can have one or more design outputs where the output is represented as several different types of business objects. A typical design output can be parts or documents, but can also be a failure mode effects analysis (FMEA) or risk analysis. User needs, and design input can have one or more validation and verification plans respectively. The verification plans are represented by test specification business objects. A verification or validation plan can produce one or more results.
Conclusion
Companies are still exposed to a high degree of non-compliance when it comes to their medical device design controls. Many vendors claim to help the medical device industry come to grips with these challenges and provide a complete solution; however, there are still gaps that ultimately lead to manual processes, shadow systems, and undocumented procedures in order to bridge these gaps.
Aras, based on decades of experience in the industry and feedback from real-world customers, has created a PLM solution aimed to minimize these gaps. With Aras Medical Device we provide a comprehensive product lifecycle management solution targeted for medical device manufacturers and the challenges they face.
Aras Medical Device PLM software is a robust PLM solution with unique integration capabilities, providing the tools needed for a complete design control solution and more.