What does a successful design control system look like? I think there are several structural questions we should consider when thinking about the content of an intelligent design control system.
- How can we optimize the data quality and visibility?
- Where is the cost of a system? In the engineering time invested. In order to provide excellence in ROI we must investigate how to salvage design work for use in another project. We call this advanced structure re-use.
- Finally, there is tremendous value in accelerating the velocity of regulatory approval.
So, what does "High quality data" mean?
We can break this down into two terms, rationalized and validated.
Validated is usually pretty well understood. We want a formalized workflow followed and the content approved by appropriate personnel. If this is done, each element has been reviewed by knowledgeable people, and is therefore of greater value than items which have not been reviewed.
The tougher part of this is rationalized.
What does it mean to have rationalized data? The central idea here is whether the data is usable. In order for the data to be usable it should have the following attributes:
What does it mean to have rationalized data? The central idea here is whether the data is usable. In order for the data to be usable it should have the following attributes:
- Appropriate granularity - If, for example, I need to understand how many screws are in an assembly, but the data only includes the top level device assembly detail, the database becomes useless for the intended use.
- Visibility - this requirements goes to data access. Are you able to report on the structure?
- Integration and Contextualization - Finding the right piece of data in a 2 Tb database can be the most difficult part of using a data base. What are the Hazardous Situations that can lead to this harm? Defining the Hazardous situations someplace in the data structure is truly not helpful. Using relationships between aspects of the data is tremendously powerful in making access to data FAST.
- Fast Access - The data needs to be inter-related, and searchable, using business intelligence.
We will get back to this in a bit, but keep this discussion in the back of your mind as we start to build a design controls system, because the system won't be worth much if we don't think about how it will be used, and the value it will provide as the product is used, launched, and re-used throughout it's lifecycle.
When building a system around the regulatory requirements the discussion can be reduced to five categories of work.
- Design Definition
- Risk Management (ISO 14971 compliance)
- Verification and Validation
- Design Transfer (Creation of DHF and DMR)
- and Regulatory Submissions
The first is design deconstruction, or our definition of good product. Design and development planning, design input, design output, and design review can be rolled into this bucket. The FDA has provided a guidance document (FDA Design Control Guidance 1998) to help guide companies construct a logical framework. In this document they provide a graphic outlining the expectations for how design definition should be presented to the agency (Figure 1 - Application of Design Controls).
 |
| Application of Design Controls, FDA 1998 Design Control Guidance |
There are a great variety of design decomposition methods including RFLP, SysML and others. We will discuss many of these methods in our next blog, however, the FDA guidance is as good a framework as any to get started.
That is all for today, but I look forward to future chats.
No comments:
Post a Comment