How Software is/as a Medical Device (SxMD) design & development is changing

AI is outpacing Moore’s law at a staggering rate and notably, the 2023 AI Index Report shows the focus area with the most investment was medical and healthcare.

That tracks when you consider in 2022 alone, the FDA authorized 91 AI/ML-enabled devices.

And when it comes to new devices, FDA approvals increased by approximately 52% YoY from 2021 to 2022. With two million different medical devices, we’re at a technological crossroads.

At that medical device crossroads is SxMD. 

An introduction to SxMD

SxMD references SaMD and SiMD together because of the overlap across medical device design and development processes and standards (eg. IEC 62304 for lifecycle processes).

Both are vital to the future of medical device innovation, and they share many of the same needs - including requirements and quality management.

As developers and engineers, there’s plenty to discuss and solve for when it comes to SaMD and SiMD. Together as SxMD, those conversations and solutions are going to be more effective.

Software as a Medical Device (SaMD)

Software as a Medical Device (SaMD) is defined by the International Medical Device Regulators Forum (IMDRF) as "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." SaMD may be interfaced with hardware medical devices, other SaMD software, and general-purpose software. 

So what’s not considered SaMD? 

In short, if it’s a part of the hardware medical device and can’t achieve its intended purpose on its own, it’s not SaMD. The FDA defines what’s not SaMD with the following examples: 

• Software used to "drive or control" the motors and the pumping of medication in an infusion pump; or software used in closed loop control in an implantable pacemaker or other types of hardware medical devices. These types of software, sometimes referred to as "embedded software", "firmware", or "micro-code" are not Software as a Medical Device.

• Software that relies on data from a medical device, but does not have a medical purpose, e.g., software that encrypts data for transmission from a medical device.

• Software that enables clinical communication and workflow including patient registration, scheduling visits, voice calling, and video calling.

• Software that monitors performance or proper functioning of a device for the purpose of servicing the device, (e.g., software that monitors x-ray tube performance to anticipate the need for replacement), or software that integrates and analyzes laboratory quality control data to identify increased random errors or trends in calibration on IVDs.

• Software that provides parameters that become the input for software as a medical device is not software as a medical device if it does not have a medical purpose. For example, a database including search and query functions by itself or when used by Software as a Medical Device.”

Software in a Medical Device (SiMD)

SiMD helps run a medical device mechanically or with information processing. This includes the ability to control a device remotely and any software that makes connectivity (Bluetooth, Wifi, etc.) possible. 

Examples include: 

• Software used in a closed-loop control of a pacemaker.

• Software that controls the inflation or deflation of a blood pressure monitor.

• Software that controls the delivery on an insulin pump.

The stage is set for SxMD, so let’s dive into a few ways the industry is changing. 

How medical device design & development is changing?

1. Web connectivity for legacy medical devices

We mentioned above the estimated two million different medical devices globally (across 7,000+ generic medical device groups). One study reported as much as 53% of common medical devices and 39% of IoT (Internet of Things) are running on legacy systems. 

While imperfect, the math on this outlook presents a daunting technological challenge. As technology continues to advance, legacy devices must be brought up to speed because of regulatory demand and ultimately patient safety. 

Because of these changes, there’s a global focus on connecting “legacy” and “old” medical devices to modern software platforms. Definitions and context for this focus area can be found in the MDCG 2021-25 guidance document:

“Legacy devices should be understood as devices, which, in accordance with Article 120(3) of the MDR, are placed on the market after the MDR’s date of application (DoA) and until 26 May 2024 if certain conditions are fulfilled. Those devices can be:

• Devices which are class I devices under Directive 93/42/EEC (MDD), for which an EC declaration of conformity was drawn up prior to 26 May 2021 and for which the conformity assessment procedure under the MDR requires the involvement of a notified body;

• Devices covered by a valid EC certificate issued in accordance with Directive 90/385/EEC (AIMDD) or the MDD prior to 26 May 2021.”

• You can learn more about the changes to legacy device timelines here.

The guidance document continues, "‘Old’ devices are those devices that were placed on the market before 26 May 2021 in accordance with the AIMDD or the MDD or in accordance with the applicable rules before the Directives had entered into force."

2. Going to market faster

Medical device design and development will always be a complex process with a web of requirements and stakeholders. It’s for good reason. But new devices are going to market faster than before.

This speed is due to a variety of factors at every level, including:

• Project management frameworks for greater efficiency and visibility

• Increased emphasis on design-to-cost by engineers

• Early systems integration

• Implementation and enhancement of SxMD

• Specialized solution providers for every stage of the design and development process.

It’s important to note the balance medical device designers must strike between speed and quality. Going to market faster is not a positive if quality suffers as a result. That’s not the case though – by deploying the efforts listed above, they strike this balance effectively.

Decreasing time-to-market is just one outcome of these factors. When engineers and developers deploy these efforts, the patient benefits through improved usability and reliability. 

3. Medical devices are more accessible for patients

Healthcare has never been more personalized and accessible, in large part due to the rise in connected devices and IoT.

The Internet of Things (IoT) was named as a concept in 1999 by a brand manager at Procter & Gamble. Now, IoT refers to physical devices being connected – to the internet and to each other – through software and sensors.

There are tens of billions of IoT products. Among those are connected medical devices and wellness wearables. High-level use cases for connected medical devices include real-time collection of patient data, analysis of technical medical device data, alerts for abnormal health readings, and remote configuration. Patients can now take control of their own health, oftentimes in the comfort of their own home.

At Matrix Requirements, we have the privilege of working with these impactful organizations.

⇒ Take Qvin, for example, the period screening solution that enables earlier detection of serious health conditions for people who menstruate.

⇒ In a similar way, there’s Gabi SmartCare, the solution that enables real-time pediatric monitoring at home.

⇒ There’s also the innovative Diabeloop, the company developing interoperable self-learning solutions to automate diabetes treatment.

⇒ And notably, consider Cognoa, the solution using AI to enable earlier diagnoses of childhood behavioral conditions. 

SxMD & the future of medical device design: what it requires 

Project managers, engineers, and consultants at the world’s largest medical device and SxMD companies trust MatrixALM and MatrixQMS to help them design the future.  

MatrixALM allows you to update user and system requirements – plus technical specifications, tests, test results, risks, and everything else you need to document for your product design. 

MatrixQMS helps you bridge the gap between the engineering teams and the quality department, allowing RA/QA consultants to ensure compliance.

Learn more at matrixreq.com