Welcome to the final installment of our series on Controlled Software Development for medical devices. With the design, implementation, and early testing phases completed, it is time to move on to late-stage development phases. As we will see, even though these phases technically come last in the process, they need to be kept in sight from project outset. Preparing well for late-stage controlled software development phases even while you’re conducting feasibility studies and making configuration management decisions set you up for smooth project flow and on-time submissions. Let’s take a look:
Human Factors Study
It is essential that human factors engineering be taking place throughout the software development process. For example, if the device includes a user interface, show sample screens to potential users as soon as they are produced. It is much easier to identify human factor issues early in the process.
Human factors testing includes both qualitative and quantitative testing. In qualitative testing, users are presented with the whole process and must use the device without being guided in each step. What errors in use are noted? What seemed to confuse or frustrate the user? Was there anything that distracted them?
Quantitative testing implements a disciplined workflow where the users are asked about every detail of the user-interface—every screen, button, control, readout, etc. Prior to this testing, as part of risk management, a predetermined percentage of positive results that are required on any unit or set of units must be identified and documented. Any aspect of human factors testing that does not meet that percentage must be reworked and taken back through the process.
System Testing
Now it is time to test everything as a complete system. The system test procedure should be planned ahead of time (as part of the overall Test Plan, at the requirements and design phases). There should be clear delineation, based on your previously-determined requirements documents, of what a “complete” software system looks like.
System testing should also include a formal code review by knowledgeable programmers who have not been a part of the development of the code under scrutiny. The discipline of presenting code to another programmer often identifies weaknesses in architecture that the author could not see in the midst of coding.
Documentation & Traceability
As should be clear by now, even though we’re presenting it here as if it is a final step, rigorous documentation following accepted industry standards must occur throughout the development process. Though many developers dislike documentation, in the eyes of a regulator, if something is not documented, it did not happen. Controlled software development requires not only that the software has safety and functionality, but that the medical device’s Design History File (DHF) contains complete records of each safety and functional element’s design, implementation, and testing. Furthermore, DHF artifacts must include traceability so that reviewers, regulators, and auditors can follow the granular development of individual elements from each process phase to the next.
Development Wrap-up
As we have seen, a reliable software design process for medical devices is disciplined and methodical. While there is significant creativity and coding skill that goes into the best software medical devices, it must occur within a framework that understands that safety and efficacy are paramount to all other concerns.
As a final thought, you will note that the software development process presented here is relatively restrictive. Changes cannot be made to any component without affecting all of the others—a change to a system requirement requires a new risk analysis, an updated to the detailed design documents, new testing of the changed unit as well as the system as a whole, etc. While such changes can be made, careful planning at the outset by an experienced team can minimize such changes and subsequent delays.
Maintenance Planning & Future Development
Developing well-controlled software for medical devices doesn’t end with market approval. Once a system is designed and planned, it must be version-locked as part of the implementation. Planned releases need to be gated against the documented design, and any ideas, feedback, or additional development work need to be isolated into a “Phase II” repository for future release. This disciplined approach ensures that the software portion of a medical device will not hold back completion or approval.
While it is possible that responsibility for the wellbeing of your software in the field may be transferred from a development team to a maintenance team, even emergency updates, like critical bug fixes and vulnerability patches, must be planned for and deployed in a controlled manner. Even though you can’t necessarily anticipate the content of these updates, you can and must leverage the know-how from your development team and your maintenance team to define the process by which the need for updates will be determined, classified according to response type and time, securely developed & delivered, and verified for efficacy after deployment.
In other words, initial release can’t be the final goal of your software design, with activities taking place afterward being treated as an afterthought or a task for someone else. In order to truly mitigated risks and vulnerabilities of your design, controlled development must include planning for controlled maintenance.
This concludes our brief overview of controlled software development for medical devices. Contact us to learn more about how Velentium can partner with you to develop secure, controlled, regulation-documented software for your medical device.
