How to Implement Software as a Medical Device (SaMD)
The healthcare sector has witnessed substantial progress towards the adoption of digital solutions for streamlining healthcare services and care delivery.
Software has gone beyond being just a tool that sits alongside patient care. In many cases, it has become the treatment, the diagnostic, or the monitoring system itself. That shift has given rise to a category of products called Software as a Medical Device, or SaMD, and it comes with its own rules, expectations, and risks.
This guide explains the main decisions healthcare executives and product teams should make before and during SaMD healthcare app development. It focuses on the United States and European Union; exact requirements depend on the product’s intended use, claims, risk, and target market.
What Is SaMD?
The International Medical Device Regulators Forum (IMDRF) defines SaMD as a standalone piece of software that delivers a medical function independently of dedicated medical hardware. It may process or analyze health data, support clinical decisions, monitor patients, or perform other medical functions while running on general-purpose computing platforms.
The key question is not where the software runs, but what the manufacturer intends it to do.
Software may qualify as SaMD when it is intended to:
- Diagnose or screen a disease or medical condition.
- Analyze medical images, physiological signals, or laboratory results.
- Calculate or recommend treatment or medication dosages.
- Monitor a patient and identify clinically significant changes.
- Assist healthcare professionals with decisions related to diagnosis, treatment, or patient care.
By contrast, software used only for scheduling, billing, claims processing, general communication, or storage and transfer of records usually does not perform a medical function. Basic wellness and administrative tools may also fall outside medical-device regulation, depending on their functions and claims.
Clinical decision-support software requires a closer review. In the United States, some functions may be excluded from the device definition when they meet all applicable statutory criteria, including enabling a healthcare professional to independently review the basis for a recommendation. Teams should evaluate the actual functionality and labeling rather than relying on a broad product category.
Examples of SaMD
Here are a few real-world scenarios:
- An algorithm that analyzes retinal images to detect diabetic retinopathy.
- A mobile application that calculates insulin dosing from patient data.
- Software that analyzes ECG data from a wearable and alerts clinicians to possible arrhythmias.
- An imaging application that highlights suspected abnormalities for clinical review.
Software embedded in or necessary to operate a hardware medical device is generally described as Software in a Medical Device, or SiMD, rather than SaMD.
An Eight-Step SaMD Implementation Process
1. Define the intended use and clinical need
Instead of starting with technology, begin with the clinical problem.
Define the medical condition, patient population, intended users, use environment, software inputs and outputs, and the clinical decision or action the output is intended to inform. Avoid vague statements such as “helps physicians make decisions.” The intended use drives classification, evidence, risk controls, labeling, and product design.
Talk to the people who would actually use this software before you build anything. Interview representative clinicians, patients, and operational stakeholders early. Map the current workflow, identify where errors or delays occur, and confirm that the proposed software addresses a meaningful need.
Documenting the knowledge, experience, and environment of your intended users affects interface design, usability validation, user instructions, training needs, and even the regulatory planning required to demonstrate safe and effective use.
2. Determine device status, risk, and regulatory pathway
Before defining the architecture, choosing technologies, or estimating development costs, determine whether the software qualifies as Software as a Medical Device (SaMD) and assess its potential risk to patients. Classification should be based on the software’s intended purpose, its role in patient care, and the potential consequences of an incorrect or delayed output. This assessment influences everything from the regulatory pathway and validation strategy to the amount of evidence needed before the product can enter the market.
In the United States, devices are classified into three risk-based categories: Class I, Class II, and Class III. A device may follow different regulatory pathways depending on its classification and applicable requirements. Under 510(k), the manufacturer demonstrates substantial equivalence to a legally marketed predicate device. If no suitable predicate exists, the De Novo pathway may apply, while certain higher-risk devices may require Premarket Approval (PMA).
In the EU, medical-device software is classified under the Medical Device Regulation as Class I, IIa, IIb, or III. Rule 11 is particularly important for software that provides information used to make diagnostic or therapeutic decisions. CE marking requires the manufacturer to meet the applicable EU MDR requirements and complete the appropriate conformity-assessment process.
Confirm the strategy with a qualified regulatory professional. Product naming, marketing claims, release plans, and clinical evidence should remain consistent with the defined intended use.
3. Establish the quality, risk, and documentation framework
SaMD development must operate within a controlled quality system. As of February 2, 2026, covered finished-device manufacturers in the United States must comply with FDA’s Quality Management System Regulation, which incorporates ISO 13485:2016 by reference while retaining FDA-specific requirements. EU manufacturers must also meet the quality-system obligations applicable under the MDR.
Most SaMD application development projects rely on a combination of established industry standards, including:
Applicable standards depend on the product and jurisdiction. HL7 FHIR is an interoperability standard rather than a general SaMD compliance requirement, but it can support standardized exchange with EHRs and other clinical systems.
Integrate documentation into normal development work. Requirements, hazards, risk controls, architecture, design outputs, test evidence, defects, changes, and approvals should remain traceable. When a requirement changes, the associated risk analysis and tests should be reviewed as well.
4. Convert clinical needs into product and safety requirements
Write functional, performance, safety, security, usability, and interoperability requirements in testable language.
- Functional requirements include the core clinical functionality, any data inputs and outputs, alerting logic, and reporting features.
- Safety requirements often come directly out of your risk management process and include things like data validation checks, fail-safes for missing or corrupted input, or specific alerting thresholds.
- For security requirements, think of authentication strength, data encryption, and how the software will handle access control across different user roles.
- Performance expectations revolve around how accurate the software needs to be, how quickly it should respond in time-sensitive situations, and how reliably it must perform under expected operating conditions.
- User workflows help you map out exactly how different users will interact with the software step by step. This helps surface edge cases early.
5. Design SaMD Architecture for Scale and Compliance
Medical device software architecture goes beyond performance, cost, and scalability. Every architectural decision should consider whether the system can remain secure, reliable, interoperable, and compliant as it evolves.
- Choose the right deployment model: Cloud, on-premises, or hybrid deployment should reflect regulatory requirements, data residency, security policies, and the IT environments of your target healthcare organizations. Avoid assuming one model will work for every customer and design your architecture around the environments your target users actually operate in.
- Design for actual users: A radiologist reviewing hundreds of images has different requirements from a patient managing a condition at home. Choose platforms and interfaces that support safe, efficient use within real clinical workflows.
- Plan for scalability: Architecture should accommodate increasing users, larger datasets, connected devices, healthcare facilities, and evolving clinical requirements without compromising performance or reliability.
- Build interoperability in from the start: SaMD often needs to connect with EHRs, laboratory systems, imaging platforms, wearables, and other applications. Standards such as HL7 FHIR help, but implementation varies across organizations. A flexible integration layer makes expansion easier.
- Make auditability a core feature: Maintain reliable records of access, actions, data changes, and system responses. These audit trails support compliance, security investigations, quality management, and incident reviews.
6. Build security, privacy, and usability into development
Security and privacy obligations depend on the organization, data, users, and jurisdiction.
HIPAA applies in the United States when an organization is a covered entity or business associate handling protected health information; it does not automatically apply to every medical application. The specific privacy obligations can also vary based on the type of data and the jurisdiction involved. For products operating in Europe, GDPR governs how personal data is collected and handled, including requirements around lawful use, limited data collection, security, and individual access rights. However, some rights may have exceptions under specific legal, healthcare, public-interest, or research circumstances.
Use threat modeling and cybersecurity risk management from the requirements stage. Address authentication, authorization, encryption, key management, secure APIs, logging, vulnerability management, update mechanisms, and third-party components.
FDA recommends lifecycle cybersecurity documentation for devices with cybersecurity risk. Products meeting the statutory definition of a “cyber device” are also subject to section 524B of the FD&C Act, including vulnerability-management processes and a software bill of materials.
Agile methods can work within a regulated process when each iteration includes the required reviews, traceability, risk updates, verification, and approvals. Human-factors engineering should involve representative users performing realistic critical tasks, not only informal interface feedback.
7. Verify, validate, and prepare for authorization
Verification shows that the software was built according to its specifications. Validation shows that the resulting product meets user needs and its intended use. Testing commonly includes unit, integration, system, performance, security, regression, interoperability, and usability testing, with evidence linked to requirements and risk controls.
Clinical evidence must be appropriate to the intended use and risk. SaMD evaluation commonly considers valid clinical association, analytical or technical validation, and clinical validation. The required study design and evidence vary by product and regulatory pathway. AI-enabled functions may also require evaluation of dataset representativeness, subgroup performance, bias, drift, and clinically meaningful performance limits.
Prepare submission documentation as development progresses. Trying to reconstruct design history, risk decisions, or test evidence at the end of the project often creates delays and gaps.
8. Deploy carefully and manage the product after launch
Plan for hospital security review, procurement, configuration, integration testing, training, and phased rollout. Each healthcare organization may have different data mappings, identity systems, network controls, and workflows even when it uses the same EHR platform.
After commercialization, perform the post-market surveillance, complaint handling, adverse-event reporting, corrective-action, maintenance, and cybersecurity activities required for the product and jurisdiction. In the United States, manufacturers generally must report qualifying deaths, serious injuries, and malfunctions within 30 calendar days; certain events require reporting within five work days.
Evaluate every software change through the quality system. A bug fix, new feature, cybersecurity update, or AI-model modification may affect risks, validation, labeling, or regulatory status. AI models do not necessarily change autonomously after release. When modifications are planned, an authorized predetermined change control plan may allow defined changes to be implemented within approved boundaries.
Common SaMD Implementation Challenges
How U.S. and EU Regulators Are Responding
Regulatory approaches increasingly emphasize risk, total-product-lifecycle controls, cybersecurity, post-market evidence, and quality management. Higher-risk software generally receives greater scrutiny, while the evidence and controls expected for a product depend on its intended use and potential impact on patients.
Manufacturers are also expected to monitor performance, manage emerging risks and vulnerabilities, and maintain traceable evidence that the software remains safe and effective after market entry.
AI and machine learning introduce another layer of complexity because models may be modified or retrained over time. AI-enabled medical-device software receives particular attention because training data, model updates, and changing clinical environments can affect performance. Manufacturers should define how changes are evaluated, validated, documented, and, when necessary, submitted for additional review. Regulatory expectations continue to evolve, so teams should verify current guidance before making market or submission decisions.
Conclusion
SaMD development succeeds when clinical purpose, regulatory strategy, quality management, engineering, security, usability, and evidence planning begin together. Teams that postpone these decisions often face expensive redesigns or gaps during regulatory review.
Zco brings more than 35 years of custom software development experience to medical and healthcare applications, connected products, AI-enabled systems, and complex integrations. We work with clients and their regulatory specialists to translate product requirements into secure, testable, maintainable software and the technical documentation needed to support the client’s compliance strategy.
If you are planning a SaMD product, we can help assess the technical scope, architecture, development process, integrations, and validation needs before major development begins.
This article offers general guidance on SaMD and does not replace advice from legal or regulatory specialists. Classification, regulatory pathways, and compliance requirements can vary by product and market and should be evaluated accordingly.
Frequently Asked Questions
A good rule of thumb is to ask whether someone would rely on your software to make a medical decision. If your application diagnoses, monitors, predicts, or performs a medical purpose on its own rather than simply supporting healthcare operations or functioning as part of a hardware device, it may qualify as SaMD.
Medical device software is the umbrella term that covers any software used in a medical context, including software built into physical devices and standalone applications.
SaMD is a specific category of medical device software wherein the software itself is the medical device that does not rely on any other dedicated medical device to operate.
For example, software that controls the settings and operation of an MRI scanner is medical device software, while software that analyzes MRI images and helps clinicians identify potential abnormalities is considered SaMD.
Not every SaMD product follows the same FDA pathway. The process depends on factors such as the software’s intended use, associated risks, and whether a comparable device already exists in the market. These factors help determine the appropriate submission route and the level of supporting evidence needed for clearance or approval.
SaMD development typically follows several internationally recognized standards, with each one addressing a different aspect of the product lifecycle:
- IEC 62304 – Provides a framework for managing the medical software lifecycle , including planning, development, testing, maintenance, and software safety classification.
- ISO 14971 – Provides a structured approach to identifying, assessing, controlling, and monitoring risks throughout the product’s lifecycle.
- ISO 13485 – Establishes the quality management system (QMS) requirements for organizations developing medical devices.
- IEC 62366-1 – Focuses on usability engineering to help reduce risks caused by user errors and improve the overall user experience.
- IEC 81001-5-1 – Provides guidance for developing secure health software by integrating cybersecurity into the software development lifecycle.
- HL7 FHIR (where interoperability is required) – Supports standardized and reliable exchange of healthcare data between software applications and clinical systems.
Most SaMD projects take anywhere from 6 to 24 months, but the actual timeline is determined by factors such as your product’s risk classification, the level of clinical validation required, and the complexity of integrating with the healthcare systems. Products with higher patient risk or more complex regulatory requirements require additional planning and validation.
Understanding the cost overhead associated with a typical SaMD project is one of the most important steps innovators need to understand before starting development.
There is no one-size-fits-all cost for SaMD development, since every medical software product has different requirements. In addition to software development, businesses need to account for activities such as risk management, documentation, quality assurance, and validation. A well-defined scope and compliance strategy can help create a more accurate cost estimate.
IEC 62304 is a globally recognized standard that provides guidelines for developing and maintaining medical device software. The standard focuses on areas such as software safety, risk management, documentation, and verification throughout the development process. Following IEC 62304 helps healthcare organizations build reliable software, strengthen their healthcare software development processes, and demonstrate that their development practices align with regulatory expectations.
The main difference comes down to how the software is used. Although both are regulated medical software, they serve different roles. If the software delivers the medical function by itself, it’s SaMD. If the software only performs that function because it’s built into or controls a medical device, it’s Software in a Medical Device (SiMD). In short, SaMD can operate independently, while SiMD is inseparable from the hardware it’s designed to support.
AI-based software may be considered SaMD when its primary purpose is to support a medical use case, such as helping analyze health data, assist with diagnosis, or monitor patients. The deciding factor is not the use of AI itself. The classification depends on factors such as intended use, risk level, and how it impacts clinical decision-making.
