A guide to software as a medical device (SaMD) development

Software as a medical device development is no longer a niche, it's the primary route for MedTech OEMs, digital health companies, and pharma teams delivering regulated functionality. The U.S. SaMD development market is projected to exceed $700 million by 2033, driven by AI-enabled diagnostics and digital therapeutics.

Most teams underestimate what building regulated software really means. They start before locking down the intended purpose, discover evidence requirements too late, treat UX as an afterthought, or release a v1 that cannot scale, triggering painful reworks. Meanwhile, software qualification and classification guidance continues to evolve.

Success in medical device software development demands strategy that integrates regulation, scalable SaMD architecture, data, and business goals from day one. This guide is your end-to-end playbook, from strategy to clearance to post-market evolution.

What is SaMD?

Software as a Medical Device (SaMD) is software intended to achieve a medical purpose, diagnosing, preventing, monitoring, predicting, treating, or alleviating disease, without being part of a hardware medical device.

Most SaMD development programs go wrong before the first sprint. That's because "medical purpose" is not a branding decision, it's tied to intended use, clinical claims, risk classification, evidence requirements, QMS scope, and how you iterate post-launch.

Step 1: Define Product and Commercialization Strategy

Before committing to architecture or feature scope, align on strategic intent: what the product must achieve clinically, how it will be adopted, and how it sustains a viable business model. This working baseline shapes intended use, evidence planning, UX decisions, and what "scalable" really means in a regulated environment.

Clinical Intent and Operational Value

• Primary users and workflows: who uses it and where it lives in the care pathway
• Decision impact: what action the software enables or informs, and consequences if it's wrong
• Outcome and proof strategy: which outcomes matter and what evidence will substantiate them
• Safe use in context: what reliable use looks like in real environments

Adoption, Monetization, and Scaling Path

• Buyer and funding model: who pays and the procurement and reimbursement reality
• Commercial constraints: uptime expectations, integration requirements, support model
• Expansion logic: what changes over time, markets, claims, indications, and what that implies for evidence and post-market obligations

Step 2: Build Your SaMD Regulatory Strategy

Your SaMD regulatory strategy is a detailed plan for navigating legal and regulatory requirements across target markets. At a minimum, teams need a working view of:

• Intended purpose/intended use statement
• Target markets (EU/UK/US and beyond)
• Risk classification and what drives it
• Regulatory pathway and conformity assessment expectations
• Clinical/performance evaluation expectations

Write your intended purpose early, then pressure-test it against what you want to claim commercially, what you can defend clinically, and what you can maintain post-market. The intended use, risk classification, and pathway for SaMD development determine evidence requirements, development strategy, cost, and speed to market.

In the EU, MDCG guidance clarifies how software is qualified and classified under MDR/IVDR. For FDA 510(k), De Novo, or PMA routes in the US, selecting the correct pathway and ensuring complete submission packages is critical to avoid non-conformities. If you're building AI-enabled functionality, growing guidance on how AI Act obligations interplay with MDR/IVDR expectations also applies.

“At Star, we assess our clients' business goals and budget to select the primary markets for SaMD development and launch. We help define the intended purpose of the medical device and risk classification, and make necessary input to product requirements to clearly set the medical device boundaries.”

Antonina Burlachenko

Head of Quality and Regulatory Consulting at Star

Step 3: Establish a Strong ISO 13485 QMS for SaMD

Modern SaMD development programs rely on frameworks including ISO 13485 QMS for SaMD, ISO 14971 (risk management), and the IEC 62304 software development lifecycle - because regulators expect traceability from requirements to risk controls to clinical verification/validation.

A strong QMS is not bureaucracy, it reduces rework, makes releases safer and faster, and keeps teams audit-ready as they evolve the product. Star provides ready-to-use ISO 13485, ISO 14971, and IEC 62304 know-how sets that kick-start QMS setup, shortening the path to compliance.

Step 4: Medical Device Software Design for UX and Human Factors

User experience in healthcare is central to safety, trust, and adoption - not just aesthetics. A confusing workflow creates use errors. A poorly designed clinician dashboard increases cognitive load. These directly affect patient outcomes regardless of how good the underlying algorithm is.

Treat UX as a regulated system component by defining user groups and use environments, mapping critical tasks and harm scenarios, designing risk controls into the interface (not as warnings), and validating with real users early and repeatedly.

What patients expect: Simplicity, accessibility, and transparency around data privacy. Medical device software design must accommodate diverse populations with varying health literacy.

What clinicians expect: Seamless integration into existing workflows, and decision support that reduces friction rather than adding it.

Step 5: Build a Data Strategy for Evidence and AI Readiness

A data strategy for SaMD development is about building a controlled, traceable pipeline that supports safety, evidence generation, interoperability, and long-term evolution. Key considerations:

• Storage and retention: what lives where, retention periods, auditability, access controls
• Normalization and standardization: consistent schemas, coding systems, and units
• Versioning and lineage: trace which data fed which analysis or evidence claim
• Downstream compatibility: pipelines that support analytics, interoperability feeds, and ML training without rebuilding

If AI/ML is on the horizon, even if not in v1, data is the groundwork for training and validating models. A forward-looking approach means preparing for adaptive models from the start without costly rebuilds later.

Step 6: SaMD Architecture and Healthcare Interoperability FHIR HL7

Scalability and healthcare interoperability FHIR HL7 are established by your SaMD architecture choices. Architectural decisions made early determine how easily you maintain compliance, how safely you can change the product, and how costly integration becomes as the product expands.

Cloud vs. Edge vs. Hybrid

This decision influences your operating model, validation effort, security controls, and how you run regulated releases, not just latency:

• Cloud: supports rapid iteration and centralized monitoring, but requires rigorous controls around access, environments, and third-party risk
• Edge: reduces latency and supports offline environments, but increases complexity in update management and post-market monitoring
• Hybrid: common for SaMD with connected devices, but demands clear separation of responsibilities and careful validation boundaries

Interoperability, APIs, and Standards

Build for real-world healthcare environments by designing around healthcare interoperability FHIR HL7 standards. The easier it is to plug into existing systems, the faster adoption tends to be and the lower integration costs.

Modular architecture: helps you iterate faster without putting the entire product at regulatory risk. Upgrade or replace components without revalidating everything.

Plan for regulated CI/CD (controlled releases, traceability), infrastructure as code, observability tied to safety signals, and secure supply chain (SBOMs, vulnerability management).

“Interoperability is more than a feature on a product; it’s a service that extends beyond the initial sale and requires ongoing monitoring and maintenance.”

Yanick Gaudet

Interoperability Solution Architect at Star

Step 7: Cybersecurity for Medical Device Software

Healthcare is one of the most targeted industries for cyberattacks. In 2024, 67% of healthcare organizations reported ransomware attacks. Cybersecurity for medical device software is a safety and regulatory requirement, not just an IT concern.

To meet HIPAA, GDPR, ISO 27001, and evolving global standards, your security posture needs to cover:

• Encryption and key management
• Identity and access management
• Audit logging and monitoring
• Secure SDLC and supply chain risk
• Incident response and vulnerability management

“As we often tell clients, cybersecurity for conventional software differs from cybersecurity for AI systems. You must implement AI-specific guardrails and risk management practices to secure algorithms, data pipelines, and model updates effectively.”

Maksym Tsivyna

Information Security Manager at Star

Step 8: Verification, Evidence, and SaMD Clinical Validation

Verification and validation is where SaMD development stops being "working software" and becomes something a clinical setting can genuinely rely on. SaMD clinical validation goes well beyond unit tests and typically includes:

• Verification testing against documented requirements
• Simulated validation in realistic scenarios, stress-testing edge cases and failure modes
• Live validation in real clinical workflows
• Clinical evaluation activities tailored to the product’s risk class

The goal is not only to show that software functions, it's to demonstrate, using real-world data and HEOR analysis, that it consistently supports patient safety, clinician trust, and meaningful clinical outcomes. Clinical trial expectations vary significantly by jurisdiction, so plan evidence requirements at the regulatory strategy stage to avoid costly delays.

Step 9: Market Clearance - FDA 510(k), De Novo, or PMA Routes

Once SaMD development and SaMD clinical validation are complete, teams prepare submissions for the FDA, EU MDR, or other regulators. This requires assembling technical documentation, clinical evidence, risk management files, and cybersecurity documentation aligned to regional requirements.

Market clearance pathways vary by jurisdiction. For example, FDA 510(k), De Novo, or PMA routes in the US and CE marking under MDR in the EU. Selecting the correct route and ensuring complete submission packages is critical to avoid non-conformities and delays.

Plan for operational readiness (support, monitoring, release process), labeling, training, integration readiness, security governance in production, and post-market surveillance obligations.

Step 10: SaMD Post-Market Surveillance and Lifecycle Management

Achieving clearance is the midpoint, not the finish line. SaMD post-market surveillance and lifecycle management are ongoing obligations that prove your product remains safe, effective, and reliable over time.

• Post-market surveillance and monitoring: track product performance, safety signals, and real-world outcomes
• AI/ML updates aligned with evolving regulation: track adaptive behavior and prevent performance drift
• Continuous usability improvements: reflect clinical feedback and evolving patient needs
• Service reliability and business continuity: guarantee system availability in high-stakes environments

Every new feature or major update must be assessed to determine whether it changes the product’s intended purpose, risk profile, or performance claims. Some may require re-validation or trigger a new clearance submission.

How Star Helps Teams Build Credible, Scalable SaMD

At Star, we align strategy with execution so teams reduce rework, accelerate decision-making, and launch software that’s credible in the real world. Our support spans:

• Solution ideation, positioning, and roadmapping
• SaMD vs. wellness positioning and intended purpose support
• SaMD regulatory strategy, classification guidance, and market planning
• ISO 13485 QMS for SaMD setup and practical implementation
• Medical device software design: human-centered UX for patient and clinician workflows
• SaMD architecture and interoperability strategy and implementation
• Cybersecurity for medical device software: regulatory-grade engineering foundations
• Regulatory-grade engineering foundations (traceability, audit readiness, secure SDLC)

Connect with our Healthcare and Life Sciences experts to see how we can help you combine product strategy, compliance, usability, and adaptability to create software that endures.

FAQs