Medical Device Development - Automating Traceability and Documentation
•
2 recomendaciones•1,371 vistas
Recomendados
Recomendados
Más contenido relacionado
Destacado
Similar a Medical Device Development - Automating Traceability and Documentation
Similar a Medical Device Development - Automating Traceability and Documentation (20)
Más de Seapine Software
Más de Seapine Software (20)
Último
Último (20)
Medical Device Development - Automating Traceability and Documentation
- 1. Automating a compliant approach to fast, innovative product development John Avellanet Cerulean Associates LLC www.CeruleanLLC.com © Cerulean Associates LLC all rights reserved
- 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
- 4. Understanding Requirements governmental regulations core documentation and reporting 4
- 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
- 22. Next Steps document ideal solution get management buy-in find right solution 22
- 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
Notas del editor
- 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