FPT Guest Blog: Software as a Medical Device (SaMD): Navigating the Future of Regulated Digital Health in Arizona
Medtech is undergoing a quiet shift. The software components that once played supporting roles inside connected medical devices are increasingly becoming the medical device itself. Algorithms that analyze imaging data, applications that deliver therapeutic interventions, platforms that monitor patients between visits, these have become products in their own right, subject to the same regulatory scrutiny as physical medical devices. The scale of the shift is already on the record: the FDA has now authorized more than 1,400 AI-enabled medical devices, up from roughly 950 in 2024.
Arizona’s medtech ecosystem is in the middle of this shift. Companies across the state are building connected devices and digital health platforms with strong product velocity, but the regulatory bar for Software as a Medical Device (SaMD) is fundamentally different from the bar consumer or enterprise software teams are used to clearing. The work of meeting that bar is where the next wave of Arizona medtech innovation either accelerates or stalls.
This article looks at what SaMD actually requires, why Arizona’s medtech sector is well-positioned to lead in this space, and what the practical path forward looks like for companies serious about moving regulated digital health from ambition to clearance.
Why SaMD Is Different
Software as a Medical Device, as defined by the FDA and the International Medical Device Regulators Forum (IMDRF), refers to software intended to perform one or more medical functions without being part of a hardware medical device. Think diagnostic algorithms that interpret imaging studies, clinical decision support platforms that recommend treatment paths, or digital therapeutics that deliver evidence-based interventions through smartphones.
The defining characteristic of SaMD is that the software itself is the regulated product. That changes everything about how it has to be developed. SaMD falls under the same FDA framework as physical medical devices, with risk-based classification levels (Class I, II, or III) that determine the regulatory pathway and the level of scrutiny applied.
In practical terms, SaMD development requires:
- IEC 62304 compliance for software lifecycle processes, including planning, design, implementation, integration, verification, and release
- ISO 13485 quality management systems applied to software development, not just hardware manufacturing
- ISO 14971 risk management integrated into the software development process from concept through post-market surveillance
- Documentation and traceability that supports FDA submission and ongoing regulatory accountability
Most medtech firms have strong product engineering capability. Fewer have the regulated-software discipline that SaMD requires. Closing that gap, without sacrificing the development velocity that made these companies competitive in the first place, is the actual work of becoming a SaMD-capable organization.
The Arizona Medtech Context
Arizona’s medtech sector has become one of the most active in the Southwest, and the numbers bear it out. The state’s bioscience industry employed more than 40,000 people across 3,652 business establishments in 2023, up 24.6% since 2019, and Arizona’s 2025 Bioscience Roadmap names medical device manufacturing among its areas of particular excellence. The state’s strengths span diagnostic imaging, connected medical devices, biotech, and digital therapeutics, supported by research institutions, a growing startup ecosystem, and proximity to established medical device hubs in California and Texas. Lower operational costs and a strong technical talent base have made Arizona an increasingly attractive location for medtech product development.
That growth comes with a familiar challenge. Arizona medtech firms competing for FDA clearance face the same regulatory complexity as their counterparts in any other state, and the companies winning that competition treat regulatory readiness as a design discipline rather than a documentation phase at the end of development. The ones that defer regulatory work to the post-development stage tend to discover, painfully, that the gap between consumer-grade software practices and SaMD-grade software practices is bigger than expected.
This is where the right product engineering partner matters. Arizona medtech firms with strong product velocity and limited regulated-software depth can close the gap by partnering with teams that bring SaMD discipline as part of their core engineering practice. The question is what that partnership should actually look like.
Nearshore Development with Regulatory Alignment
For Arizona medtech firms, nearshore product development offers a specific set of advantages that matter for SaMD work. Time zone alignment with US-based regulatory affairs and clinical teams means real-time collaboration during validation cycles. Easier coordination during FDA submission preparation reduces the friction that often slows regulatory milestones. Cultural and language alignment matters more than it sounds when regulatory documentation requires the kind of precision that ambiguity cannot survive.
But nearshore alone is not enough. SaMD development requires partners who bring regulated-software experience, not just product engineering capability. That means teams that understand:
- IEC 62304-compliant development processes built into how every sprint operates, not bolted on as separate documentation
- Risk management integrated into design decisions, with hazard analysis informing architecture choices from day one
- Validation and verification practices that produce evidence packages aligned to FDA submission requirements
- Quality management discipline applied to software development without slowing the iteration cycles that medtech innovation depends on
The combination of nearshore proximity and regulated-software discipline is what makes SaMD development viable at the pace medtech firms need. Arizona companies targeting the US healthcare market specifically benefit from this combination because their regulatory pathway, their clinical partners, and their customers all sit on the same side of the border. Reducing the operational distance between development teams and regulatory milestones translates directly to faster, cleaner submissions. FPT has delivered this model in practice: for a US division of a global diagnostics leader, it built a compliant, cloud-based quality control system for hematology instruments using an AI-augmented software development lifecycle, achieving 57% faster user manual creation, 50% less effort in requirements breakdown, and 14% overall cost savings while meeting regulated-software standards.
The Technical Backbone: Azure and the Microsoft Frontier Partnership
Regulated digital health depends on cloud infrastructure that meets a specific set of requirements. HIPAA compliance is the starting point, but SaMD workloads also need FDA-recognized validation patterns, data residency controls, continuous audit logging, integration with healthcare data standards like FHIR and HL7, and the ability to support clinical validation environments that meet the same scrutiny as the production system.
Microsoft Azure has emerged as the platform of choice for regulated digital health. Azure Health Data Services provides FHIR and DICOM capabilities purpose-built for healthcare workloads. The Azure compliance portfolio covers HIPAA, HITRUST, and the validation patterns that translate directly to FDA submission documentation. For SaMD teams building on Azure, the platform itself shortens the distance between development and regulatory readiness.
FPT’s position in the Microsoft ecosystem strengthens that path. In May 2026, FPT became the first Microsoft Enterprise System Integrator in Southeast Asia to achieve Frontier Partner status, one of the most selective tiers in the Microsoft partner ecosystem. The designation reflects audited delivery evidence, enterprise-scale implementations, and consistent performance across complex transformation programs.
For Arizona medtech firms building SaMD on Azure, that partnership tier translates into deeper technical alignment, validated implementation patterns for regulated workloads, and access to joint capability across AI, cloud, and data foundations. Combined with nearshore product development discipline, the result is a clear operational path: regulated-software development applied by experienced teams, deployed on a healthcare-validated cloud platform, backed by Frontier-tier Microsoft expertise.
What to Ask Before the Next SaMD Initiative
For medtech leaders preparing the next wave of regulated digital health work, five questions distinguish initiatives that will clear regulatory review from initiatives that will stall.
- Is regulatory readiness treated as a design discipline within your development process, or as a documentation phase at the end of the project?
- Does your engineering team have demonstrated experience with IEC 62304 and ISO 13485, or are consumer-software development patterns being applied to a regulated context?
- Are validation and verification practices aligned to FDA submission requirements from the first sprint, or will they need to be reconstructed before submission?
- Is your cloud infrastructure platform validated for healthcare workloads, with HIPAA compliance, audit logging, data residency controls, and FHIR/HL7 capabilities built in?
- Does your development partner bring the Microsoft and Azure depth that regulated digital health work actually requires, or is the partnership stopping at standard cloud deployment?
These questions are not blockers. They are clarifying questions that, asked honestly at the start of a SaMD initiative, prevent the stalls that have consumed so much medtech investment over the past several years.
The Foundation for Regulated Digital Health
The medtech companies defining the next decade of digital health share a common trait: they treat SaMD readiness as a core discipline built into how they develop from the start.
For Arizona medtech firms with strong product velocity and growing regulatory ambition, the practical path forward combines three things: regulatory discipline applied as a design principle, nearshore product development with proven SaMD experience, and a cloud foundation built on Azure and backed by Frontier-level Microsoft expertise.
That combination is what turns connected device ambition into clearance-ready Software as a Medical Device. And it is the foundation Arizona medtech needs to lead the next chapter of regulated digital health.