As a development engineer in the medical device industry, it has been my experience that using and following the FDA Design Control process can often be a burden to the development team that can cause inefficiencies and delays in the development of medical devices.
One of the biggest reasons this becomes a burden is the documentation process that typically goes along with most company’s interpretations of how to follow the design control process. This interpretation typically includes a series of documents. Documents such as marketing requirements, user requirements, and design requirements--as a few examples--are all typically written and released at the beginning of a product's development.
Each of these requirements tends to be made into their own stand-alone documents that go through a company’s document control system, typically the DCO (design change order) process where a hard-copy is circulated for review, signature, and then filed by document control. In a paper system we all know this can take some time and hand holding to get documents signed off and released. These documents are often released and rarely revisited as the product development cycle gets under way and the team goes to work.
One of the reasons is the documents become obsolete or incomplete fairly quickly as the team goes through the design process and revising the document each and every time there is a change, will only stop progress on what could be important testing, design, and collaboration activities to get that product to market. What sometimes happens is these requirement documents are updated retrospectively to reflect what the team has learned the product should be and requirements it should meet. This in turn makes design control something that is seen as another item to be checked off in an effort to be in compliance.
There is a major disconnect here in that the natural design process a development team will go through is fluid, collaborative, and constantly changing and a company’s Document or Engineering Change Order process cannot possibly keep up. In this current state of operation there are a few questions that need to be asked and common habits that should be challenged. One of the biggest questions is why do we have to establish all these separate documents capturing different types of requirements in the first place and is it the most effective way?
Don’t they all interconnect with each other to define the medical device purpose and design? It can be a challenge to make and remember these connections and then continually drive the product development to successfully meet them all. Wouldn’t it make more sense to more clearly define and even show the relationships between what the market requires and the design needs directly? This way the picture is always clear on where the device purpose is originating from and the direct design features that must be created.
Design control is a methodology--not a documentation system. The methodology at its core requires user needs, design inputs, design outputs, verification, and validation of those outputs. In my opinion the connections between those design control essentials is what holds the most value to the development team on a daily basis. When the essential reasons for a medical device are not regularly referenced, inefficiencies and the dreaded scope creep almost always come into the picture. Those essentials and connections define what work needs to be done to bring a medical device to market.
An embodiment of this approach is what could be called a design control matrix where the user needs, design inputs, design outputs, verification, and validation are listed together but more importantly are linked to each other creating the matrix. A company pioneering an online tool for creating and managing this design control matrix is Greenlight Guru.
A system, like Greenlight Guru’s design control matrix, that keeps the development team always aware of the driving need behind their work and emphasizes the connections between the essential pieces of the design control methodology should be the way of the future for medical device companies, especially the small start-ups where no time or resource can be wasted with often limited budget and personnel.
Design control can and should be seen as a tool, the tool, to help coordinate and drive the team’s effort; as the road map or the central control for product development, not a road block. It can be a tool that allows collaboration but also implements the necessary levels of control to hold up under audit. Utilizing this new approach to design control will create an extremely efficient work environment improving development cycle time, which ultimately translates to speed to market.