Design History File Archives

Tag Archive for: Design History File

Congratulations! Your organization has gained regulatory approval and launched its medical device product. The ‘History’ in Design History File may elicit impressions that all those design and development requirements are now done and considered part of the past. However, several components of the DHF continue as a reference and evolve, including requirements and risk management. Here are 3 ways active management of requirements and risk continues after commercialization:

1: Post-market surveillance

Once your medical device is on the market, post-market surveillance programs, including complaint management processes, must now be exercised. That includes evaluating feedback, determining if it is a complaint, investigating complaints, and determining whether to initiate corrections or corrective actions. As part of this process, requirements and risk management are being used in 2 ways, 1) as a resource to evaluate complaints and 2) a living document to be updated with the experience gained.

As a resource, it is important to reference risk management files to determine if the frequency of occurrence and types of failure modes documented during design and development matches the infield data being gathered. A more frequently occurring failure or new failure mode indicates an investigation is warranted and re-evaluation of the risk. Depending on the outcome, corrective action may be needed.

For example, during design and development, it was determined that a sensor failure leading to customer annoyance occurred rarely, leading to a low risk rating at the time of market launch. The first year on the market, reports of this failure occurred rarely, matching the occurrence rates in the risk management file. Given the low risk and lack of trend, further failure investigation and corrective action were not taken. However, one year later, a change in supplier coincides with a change in occurrence from rarely to frequent, leading to a medium risk. This increase in risk prompts an investigation to determine why the sensor failure rate is higher and to determine corrective actions and controls with the new supplier.

As a living document, the risk management files are to be updated with the observed occurrence rates, new cause(s) of the failure mode of the sensor, mitigations and controls put in place, resulting verifications, and revised risk rating.

2: New Products

Another reason requirements and risk management continue once a product is commercialized is to aid in the development of new products, including line extensions, new models, and next generation platforms and portfolios.

The existing product’s requirements and risk management, supplemented with what is learned from post-market surveillance and other feedback from the field, provide the foundation for new products. A requirements and risk management tool like JAMA Connects® can simplify the management of requirements and risks shared between products to keep teams aligned and prevent requirements or risks being missed during the transfer from one product’s design history file to another. Likewise, line extensions can be more easily incorporated into an existing design history file if requirements and risk management have been properly updated as needed and are accessible.

3: Change Control Evaluation

Change control evaluations is another way management of requirements and risks continue after commercialization. Changes to a product and how it is manufactured occur for many reasons, including replacement of a component that has reached its end of life from a supplier, software upgrades to address bugs, duplication of a manufacturing line, and changes that address complaints.

Changes must be evaluated as to their impact on the form, fit and function of the product, and can have varying degrees of potential impact. Well managed and active requirements and risk management, with traceability to design outputs and verification, become a strong tool for organizations to evaluate the potential impact more quickly.

For example, say a temperature sensor was added as mitigation to prevent overheating of a medical device; overheating that could result in burns to the patient. The sensor, including the necessary accuracy, is listed as a control for the risk of overheating and burns. There’s also a corresponding design requirement, and the sensor and its specification are linked as design outputs. The supplier of the sensor has recently informed the medical device manufacturer that the sensor is reaching its end of life and will no longer be available in 6 months’ time. A change owner is assigned to identify and evaluate a new sensor. This person is most likely not the same engineer who originally designed and selected the first sensor. And that the original engineer may or may not still be with the organization, and may not remember why that sensor was selected. This is where having accessible and well managed requirements and risk management becomes important. The change owner can reference and look up the sensor, see the design inputs and risk with which it’s associated, and understand more quickly the criticality of the sensor and ensure the proper selection and testing are performed on a new sensor.

While change post-commercialization is inevitable, difficult change control management is not.

Beyond Commercialization

Management of requirements and risk extends through the entire life cycle of a medical device, including after a device has gained the necessary regulatory approvals and reached the market. Thus, take care in selecting the tools and developing the processes your organization uses for requirements and risk management.

Design history files were first required by the FDA in 1990 for medical devices. Learn how DHFs impact product teams, and get Jama Software’s DHF template.

In the competitive world of medical device development, medical device companies can’t afford to lag behind the pack. Streamlining the design and approval process is vital to getting products to market in a timely manner. Proper documentation is key to a smooth approval process.

One essential ingredient to medical device documentation is the Design History File, or DHF. While a bad DHF may not result in non-compliance, a good DHF can make the difference between a smooth compliance process and a bumpy one. To create a good DHF that streamlines compliance, design teams should know what to include—and what to avoid—as they go through the entire design and approval process.

What’s a Design History File, and How are They Used by Product Teams Working on Medical Devices?

Before reviewing all of the essential DHF ingredients, it can help to back up and establish what it is and why it’s important.

The Design History File is a collection of documents that describe the design and development activities of a medical device. Its purpose is to demonstrate that the device was developed using the design control process needed to meet FDA requirements.

Figure 1: Design Control Process for Meeting FDA Requirements

The DHF requirement was established as part of the Safe Medical Devices Act of 1990. The act describes the DHF in section 21 CFR 820.30, sub-section (j) as follows:

“Each manufacturer shall establish and maintain a DHF for each type of medical device. 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 regulations of this part.”

There are two key terms in the DHF requirement: “establish” and “maintain.” “Establish” means that the development team must define, document, and implement requirements. Evidence is found in procedures, work instructions, drawings, and other similar documents. “Maintain” means that the team must review, approve, and update requirements. Evidence of maintenance is typically found in document control or change control systems of a company.

While a comprehensive DHF is vital to the FDA approval process, design teams will realize other benefits of maintaining the DHF, including:

Requirements traceability;
Change control; and
Knowledge preservation and information sharing among key stakeholders.

What is the difference between DHF and DMR?

The DHF is one of three pillars of design compliance for medical devices:

Design controls: The moving parts of product design and development.
Design History File (DHF): The collection of records from design and development activities.
Device Master Record: The “recipe” for product manufacturing once the design is complete.

As one of the pillars of design compliance, the DHF is important, but it cannot hold up the design process on its own. It’s one leg of a tripod, and removing any one of the legs means that the entire design compliance process may tip over. Equally important to the process are design controls and the Device Master Record, or DMR.

What are design controls, and how does the DHF establish the design control process?

Design controls establish a plan to manage new product development; they are the process pieces that guide development along a predictable path to ensure that requirements are met. The Safe Medical Devices Act requires that manufacturers of Class II and Class III medical devices (and some Class I devices as well) implement design controls over the development process.

Design controls include:

Design inputs: The physical and performance requirements for the type of device. May also include types of materials needed, interfaces with other devices, and even packaging required, especially if the device must be sterilized.
Design outputs: Usually the final specifications for the device, typically documented in models, drawings, engineering analysis, etc. Outputs should trace directly back to initial requirements. Design outputs are the basis of the Design Medical Record (DMR).
Design review: A formal review by the design team and any other relevant parties, such as sales, marketing, manufacturing, etc. Documentation of the review should include the date, participants, version/revision reviewed, and results.
Design verification: This process verifies that the design output meets the requirements expressed by the design inputs and that specifications are correct. Documentation of this process must include the date, participants, version/revision reviewed, and the verification method and results.
Process validation: Process validation involves producing the device with a normal, low-level production process to confirm that the device will function as designed outside of the prototype process. Documentation of the process is required for the DHF.
Design validation: In this process, each manufacturer validates device design under specific conditions on small production lots or batches. The DHF documentation must include identification of the design, methods of production, date, and individuals performing the validation.
Design transfer: The process of transferring design into production, distribution, and installation specifications.
Design changes: May be referred to as “engineering change” or “enterprise change,” this process identifies and documents any design changes.
Design history file: This is the formal document prepared for each medical device that includes either all documents generated in product development process OR an index of documents and locations where they are stored.

As you can see, the DHF is one of many design controls, but it also serves as the repository of records of all other design controls. Think of it as the final stop for the information generated by all other design controls.

What is in a Device Medical Record (DMR)?

The third leg in the tripod supporting your compliance process is the Device Medical Record, or DMR. Think of the DMR as the “recipe” that resulted from the design controls to manufacture the device according to design specifications. It’s more than just a production traveler—it will include device specifications, compositions, drawings, formulations, software specifications, etc., as well as production process specifications, including appropriate equipment, methods, procedures and environments, such as clean rooms, humidity controls, quality assurance procedures, and any specialized equipment needed. The DMR will include everything from beginning to end of the production and shipping process, including any relevant installation instructions.

What are some pitfalls to avoid when compiling the DHF?

Many companies make costly and time-consuming errors when creating their DHFs, leading to longer-than-necessary audits and failed FDA inspections. Avoid these mistakes, and you’ll minimize lost time and unnecessary costs getting to market.

Jama Software hosted a webinar led by Quality Centric Consulting to review:

The top DHF errors that are costing you money
How to tackle 21 CFR 820.30 requirements
How Jama Connect™ streamlines the DHF process

Five of the most common pitfalls of the DHF include:

Not having a DHF: Usually small companies strapped for resources will put all their efforts into designing and getting a product to market, with the intention of doing the DHF later on. This could be due to a lack of understanding of what DHF outputs are required.

Chaotic and unorganized DHF: This is more typical in paper-based companies that keep all information in binders, but leave off dates or include unapproved documents, making it impossible to organize at the time of an audit or inspection. Disorganization — whether paper- or email-based — also makes it difficult to manage changes and revisions due to information silos and lack of sharing information.

Including unnecessary documents: Adding business documents, such as supplier quotes, financial information or unused concepts, can bring a flurry of unwanted questions from inspectors. This can also be a symptom of not having a DHF tool or template, as well as a linear process that involves lengthy review and approval times.

Unmaintained DHF: Often companies use either outdated or improper technology for the job. Paper-based systems, email, shared folders with read-write access and the like, are not always effective document controls. This can lead to lost copies of important records, making a DHF non-compliant.

Not traceable to outputs: Without a DHF, it’s impossible to create your DMR, and very difficult to establish your traceability matrix. If design control results are not well documented, easy to locate or current, your DMR will fail to be compliant.

Ask Jama: Defining and Implementing Baselines to Simplify Compliance

Julie Goodner: I’m really excited to show you the enhancements that we have made to the Baseline area along with giving you a sneak peek of where we’re headed. Over the last few releases, we have dramatically changed the look and feel of the Baseline area of Jama Connect. We’ve worked extensively on permissions, auditability, and usability to make Baseline workflow more efficient.

I’ll be walking you through the way we have dramatically enhanced our Baseline preview, the list and reading views, the header activity stream and our new slide over panel preview. Everything that I’ll be showing you today has come from direct customer feedback and I’m excited to show you where we’re at and where we’re going. Over the years, we’ve received feedback from our customers regarding enhancements to the Baseline tree.

This was a large body of work that we hope creates a more useful and consistent experience for you. You can now add all version core and custom fields to your baseline list view including the workflow status. When looking at your baseline list view, we now provide a count of all the items that are included. So, at a glance, you can easily see the scale of your baseline items.

Watch the below recording to see the top five improvements to Baselines in Jama Connect in these key areas:

Baseline tree view
List and reading views
Baseline header
Activity streams
Slide-over panel previews

Adrian Rolufs: Now we’re going to talk a little bit about how to utilize these baselines and the new capabilities that Julie just described in Jama Connect while you’re doing your requirements engineering work. Most of the work around baselines is focused on the management of work products.

We’re going to talk today, about how that work aligns with your compliance needs and we’ll talk about how different standards for different industries drive those requirements. We’re going to talk about how that aids in understanding the traceability during your document life cycle and we’ll also focus on some best practices around what we find works best for our customers when managing baselines in Jama Connect.

First of all, let’s take a look at the automotive industry. If you’re developing automotive products that have a functional safety concern, then you’re typically following ISO 26262 as part of your development and if you’re developing software, you may well be following Automotive SPICE. Both of those standards or regulations have requirements that are met by the Baseline features of Jama Connect and that falls under the categories of configuration management as well as document management.

Those standards require that you are able to keep track of the versions of the documentation that when you have a completed product, you can point back to the specific versions of the requirements that it met and the Baseline feature of Jama Connect is the way to do that. If we switch over and take a look at the medical device industry, in the medical device industry, there’s a design history file or DHF that is required to be generated for every product that is submitted to the market.

That DHF, an integral part of that if you’re using Jama Connect is the baselines, the baseline captures exactly the version of the content of each of the different work products that’s going to go into the DHF and typically, there’s a baseline for every work product and an exported document to a QMS system that goes along with that. So, similar to the needs of automotive but a little bit different terminology.

Now, if we take a look at airborne systems. Each of the requirements or the standards that’s typically followed there has requirements for configuration management. Configuration management is typically the activity that is most closely associated with the Baseline function of Jama Connect and you’ll see there’s sections there that drive that as well. The nice thing is even though there’s different standards for different industries, they’re largely requiring teams to achieve the same goals.

So, the common functionality provided by Jama Connect through the baselines and version history meets those requirements and that’s what we’ll be looking at today. First of all, what is that common workflow through Jama Connect that meets all those requirements? For any work product or document that you’re generating from Jama Connect, it generally needs to go through the same process.

You’re going to create the material either by importing or creating the content in Jama Connect, you’re going to build traceability using the relationship features of Jama Connect to associate the individual requirements with other requirements or test cases. That material then needs to go through a comprehensive review process to make sure that the right people have reviewed the content for accuracy, completeness, verifiability, ability to implement a solution and capture that feedback and then eventual approval in Jama Connect.

Once you have that, you then will have baselines that came about as part of the review process and the final baseline that was actually signed off in Jama Connect, you’ll want to capture as an official record saying that this is the signed off version that we are building our product to meet. And then finally, in many cases, it makes sense to export a document version of that to check into a PLM system or a QMS system or to distribute to other people who may not have access to your Jama Connect environment.

You can view the full webinar by clicking on the button below, or take a moment to go back and watch a few of our other Ask Jama webinars, like this one on release management options in Jama Connect, or this one on moving from a document-based design control and risk management in medical device development.

Watch the full webinar to learn more about the latest product roadmap enhancements related to Baselines, and how to get the most out of Jama Connect.

WATCH NOW

At Jama Software, we’ve been lucky enough to work directly with some of the world’s most forward-thinking medical device companies. What we’ve learned is that these innovators must balance increasingly complex development processes; the need to release high-quality, regulatory-compliant, market-driven products; intense pressure to nail delivery timelines; and the imperative of patient safety.

With the recent findings by the the International Consortium of Investigative Journalists that more than 1.7 million injuries and nearly 83,000 deaths may be linked to faulty medical devices over a decade-long period, coupled with the FDA’s promise to overhaul its system for approving medical devices, it’s clear there are still plenty of areas for improvement within the industry.

In a recent webinar, we offered project and engineering teams working on medical devices some strategies for gaining a competitive edge by streamlining process, mitigating risk, reducing rework and easing the path to regulatory compliance.

Jama Software’s mission is to modernize, digitize and transform the process of complex product development by transcending the headaches and limitations of document-based requirement systems. To that end, we’re constantly working to ensure our platform and services help teams better manage the growing complexity of developing Class II and Class III medical devices.

Our medical device customers depend on our platform to standardize and optimize their product development processes to mitigate risk, improve quality and trim time to market.

Jama Connect helps medical device development teams operationalize their development processes by enabling requirements definition, traceability, testing and collaboration across all stakeholders.
Jama Partners allows customers to extend the Jama platform via popular third-party integration hubs or an open REST API to support integration of technologies used throughout the development process.
Jama Professional Services assist our customers in speeding time to value for our solutions with a host of offerings including expert assistance in optimizing and implementing the platform, as well as industry-specific consultation and training.

Overcoming Low-Value Work

Over the years, our professional services team has spent many hours working closely with medical device developers, and we’ve learned a lot about their challenges and opportunities.

A key understanding has emerged from our deep dive into the world of medical device manufacturing: Teams are struggling to balance regulatory compliance with how they want to work.

More often than not, our customers are looking to modernize and become more collaborative, but the weight of regulatory requirements can keep them from realizing the benefits of updating their process. Teams can start to see the work and the documentation as being at odds with one another, but that doesn’t have to be the case.

The challenge is balancing the requirements of the quality system with your organization’s approach to product development. You find this equilibrium by ensuring that the quality system needs and documentation in the design history file (DHF), for example, are byproducts of your work rather than defining or constraining factors in themselves.

When this balance is lacking, we’ve seen that a heavy focus on documentation needed for the DHF can introduce time-consuming, low-value work and create friction in team hand-offs.

The Benefits of Greater Efficiency

Among the biggest challenges faced by medical device developers looking to improve their product development process is that teams are spending too much time on work that doesn’t add value – especially when they’re reliant on a document-based approach to defining and managing requirements and testing.

One study of nearly 250 manufacturing organizations, according to Tech-Clarity researchers, found that engineering teams spend a third of their time on non-value adding work, especially manual data management, including manual data collection, content editing and recreating lost data.

In the requirements management space, this time might be spent checking documents in and out and tracking down the latest version for updates or reviews – not to mention time spent in meetings getting everyone aligned and establishing the path forward.

Medical device developers need to bring higher-quality products to market faster, with less risk and at a lower cost. Giving engineering teams a third of their time back would help make this goal a reality.

Stay tuned for more posts about improving medical device development and the integral role Jama is playing for its customers. In the meantime, get a deeper dive into how Jama Connect helps developers balance medical device compliance and innovation by watching our webinar.

In a recent webinar about the common pitfalls of the Design History File (DHF), experts discussed what medical device manufacturers need to know about design compliance. Below are some highlights.

Three Pillars of Design Compliance

There are three pillars of design compliance for medical devices:

Design Controls: The moving parts of product design and development
DHF: Collection of records from design and development activities
Device Master Record (DMR): The “recipe” for product manufacturing once design is complete

In order to achieve FDA compliance and effectively bring your product to market, you must successfully satisfy each of the three pillars.

What is a DHF?

The DHF is a compilation of documents that describe the design and development activities of a medical device. Its purpose is to show that the medical device was developed using the design control process, pictured below, needed to meet FDA requirements.

Design Control Process for Meeting FDA Requirements

The FDA lists specific guidelines for DHF under 21 CFR 820.30 (j):

“Each manufacturer shall establish and maintain a DHF for each type of medical device. 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 regulations of this part.”

The DHF also provides traceability to requirements, can assist with change control and acts as a tool for knowledge preservation and information sharing within your organization or with your supply chain.

Complications of an Incomplete DHF

As the second pillar of design compliance, the DHF connects the first and the third pillars. As noted, it documents that the correct design control process was followed. The DHF is also the basis of the DMR, which must be created according to design specifications.

An incomplete DHF makes it nearly impossible to prove you used the correct design control process for meeting FDA compliance, or create a compliant DMR.

Furthermore, if there are deficiencies noted within the design control subsystem during an inspection, they are documented by the FDA. If your company’s response is inadequate or not timely – which is likely when your DHF is lacking – a public warning letter could be issued. This could not only hurt your credibility in the market, but it might also give your competition some insights that you’d rather have kept within your company’s walls.

Five Common Pitfalls of the DHF

According to experts, these are some other reasons a DHF might fail:

Not having a DHF
Usually small companies strapped for resources will put all their efforts into designing and getting a product to market, with the intention of doing the DHF later on. This could be due to a lack of understanding of what DHF outputs are required.

Chaotic and unorganized DHF
This is more typical in paper-based companies that keep all information in binders, but leave off dates or include unapproved documents, making it impossible to organize at the time of an audit or inspection.

Disorganization — whether paper- or email-based — also makes it difficult to manage changes and revisions due to information silos and lack of sharing information.

Including unnecessary documents
Adding business documents, such as supplier quotes, financial information or unused concepts, can bring a flurry of unwanted questions from inspectors. This can also be a symptom of not having a DHF tool or template, as well as a linear process that involves lengthy review and approval times.

Unmaintained DHF
Often companies use either outdated or improper technology for the job. Paper-based systems, email, shared folders with read-write access and the like, are not always effective document controls. This can lead to lost copies of important records, making a DHF non-compliant.

Not traceable to outputs
Without a DHF, it’s impossible to create your DMR, and very difficult to establish your traceability matrix. If design control results are not well documented, easy to locate or current, your DMR will fail to be compliant.

If it feels like creating a DHF is a heavy burden, you should seriously consider the alternatives as well as the urge to make it an afterthought. If you treat your DHF as part of your design and development process, these requirements become seamless and help ease the path to compliance.

To learn more about preventing these issues in your DHF, watch the webinar, Common Pitfalls of the Design History File and How to Avoid Them.