2. Acknowledgements
Tim Ulatowski
Dan O’Leary
Anita Fauchier
Mike Weber
Nancy Singer
Karen Steinberg
Kerry McCarter
Akos Bartha
Carl Anderson
Jackie Cassada
John Lincoln
Jim Shore
Tom Colonna
Terry Winchell
Chris Szustkiewicz
Kim Trautman
Larry Nicholson
Jan Welch
David Elder
Annamarie Kempic
Doug Throckmorton
Jonathan Lee
2
3. Agenda
core requirements
industry challenges
an ideal solution
beyond compliance
next steps
This is not legal advice. Information in this presentation draws upon a variety of sources, including published FDA warning letters, personal
experiences, interviews and research, all or any of which may or may not have been prepared or conducted by Cerulean Associates LLC. Cerulean Associates
LLC does not provide a warranty concerning the accuracy of the information contained in this presentation. The contents of this presentation are intended
for general information only and should not be construed as legal advice. Cerulean Associates LLC assumes no liability for actions taken or not taken as a
result of the information in this presentation. This presentation is copyrighted 2011 by Cerulean Associates LLC, all rights reserved.
3
5. 21 CFR 820.30
(a) “General. (1) Each manufacturer…shall establish and maintain
procedures to control the design of the device in order to ensure that
specified design requirements are met.”
Translation for FDA inspectors
“The purpose of the design control subsystem is to
control the design process to assure that devices meet
user needs, intended uses, and specified requirements:
• Inputs must be documented
• Outputs must be documented
• Confirm that device outputs are traceable to design inputs”
5
6. 21 CFR 803.18
(b) (1) (i) “…including all documentation of your deliberations and
decisionmaking processes used to determine if a device-related death,
serious injury, or malfunction was or was not reportable….”
Translation for FDA investigators
“A firm must demonstrate that it exercised “good faith” in
any attempts to obtain required data…. In addition, the
Center believes that the parameters of good faith must,
at a minimum, comport with the level of risk/nature of
the device….”
6
7. 21 CFR 806.20
(b) (4) “Justification for not reporting the correction or removal action to
the FDA, which shall contain conclusions and any followups….”
Translation for FDA investigators
“Verify that non-reported device corrections or removals
meet the following criteria based on design controls:
• Risk is not increased
• Repairs are not unexpected
• Part replacement is not earlier than expected”
7
8. Other Requirements
FDA Guidance Documents
• Human Factors Points to Consider for IDE Devices (1996)
• Human Factors Implications of the New GMP Rule: Overall Requirements of
the New Quality System Regulations (1997)
• Design Control Guidance for Medical Device Manufacturers (1997)
• Medical Device Use-Safety: Incorporating Human Factors Engineering into
Risk Management (2000)
• Guidance for Industry 21 CFR Part 11; Electronic Records; Electronic
Signatures Validation (2001)
• General Principles of Software Validation (2002)
• Guidance for the Content of Premarket Submissions for Software Contained
in Medical Devices (2005)
• Draft Guidance for Industry and Food and Drug Administration Staff - In
Vitro Companion Diagnostic Devices (2011)
• Draft Guidance for Industry and Food and Drug Administration Staff - Mobile
Medical Applications (2011)
8
9. Other Requirements
GHTF Guidelines
• SG3 N:99 Quality Management Systems - Process Validation
Guidance (2004)
• SG3 N:15 Implementation of Risk Management Principles and
Activities Within a Quality Management System (2005)
• SG1 N:11 Summary Technical Documentation for
Demonstrating Conformity to the Essential Principles of
Safety and Performance of Medical Devices (STED) (2008)
• SG4 N:28 Guidelines for Regulatory Auditing of Quality
Management Systems of Medical Device Manufacturers - Part
1: General Requirements (2008)
• SG1 N:068 Essential Principles of Safety and Performance of
Medical Devices (2011 draft)
9
10. Industry Challenges
information overload
tracking and documenting
change is inevitable
disconnect between groups
innovate with VOC
getting to market faster
outdated technology
10
11. Information Overload
FDA
ISO
IEC
IEEE ANSI
GHTF
Source:
FDA Acronyms & Abbreviations List
(FDA.gov, 2011)
11
12. Funny Horror Story
“We submitted a 510(k) with the FDA. A few months later, we got a 482.
They checked our SOP, SRD, URS, DHF, and VMP then issued us a
483. The FDA said we didn’t have good V&V processes and we need to
improve our CAPA, FMEA, and RVTM documentation and processes.
So now our management team feels SOL and they have to ask for
more VC to get FDA approval.”
Translation
“This fictitious play on acronyms company was using
outdated and manual efforts to update documents,
versus using a tool that helps automate, trace and
document for them….”
12
13. Tracking and Documenting
Development Must Track and Document
• SOP : Standard Operating Procedure for Design Control
• DHF : Design History File
• SRD : System Requirements Document or PRD
• URS : User Requirements Specifications or SRS
• CAPA : Corrective and Preventative Action
• RVTM : Requirement Verification/Validation Trace Matrix
• VMP : Validation Master Plan
13
14. Change is Inevitable
documentation, tracking, verifying earlier
Cost of Change (incl.
tests, add’l tests, etc.)
Perception
Reality
Requirements Early Design Protype Production Clinical Final Production
Time (development cycle)
Source:
Adapted from Scott Ambler, Agile Modeling (2002)
14
15. Disconnect Between Groups
Lack of Effective Communication
• Change : Usually Delayed and Not Automated
• Handoffs : Usually Delayed and Not Automated
• Vernacular : Usually Different Naming and Taxonomy
• Departmental Silos : Disparate Processes and Systems
Nobody Looking at Bigger Picture
• Decisions : Made at Departmental Level
• Traceability : Usually Not Accurate or Automated
• Documentation : Requires Multiple Data Elements
• Perception : Already have Solution; QMS, PLM, etc…
15
16. Innovate with VoC
Get VoC and Use It
• Get it early and often
• Share it on use cases/user stories
• Manage and communicate feedback from clinicals
Don’t let Documentation Hold You Back
• Lower risk items can be fast-tracked
• Agile: Scrum, XP
• Six Sigma: LEAN
16
17. Getting to Market
Source:
Design Control Guidance For Medical Device
Manufacturers (2011, FDA)
17
18. Getting to Market Faster
AUTOMATE
Source:
Get to Market Now! Turn FDA Compliance
into a Competitive Edge (2010, Logos Press)
18
19. Outdated Technology
Challenges from Evolving
• Reactive Mode : Too Much Manual Operations
• Departmental Silos : Disparate Systems
• Fear : Resistance to Change and Validation
• Compliance : Over Interpretation of Regulations
• Too Big : Simply Believe It Cannot Be Solved
• Knowledge : Simply Don’t Know Technology
• Cost : Perception of Total Cost
19
20. An Ideal Solution
traceable content reuse
integrated into daily activities
transparent enforceable workflow
processes generate good documents
20
21. Beyond Compliance
greater visibility
better content reuse
focus on getting work done
faster development cycles
stronger user adoption
higher quality
21
23. Want More?
Seapine Life Science Solutions
http://www.seapine.com/lifesciences.html
FDA Expectations for Traceability
http://www.youtube.com/v/iB8JDuHTdIk
Six Exercises to Strengthen Traceability
http://downloads.seapine.com/pub/papers/SixExercisesStrengthenTraceability.pdf
Traceability Resources
http://www.seapine.com/traceability.html
The Seapine View Blog
http://blogs.seapine.com
23
24. Picture Credits
Photos, images and clip art that appear on these slides have been used to enhance this presentation and may NOT
be used for commercial or promotional purposes without permission from copyright holders. Do not remove or copy
from this presentation.
Contact:
iStockphoto.com
Microsoft Corporation
Seapine Software
Cerulean Associates LLC
Logos Press
24
Notes de l'éditeur
MODIFIED TO REFLECT MORE PRODUCT DEVELOPMENT RELEVANT REQUIREMENTS, LIKE?CONSIDERATION:Providing Regulatory Submissions in Electronic Format — General Considerations (2003)Draft Guidance for Industry, Third Parties and FDA Staff: Medical Device ISO 13485:2003 Voluntary Audit Report Submission Program (2010)Strategic Plan for Risk Communication http://www.fda.gov/AboutFDA/ReportsManualsForms/Reports/ucm183673.htmTOOK OUT:Radiation Safety Considerations for X-Ray Equipment Designed for Hand-Held Use(2008)Technical Considerations for Pen, Jet, and Related Injectors Intended for Use with Drugs and Biological Products(2009)Clinical Investigations of Devices Indicated for the Treatment of Urinary Incontinence(2011)
MODIFIED TO REFLECT MORE PRODUCT DEVELOPMENT RELEVANT REQUIREMENTS, LIKE?CONIDERATION:SG1 N:63 Summary Technical Documentation (STED) for Demonstrating Conformity to the Essential Principles of Safety and Performance of In Vitro Diagnostic Medical Devices (2011)SG3 N:18 Quality Management System - Medical Devices - Guidance on corrective action and preventive action and related QMS processes (2010)TOOK OUT:SG5 N:2 Clinical Evaluation(2007)SG5 N:3 Clinical Investigations(2010)AHWG N:2 Unique Device Identification (UDI) System for Medical Devices(2010 draft)
1st CLICK: FDA, ISO, IEC, IEEE, ANSI, and GHTFIt is not easy to put your head around all the documentation and process information used in medical device development, let alone all the acronyms used by the industry. I thought I would go to the FDA's web site and get a listing of these, here are just a few of the over 3,700 that were listed in their zipped text file.2nd CLICK: Common Industry Acronyms Used in Medical Device DevelopmentThere is a ton of information and terminology we all must understand.3rd CLICK: OMGThis is how most feel with all the jargon used in our industry. Before your head explodes, if you are new to this industry, lets move onto a short story.SOURCE: http://www.fda.gov/AboutFDA/FDAAcronymsAbbreviations/ucm070296.htmNot all shown above are part of this text file, like: MRD, PRDBetter SOURCE specific to Software Development Terminology: http://www.fda.gov/ICECI/Inspections/InspectionGuides/ucm074875.htm
Here is a story from a fictitious (that’s the funny part) small medical device company some of you might be able to relate with using acronyms and jargon from our industry.Unfortunately, this is a sad reality and a horror story for some, because it’s difficult to get your head around all the things you need to track and document. Here are a couple things that should be easy to get your head around.
As a life sciences company, you must document key development activities and make them completely auditable, just ask your compliance guy. This is pretty standard stuff from the FDA, ISO, and IEC.SOP, DHF, PRD, URS, CAPA, RVTM (this was not part of FDA's Acronym list, but commonly used for Requirement Verification/Validation Trace Matrix)
For the most part, companies realize that change is going to happen, especially if they try to adopt faster development methodologies, want to react to market trends, or leverage newer technologies.It will likely happen at every level. Requirements > Design > Specifications > Coding > Testingno matter how well you analyze or review. Change is going to happen!
Disconnect between teams usually happens with larger organizations, but can also exist with smaller organizations. I’m not going to read each of these items, as I believe some of you can quickly relate, but instead will ask three questions:Are you sifting through documents looking for the relevant information to do your task?Are you the last one to know about a change to a specific requirement?Does your organization manage traceability in a spreadsheet?If you don’t believe you have any of these problems, then you should probably jump off of this webinar.
HELP!
HELP!Design controls may be applied to any product development process. The simple example shown in Figure 1 illustrates the influence of design controls on a design process.Seems very waterfall, but they say’s it’s not practical?“CONCURRENT ENGINEERING. Although the waterfall model is a useful tool for introducing design controls, its usefulness in practice is limited. The model does apply to the development of some simpler devices. However, for more complex devices, a concurrent engineering model is more representative of the design processes in use in the industry.In a traditional waterfall development scenario, the engineering department completes the product design and formally transfers the design to production. Subsequently, other departments or organizations develop processes to manufacture and service the product. Historically, there has frequently been a divergence between the intent of the designer and the reality of the factory floor, resulting in such undesirable outcomes as low manufacturing yields, rework or redesign of the product, or unexpectedly high cost to service the product.”
Ideally an image that might reflect a more Agile approach with lower risk items taking a separate path.I think we want to stay focused – the key message on this slide is that you have a LOT going on over a LONG period, and if you don’t automate (i.e., buy Seapine SW), how to propose to stay in control, stay on top of things, and keep costs down?Let’s use this one from my book – and I’ll talk to the Agile approach and lower risk while tackling compliance … lots of balls in the air so need to automate.
Most life sciences companies are beyond paper-based tracking, but still are managing Office documents in a QMS or Document Control System. Many other industries have evolved to take advantage of the latest technology that gives them better visibility and efficiencies, thus providing them a competitive advantage with faster and more effective ways to do the same thing.
NEW IMAGE NEEDED
NEW IMAGE NEEDEDCome Back from Demo
Do we have (or need) something that helps them document the ideal solution? It sounds like we’re proposing they do something along the lines of a RFP, which is just more documentation that they don’t have time to do.Wouldn’t management be involved in documenting the ideal solution, in which case their buy-in would be needed prior to documenting?What about steps like this:Identify challenges and gaps in current processes/toolsGet management buy-inPilot potential solutionsImplement optimal solution