The secret of SaMD? 

We are back at our medical device company and the product manager talked with the CEO and convinced him that software as a medical device will be a very interesting and fast-growing market. The perspective is tempting, so the CEO decides to launch a project for their own SaMD-App.

The product manager sets up the specification, pointing out that the graphical user interface and a touch of artificial intelligence are most important. The software engineer raises concerns about the intended purpose of the SaMD-App however she is overruled by the CEO and the product manager, so she starts to design the software.

With the start of the project, the quality manager is of course also invited to the project to ensure regulatory compliance from the start. The quality manager is not so happy about this new assignment. He heard that no traditional quality approach will work on software and software as a medical device is supposed to be complicated, hard to understand, and the regulatory requirements are all in the dark.

To understand the SaMD-App project, the quality manager asks the software engineer to explain the SaMD-App to him. The quality manager does not understand everything he hears, but he understands the software engineer wants to go to Java, because of all the libraries with cool architecture. She also wants to go (sprint???) to a daily scrum and maybe have a python, too but when the quality manager asks her why she wants to go to Jakarta to look for snakes in the crowd, he gets a very weird look from the software engineer and decides that it would be better to leave. The quality manager’s opinion on software as a medical device is confirmed that it is supposed to be complicated, hard to understand, and the regulatory requirements are all in the dark.

The quality manager gets in touch with the Notified Body to have a technical meeting about the SaMD-App. The Notified Body tells him software as a medical device is supposed to be complicated, hard to understand, and the regulatory requirements are all in the dark but they are hiring a senior software expert soon, who will rule the topic. The quality manager knows that much already and asks for a more practical answer. The Notified Body explains that he is not allowed to tell him more as that would be consultancy, and Notified Bodies are not allowed to do that. However, they will be very happy to review the technical file once submitted.

The quality manager hires a consultant to get behind the SaMD story. The consultant does a very nice presentation with many colorful slides. The quality manager does not understand much and asks at the end of the presentation what the message is and what he should do? The consultant is a little indignant about this question and replies to him: “Didn’t you listen to my presentation? Software as a medical device is complicated, hard to understand, and the regulatory requirements are all in the dark. If you do not get this, I can’t help you.”

Finally, the software engineer completes the design, even though complaining again that the specification does not contain anything with a medical purpose. Again, the software engineer is overruled by the CEO and product manager, saying that the SaMD-App is perfect. The quality manager cornered to complete the technical file, but still being clueless about what to do, decides to replace the technical documentation of a “real” device, with the name of the SaMD-App and some stuff he got from the software engineer (by email, he still does not dare to go there in person). The file is submitted to the Notified Body, and to the surprise of the quality manager and the Software Engineer, the technical file is accepted by the Notified Body and the SaMD-App receives the CE mark.

With the SaMD-App being made available on the market, a post market study is launched to gain more evidence on the clinical benefits of the SaMD-App. The results of the study are impressive as a significant majority of the patients reports that the SaMD-App does help them and improves their life. The performance and benefit of the software is confirmed.

The CEO is all pleased with the new device. The SaMD-App is a big success and being labelled as a medical device the company can charge ten time the price it could compared to a standard app.

The quality manager is happy, too. Even so, he still has no idea about SaMD, he regained his reputation and trust from the CEO, which was lost after the “safe-street-crossing issue” (previous blog). He plans to spend his next holiday on Java, just to understand what this fuss is all about. Of course, he will sprint away from any scrum and keep a safe distance to all the pythons around there.

The software engineer was the only one not being happy, but all confused. The software engineer ran through the code again and again, and did not find any algorithm, that would explain the performance of the SaMD-App. The software engineer becomes totally anxious about that and begins to lose trust in science.

So, how did the software work in the end? The patients strongly believed, as the software was labelled as a medical device, that it would help them and to their recognition it did. As everybody knows this is called a placebo effect (or the touch of AI has a yet unknown effect…).

I know, I did not answer the question about the secret of SaMD. Well, you know: SaMD is supposed to be complicated, hard to understand, and the regulatory requirements are all in the dark.