Descriptions in this article are provided to Qualio customers to assist with understanding. |
One of the most important things a medical device company can do to help bring products to market quickly is to stay organized. If your team isn't organized, you risk hurting product quality, not passing an audit and slowing production of the product(s). Design Controls and Proper documentation is vital to the organization, and, during the product design phase, that means creating and maintaining your Design History File (DHF).
Design Controls – What are they?
A set of quality practices and procedures to control the design process and to ensure that the device meets:
User needs
Intended uses
Specified requirements
Taking necessary actions during the Design Controls can improve and prevent future issues.
What is a Design History File?
A Design History File is a record of all the actions and steps involved in designing a medical device. The documentation that comes out of design control procedures is collectively called the “Design History File” or DHF.
What should be in a Design History File?
For a DHF to be comprehensive, there are certain components that must be included. These are:
Design Plan
A Design Plan is an overview for the medical device design and product development that outlines all activities necessary to conceptualize and create the proposed product. The Design Plan will specify details like who is responsible for implementing each step and the order of implementation. Additionally, the Design Plan will describe how the responsible parties will interact throughout the design process and when they will meet.
User Needs
User needs refers to the parameters a user needs for a device to be successful in the market. User needs can come from end users, regulators, and manufacturers’ desires. Typically user needs are more broad and the specifics feed into the design inputs. For example, a User Need could be “designed for use in pediatrics.” To meet that User Need, the manufacturer will develop a series of design inputs that will make the user need “pediatric use” possible.
Design Inputs
Design inputs are specific physical requirements for the device. The DHF must include documentation that lists all of the design inputs. Design inputs are developed from user needs and the intended use of the device. In the pediatric example, design inputs to meet the user need for pediatric use could include specifications for a smaller patient, color choices to make the device more appealing to children, or weigh less than 3 pounds to be easily held by children.
Design Outputs
The outcome of a Design Input is the Design Output. In the pediatric example, a Design Output from the Design Input to make a lighter design could be to utilize plastic components. The Design Output would be all the components that are plastic to help ensure the device remains lightweight. The design outputs tell the story of how to make the device. Eventually the design outputs become the basis for the Device Master Record (DMR). The DMR is used to transition the device to a manufacturing floor..
Design Review
Throughout the design process, a group of cross-functional stakeholders will need to meet to review the DHF. These meetings are called design reviews. They must be documented with minutes recorded. In this meeting, the stakeholders will review the design and make a decision about moving forward with the development of the product. The decision must be documented as part of the DHF.
Design Verification
Design verification refers to all testing done to ensure that the design outputs meet the design inputs. All parameters identified in the design inputs must be tested to ensure they are met by the design outputs. In the pediatric example, the design verification might be a test that weighs the pediatric device. The acceptance criteria could be “the product must weigh less than 3 pounds.” The design is verified if all design inputs are met by the design outputs. The technician who performs the testing must document when the testing was performed, what methods were used, and the results.
Design Validation
Design validation refers to all testing done to ensure the user needs are met by the final finished medical device. This type of testing will prove that the intended use is appropriate and there is a clinical use for the device. In the pediatric example, the design validation would test whether the device can be used for pediatric patients. Design validation is often animal testing or human clinical trials.
Design Transfer
Design transfer outlines how the designed device is translated into production specifications. Some manufacturers use a design transfer checklist to ensure they’re capturing all steps for design transfer to production.
Design Changes
Medical devices iterate and change throughout their lifecycle. The FDA and other regulators are aware and recognize that medical devices will go through changes. All design changes must be documented using a design change process and documented the rationale for the change.
Design History Files for Software in Medical Devices
The FDA recognizes that software in medical devices and as a medical device (such as firmware controlling a device, standalone software applications, and software installed on a computer) cannot always follow the traditional medical device regulatory pathways and DHF structure.
For software in medical devices and as a medical device, DHF documentation will need to include the following:
Level of Concern
Level of concern is an FDA term that defines the risk associated with the software. There are three levels of concern: major, minor and moderate. Manufacturers must determine the device's level and document the justification for level of concern. The FDA provides guides and definitions to guide manufacturers through this exercise.
Software-related Documentation
Software-related documentation includes the design of the device, how to implement that design, how the device was tested, how any potential hazards were identified, risk management practices, and provides traceability.
Device hazard analysis
Device hazard analysis refers to a software-related risk documentation. This document includes all software or hardware hazards, including how severe those hazards are and any mitigations that were taken.
Software Requirements Specification (SRS)
This document is very similar to the design inputs document, but for software. A software requirement specification (SRS) includes information about all the functional and non-functional requirements for a software. The SRS serves as the main point of reference for the software development team who’ll build the software product, as well as for all other involved stakeholders.
The software requirements specifications define the requirements, which might include requirements for installing and using the software properly. This could include hardware requirements, programming language, software performance, and other requirements. The level of detail required in this document is dependent on the level of concern.
Again, for minor-concern devices, there are no requirements needed. Moderate- and major-concern devices will need to submit how the software requirements’ specifications are implemented.
Architecture Design Chart
If your device is a minor concern, no documentation is needed here. For moderate- and major-concern devices, you’ll need detailed diagrams and/or flowcharts of the functional units and software modules.
Software Design Specification (SDS)
The software design specification (SDS) is a description of the software components and sub-systems to be provided as part of the product. The objective of the software design specification (SDS) is to ensure that the final software product meets the requirements of the end user.
Traceability Analysis
Because every input requirement and specification of a medical device requires an output, the FDA requires documented traceability between the requirements and outputs. The FDA recommends showing this through a matrix with line items.
Software Development Environment Description
This is a requirement only for moderate- or major-concern devices. Software development environment is a “summary of the software development life cycle plan,” according to the FDA. With major-concern devices, an annotated list of control documents created during the development process and a list of coding standards will be included in this document.
The International Medical Device Regulators Forum (IMDRF) Software as a Medical Device Working Group (WG) published a a possible risk categorization framework (IMDRF/SaMD WG/N12FINAL:2014) for Software as a Medical Device. The recommendations provided in this document allow manufactures and regulators to more clearly identify risk categories of Software as a Medical Device based on how the output of a Software as a Medical Device is used for healthcare decisions in different healthcare situations or conditions.
Verification and Validation (V&V) Documentation
All software related devices will need to have documented protocols with identified pass/fail criteria and corresponding reports. For devices with moderate and major levels, it’s recommended to list all V&V activities, results, and pass/fail criteria. In addition, the traceability analysis must identify how these are linked to the design requirements.
Revision Level History
You can log revision level history as a line item sheet that outlines each revision to the software during development and include the date, version number, and description of the changes.
Unresolved Anomalies
Manufacturers must document all unresolved software anomalies only for devices with moderate and major levels of concern. Indicate each activity, the impact to device performance, and the timeframe for correcting the problem. The FDA recommends an explanation for how each anomaly could impact the device’s effectiveness and safety.
Of note, the FDA points out that “software not covered by this guidance includes software designed for manufacturing or other process-control functions, but not intended for use as a device.”
How to prepare your DHF for an FDA Audit
Manufacturers who don’t maintain their documentation properly are unprepared for an audit. Poor documentation practices typically result in longer audits, with more findings, and a poor relationship with FDA. All of these things can be costly and resource intensive.
To be audit-ready when the FDA comes to visit, start the documentation process early. Begin preparing the design history file early in the design process to ensure it is accurate and captures all design discussions.
Create procedures that identify how to document design and development activities. Utilize forms or templates to ensure DHF harmony between other devices in the portfolio. Procedures, work instructions, forms, and templates are all good ways to standardize documentation activities and ensure they are part of the company’s culture.
Keep your DHF organized with an eQMS
Finally, one of the most effective ways to prevent having to scramble during an FDA inspection, is to utilize digital documentation methods for the DHF, DMR, and DHR. Using a paper-based system is cumbersome, and it takes longer to locate documentation. Storing your DHF and other documents in a cloud-based quality management system (eQMS) means everything will be in one place, organized, and easy to update.
An eQMS can help you maintain documentation at all phases of the design process, providing traceability between input requirements and output results. With features like document templates and revision control, you’ll be able to see how your documentation changes over time and easily identify when updates are made.
By using a quality management system designed purpose-built for medical device companies, manufacturers can store and maintain DHFs in software designed with regulatory compliance top of mind. Qualio’s quality management platform is made to scale with medical device startups and has built-in features and templates to help manage and accelerate the product development process.
Design History File vs. Device Master Record vs. Device History Record
Design History Files, Device Master Records, and Device History Records sound similar, but are separate forms of documentation that represent different stages of the medical device development process.
The Design History File (DHF) and Device Master Record (DMR) are like a medical device recipe and contain all of the information that’s needed to actually make the device. The DHF contains all of the specifications, materials, and data of the finished medical device. During development, all documentation about design is stored within the DHF. The DMR identifies the manufacturing steps and processes used to make the device. Once design outputs are being evaluated, documentation is stored within the DMR.
The Device History Record (DHR) keeps the records of production. The DHR contains documentation of every batch, lot, and unit made, as well as the date and time of manufacturing. The DHR includes each device that was made according to the DMR. If a customer complaint comes in, manufacturers use the DHR to determine what batch was affected and will alert other customers if it affects the batch.
Technical Documentation
Technical documentation has to be developed during the design and development process of a device and maintained throughout its entire life cycle. As illustrated in Figure 1, this process can be represented using the V-model, as it delivers documents and records, which form the Design History File (DHF).
Technical Documentation contents
The technical documentation represents the entirety of the documents describing a device. It therefore includes the device’s design, development, V&V (including clinical and performance validation) as well as its regulatory status within target markets. Furthermore, the MDR now requires a closed loop process, implemented with data from the post-market use of the device (PMS), in order to ensure that early warnings are captured, that the ‘General Safety and
Performance Requirements (GSPRs)’2 are continuously fulfilled and that the benefits for the patient always outweigh the risks.
The technical documentation should be structured and presented, in such a way, as to facilitate its review and assessment by the NB (Figure 2). This means that the compilation of technical documentation requires the application of quantitative and qualitative filters, allowing an adequate level of detail to be maintained, while avoiding the inclusion of superfluous details not necessary to demonstrate fulfillment of the GSPRs.
As illustrated in Figure 2, specific elements required by the NB for the review (e.g. cover letters etc.), as well as the elements from the Quality System (QS) required to demonstrate compliance, are also to be included in the technical documentation. Post-market data is the final subset of documents to be included; for new devices this may consist of, amongst other things, vigilance data from competitors and of the manufacturer’s plan for activities to be implemented once the device is on the market (such as a Post-Market Clinical Follow-up (PMCF) Study); for devices that have previously been placed on the market, this includes, but is not limited to the PMCF data, vigilance data, user feedback and complaints. Based on these post-market data, new inputs may trigger a novel cycle in the design and development process. This input may be implemented under design change controls, which are necessary to introduce corrective and preventive measures, in order to maintain the benefit-risk balance and to ensure continuous
fulfillment of the GSPRs.
A clear structure throughout the technical documentation is helpful in ensuring that the reviewing body can clearly understand the contents. Therefore, it is important for the manufacturer to maintain traceability from the User Requirements Specification (URS), to the Functional Requirements Specification (FRS), risk analysis, clinical evaluation
and the general requirements for safety and performance, as well as the reverse to ensure consistency of the evidence documents and records throughout the technical documentation. A URS can determine several FRSs.
Each FRS may be involved in several hazards and associated risks. Each risk, identified through a risk analysis, may be linked to one or more questions to be treated by clinical evaluation and to one or more general requirements for safety and performance. Keeping traceability of all of this within the manufacturer’s technical documentation, whilst
challenging, is essential for demonstrating to Notified Bodies (NBs) continuous fulfillment of the GSPRs.
When compiling technical documentation, manufacturers should ensure they take into account the EU which determines the extent and detail by which the CAs/NBs will review the technical documentation, as determined by the MDR provisions.
Table -1 |
Required Content of Technical Documentation as per MDR |
(a) Annex II - Technical Documentation: |
1. Device description and specification, including variants and accessories |
1.1 Device description and specification |
1.2 Reference to previous and similar generations of the device |
2. Information to be supplied by the manufacturer |
3. Design and manufacturing information |
4. General safety and performance requirements |
5. Benefit-risk analysis and risk management |
6. Product Verification and Validation |
6.1 Pre-clinical and clinical data |
6.2 Additional information required in specific cases |
(b) Annex III - Technical Documentation on Post Market Surveillance |
1. The post-market surveillance plan |
2. The PSUR (Periodic Safety Update Report) |
3. PMS Report |
