Software used in the medical device industry presents more risk than in many other industries. For example, an application used to store financial data in the banking industry could certainly have negative effects if it fails, but it is highly unlikely that such a failure would be related to the death or serious injury of a human.

It is easy to recognize that software used within a medical device is critical, but beyond that software utilized in the manufacturing of the medical device and in support of the operations of the quality system are also important. This is where many medical device industry professionals struggle. Part of this struggle is related to the complex and cumbersome nature of software validation for the riskiest software, which sucks up resources (people, time, money); there is very little left to address validation for the less-risky software (e.g., simple spreadsheet that tracks training metrics). Another part of this struggle is a basic misconception about what software validation is and how simple systems may affect the patient.

David Vogel’s Medical Device Software: Verification, Validation, and Compliance addresses these and other challenges the industry faces related to software. The text is a comprehensive guide to “all things software” in the medical device industry. He clearly communicates his intent in the first part of the book, which is supported by his statement, “I don’t trust software.” (Vogel, D., pg. XV) His intent is to share his experiences, remind the reader repeatedly why validation is important and why it should add confidence, convince the reader to take software validation seriously, and ultimately, make devices safer. He states, “None of us wants to worry about device safety when we see a device connected to a loved one.” (Vogel, D., pg. xvii)

Vogel is founder and president of Intertech Engineering Associates, Inc, which started in 1982. The company has served the medical device industry for 29 years with electronics hardware and software development services. He has also participated in an AAMI/FDA work group to develop a standard for critical device software validation, which is part of IEC 62304. He contributed to the creation of TIR36:2007, which focuses on the validation of software for regulated processes. Vogel is a frequent lecturer at conferences and webinars and contributes to articles for various industry publications. Additionally, he is an AAMI instructor, serves as an editorial advisor for two industry magazines. His experience and expertise is evident throughout the text. (Vogel, D., pg. 409)

There are 407 pages dedicated to the 20 chapters in the book, which includes three parts:

• The first part sets the background and premise for software in the industry. It presents the regulatory background and its evolution, why validation should be performed even if it’s not required by regulation, some organizational considerations, definitions of verification and validation for the industry, and information on the software development lifecycle and its supporting activities.

• The second part of the book focuses on validation for software in the medical device. It presents the information according to the phases of the development lifecycle. The phases covered include concept, software requirements, design and implementation, testing, and maintenance.

• The third part of the book augments part two by pointing out the differences between validating nondevice software compared with quality system software. There is a focus on the differences in validation planning, risk management, configuration management, testing, and maintenance and retirement. Multiple times throughout part three, the reader is referred to part two for more detailed information.

Since the book covers all aspects of software for the industry, the stated audience is large. The audience of the book is meant to be quality assurance engineers, software developers, software users, compliance professionals, and corporate management. An experienced software professional may not find value from reading the book from beginning to end; it is probably more beneficial to review it at a higher level and use it as a reference to address problems when they arise. An individual with little experience will benefit more from a cover-to-cover read because the book provides the basics of software validation and provides the reasons that drive medical device industry requirements.

Corporate managers will most likely not benefit from reading this book as they do not need to know how to carry out the details of software validation. It is more reasonable to believe that someone will provide a summary of the book to corporate management or reference it to support decisions made at the developer or compliance manager level. It would be powerful to present this summary and a glimpse of the book to management along with other guidance in the industry to emphasize the importance of software validation and its visibility in the industry. An inexperienced user who is thrown into validation may not benefit from the book, because it would likely be overwhelming to them. Someone not familiar with software would have a difficult time following the complex concepts.

Vogel presents the challenges of software validation frankly and prompts the reader to think about the why of what they may be doing. He discusses the struggle between quality professionals and developers. He states, “Too many developers spend too much time coming up with clever ways to get around the quality system, or to prove to themselves that the efforts of the quality team are worthless. Likewise, too many quality professionals spend too much time getting too involved in the development process…” (Vogel, D., pg. 3) It’s clear that he promotes a healthy balance between quality and requirements for software validation.

He clearly states that professionals in the industry should not be creating paperwork just for the sake of creating it. His focus is on building confidence in the software in a practical way, and he provides several examples of flexible tools to implement for differing needs of software validation, which he claims cannot be a one-size-fits-all approach. He includes examples of other tools such as information on what constitutes quality system. He also provides a diagram that details the regulation and includes software examples (Vogel, pg. 331).

A lot of basic software development life cycle information is included that is not specific to the medical device industry. The life cycle information is relevant and points out the specific medical device industry elements, but much of it repeats already known practices. An experienced software professional will already know much of this content or will have the wherewithal to find the information. Additionally, there could have been more information focused around simple systems and how these could affect the medical device and ultimately, the patient.

Overall, this book will be most beneficial as a reference and guide for the experienced practitioner. Aside from that, it would be best used as a text for training or a course for inexperienced professionals. The presentation of the challenges that the industry faces and some of the ideas for practical application are very beneficial to any audience, but are integrated throughout, so it would be difficult to just focus on those aspects of the book while reading.

Vogel ultimately captures the essence of the criticality of medical device software and accompanying process software, which is also known as nondevice or quality system software. He covers all aspects of the regulation and the software development lifecycle.