By (author): David A. Vogel

Copyright: 2016
Pages: 428
ISBN: 9781596934221

Artech House is pleased to offer you this title in a special In-Print-Forever® ( IPF® ) hardbound edition. This book is not available from inventory but can be printed at your request and delivered within 2-4 weeks of receipt of order. Please note that because IPF® books are printed on demand, returns cannot be accepted.


Our Price: $124.00
Qty:
Our Price: $102.00
Qty:

Description

Here's the first book written specifically to help medical device and software engineers, QA and compliance professionals, and corporate business managers better understand and implement critical verification and validation processes for medical device software. Offering you a much broader, higher-level picture than other books in this field, this book helps you think critically about software validation - to build confidence in your software's safety and effectiveness. The book presents validation activities for each phase of the development lifecycle and shows: why these activities are important and add value; how to undertake them; and what outputs need to be created to document the validation process.

 

From software embedded within medical devices, to software that performs as a medical device itself, this comprehensive book explains how properly handled validation throughout the development lifecycle can help bring medical devices to completion sooner, at higher quality, in compliance with regulations.

 

DVD Included: Contains a collection of FDA regulations and guidance documents related to software in the medical device industry, valuable sample forms and templates, and supplemental figures that support key topics covered in the book.

Table Of Contents
Part I: Background; The Evolution of Medical Device Software Validation and the Need for This Book - The Evolution of Validation in the Medical Device Industry. Building a Language to Discuss Validation. Risk Management and Validation of Medical Device Software. About This Book. Goals of This Book. Intended Audience. Are You Wasting Time?.; Regulatory Background - The FDA: 1906 Through 1990. The FDA Today (2009). How the FDA Assures Safety, Efficacy, and Security. Quality System Regulations and Design Controls. Understanding How Regulation Relates to Getting the Job Done. Medical Devices Sold Outside the United States.; The FDA Software Validation Regulations and Why You Should Validate Software Anyway - Why the FDA Believes Software Should Be Validated. Therac. Building Confidence. The Validation Regulations. Why You Should Validate Software Anyway.; Organizational Considerations for Software Validation - Regulatory Basis of Organizational. Responsibility. A Model for Quality Systems. Thinking Analytically About Responsibility. So, What Could Go Wrong with a Design Control Quality System?. What Happened?. Designing Streamlined RR&A Requirements for the Quality System. Fixing the Problem: Designing a Value-Added Approval/Signature Process. Regulatory Basis for Treating Approvals and Signatures Seriously.; The Software (Development) Life Cycle - What Is a Software Life Cycle?. Software Validation and SDLCs: The Regulatory Basis. Why Are Software Development Life Cycle Models Important?. What Do Different Software Development Life Cycle Models Look Like?. Waterfall and Modified Waterfall. Sashimi Modified Waterfall Model. Spiral Model. Extreme Programming: Agile Development Models. How Do You Know What Life Cycle Model to Choose?. How Do Software Development Life Cycles Relate to the Quality System?. The ANSI/AAMI/IEC 62304:2006 Standard. An Organization for the Remainder of This Book.; Verification and Validation: What They Are, What They Are Not - What Validation is NOT. Validation and Its Relationship to Verification and Testing. Software Validation According to Regulatory Guidance. Can Other Definitions of Validation Be Used?. User Needs and Intended Uses. Software Verification According to Regulatory Guidance. How Design Controls, Verification, and Validation Are Related. Validation Commensurate with Complexity and Risk. Is All Validation Created Equal?.; The Life Cycle Approach to Software Validation - Validation and Life Cycles. Combined Development and Validation Waterfall Life Cycle Model. A Validation Life Cycle Model. The Generic or Activity Track Life Cycle Model . Life Cycles and Industry Standards. Final Thoughts on Selecting an Appropriate Life Cycle Model.; Supporting Activities that Span the Life Cycle: Risk Management -Introduction to Activities Spanning the Life Cycle. Risk Management. Risk in the Regulations and Guidance Documents. ISO 14971: Application of Risk Management to Medical Devices. AAMI 's TIR32:2004: Medical Device Software Risk Management. Risk and the IEC 62304 Standard on Life Cycle Processes. IEC/TR 80002-1: Application of 14971 to Medical Device Software. The Risk Management Process. The Language of Risk Management. Risk Management Outputs. Risk Management Concepts and Definitions. Risk Management Activities. Risk Evaluation. Risk Control. Summary.; Other Supporting Activities: Planning, Reviews, Configuration Management, and Defect Management - Planning. Configuration Management. Defect (and Issue) Management. Reviews. Traceability. ; Part II: Validation of Medical Device Software; The Concept Phase Activities - The Concept Phase. Regulatory Background. Why a System Requirements Specification Is Needed. Validation Activities During the Concept Phase. Make or Buy? Should Off-the-Shelf (OTS) Software Be Part of the Device?. The System Requirements Specification. Who Is the Intended Audience?. What Information Belongs in an SyRS?. Further Reading.; The Software Requirements Phase Activities -Introduction. Regulatory Background. Why Requirements Are So Important. The Role of Risk Management During Requirements Development. Who Should Write the Software Requirements?. The Great Debate: What Exactly Is a Requirement?. Anatomy of a Requirement. How Good Requirements Are Written. Summary.; The Design and Implementation Phase Activities -Introduction. Regulatory Background. Validation Tasks Related to Design Activities. Validation Tasks Related to Implementation Activities.; The Testing Phase Activities -Introduction. Regulatory Background. Why We Test Software. Defining Software Testing. The Psychology of Testing. Levels of Testing. Testing Methods. Test Designs, Test Cases, and Test Procedures. Managing Testing. Automated Testing. Summary.; The Maintenance Phase Validation Activities -Introduction. A Model for Maintenance Activities. Collection of Post-Market Data. Analysis. The Maintenance Software Development Life Cycle(s). Software Release Activities: Version n + 1.; Part III: Validation of Nondevice Software; Validating Automated Process Software: Background -Introduction. Regulatory Background. Nondevice Software Covered by These Regulations. Factors that Determine the Nondevice Software Validation Activities Risk. Size and Complexity. Intended Use. Confidence in the Source of the Software. Intended Users Industry Guidance. Who Should Be Validating Nondevice Software?.; Planning Validation for Nondevice Software -Introduction. Choosing Validation Activities. Do-It-Yourself Validation or Validation for Nonsoftware Engineers. The Nondevice Software Validation Spectrum. Life Cycle Planning of Validation. The Nondevice Software Validation Toolbox. The Validation Plan.; Intended Use and the Requirements for Fulfilling Intended Use -Introduction. Intended Use. Requirements for Fulfilling the Intended Use.; Risk Management and Configuration Management of Nondevice Software Activities that Span the Life Cycle - Risk Management. Configuration Management for Nondevice Software.; Nondevice Software Maintenance and Retirement Activities - Maintenance Activities.; Retirement of Software. About the Author. Index.;

Author

  • David A. Vogel David A. Vogel, Ph.D is founder and president of Intertech Engineering Associates, Inc. in Westwood, Massachusetts. The company specializes in the management of hardware and embedded software development and verification/validation projects for medical devices. He has also served as principal bioengineer at Becton Dickinson Medical Systems, and as software engineer for Honeywell Information Systems. He earned a Ph.D. in biomedical engineering at The University of Michigan, Ann Arbor.