By ShweThee Kale with Naghmeh Nouri contributing.
If your new medical device includes software with a user-facing interface, answering one critical question will shape nearly every development and regulatory decision that follows: what does your medical device solve and how? The challenge isn’t asking the question. It's answering it too late, inaccurately, or by accident.
How your technology impacts the end user(s) and patient outcomes can provide insight into which pathway to take. Maybe your software introduces novel clinical therapy. Maybe it's a usability upgrade on a previous generation device or technology. Maybe it presents data that helps a clinician choose a care pathway or connects data across a hospital network and an external cloud. It's easier to tread into device territory than you realize.
Consider the regulatory classification & strategy, use environment and clinical workflows that currently exist, rigor & complexity of what you design for, what you test, the training and labeling you'll need, to estimate the time and cost to launch your product commercially.
Understanding where your software falls on the spectrum is typically the first regulatory decision you’ll make for the product. These five questions can help you identify the right strategy early, while changes are still inexpensive.
Some software visually organizes patient data to help a clinician make their own decision. When software doesn't make a diagnostic decision, it often keeps it out of device territory.
If your software gathers data and presents it so a clinician can reach their own conclusion, and they can see the basis for what you're showing them, it's likely a clinical decision support tool rather than a medical device. The distinction isn’t simply that the clinician makes the final call. It's whether they can independently evaluate the information the software provides.
For example, we built a decision-support tool that presented raw data from a patient’s wearable to sleep clinicians. It allowed the clinicians to zoom into different metrics like oxygen saturation, heart rate, etc. to diagnose a sleep condition. The software organized and displayed the data but did not generate diagnoses or treatment recommendations. The clinician remains responsible for interpreting and acting upon the presented data.
Sometimes the software itself is not what defines a software to be a medical device; it’s the claims you make about your software that can turn it into a medical device.
Displaying usage or monitoring data is not a claim. Saying the software uses that data to diagnose, predict, treat, prevent, mitigate or recommend treatment for a condition is. “Our software displays patient monitoring trends,” is fundamentally different from, “Our software analyses patient monitoring data to detect early signs of sepsis.”
Regulatory bodies evaluate both explicit and implied claims in your labeling, marketing materials, website, sales and marketing promotional materials and Instructions for Use. Once a medical claim is made, you have fundamentally changed the expectation for your product.
Displaying clinical information is fundamentally different from controlling a medical device intervention. Once software enables a clinician to plan, configure or adjust treatment parameters that are executed by a medical device, the software becomes an integral part of the therapy delivery system. Recognizing this distinction early in development drives decisions for system architecture, concept design solutions, system engineering, verification & validation strategies, human factors engineering, labeling & packaging, cybersecurity & risk management throughout the product lifecycle.
Two broad software paradigms exist:
Software as a Medical Device (SaMD) operates on an existing hardware platform such as a desktop computer or mobile application to perform a medical purpose. The software itself provides clinical functionality, such as analyzing MRI images to detect abnormalities, calculating diagnostic indices, or generating treatment recommendations. Development efforts focus on technical feasibility of algorithms, data integrity, clinical performance, cybersecurity, and usability of the digital interface because the software independently, is a medical device.
Medical Device (MD) may consist of multiple sub-systems where hardware and software are inseparable. When software is a sub-system embedded as a digital touchscreen display, the user experience must also be seamless between hardware and software. Consider a surgical platform where software controls therapy delivery through laser ablation. Clinicians can use software’s user interface to control energy delivery, adjust treatment parameters, view live procedural data & imaging, configure system settings, by coordinating multiple subsystems including laser modules, imaging components, sensors, and disposable accessories. In these systems, software cannot be developed in isolation. System architecture, hardware and software interfaces, timing, reliability, usability, fault tolerance, and overall system performance must be designed, engineered, verified, and validated as a single integrated product. Successful system performance depends on balancing clinical usability, technical feasibility, and product reliability. Because of the hardware and software interdependencies, any failure of software or hardware can affect patient safety and treatment effectiveness.
The distinction between SaMD and MD is not simply whether software has a medical purpose; it is whether software itself is the medical device, or whether software enables and controls an integrated medical device system. Identifying this early in the product lifecycle, establishes the appropriate systems engineering approach and influences the entire design and development lifecycle.
Once your software influences diagnostics or treatment, device failures or use errors can cause harm. This decides how heavily you're regulated, not just whether you're a medical device. FDA’s expectations scale with risk related to the harm a failure could cause, not simply with whether software is considered a medical device. Two things set the level: how serious the clinical situation is, and how directly your software drives the action.
Software that displays values for clinicians for documentation presents very different risks than software that controls energy delivery during an ablation procedure. Where your device lands, maps to your device classification, drives your submission pathway for how much verification, validation, and clinical evidence you must perform.
Good risk management is realized through influencing the software architecture, user interface design, alarms, workflow, and providing context through the alert or labeling. For example: On one device, we designed the software to detect over-pressurization, alert the clinical team through the digital interface, disabled specific functions of the sub-system and place the device into a safe state to allow clinicians to resolve the error. Every user task no matter its granularity, should trace back to its identified hazardous condition, appropriate mitigations and verification evidence.
Many products no longer operate in isolation. Once you determine if your product is SaMD or SiMD from question 3, It is important to define how you Does your software:
These capabilities improve workflow efficiency and reduce documentation burden, but they also introduce cybersecurity responsibilities. Essentially any device with software that can connect to the internet, Bluetooth, USB, or Wi-Fi is considered a cyber device. For products meeting FDA’s definition of a cyber device, manufacturers are expected to provide cybersecurity documentation including:
Connectivity is often a competitive advantage, but it must be part of your regulatory strategy.
None of these questions have a clean yes-or-no answer on their own. They’re dependent on the user needs your software aims to address for your end user. Software classification is driven by several factors, including what the product does, the claims you make about it, and where it fits within the clinical workflow. Getting the assessments right early can have a significant impact on your development effort. When the regulatory pathway is clear from the onset, your product development plan, verification & validation activities and submission strategy can be aligned from the beginning. Get it wrong, and you may find yourself revising and reworking all three.
This is one of the most common conversations we tend to have with innovators. The best time to have it is before the product architecture is frozen. Engaging an experienced regulatory & product development partner early helps you understand potential requirements, development pathways, costs, and risks upfront. In some cases, it may even determine whether you need regulatory clearance at all.
Ready to figure out where your software lands in the medical device realm? Let's talk.
Designing a novel product and preparing a pathway for FDA submission vs speed to market of an established technology has conflicting goals. A flat screen display serving as the digital interface for your medical device may seem a simple proposition. However, its embedded interactions and guided workflows are highly complex. Early software engagement, iterative user testing, and balancing technology with business and clinical needs determine success.
The Veranex Design and Engineering teams bring decades of experience navigating the unique challenges of medical device UX/UI. We transform complex clinical workflows into intuitive digital experiences that seamlessly integrate with physical medical devices integrated within the industry’s first, full lifecycle Innovation CRO.
Ready to discuss your medical device's digital experience? Together we can establish a strategy that meets your needs. Let's explore how our integrated approach can accelerate your path to market.
ShweThee Kale is Manager of UX/UI Design for Veranex leading a team that works across the design continuum to ensure the UX intent is maintained on a variety of client programs ranging from early phase design to late phase development. Her cross-disciplinary collaborative nature with teams comprised of Research & Strategy, Human Factors, Industrial Design, Software Development, and more ensures we design empathetic, meaningful, and impactful solutions. ShweThee's passion for user experience also includes labeling design and development activities such as creating Instructions for Use (IFUs), on-device labeling and packaging that focuses on communicating safety, usability, and risk mitigation at varying levels of rigor for usability evaluations.
Naghmeh Nouri, previously served as Executive Director of Quality and Regulatory.
About Product Design & Engineering at Veranex
Concepts sketched on whiteboards don't survive contact with manufacturing tolerances, sterilization requirements, or real-world clinical use. Veranex Product Design & Engineering transforms early-stage ideas into robust, manufacturable medical devices through integrated mechanical, electrical, and software engineering, with industrial design, prototyping, and DFM expertise built in from the start. Upstream, our engineers receive validated user needs from Research and Strategy, Human Factors engineers, biocompatibility guidance on material selection, and regulatory intelligence and quality guidance that shapes design inputs before CAD work begins. Downstream, mature designs flow into testing and verification, manufacturing for clinical builds, and preclinical studies, with documentation aligned to quality systems and regulatory submissions. When design decisions are informed by downstream constraints from day one, you avoid the costly rework loops that stall programs and drain capital. In short, we add velocity to your vision as the industry's first and only Medical Device Innovation CRO.
Supporting references
• FDA · Clinical Decision Support Software (guidance)
• FDA · Software as a Medical Device (SaMD)
• FDA · Cybersecurity (section 524B / “cyber devices” hub)
• FDA · Marketing Submission Recommendations for a Predetermined Change Control Plan for AI-Enabled Device Software Functions (final guidance, Dec 2024)