What Medical Device Software is
What is medical device software? And why would its “standard of care” be an important subject?
In simple terms, medical device software is a component of, or an accessory to, a piece of electronics that interacts with the human body (see figure 1).
Figure 1: A medical device which is highly dependent on internal software. In it, software collects, manipulates and displays blood pressure, data on lung function, electrocardiogram and blood composition.
“Standard of Care” is a key phrase in many areas of law and expert witnessing. In fields as diverse as construction and medicine, “standard of care” refers roughly to what a professional of ordinary skills would do in the same or similar circumstances. Violation of the standard of care which causes harm can result in legal liability.
In medical device software, the “standard of care” refers to the process by which software should properly be created, documented and maintained.
Why does software development go wrong so often?
One might think that software could be developed in an orderly and disciplined fashion to create predictable results. This is what patients and physicians expect from medical devices whose failure can have devastating effects. And for small projects with skilled programmers, this is often the case.
But large-scale software development for medical devices rarely works like this. A superb book by Fred Brooks entitled The Mythical Man-Month (figure 2) describes why.
Figure 2: Frederick Brooks’ classic volume explains why software development can be usefully likened to dinosaurs thrashing around in tar pits until they drown. His elegant writings are highly recommended to anyone involved in the software development process.
Brooks, who managed software development at IBM, describes many issues as relevant today as when he penned them in 1975. His most telling point is about communication. The capacity of a team of engineers grows proportionally with the size of the team, but the effort and time spent on communication grows roughly as the square of the size of the team.
This means that large software projects, staffed by large teams, have a greater tendency to fail because communication needs overwhelm the resources of the organization to facilitate them.
Coping Mechanisms
Many regulatory bodies have stepped in with standards aimed at improving software in the medical device field. Prominent current standards include:
-
- IEC 62304 – This European standard is recognized by the US FDA as defining requirements for medical device software development.
- ISO 14971 – A document detailing ways of managing risk in medical device development.
- IEC 60601 – Concerns technical safety and effectiveness benchmarks for medical electrical equipment.
- ISO 13485 – Describes quality management systems for medical devices.
Numerous other standards and documents (e.g., [1]-[4]) should also be considered by the developer of medical device software.
Quality Control and Medical Device Software
There are many steps that a development company can take to ensure quality medical device software. These steps could include:
- Taking a holistic view of the entire software life-cycle.
- Extensive V&V (verification and validation) testing.
- Attention to the Design History File. These are the records describing the product, its history, testing and reviews. These must be updated even after the product’s release, to respond to alterations by FDA in its requirements, and any changes in the firm’s quality system.
- Document version control.
- Defect Tracking – from when bugs are found, to developer assignment, implementation, verification and deployment.
- Complaint Management – tracking complaints from inception to closure.
- Corrective/Preventive Action (CAPA) – tracking Corrective and Preventive actions from inception to closure.
- Reports to show project status, defects, training assignments, complaints, CAPAs and document approvals.
Litigation around medical software standard of care
The combination of a fraught development process and a complex regulatory environment makes litigation in this area common.
Frequently, the software for a new medical device is contracted by the original equipment manufacturer to an independent firm. Contractual disputes abound when the resulting software lacks features, exhibits bugs, or is delivered late or over budget.
In these cases, a medical device software expert witness can assist lawyers in discovering what has gone on in the development process, and what the state of the software is. The medical device coding expert witness can use specialized tools (e.g. Coverity, Understand, PMD, etc.) to evaluate important characteristics like source code complexity. Further insight into the software can come from static program analysis and architectural analysis.
About the author
Dr. Chris Daft is an award winning, Oxford Educated scientist. He is an expert witness and consultant whose areas of expertise include medical devices, software quality, MEMS, transducers, ultrasound and medical imaging. Dr. Daft also has extensive Intellectual Property experience including patent development, analysis, licensing, and strategy. He is a serial inventor who holds 22 U.S. Patents with more pending. Dr. Daft holds a BA and MA in Physics from Oxford as well as Doctorate from Oxford in Materials Science. The author may be contacted at:
chris.daft@riversonicsolutions.com
+1 (415) 800-3734 +1 (408) 806 7525
River Sonic Solutions LLC 2443 Fillmore St #380-4039, San Francisco, CA 94115.
References
-
- IEEE Standard 24765:2010, Systems and software engineering — Vocabulary
- ISO/IEC Standard 8631:1989, Information technology — Program constructs and conventions for their representation
- ISO Standard 90003:2014, Quality management and quality assurance standards — Software engineering — Guidelines for the application of ISO 9001:2008 to computer software
- IEEE Standard 1061-1998, IEEE Standard for a Software Quality Metrics Methodology
