If you’re using a paper-based system to manage your design history file (DHF), it can raise several issues that lead to complications.
Let’s begin with a story. A true story that happened to me more than a decade ago before Greenlight Guru.My project was called to be part of an ISO audit where they were looking for evidence from the DHF that we had followed procedure and kept good records.
I was feeling good - I thought we’d been thorough and I was confident it would be a good day. I walked in with a handful of 3-inch binders, all tabulated and indexed. The auditor started going through the files and asked about a particular test report. We had made some justification and rationale for our results and he didn’t question us much about that, but I began to sweat when he flipped to the signature page.
It was missing a signature. This is when the grilling began. How could I say this project was good when the VP of Engineering hadn’t signed? How could we move forward when we didn’t have key approvals? We got written up for this error and, as project manager, that is a horrible feeling. Remember, this was a project I felt good about going into the audit!
This story illustrates just one of the perils of a paper-based system, read on for the seven problems we’ve identified.
Bonus Resource: Click here to download 5 Additional Tips for Better DHF Management.
To preface this, we always encourage people to be quality-focused rather than compliance-focused.
By this, we mean that, while compliance is obviously something that you need to have done right, it shouldn’t be done as a checkbox activity. It should be used to bring about real quality in your work.
That being said, a risk of a paper-based system is that you can miss the boat compliance-wise, much like what happened in my opening story. Part of the reason we built the Greenlight Guru Design Control module and overall QMS is to build fail-safes so that things can’t proceed if something is missing. For example, a document can’t go ahead without a signature.
The aim is to keep companies audit-ready. It shouldn’t be a last-minute scramble to ensure that all documentation is in place and has appropriate approvals.
Traceability is a big one. We talk to hundreds of companies who are involved with medical device development and this is almost always one of their number one issues.
Why? Quite simply, traceability is challenging. A lot of the tools companies use are very inefficient. Commonly, people create spreadsheets to try and keep track of information flows, and these are not easy to keep updated during the course of a project.
The details of a project evolve a fair bit over its course. Project managers end up trying to merge files and work manually to update documentation. Spreadsheets just aren’t efficient. Greenlight Guru has been built with traceability as a key element.
The data you’re compiling in your DHF has a number of potential benefits, many of which become apparent further downstream.
One of those is a regulatory submission. At some point, there’s a good chance that the information contained in the DHF will find its way into a regulatory submission.
This information informs the rationale that you build to seek clearance. By nature, paper-based systems can get messy. Information is often missing, updates get forgotten. When you’re trying to bring together everything you need for your submission, a cloud-based, always updated DHF can greatly simplify your task.
So many of the tools that people use for managing the DHF and design control activities are too restrictive.
For example, if you use a paper-based system, it’s usually the case that one or two people know (or think they know) where things are, while others who may also be quite central to the project have no idea.
It’s important to have a system that encourages collaboration, allowing you to have your entire project team involved. This gives team members visibility over the documentation and will help you to create strong and accurate submissions later on.
Many of our product development efforts these days take place virtually. It is rare to have everyone co-located because remote work allows you to access some of the best possible people. To work in this environment, centralized solutions that enhance collaboration are essential. How else will you maintain visibility across the team?
If you have not integrated your risk management process with your design and development process, it will raise issues and challenges during audits. There is an expectation from ISO auditors and FDA inspectors that these processes are on a continuum - they are effectively one process.
When you’re getting into macros and spreadsheets while trying to hack your way through, you limit your collaboration potential and the continuum of these processes. A tool like Greenlight Guru's Risk Management module pulls your risk management process into your design and development so that it is an integrated process.
It is not a good idea to try to separate the two because one of the key areas where quality manifests in product development is how well we establish our design controls. A second key area is identifying risk. Design controls inextricably feed into risk, and risk is where quality becomes important for us as developers.
The term design history file is often taken literally by people. The idea behind it in 2018 is that it is a total product life cycle activity. This means that it lives as long as your product is in existence.
Sure, you start out with your DHF one way as you go through development, but once your product is launched, there will be changes. Something will need refining or changing in some way, and you need to know what the impact will be. This includes from a risk standpoint and from ramifications on validation.
If your DHF is paper-based, keeping it up-to-date throughout the product lifecycle will be challenging. If your team is distributed, where is your single source of truth? Even if your team is co-located, paper is something that goes missing, or Excel spreadsheets don’t get saved or aren’t updated.
You may have noticed a theme through all of these points - good management of a DHF involves connectivity across several moving parts. A major problem with paper-based solutions is that connectivity is impeded.
For example, your functional groups end up creating silos where information is not easily shared or collaborated over. This can lead to an environment where you become reactive rather than proactive because the flow of information is impeded. This can result in poor decision-making, made in haste as you react to a situation.
The idea of a cloud-based DHF is that connectivity is simplified across all functions and people who need to be involved. You can build up a clear overall picture of your projects and proactively visualize what needs to be done.
Bonus Resource: Click here to download 5 Additional Tips for Better DHF Management.
We are huge advocates of making the paperwork side of medical device development as streamlined as possible. Yes, your DHF is a compliance requirement, but it’s also a valuable tool to promote quality in your development process.
Paper-based systems are cumbersome. They inhibit collaboration and they have built-in faults in that it’s easy for things to be lost or out-of-date.
Using a cloud-based solution such as Greenlight Guru helps to eliminate or mitigate those issues that are common with paper systems.
Jon Speer is a medical device expert with over 20 years of industry experience. Jon knows the best medical device companies in the world use quality as an accelerator. That's why he created Greenlight Guru to help companies move beyond compliance to True Quality.