The evolution of digital medical devices has paralleled digital technology since the time of the first computers.
As far back as 1965, computers have affected how medicine is practiced. In that year Medicare and Medicaid were introduced in the United States. To manage this new, massive patient base, the first large-scale electronic medical records were introduced to 70 hospitals. By 1971, Lockheed Corporation had introduced a physician ordering system.
According to Orthogonal, the first real SaMD (software as a medical device) arrived in the mid-1990s with automated testing techniques. The introduction of Bluetooth in 1999 paved the way for connected devices that delivered medical information for SaMD to process.
Today, SaMD is everywhere, from our wristwatches to the most advanced operating theatres.
In this blog, we’ll look at how software can be a medical device, provide a few examples, and talk about the future of SaMD.
What is SaMD?
Software is in nearly every device in hospitals or physicians’ offices. The question can be better phrased: What is software as a medical device versus other types of software?
According to this Orthogonal guide, not all medical software is considered SaMD. SaMD is a stand-alone product that can produce a medical diagnosis. This is in contrast to, for example, the software installed in a digital device that allows it to deliver data. This second type of software is known as “software in a medical device” or SiMD.
One simple example would be the types of software associated with an MRI machine. The software that receives information from the machine and converts it to images is SiMD. The additional software that analyzes those images and discovers anomalies and produces diagnoses is SaMD.
Deloitte defines SaMD as software that performs a medical function, even if that software is a permanent part of a single device. With SaMD, “it’s the software that performs the medical function.”
Providing an excellent chart that more clearly makes this distinction, Deloitte distinguishes between the software that operates a pacemaker (SiMD) versus the software that determines the proper dosage of a medication using personalized patient data (SaMD).
How SaMD is Regulated
Because SaMD differs from traditional medical devices, a new regulatory framework is being established by the international community to oversee the development and certification of SaMD.
Consider that SaMD, as in the example above, is actually doing the doctor’s job of determining a drug dosage, it requires close regulation and study simply because a misdiagnosis by a machine, as if it were by a human, could be catastrophic for the patient.
The FDA, in the article “Software as a Medical Device (SaMD)”, discusses how the International Medical Device Regulators Forum (IMDRF) was formed to create global rules and policies regarding medical device regulation. The FDA chairs the organization. Collectively, the members agreed upon “key definitions for Software as a Medical Device, framework for risk categorization for Software as a Medical Device, the Quality Management System for Software as a Medical Device, and the clinical evaluation of Software as a Medical Device.”
The challenge for regulators is that this software is developing faster than the forum can even define it, let alone test it. Since brilliant designers and developers all over the world are putting together SaMD, organizations charged with regulating medical devices struggle to keep up.
So far, the guidelines established by the IMDRF have been flexible and agile enough to cover the rapid development that is occurring around the world.
The SaMD Challenges
Orthogonal points out the fundamental challenges for SaMD developers: “How do you integrate modern product development methodology that is designed for a fast-changing, ever-evolving ‘internet of everything’ world with patient safety, clinical efficacy and regulatory compliance?”
The article mentioned above delves into the answers to this question, but the fundamental issue is that in resolving each challenge the rapid development, coupled with safety and compliance, needs to be part of the fabric of the development company. The company must have these issues and solutions as part of its foundation if it is to be agile enough to adapt to change and fast enough to capture market share.
Overcoming these challenges is what has defined the companies involved in SaMD development. Unlike a game developer or a company that creates office software, the layers of safety, testing, and compliance have forced a massive new aspect to their software development efforts.
The Future of SaMD
Any fan of science fiction has seen Hollywood’s version of the future of SaMD and medical devices in general. Machines that diagnose a disorder then perform surgery to correct it. The machine will sew the person back up and send them on their merry way. Scifi sees machines that perform the necessary scans, diagnose a cancer, then prescribe the right doses of medicine to get rid of it.
We’ll see if that becomes the future, but…
The first step into the future will come from widespread patient acceptance of machine diagnoses. We’re starting to see this now with diabetics who adjust their insulin based on the diagnosis of a device on their skin and heart patients who adjust their medications when a monitor tells them to do so.
The COVID-19 pandemic forced many organizations to create automated diagnostic systems. Where one might once have called and spoken to a nurse, patients instead log into a software product, explain their symptoms and receive a diagnosis, a treatment plan, and even schedule a follow-up contact.
SaMD is likely to become an increasing part of our medical experience. It allows medical facilities and professionals to scale their work, serve more customers and making more money.
It’s part of millions of lives today and, in the next ten years, it could be how we get most of our medical care, if we choose to do so.
Yes. Software can be a medical device. In fact, it is already likely that something in your home does exactly this.