What Makes Medical Device Software Design and Development Different?
Software development in general follows a particular flow. This article describes the software development process for medical device products and some of the notable differences within. Some examples of medical device products include everything from user interface design for image guided surgical tools, intraoperative devices, CT/MRI (as shown in Figure 1) and fluoroscopy imaging systems, surgical robotics and devices for tumor ablation.
Figure 1. MRI Scanner with head coil. Image Courtesy of Wikimedia Commons
The FDA (Food & Drug Administration) classifies medical device software into Class I, Class II and Class III device types depending on the potential of severity of harm to the patient in the event of a device malfunction. The ISO 13485 standard, describes various phases of the software development lifecycle and the standards of conformance for clinical use. [1] This standard works in conjunction with the regulatory aspects of development and really sets forth a foundation of best practices for device development.
The various stages within medical device development include:
- Software proposal / software requirements
- Design and development
- Software verification
- Software validation
The software proposal phase is when initial mockups of the product can be designed with minimal documentation. This research and development phase helps shape product concepts, develop prototypes and receive clinical and user feedback. Documentation for this phase involves market research, scientific research, literature review and clinical workflow analyses. The software requirements phase is the first formal project phase when requirements are generated through various brainstorming sessions with the marketing group and clinicians.
Agreed upon requirements have to be validated and tested in the final device. To do this, having a development methodology in place that allows for stringent standards with specific approval along the way lends itself to the success of the device. The design and development phase involves implementing the requirements and can include; software architecture, unified modeling language (UML) diagrams and use case scenarios to meet the product specifications. These elements make up the design specification document and will have a review and approval processes as part of a formal phase gate review.
The software can now be built and implemented based on the design specifications. Accurate revision history logs will need to be maintained as part of the change history documentation for any software to be developed in tandem with detailed feature and quality assurance tracking. The change history logs are useful in reverting to the previous version of the software prior to a commit that might involve a bug fix. This allows engineers to compare the state of the software, analyze the impact of bug fixes or feature implementations.
The software requirements and design documentation is then updated based on changes made to the software.
Developer Level Unit Tests are written as part of this phase. Additionally, this phase involves software risk management, which includes defining risks associated with individual features and design details. The risk assessment process should also involve mechanisms to mitigate risks and residual risk measures associated with the device. The updated requirements and design specifications documents are approved before proceeding to the next phase.
The software verification phase involves verifying the functional form of all software developed with the help of software verification checklists and verification protocols. These protocols are implemented and documented in their respective software verification reports. The regression tests necessary to verify the functionality are executed in this phase. Various off-the-shelf software components used within the software are identified and their functionality is verified in detail based on the level of risk associated with the device. It is important to verify functionality of the software as it is critical to the function of the device.
As in previous phases, the verification checklists and protocols are approved and any outstanding software requirements and design specifications are updated. The software validation phase involves accurate validation protocols and procedures that further authenticates the efficacy of the software functionality developed. The main difference between verification and validation is the verification process will test the software requirements and the validation process will test the design specifications. The validation process would involve generating hardware jigs, fixtures and mechanisms to validate the functionality of the software and any phantoms to provide optimization of its performance.
Examples of this process include MRI/CT phantoms to test the image processing functionality of software as well as features such as segmentation and image registration. Any precautions necessary for safety measures need to be listed in the training manual and documentation for the software with necessary contraindications.
Figure 2: Radiation therapy planning software for Mevion Medical Systems
The software developed as part of this process is now in conformance with the FDA requirements for the intended use of the device. Figure 2 shows an example of software for radiation therapy from Mevion Medical Systems. [2] In this instance, a design transfer process ensures release of software to outbound shipping or manufacturing as the case might be. Post-operative documentation of the clinical software is necessary to ensure long-term use of the device after release.
The user experience (UX) development process for medical device software is largely based on the process described.
Functionality in graphical user interface (UI) controls including 3D visualization and patient monitoring services entail thorough requirements, design specification and use case scenarios. Testing the device functionality in real world environments such as the operating room is vital and should include offline mode testing as well. The latter is addressed using verification checklists that cover an exhaustive list of UI control operations and its action with expected output and clinical software workflow.
When Qt/QML is used for creating graphical user interfaces, the software documentation must include revision history for change control in the Qt development process. This should also include a description of user interface guidelines and performance tests characterizing the stability of Qt software on workstations and embedded platforms. The FDA has cleared the QNX OS for Medical 1.1 in conformance with IEC 62304 standards as a platform for medical device software development [3]. Various gesture controls and interoperability (IO) devices can be incorporated to improve the clinical interface adding to patient safety and improved surgical intervention. The illustrations below indicate the power of visualization applied to medical image reconstruction and display.
Image [A] BrainVISA HBM (Human Brain Mapping) Image [B] VTK.org Creative Commons
Figure 3. Examples of volumetric reconstruction using BrainVisa and VTK. [4, 5, 6]
The rise of mobile healthcare applications has driven the FDA to provide guidelines for development of healthcare applications on mobile devices, information via a PDF download can be found on the FDA website. [7]
A comprehensive list of guidelines to develop applications that represent clinical software, healthcare apps and/or are part of a medical device are described within the document. The applications may contain visualization software components that form an organic part of the clinical software solution on a medical device or applications that monitor and provide a therapeutic course of action for clinical conditions. While it’s true that most of the clinical software requirements for workstations are applicable to mobile applications, there might be additional requirements in terms of stability and choice of platform for intended use and safe functioning in the operating room (OR).
Medical device software development has strict regulatory requirements that insist on a lifecycle development process to include stringent validation protocols to make it feasible for those designers and engineers seeking to develop these important products that can save lives.
References
- Wikipedia IEC 62304 Medical Device Software, Software Lifecycle Processes, website last accessed February 9, 2015, http://en.wikipedia.org/wiki/IEC_62304. Figure 1 Image Courtesy of Wikimedia Commons
- Photo credit, Mevion Medical Systems, Figure 2
- QNX Corporation, QNX OS for Medical, website last accessed February 9, 2015, http://www.qnx.com/products/certified_os/medical.html
- BrainVISA research paper, D. Geffroy, D. Rivière, I. Denghien, N. Souedet, S. Laguitton, and Y. Cointepas, A Complete Software Platform for Neuroimaging, in Python in Neuroscience workshop, Paris, Aug. 2011, web article last accessed February 9, 2015, https://www.google.com/?gws_rd=ssl#q=BrainVISA:+a+complete+software+platform+for+neuroimaging
- The BrainVISA project, Y. Cointepas, D. Geffroy, N. Souedet, I. Denghien, and D. Rivière, A Shared Software Development Infrastructure for Biomedical Imaging Research, In Proc. 16th HBM, 2010, web article last accessed February 9, 2015, http://static.lnao.fr/papers/Cointepas-HBM10.pdf
- Visualization Toolkit, W. Schroeder, The Visualization Toolkit, (3rd Edition, Kitware, Inc., 2003), website last accessed February 9, 2015, www.vtk.org. Images Courtesy of: Image [A] BrainVISA HBM (Human Brain Mapping) Image [B] VTK.org Creative Commons
- FDA, Medical Device Guidelines, PDF download from website last accessed February 9, 2015, (http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM263366.pdf)