Last time I talked about how saying that software is compliant with IEC 62304 is not really a thing.

It’s not the software that is compliant with IEC 62304. It’s the process you used to create the software that complies with the standard. Because of that, taking existing software that was not developed with a compliant process, and just adding the documentation after the fact, does not make that software compliant. The documents, and the code itself, are the artifacts of correctly following the process.

This may seem like beating a pedantic dead horse, but it’s important to understand this concept.

But, in the real world, people often write prototype code, even for medical devices, in a quick and dirty fashion with little regard for process. Then, understandably, they want to bring that code up to snuff so that they can take their prototype device to production.

What do we actually do in this case?

I have a confession: Despite my rant against this practice yesterday, I actually prefer working this way. I’m working this way on a project right now. I wrote prototype code for a client myself, sidestepping most parts of a 62304 compliant process, to get a prototype unit working for a customer demo. Now, I’m going through a proper development process from the beginning, but using the lessons learned, and in many cases actual code snippets, from my prototype code.

Let’s look at the standard IEC 62304 software development process:

Here’s what you do when you are starting with prototype code.

You follow the process faithfully.

Software Risk Management must be done without regard to the prototype code. The prototype code has no effect whatsoever on the Software Risk Management process.

The system requirements (which incorporate the results of the system risk management and software risk management) drive the software requirements. Again, these should be developed incorporating lessons learned from using your prototype, but they should not be driven by the current state of your prototype code.

When it’s time to make design choices, you are informed by your prototype code. If you have multiple architecture alternatives that can fulfill the requirements, and one of them happens to be the architecture of your prototype code, well, then you can choose that one. No problem.

However, if the design of your prototype code will NOT meet requirements, then you CANNOT USE IT.

You do have the option of going back and modifying the software requirements so that your prototype code can satisfy them. But…

You cannot remove or loosen requirements that flow from your risk analysis.

This is where people get in trouble. They don’t want to spend more money developing new code. They want to use the prototype code as is. It works fine on the prototype, right? Even when they follow the process and develop a hazard and risk analysis, they don’t like that the results tell them that the prototype code isn’t usable. Then, they start to re-evaluate the risks, to come up with the answer they have already decided they want. That probability of occurrence isn’t THAT big, right? That hazard is moderate, not severe, right?

Don’t go down this path. Please. Remember the Safety Critical Mindset. Remember that you have a responsibility to the practitioners and patients who will use your device.

If the architecture of your prototype code meets the requirements, and passes a good-faith review, then you must still review the code as part of your code review process. Again, don’t skimp on this. Changes at this point should be much easier to make than large-scale architectural changes, so there are no excuses.

Finally, you have your production code. Maybe it’s exactly the same as your prototype code (unlikely). Maybe it’s got a few big refactoring changes and lots and lots of smaller fixes (more likely). Maybe you decided it was easier to scrap it entirely and start from scratch (sometimes…). Regardless, from here on out, the process doesn’t look any different than if you had developed the code in one go from the beginning.

Now, go forth and prototype! Just don’t make the mistake of assuming that a well-functioning prototype absolves you from following the proper process diligently.