Software in Medical Devices, by MD101 Consulting

A recurring question is the confusion, or more precisely the difference between software release of IEC 62304, and design transfer of ISO 13485.

Usability is a requirement, which has been present in regulations since a long time. It stems from the assessment of user error as a hazardous situation. It is supported by the publication AAMI HE75 standard, FDA guidances, and the publication of IEC 62366 in 2008 followed by IEC 62366-1:2015. Although usability engineering is a requirement for the design of medical devices, most of people designing software are not familiar with this process. This article is an application of the process described in IEC 62366-1 to software design.

Validation of software is an unlimited source of topics!
After discussing in a previous article the validation of software in development process, let's see how to validate software used in production processes and in the management of QMS documents and records.

We saw in the last post how to validate a software development tool. But we saw also that validating a compiler this way is not a satisfactory task.
Then: Why, when, and how to validate a compiler?

If you've haven't heard about Apple's security flaw registered as CVE-2014-1266 on apple website, you probably were on planet Mars.
Basically, it was unsafe to use https connections. I couldn't help but write an article about this!
Components dealing with secured connections are abolutely critical. Applying rigorous development process is the best chance to avoid any trouble with these components.

Your company develops medical web apps (HTML/JS, HTML5 or any other client-side technology) and your customers would like them to run on every web browser.

Web browsers are SOUP, according to IEC 62304. In case of Chrome and Firefox there are dozens of versions...

Does it mean that software has to be tested - and documented - with every single browser and every single version of the browser?
That's a nightmare!

In my last article, I talked about the most classical methods used to verify software: human testing (driven by test cases or not) and unit tests. I was about to talk about static analysis, that I place at a higher level of complexity in the list of verification methods, but I have to say a bit more about unit tests.

Writing about V&V in two previous posts, I had a lot of comments from people on a well-known social network. They made corrections to my view of V&V and brought their own definitions.
Here is an excerpt of their comments.

Many people make the confusion between verification and validation. There is no exception for software! I'd even say that the confusion is even worse for standalone software.

Let's see first the definition of verification and validation. I borrowed these definitions from the FDA website:

• Verification is confirming that design output meets the design input requirements,
• Validation is ensuring that the device conforms to defined user needs and intended uses.

OK, this remains theoretical. How to do that with software medical devices?
In this article I focus on verification and will focus on validation in the next article: What is software validation.

Are agile methods compatible with the constraints of development set by IEC 62304 standard of class C software?
After a series of three posts about agile methods and risks analysis. I focus in this post on IEC 62304 class C critical software.