Design History File (DHF) Remediation using Principles of Lean Documents and Lean Configuration

Does your DHF remediation process resemble the very mess that it is trying to resolve?

The Design History File (DHF) is the objective evidence that a medical device was designed per design control guidance and applicable regulations and standards. While it is retrospective in nature, it is the end result of a process that begins with planning and ends with Design Transfer and has the Device Master Record (DMR) as a deliverable.

Remediation is a retrospective reconstruction of that process. While one may be tempted to focus on the technical details of part and process specifications, one must not lose sight of the fact that remediation itself is a process.

Typical remediation practices are not managed as a process as one would understand the term. It has many fluid and moving decisions and ever-changing rules which are as good as the last meeting or the last conversation, not all of which are documented, not all of which every team member is privy to, and not all of which are communicated properly.
Does this sound familiar? This webinar can help you!

A process has distinct inputs and outputs, distinct workstations, PARTS*** moving through it, distinct roles and responsibilities defined at each step, it has “traffic signals” and controls in place to make sure certain things have happened before those parts move on to the next step. It also involves resource allocation and movement to address bottlenecks. It means having the correct information and asking the right questions at the right time. Not tribal knowledge, nor dependent upon the memory of one person, no matter how experienced, intelligent, or talented that person may be. A swim lane diagram does not have parts, controls, and signals, or active bottleneck resource management. It does not have workstations, and it is not the living and moving thing that a process is.

A swim lane diagram is NOT a process. It is a map and depiction of the process flow, but it is NOT the process itself. Also, a tracker is not a process. It is at best a score board but not a substitute for the real thing.

This webinar deconstructs the DHF remediation process based upon lean manufacturing and documentation principles.

Which do YOU want to be? Only you can answer that. This webinar can show you how to be the latter:

Old school remediation:
– Hire 50 consultants, tribal knowledge
– Put them to work on a PUSH system
– Build mountains of work-in-progress
– Bury your information in folders
– Spend endless hours on rework
– Flood customer resources to review
– Endless trackers to track trackers
– Busy work with huge expenses
– Focusing on numbers not actual results

Lean and new school remediation:
– Process flow with signals
– Pull system and Kanbans
– Constraint management
– Focus on process flow and output
– Learn from initial successes
– Involve reviewers as part of flow
– Automatic information flow and tracking
– Productive work with successful output

 
Areas Covered in the Session :

Part 1 – Success begins with proper discovery

• Examining documents, work instructions, specifications, process controls, BOMs, routers, etc.
• Elements of lean documents and lean configuration and their role
• Interviewing customer and supplier with first-hand knowledge,
• Examining physical parts, and the process that created those parts 

Part 2 – The Design History File (DHF) Remediation Process

• Inputs, Outputs, workstations, moving parts
• Signals, Kanban, pull system
• Flow diagram
• Process Constraints
• RACI – responsible, accountable, consulted and informed

Part 3 – Management of / Access to / Accuracy of / Relevance of / Information

• Product information
• Process information
• Supplier information
• Risk information
• Fixed information
• Variable information
• Flow of information

Who Should Attend:

• Quality Assurance Departments
• Regulatory Affairs Departments
• Manufacturing Departments
• Engineering Departments
• Research and Development Departments
• Compliance Departments
• Production Departments
• Documentation Departments
• Operations Departments
• Medical Device Software Engineers
• Medical Device Software Validation Departments
• Medical Device Software Compliance Engineers
• Document Control Teams
• Design Engineers
• Design Assurance