What Is Software as a Medical Device (SaMD)? Definition, Examples, and Regulations

Software as a Medical Device (SaMD) is software intended to perform one or more medical purposes without being part of a hardware medical device. It can analyze medical images, support clinical decisions, monitor health conditions, or provide information used in treatment. The International Medical Device Regulators Forum (IMDRF) established the widely used definition of SaMD, which is also recognized by the U.S. Food and Drug Administration (FDA).

Whether software qualifies as SaMD depends on its intended medical purpose and functionality, rather than the technology used to build it. A general wellness app and software designed to detect a medical condition may use similar technologies but face different regulatory requirements. Understanding that distinction early helps healthcare product teams make better decisions about architecture, patient safety, validation, and regulatory compliance.

What Is Software as a Medical Device (SaMD)?

Software as a Medical Device (SaMD) is software designed to perform a medical function without needing to be integrated into a hardware medical device. The IMDRF established the foundational definition in 2013 and published its SaMD risk categorization framework in 2014. The FDA also uses this terminology when discussing medical device software. The defining factor is the software's intended medical purpose, not the computing platform on which it runs. That purpose may involve diagnosing a condition, supporting treatment, evaluating medical information, monitoring a patient's health, or informing clinical management.

Consider software that analyzes MRI images to identify potentially abnormal findings. The application may qualify as SaMD because it performs an analytical function intended to support medical assessment, even though the images originate from an imaging device. Software that directly controls the MRI machine's operation serves a different purpose because its function is integral to the hardware. Both involve medical technology, but their relationship with the physical device differs. That distinction affects regulatory qualification, product architecture, risk assessment, and the evidence needed to support the software's intended use.

The term medical device software covers more than SaMD. It includes software embedded in physical medical equipment, software that independently performs medical functions, and other functions associated with medical devices. Software in a Medical Device (SiMD) is integral to a hardware device's operation, often taking the form of embedded software such as firmware or microcode. A pacemaker's control software is a familiar example because it works as part of the device itself. SaMD, by comparison, can perform its intended medical function on a general-purpose computing platform.

SaMD may run on a smartphone, tablet, laptop, desktop computer, or cloud server. It can also exchange information with connected sensors and other medical devices without necessarily becoming part of those devices. Standalone software does not mean software that operates without hardware or external connections. Every application needs computing infrastructure, and the origin of its input data does not automatically determine its regulatory status. The relevant question is whether the software needs to be part of a hardware medical device to perform its intended medical function.

What makes SaMD different from traditional medical devices?

Traditional medical devices often combine physical components with software that controls or supports their operation. Their medical functions may depend on dedicated sensors, electronics, mechanical systems, or other specialized hardware. SaMD performs its intended medical function without needing to be incorporated into such equipment, which can make certain medical capabilities available through general-purpose platforms and connected healthcare systems. Software-based functions may also be updated without physically modifying a medical device. Those updates can still require regulatory assessment, testing, and controlled change management.

A wearable medical sensor illustrates the distinction. An application might receive measurements from the sensor, analyze them, and produce information intended to support clinical assessment. That analytical function may qualify as SaMD even though another medical device supplies the measurements. Software responsible for controlling the sensor's essential operation would need a different assessment because its function is tied to the hardware. The same reasoning applies to cloud-based medical systems that process information collected from external equipment.

The distinction also has implications for patient safety. Independent diagnostic software may produce incorrect results because of coding defects, unreliable input data, unsuitable analytical methods, or problems with its intended clinical application. Such errors can influence patient care even when the software does not contain specialized medical hardware. The absence of dedicated hardware does not automatically make SaMD less risky or easier to validate than traditional medical devices. The consequences of incorrect software behavior depend on the function and the clinical decisions it supports.

Broader healthcare software development includes applications with different medical purposes and regulatory responsibilities. A patient scheduling platform and diagnostic image analysis software may use similar web technologies, but their functions can place them under very different requirements. Defining the medical purpose during product planning helps teams choose appropriate development, testing, and documentation approaches. It also establishes whether a formal medical device qualification assessment is needed before the product moves further into development.

Medical Device Software vs Health Software: What Qualifies as a Medical Device?

Health software does not automatically qualify as a medical device because it collects, stores, or processes medical information. Regulatory qualification depends on the software's intended purpose, its actual functions, and the applicable legal framework. An application that records blood pressure measurements for personal reference may have a different regulatory status from software that interprets those measurements to identify a disease or recommend treatment. Both handle medical data, but the significance of their outputs is different. What the software does with the information matters more than the type of information alone.

This distinction extends to healthcare administration, patient communication, general wellness applications, and clinical decision support (CDS). Software may support health care providers without independently performing a regulated medical function. Conversely, an application designed for patients or caregivers may qualify as a medical device when it performs an intended medical purpose. The intended users, product claims, and functionality therefore need to be assessed together. Neither the software's distribution method nor its user interface is a reliable classification criterion on its own.

The main differences between common categories of health software can be summarized as follows.

The categories describe typical functions rather than automatic regulatory outcomes. Software that merely displays information can have a different purpose from software that interprets the same information and recommends a clinical action. Even simple medical calculations require assessment of their intended use and significance to patient care. A medical purpose must be established from the actual function and product claims, not inferred from the fact that an application operates in healthcare.

How Intended Use and Intended Purpose Determine Medical Device Status

Intended use describes the purpose for which a manufacturer designs and presents a product. In medical software, it helps determine whether a function falls within the applicable legal definition of a medical device. Software intended to diagnose, treat, mitigate, or prevent a medical condition may be subject to medical device regulation, depending on the jurisdiction and relevant exclusions. Product labeling, instructions, functionality, and claims about medical benefits can all contribute to this assessment. A product's description should therefore be consistent with what the software actually does.

Consider a mobile app that records daily heart rate measurements. One version might display activity trends to help users understand their exercise patterns, while another analyzes those measurements to identify signs of a specific medical condition. The underlying technologies may be similar, yet the intended functions create different regulatory considerations. Changing the intended purpose can change a product's regulatory status even when its technical architecture remains largely the same. This makes intended-use decisions particularly important before substantial development work begins.

A product discovery workshop can help establish the software's intended users, required functions, expected outputs, and operational boundaries. These decisions shape technical requirements and reveal questions that may need specialist regulatory assessment. For example, a feature intended only to display health information may require a different approach from one that interprets the information to recommend clinical action. Discovery helps organize the relevant product information, although it does not itself determine regulatory classification.

Clinical decision support is a particularly important boundary case. The FDA's January 2026 guidance explains that certain CDS functions are excluded from the US device definition when they satisfy specific statutory criteria. Other clinical decision support functions remain regulated, including functions that do not meet the conditions for exclusion. The FDA's General Wellness guidance, also updated in January 2026, addresses certain low-risk wellness products and their regulatory treatment. Exclusion from the medical device definition and FDA enforcement discretion are different regulatory concepts. Teams considering a non-device wellness product must also ensure that its functions and claims remain consistent with that intended purpose.

For a more detailed qualification assessment, the relationship between intended purpose, hardware, and regulatory treatment needs to be considered together.

A single product may contain several of these functions. A healthcare platform could combine appointment scheduling, electronic patient records, communication features, and an independent diagnostic module. The administrative components do not automatically become medical devices because they share infrastructure with a regulated function. Equally, including nonmedical features does not remove regulatory obligations from a function intended to diagnose or treat a medical condition. Qualification may need to be assessed at the software-function level, including relevant interactions between functions.

Software used to manage healthcare compliance provides another useful distinction. A regulatory compliance management software product may help an organization organize compliance workflows without performing a medical function itself. Its regulatory status depends on its intended functionality rather than the fact that it serves a regulated industry. Compliance documentation software should therefore not automatically be classified as SaMD.

A preliminary qualification assessment can start with five practical questions:

• Does the software have an intended medical purpose? Determine whether it is designed to diagnose, treat, monitor, prevent, or otherwise support clinical management of a medical condition.
• What does the software actually do? Distinguish storing or displaying information from interpreting data, generating diagnostic outputs, or recommending treatment.
• What claims are made about its functionality? Review intended users, labeling, product descriptions, and statements about medical benefits.
• Does the medical function depend on being part of a hardware device? Assess whether it performs the function independently or operates as an integral device component.
• Which regulatory framework and exclusions apply? Identify the relevant jurisdiction and any applicable rules for wellness products, clinical decision support, or other software functions.

These questions help identify where a detailed regulatory review may be necessary, but they are not an official classification test. A reliable conclusion requires a precise intended-use statement, a description of the actual software functions, relevant product claims, and applicable legal requirements. Complex systems may also need assessment of dependencies between regulated and nonregulated functions. The practical examples that follow show how these distinctions affect different types of medical software.

Try our developers.
Free for 2 weeks.

No risk. Just results. Get a feel for our process, speed, and quality — work with our developers for a trial sprint and see why global companies choose Selleo.

Test our team

Share this offer

Examples of SaMD and Mobile Medical Applications

SaMD can perform diagnostic analysis, provide medically relevant treatment recommendations, or process clinical information for a defined medical purpose. These functions can operate through mobile apps, desktop applications, cloud platforms, and connected healthcare systems. The platform itself does not determine whether software qualifies as SaMD. An application may also communicate with hardware, general-purpose software, or other SaMD software while independently performing its intended medical function. What matters is the role of the output in medical care and the software's relationship with any hardware medical device.

SaMD applications vary considerably in their clinical purpose. Some analyze medical images, while others interpret physiological measurements or generate information used in treatment decisions. Similar applications may be subject to different requirements because of how their outputs are intended to be used and the potential consequences of an incorrect result. The following categories illustrate common applications:

• Medical imaging and diagnosis: Software analyzes MRI scans or other medical images to identify findings that may be relevant to diagnosing a condition.
• Clinical decision support: Certain software functions analyze medical information and generate recommendations or assessments intended to support clinical decisions. Their regulatory status depends on the particular function.
• Monitoring and alerting: Software interprets physiological measurements to identify clinically relevant changes or conditions requiring attention.
• Treatment support and digital therapeutics: Software may recommend treatment-related actions or deliver a therapeutic intervention according to its intended purpose.

These are application categories, not fixed regulatory classes. Two products used in the same clinical area may have different intended purposes and risk considerations. The distinction becomes clearer when examining how individual software functions operate. Medical image analysis, medication recommendations, and general wellness tracking illustrate three different situations.

Illustrative example 1: Medical image analysis

Consider a hypothetical application that receives MRI images and analyzes them to identify potentially abnormal structures. It generates findings intended to help healthcare professionals decide whether further investigation is needed. The software goes beyond storing or displaying images because it performs an analytical function with an intended medical purpose. It may therefore qualify as SaMD, subject to its specific functionality, claims, and the relevant regulatory requirements.

The clinical role of its output matters. Software that highlights areas for further professional review may raise different risk considerations from software intended to establish a diagnosis or directly guide urgent treatment. Artificial intelligence can support image analysis, but using AI does not independently establish SaMD status or prove clinical effectiveness. A model that performs well on technical tests still needs evidence appropriate to its intended medical function and the conditions in which it will be used.

Image processing, model integration, and data pipelines are relevant capabilities within AI solutions for healthcare, but medical applications introduce further questions about reliability and evidence. The intended clinical function determines which regulatory considerations need assessment. Algorithmic accuracy alone cannot establish whether the software produces clinically meaningful results for its intended users and patient population.

Illustrative example 2: Insulin dosage recommendation software

Imagine an independent application that receives glucose measurements and calculates an insulin dosage recommendation. Its output is intended to influence patient treatment, making accuracy and reliability particularly important. An incorrect recommendation could have consequences for a patient's medical condition. That clinical purpose is central to assessing whether the software qualifies as a medical device and what risks need to be addressed.

The development team would need to understand the conditions in which recommendations are generated, the reliability of the input data, and how intended users interpret the results. Those considerations differ from an application that simply stores glucose measurements for later review. Both products may use the same data sources and similar interfaces, but their outputs serve different clinical purposes. The treatment-related recommendation changes the significance of the software's behavior.

This hypothetical example cannot establish a particular FDA device class or regulatory pathway without a product-specific assessment. The same limitation applies to software supporting other medication-related decisions. Intended use, functionality, and relevant regulatory criteria must be examined before classification.

Illustrative example 3: Wellness tracking versus medical assessment

Consider two mobile applications that display heart rate information. The first helps users review exercise patterns and general activity trends, while the second analyzes measurements to identify a particular medical condition. Both applications may rely on data from similar sensors. Their regulatory treatment can differ because the intended functions are different, even though the underlying data and technology overlap.

The second application introduces a medical purpose that may bring it within medical device regulation. Its classification still depends on the precise function, product claims, applicable exclusions, and jurisdiction. Similar distinctions arise in applications that analyze breathing patterns, monitor physiological processes, or generate disease-related risk assessments. A short description such as “heart rate monitoring app” is therefore insufficient to determine regulatory status.

SaMD and connected healthcare platforms

Mobile medical applications frequently exchange information with wearable sensors, electronic patient records, healthcare professionals, and connected medical equipment. An app may receive measurements from an external sensor and independently analyze them for a clinical purpose. The presence of that sensor does not automatically prevent the analytical function from qualifying as SaMD. Product architecture needs to make clear which component performs each function, where information originates, and how the output is intended to be used.

Projects involving mobile medical app development therefore need to consider more than the choice of mobile framework when regulated functions are involved. Data handling, reliability, user interaction, and testing must reflect the software's purpose and operational context. An app's regulatory status depends on its functionality rather than whether it runs on iOS, Android, or another mobile platform.

The same principle applies to larger healthcare systems with several interconnected modules. A multi-sided healthcare platform illustrates a connected product architecture, although such a platform should not be assumed to qualify as SaMD merely because it operates in healthcare. Administrative, communication, and medical functions may coexist while having different regulatory implications. Each intended medical function needs assessment on its own terms, including dependencies that could affect its performance.

Benefits of Software as a Medical Device for Patient Care

SaMD can support patient care by delivering clinically relevant software functions through digital platforms. Potential applications include screening, diagnosis, monitoring, chronic condition management, and software-based treatment. These functions can give healthcare professionals and patients access to information relevant to medical decisions. Actual benefits depend on the particular product, its clinical performance, and the setting in which it is used. Improvements in outcomes or healthcare spending cannot be assumed simply because a software product qualifies as SaMD.

Screening and diagnosis are common areas of application. Software may analyze medical images or combine clinical information to produce findings intended to support assessment. In some cases, software may fall under in vitro diagnostic device rules when its intended purpose meets the relevant IVD definition, rather than being assessed solely under general medical-device provisions. The regulatory framework depends on the function and jurisdiction. Regardless of classification, technical prediction accuracy does not automatically establish clinical effectiveness. The output must be evaluated against the medical claims made for the intended users and clinical setting.

Monitoring and alerting offer another potential benefit. SaMD may analyze physiological measurements collected from connected devices or other sources and identify changes relevant to a patient's condition. A software function could process information collected outside a hospital and generate an alert intended to support follow-up. The reliability of that process depends on accurate data, suitable alert logic, and timely delivery. An alert based on incomplete information or interpreted incorrectly may fail to serve its intended clinical purpose.

Chronic condition management can also involve SaMD. Software may help analyze repeated measurements, support monitoring, or provide information used in treatment-related decisions. Diabetes management offers examples of applications that process glucose information and support clinical management. The role of healthcare professionals remains important wherever decisions require clinical judgment. Producing recommendations does not automatically make software a substitute for medical expertise.

Digital therapeutics involve software-based interventions intended to achieve defined therapeutic purposes. Some products may qualify as SaMD, while others require separate assessment of their functionality and regulatory treatment. Their effectiveness needs evidence appropriate to the intended clinical claims. The potential value of a therapeutic application therefore depends on its demonstrated performance, not simply its delivery through a digital interface.

Healthcare delivery also relies on software that does not perform a medical-device function. For example, a HIPAA-compliant communication platform may support communication within a healthcare environment without independently diagnosing or treating a condition. Communication features and clinical decision-making functions can operate within the same product while remaining distinct in purpose. Their regulatory responsibilities should be assessed accordingly.

Connected platforms can also make healthcare information accessible across different locations and systems. In cloud-based SaaS platform development, architecture decisions may involve service availability, integrations, access control, and ongoing maintenance. These capabilities can support healthcare delivery, but cloud deployment does not establish medical effectiveness or determine SaMD qualification. The intended clinical function and supporting evidence remain decisive.

SaMD Risk Classification: IMDRF Categories and Health Canada Guidance

SaMD risk categorization considers how software-generated information is used in healthcare and how serious the relevant medical situation is. The IMDRF framework combines these dimensions to categorize SaMD according to the significance of its intended clinical function. It provides a common international basis for discussing software-related medical risk. National and regional regulations, however, determine the legally applicable device classification and associated obligations.

The IMDRF published its SaMD risk categorization framework in September 2014. It evaluates two dimensions: the significance of the information provided by the software and the state of the healthcare situation or condition. Information may be intended to treat or diagnose, drive clinical management, or inform clinical management. The healthcare situation may be non-serious, serious, or critical. These distinctions determine how the software's clinical role is considered within the framework.

Software that directly informs treatment or diagnosis has a different role from software that provides information for general clinical assessment. Similarly, a function used in a critical medical situation may involve more serious consequences than a comparable function used in a non-serious condition. Risk categorization depends on the intended clinical purpose and healthcare situation, not simply how technically sophisticated the software is. A complex AI model is not automatically assigned the highest risk category, while a relatively simple calculation may be highly significant when it influences an important treatment decision.

The IMDRF framework combines the two dimensions into Categories I, II, III, and IV. Category I represents the lowest category within this framework, while Category IV represents the highest. A particular product must be assessed against the framework's criteria rather than classified from a broad description of its technology. Image analysis software, for example, cannot be assigned a definitive category solely because it analyzes medical images. The role of its output in diagnosis or treatment and the seriousness of the relevant condition need to be established.

The distinction between the IMDRF categories remains useful when evaluating SaMD functions, but the categories must not be confused with national regulatory classifications. In particular, FDA device classes and EU medical device classes are established under their own regulatory systems. Their terminology may appear similar, but the criteria and legal consequences are different.

An IMDRF Category III product is not automatically an FDA Class III device. The corresponding numbers describe different classification systems. A medical software manufacturer may therefore need separate classification assessments for different markets, even when the product's intended function remains unchanged. The relevant jurisdiction determines which rules apply and what regulatory evidence is required.

In the European Union, medical device software qualification and classification depend on the applicable MDR or IVDR provisions. Under EU MDR Rule 11, software intended to monitor physiological processes is generally Class IIa, but it may be Class IIb when it monitors vital physiological parameters and variations could create immediate danger for the patient. The European Commission's revised MDCG 2019-11 guidance, published in June 2025, addresses software qualification and classification under these frameworks. That guidance supports interpretation of the applicable legislation rather than replacing it.

These differences make compliance and regulations in healthcare software development relevant when a product is intended for more than one market. Jurisdiction-specific requirements can influence documentation, testing, and the evidence needed to support the same medical software function. Using a common software architecture does not mean that regulatory obligations will be identical across countries.

What the Health Canada Guidance Document Explains

Health Canada's 2019 guidance document explains how SaMD is qualified and classified under Canadian medical device requirements. It addresses intended use, relevant software functions, and circumstances in which software may fall outside the medical device definition. The guidance helps distinguish software performing a medical purpose from software used for administrative or general healthcare activities. Its legal application, however, remains specific to Canada.

The intended function and associated risk are central to the Canadian assessment. Software used solely for healthcare administration should not be assumed to qualify as SaMD because it handles health-related information. A function that analyzes medical data for diagnosis or treatment requires a different assessment, particularly where an erroneous result could create immediate danger. Depending on the applicable criteria, higher-risk functions may fall into Canadian Class III or other relevant classes.

Health Canada also recognizes that standalone SaMD may communicate with other medical devices without becoming software embedded in those devices. Interfacing with hardware does not, by itself, determine the regulatory category of a software function. Although Canadian guidance can help explain these boundaries, products intended for the United States must be assessed against applicable FDA requirements. The same principle applies when evaluating regulatory obligations in the European Union or other markets.

FDA Regulation of Device Software Functions

FDA regulation of device software functions depends on the software's intended purpose, its status under the medical device definition, and the applicable classification and regulatory pathway. Different SaMD products can therefore face different requirements. The FDA uses a risk-based regulatory framework, with oversight determined by the relevant device function and legal requirements. Healthcare software is not automatically subject to FDA premarket approval, but software-only medical products are not automatically exempt either.

A product-specific regulatory assessment begins with the intended medical function, applicable exclusions, and relevant device classification information. The FDA's treatment of a function may depend on the role its outputs play in clinical decisions and the regulatory requirements that apply to that type of device. The use of AI, a mobile interface, or medical data alone does not determine the pathway. These characteristics need to be considered in the context of the intended use.

FDA pathways for regulated software

Medical device manufacturers may use different premarket mechanisms depending on the product and its classification. For applicable devices, a 510(k) submission demonstrates substantial equivalence to a legally marketed predicate device. Other products may follow a De Novo classification request or a premarket approval pathway. These mechanisms serve different legal purposes and have different requirements. FDA clearance, De Novo authorization, and premarket approval should not be described interchangeably as “FDA certification.”

AI-enabled products illustrate the range of medical software considered by the agency. By August 2024, the FDA had reported authorizing more than 950 AI-enabled medical devices, reflecting the breadth of AI applications reaching regulatory review. That historical figure does not establish the current total or indicate which pathway applies to a particular AI product. The regulatory route still depends on the intended function, device classification, and relevant requirements. Neither AI functionality nor SaMD status provides an automatic route to authorization.

FDA software documentation requirements

In June 2023, the FDA issued its final guidance, Content of Premarket Submissions for Device Software Functions. The document describes recommended software documentation for applicable premarket submissions, extending beyond a demonstration that the application performs its expected features. Depending on the relevant submission and product requirements, documentation may cover software requirements, design, development, verification, validation, and risk-related information. The aim is to provide sufficient information about the software function and its behavior within the applicable regulatory context.

Documentation expectations also depend on the software components and systems involved. Manufacturers may need to identify and assess off the shelf software components, along with their potential impact on performance and risk. Cybersecurity-related submissions may call for a Software Bill of Materials (SBOM), which records relevant software components and dependencies. A software bill of materials is not a universal substitute for design, verification, validation, or risk-management documentation. Its applicability and required detail depend on the relevant regulatory requirements.

Medical software testing must also account for conditions beyond a successful product demonstration. A function may perform correctly with expected input yet behave differently when data is incomplete, malformed, delayed, or inconsistent. Where its output influences medical decisions, the development team needs an appropriate understanding of those failure modes. Even correct implementation of an algorithm does not establish that the algorithm is clinically suitable for its intended purpose.

A structured approach to custom medical software development can help connect requirements, implementation decisions, and engineering evidence. That approach needs to reflect the actual medical function and the applicable regulatory framework rather than treating every healthcare application as equivalent. Development services can support technical delivery, while the manufacturer remains responsible for meeting its relevant regulatory obligations.

Quality management and the FDA QMSR

Quality management systems establish processes for developing, maintaining, and controlling products within applicable medical device requirements. The FDA's Quality Management System Regulation (QMSR) took effect on February 2, 2026. The revised regulation amended 21 CFR Part 820 and incorporated ISO 13485:2016 by reference. This change aligned significant elements of the US medical device quality management framework with an internationally recognized quality management standard.

Regulated SaMD manufacturers may be subject to the relevant quality management requirements, but the same obligations do not automatically apply to every organization building healthcare software. Applicability depends on the product, organization, and regulatory circumstances. For manufacturers within scope, quality management can influence how requirements are documented, design activities are controlled, changes are assessed, and records are maintained. These processes connect software delivery with the evidence needed to support a product's intended medical purpose.

What happened to the FDA Software Precertification Program?

The FDA's Software Precertification, or Pre-Cert, pilot was launched in 2017 as part of the agency's broader digital health innovation work. It explored alternative approaches to software regulation, including ways to account for iterative development and product lifecycle considerations. The pilot contributed to discussions about how medical software should be evaluated and regulated. The FDA Pre-Cert pilot ended in 2022 and is not an active pathway for obtaining SaMD authorization.

The program remains part of the history of FDA digital health policy, but older descriptions should not be interpreted as current regulatory options. Manufacturers need to use applicable rules and available pathways when planning submissions. A historical initiative cannot replace a product-specific assessment of the medical function and the requirements that apply to it.

FDA guidance on clinical decision support and general wellness

In January 2026, the FDA issued updated final guidance on Clinical Decision Support Software. It explains the agency's interpretation of the statutory criteria under which certain CDS functions are excluded from the US medical device definition. Software that provides information to healthcare professionals is therefore not necessarily regulated as a device. The exclusion is conditional, however, and some functions that generate clinical recommendations remain subject to regulation.

The FDA's General Wellness guidance was also updated in January 2026. It addresses certain products intended for general wellness purposes and their regulatory treatment. An application that supports general lifestyle activities may be treated differently from software intended to diagnose a disease or guide treatment. The distinction depends on intended use, functionality, claims, and applicable legal criteria. Processing medical or physiological data alone is insufficient to establish whether a function is regulated.

Cybersecurity as a regulatory consideration

Medical device software may depend on cloud services, connected equipment, external data sources, and network infrastructure. These connections introduce cybersecurity risks that can affect device functionality, data reliability, and patient safety. The FDA's February 2026 medical device cybersecurity guidance addresses quality management considerations and cybersecurity information for applicable premarket submissions. It superseded the June 2025 version and reflects the agency's continued attention to cybersecurity across the medical device lifecycle.

The PATCH Act introduced statutory cybersecurity requirements for certain connected medical devices, including requirements relating to vulnerability management and supporting information. Broader US cybersecurity policy also developed through measures such as the May 12, 2021 Executive Order on Improving the Nation's Cybersecurity. Such broader initiatives should be distinguished from the specific medical device obligations established under applicable law. The cybersecurity requirements relevant to a given SaMD product depend on its functionality, connectivity, and regulatory scope.

For software within scope, cybersecurity planning may involve threat assessment, architecture decisions, testing, vulnerability management, and maintenance after release. Product teams also need to understand where critical software dependencies exist and how security failures could affect the intended medical function. Not every medical application has identical cybersecurity risks or documentation obligations. Appropriate controls must be determined through a product-specific assessment.

Regulatory planning during early product development

Healthcare products frequently begin with a prototype or limited implementation intended to test technical feasibility and clarify requirements. Such work can help establish how a proposed function might operate, but a successful demonstration does not establish clinical safety or regulatory authorization. A conventional minimum viable product (MVP) is not automatically suitable for clinical use. The intended use and deployment context determine which risk controls, evidence, and development activities may be needed.

Early-stage MVP development for medical device startups therefore needs to distinguish exploratory product validation from the development of software intended for regulated medical use. A prototype can help evaluate assumptions about functionality, architecture, and user interaction, but it cannot replace the applicable clinical and regulatory assessment. Requirements become more manageable when the team connects intended use, regulatory scope, implementation, testing, and lifecycle planning from the beginning.

The SaMD Development Process: Safety, Validation, and Challenges

SaMD development combines software engineering with the safety, risk-management, documentation, and clinical-evidence activities required for the product's intended medical function. Conventional development practices remain important, but ordinary feature testing and release procedures may not address every obligation associated with regulated medical software. Teams need to understand who will use the product, what decisions its outputs support, and what could happen if it behaves incorrectly. These considerations influence development planning from initial requirements through maintenance after release.

Defining intended use provides a starting point for both engineering and regulatory assessment. A diagnostic function, for example, may require different evidence and controls from an administrative module within the same application. Software requirements should reflect the function's clinical purpose, expected behavior, operational conditions, and relevant risks. The development process can then connect those requirements with design, implementation, verification, validation, and maintenance. The activities are related, and changes to one part of the system may affect several others.

The following seven stages describe a practical development workflow. They are an engineering synthesis rather than a universal sequence prescribed in this exact form by a regulator.

1. Define intended use and software functions. Establish the proposed medical purpose, intended users, expected outputs, and operational context. Separate regulated medical functions from other product capabilities.
2. Assess qualification and product risks. Identify the applicable regulatory framework and evaluate risks associated with incorrect outputs, missing information, failures, or inappropriate use. The assessment should reflect the clinical significance of the function.
3. Document traceable software requirements. Translate product needs into testable functional and technical requirements. Maintain appropriate links between requirements, implementation, identified risks, and verification activities.
4. Plan architecture, controls, and development documentation. Define software components, interfaces, responsibilities, data handling, and development controls suited to the product. Consider how software changes will be evaluated throughout its lifecycle.
5. Implement and verify software functions. Develop the application and check whether components and integrated functions meet their specifications. Use appropriate test protocols, including tests involving error handling and abnormal conditions.
6. Evaluate validation and clinical evidence. Assess whether the software fulfills its intended use and whether the available evidence supports its clinical claims. The necessary activities depend on medical purpose, risk, and applicable requirements.
7. Manage release, monitoring, changes, and maintenance. Apply relevant processes for software updates, problem resolution, corrective actions, cybersecurity, and continued evaluation after deployment.

Two healthcare applications can use the same technology and process the same patient data, yet face completely different regulatory requirements. The difference comes down to what the software is designed to do with that information. That's why the intended medical purpose needs to be clear before architecture and development decisions start taking shape.

These stages are connected throughout the software lifecycle. A change to intended use can affect risk analysis, requirements, verification, validation, and potentially regulatory obligations. Replacing an external data source or modifying an algorithm may similarly require reassessing the reliability of the software's outputs. Controlled development depends on understanding the consequences of changes for the intended medical function, rather than treating updates as isolated technical tasks.

Medical software development standards

Medical device software development commonly involves standards addressing software lifecycle processes, quality management, and risk. IEC 62304 provides a framework for medical device software life cycle processes, including development and maintenance. It addresses activities such as software development planning, configuration management, maintenance, and problem resolution. Planning is an early lifecycle activity because requirements, responsibilities, and verification approaches need to be established before they can be executed consistently.

IEC 62304 also uses software safety classes A, B, and C based on the potential consequences of software failure under its classification approach. These software safety classes are distinct from FDA Class I, II, and III device classifications and IMDRF SaMD Categories I to IV. The different systems serve different purposes and should not be mapped directly onto one another. ISO 13485 addresses medical device quality management systems, while ISO 14971 provides a framework for medical device risk management.

The precise applicability of each standard depends on the product and regulatory context. Medical software developers need to consider the editions and requirements relevant to the device they are building. Work toward an IEC 62304 second edition has included consideration of evolving software technologies, including AI and machine learning, but expected future provisions should not be treated as requirements already in force. The applicable published standards and regulatory obligations remain the basis for compliance assessment.

Together, these frameworks help explain why medical device software may require more formal controls than a conventional consumer application. Development records can connect requirements, design decisions, risk controls, testing evidence, and maintenance activities. Such records support the development and evaluation of safe and effective software within the relevant regulatory framework. Compliance with one standard, however, does not automatically establish that every applicable regulatory requirement has been met.

Software verification, validation, and clinical evaluation

Verification and validation answer different questions about software performance. Verification examines whether the software meets specified requirements, while validation concerns whether the product fulfills its intended use under relevant conditions. A function can pass technical verification and still lack evidence that its outputs are suitable for medical decisions. Correct implementation of software requirements does not automatically demonstrate clinical effectiveness.

An image-processing algorithm might reliably produce a defined output when given a set of test images. That result supports assessment of its technical behavior, but it does not independently establish that the output is appropriate for diagnosis in the intended clinical setting. Clinical performance depends on the relevance of the analysis, the intended users, and the conditions in which the software operates. These distinctions become especially important when outputs may influence treatment or diagnosis.

A feature can pass every technical test and still be unsuitable for its intended medical use. In healthcare software, testing has to account for the decisions people will make based on the output, not just whether the code behaves as expected. That distinction changes how requirements are written, risks are assessed, and the product is validated.

The IMDRF's September 2017 SaMD clinical evaluation framework identifies three relevant dimensions: scientific validity, analytical validation, and clinical validation. Scientific validity addresses whether the association between the software output and the targeted clinical condition or physiological state is supported. Analytical validation concerns whether the software correctly processes input data to produce its intended output. Clinical validation considers whether those outputs are clinically meaningful for the intended purpose and target use.

The depth of evidence depends on the medical purpose, risks, and applicable regulatory requirements. Appropriate software quality assurance and validation testing can support evaluation of software behavior, specified requirements, and identified failure conditions. Clinical evaluation and regulatory responsibilities may require additional specialist activities beyond technical software testing. Completing a test suite does not, by itself, establish that a regulated medical product satisfies every applicable clinical requirement.

Cybersecurity, cloud systems, and controlled changes

Connected medical software may rely on networks, cloud services, identity management, external data sources, and third-party software components. A failure in one of these dependencies can become a patient-safety concern when it compromises information or functionality used for a medical purpose. Cybersecurity planning may therefore involve assessing threats, protecting information, evaluating dependencies, managing vulnerabilities, and maintaining controls after release. The required activities need to reflect the product's architecture, connectivity, and regulatory context.

Third-party software visibility is particularly relevant in systems that depend on external libraries and services. Software developers and medical device manufacturers may need to maintain information about components that could affect regulated functionality or introduce security risks. This can also support vulnerability assessment and ongoing maintenance. The scope of the work depends on the product and applicable requirements rather than a universal checklist.

Cloud infrastructure introduces additional operational considerations. Teams need to know where medical data originates, how it moves between components, and what happens if a dependent service becomes unavailable. Incomplete or delayed information may affect a medical function even when the application's own code performs as designed. Reliability must therefore be evaluated across the relevant system dependencies, not only within an individual software component.

Managing AI-enabled SaMD updates

AI-enabled medical device software raises questions about model performance and how changes may affect its intended medical function. A modification to data processing, an algorithm, or a model component can alter the software's behavior. Teams need to assess those changes in relation to performance, safety, and intended use. The relevant regulatory controls depend on the particular product and the nature of the proposed modifications.

In August 2025, the FDA issued final guidance addressing predetermined change control plans (PCCPs) for AI-enabled device software functions. A PCCP can describe specified planned modifications and the methods used to develop, validate, and implement them within the applicable regulatory framework. This provides a structured way to address certain anticipated changes. A PCCP does not provide unrestricted permission to update an AI medical device without evaluating the consequences.

AI implementation also requires decisions about purpose, architecture, evaluation, and maintenance. An AI strategy consulting process may help teams organize technology choices and product assumptions before development begins. For medical applications, those decisions still need to be assessed against the intended medical function and applicable regulatory requirements. Technical strategy cannot replace clinical evidence or regulatory evaluation.

Similarly, AI-powered SaMD product development involves more than integrating an algorithm into an application when the software performs a regulated medical function. Teams need appropriate ways to evaluate software behavior, manage changes, and assess the reliability of outputs. Their responsibilities depend on the product and its regulatory pathway. Successful model integration alone does not establish that the resulting software is suitable for clinical use.

Broader developments discussed in the future of AI in healthcare diagnostics offer additional context for diagnostic applications, treatment, and the challenges of AI-based medical software. These possibilities should be distinguished from evidence about a particular product's safety and effectiveness. Each intended medical function requires support appropriate to its claims. Technical capability and clinical suitability remain separate questions.

Challenges in SaMD development

The main development challenges arise where software behavior, clinical purpose, and regulatory obligations meet. Some concern reliability and security, while others involve validation evidence, documentation, or the management of changes after release. The consequences differ according to the medical function and the seriousness of potential failures. Teams need to address the relevant challenges throughout the lifecycle, rather than treating them as problems to resolve only before deployment.

• Patient safety: Software defects, incorrect outputs, or inappropriate use may affect clinical decisions. Risk analysis needs to reflect the intended function and potential consequences.
• Validation evidence: Passing technical tests does not necessarily establish clinical suitability. Evidence must be appropriate to the software's purpose and risk.
• Data integrity and security: Medical information may originate from sensors, external platforms, or users. Missing, inaccurate, or compromised data can affect software outputs.
• Traceability and documentation: Requirements, risk controls, tests, and software changes may need to be documented and linked through relevant development processes.
• Controlled software changes: Updates to features, algorithms, integrations, or infrastructure can affect regulated functionality. Change management must consider the resulting technical and regulatory implications.

The appropriate response to these challenges depends on the product's intended purpose and regulatory context. Development teams need to distinguish engineering recommendations from obligations established by applicable regulations and standards. A function intended for diagnostic decision-making may require different evidence and controls from a nonmedical feature within the same platform. This is why the scope of development activities should be based on a clear understanding of the software's function and risks.

A defined medical purpose, an appropriate regulatory assessment, and traceable engineering evidence provide a sound foundation for SaMD development. Iterative software development remains possible, but changes to regulated functionality need to be evaluated within the relevant controls. Product teams can use modern software practices while maintaining the documentation, validation, and risk-management activities appropriate to the medical purpose. Patient safety and regulatory responsibilities remain part of the software lifecycle, even when the product is delivered entirely through general-purpose computing platforms.