Managing a Medical Device Project with an Embedded Software Component

By Rick Sabourin, Senior Software Engineer

A recent post on the MD&DI DeviceTalk blog is titled, “Understanding the Software Development Process When You’re Not a Software Engineer”. This article focuses on the challenge of managing a medical device project with an embedded software component, and it touches on a number of points which I think deserve highlighting. In my experience, those who are not familiar with medical software development will sometimes suggest merging the design phase into preceding or subsequent phases, in an effort to save time and money. Additionally, some people seem to have the idea that using a well-defined software lifecycle process is pedantic or excessive. At Ximedica we recently underwent a review and subsequent re-architecting of our software SOP to incorporate IEC-62304, HE-75, and FDA draft guidance documents into a streamlined software development process that is now fully integrated into the entire multi-disciplinary medical device development process.

Similar to the points put forth in the MD&DI blog here is what we emphasized to the non-software engineers on our team in drafting this process:

An SRD also serves as the base document for the software quality assurance team, which develops test protocols to verify that every requirement is fulfilled in the end product.
Imagine if the sponsors of the Eiffel Tower had decided they wanted five legs instead of four, after construction was half complete.

• The Planning and Research phase of a project will often include the development of prototypes or breadboards to test or demo some important aspect of the technology. But it is a mistake to assume that these prototypes can translate directly into marketable product. Thorough planning and documentation are crucial to an efficient and successful development effort.
• While the Software Requirements Document (SRD) may seem like redundant paperwork to some, it is in fact a crucial part of any successful project. The software requirements serve as a contract, defining exactly what the software will and won’t do, and how it will interact with its environment (including hardware, other software, and users).
• During the Design and Development phase, requirement changes are often unavoidable. But all project stakeholders need to be aware that, “requirement changes during this phase become progressively more expensive and constrained as more and more design and code needs to be updated to accommodate them.”