By Jeff Jackson, Director of Quality Assurance
The need for high quality medical device software seems so obvious you might wonder why it needs to be talked about. But how you achieve quality is an excellent topic for discussion. Here are the four principles that are key to the successful development of high-quality medical device software at CriTech. You can watch my video, or read this simple checklist version.
1: Standards Are Your Friends
IEC 62304 defines a set of standardized processes and activities for software that supports a safe, effective device. If you look at them as obstacles to getting the job done, they will not serve you well.
Instead, look at IEC 62304 as a basic framework to help you structure your software development effort.
Here are a couple of friendly reminders:
- Trying to save money or time early in the development life cycle can lead to far higher costs later.
- Medical device software standards like IEC 62304 are not in themselves a complete quality system, or even a complete set of processes that may be needed for a particular device.
2: Software Quality Assurance Begins Before the First Line of Code
When you read IEC 62304, you see that there is no defined process for software quality assurance. That’s because software development is not a compartmentalized process, but an integral part of every other process. It needs to be practiced from the very beginning of software development.
Other shortcuts to avoid:
- Putting off design, or code reviews, until near the end
- Writing code and then going back to “harden it” later
- Code freezes that never freeze
- Outsourcing code without reviewing it sufficiently
Software quality starts with the software requirements.
IEC 62304 places a big emphasis on developing comprehensive requirements
before you write any code.
3: Software Quality Cannot Be Tested In
No amount of testing can compensate for poorly written software requirements, inadequate design, or undisciplined coding.
Testing cannot prove the software is free of bugs. In fact, it needs to focus on disproving exactly that. Even with a strong front-end effort, if you design your software tests to focus mainly on nominal success conditions, you’ll overlook opportunities to find bugs by using unexpected inputs and testing unusual conditions.
Keep in mind:
- The most error-prone portions of the software should be tested the hardest. That includes safety-related code, complex code, and parts of the software that could cause a device failure in case of error.
- Software written to mitigate risks is also prone to errors. For this reason, software risk analysis should be performed as early in the life cycle as possible.
- It is far easier to implement and test risk controls as part of coding and testing than to retrofit them in later.
In his classic textbook, The Art of Software Testing, Glenford Myers defines a good test case is one that has a good likelihood of finding a bug, and a successful test case is one that does.
4: Everyone Must Be Part of Software QA
Everyone on a software development team wants high quality software, but it’s harder to produce if it is seen as someone else’s responsibility.
At CriTech, QA is part of the development effort for the whole team from the very start. We train our entire development staff in our quality system, which is based on IEC 62304. While we teach the concepts of software quality, we focus on our proven processes and procedures.
The CriTech Takeaway
Focusing on the four principles I just covered – seeing standards as useful tools instead of obstacles, building in quality from the very start of development, understanding the value-added part of testing, and involving the entire development team in software quality – is part of a larger overall approach to developing high quality software.
If you have questions, want assistance getting started, or need help along the way, talk to CriTech today.