Cloud-Native Architecture for MedTech

Cloud-Native Architecture (What MedTech Teams Can Learn from Amazon, Google and Microsoft for MedTech)

Randy Horton

Published on: April 8th, 2026

Executive Summary

Orthogonal recently hosted a webinar featuring MedTech experts from AWS and Cepheid to explore a growing challenge in MedTech and SaMD:
As products become more connected, even small updates start to ripple across the system. What used to be a straightforward release turns into a coordination problem. Teams slow down, not because they lack skill, but because the system makes it hard to predict what a change will affect.

That’s not a process issue. It’s an architectural one.

The discussion focused on what happens when tightly coupled systems are expected to support frequent updates, new integrations, and ongoing changes after release. In contrast, cloud-native architecture treats systems as a set of smaller, independent services rather than a single unit. Teams can develop, test and deploy these services separately, introducing changes in stages and validating them as they go.

In tightly connected systems, each update touches more of the product. Over time, that makes changes harder to modify, test, and release.

Cloud-native approaches address this by isolating parts of the system and controlling how changes are introduced. Instead of treating the product as a single unit, they break it into smaller services with clear boundaries. That makes it possible to update one part without affecting the rest, giving teams more room to move without introducing unnecessary risk.

For MedTech teams building connected devices and SaMD, this is becoming a competitive advantage, and even just table stakes. Systems that become harder to change with each release slow teams down, increase coordination overhead, and make it harder to respond to real-world use.

Where Systems Begin to Break Down

Most teams don’t design systems to fail. They design them without a clear plan for how they will change.

That gap doesn’t show up early. It starts to surface as the system grows, something the group pointed out early in the webinar.

As teams add features and integrations, the system becomes harder to modify. The impact shows up in a few ways:

The system becomes harder to change
Even small updates require coordination across multiple teams
Release cycles stretch out
Adding more engineers doesn’t increase output and can even slow things down

This pattern shows up often in MedTech organizations building connected devices and SaMD-enabled products. What starts as a focused product turns into a network of devices, services, and data flows. When teams keep those pieces tightly connected, small changes begin to affect much larger parts of the system.

At that point, teams spend more time managing dependencies than improving the product.

Cloud Adoption Is Not the Same as Cloud-Native

Many MedTech teams turn to the cloud when systems become difficult to manage.

As discussed in the webinar, this move solves a very specific problem.

Moving to the cloud removes the need to maintain infrastructure and gives teams access to highly reliable, scalable services. Cloud providers operate at an operational level most organizations cannot match. For example, standard storage services automatically replicate data across multiple data centers.

This allows engineers to focus on the domain where they create value, whether that’s device performance, clinical workflows, or SaMD functionality.

But moving a tightly coupled system to the cloud doesn’t reduce the coordination required to make changes.

If teams keep that architecture, the system behaves the same way in the cloud as it did on-premise. Changes still affect large parts of the system. Releases still require coordination across teams.

Cloud-native architecture addresses that issue directly. It breaks the system into smaller services with clear interfaces. Teams can update those services independently, which reduces the scope of each change and makes releases easier to manage.

Digital Ecosystems Increase Value and Complexity

As systems evolve, they rarely stay contained within a single device.

Throughout the webinar, the group returned to the question of how quickly products expand into broader ecosystems.

Most MedTech products now operate within digital ecosystems that include mobile apps, cloud services, third party system integrations, and continuous data exchange. Many of these ecosystems support SaMD features that rely on ongoing data processing, algorithm updates, and clinician-facing insights.

This creates real value. It also introduces complexity.

Dependencies grow. Systems interact in ways teams can’t fully predict. Some components evolve outside your control, such as mobile platforms or third-party services.

As that environment expands, architecture starts to matter more.

Systems designed as tightly controlled units struggle to keep up. Modular systems, built with change in mind, handle these interactions more effectively.

Designing for Continuous Change

Once systems operate in that kind of environment, teams can’t treat change as an exception.

Traditional approaches try to limit change to reduce risk. That works when systems stay stable and isolated. It breaks down when systems support connected devices and evolving SaMD functionality.

Teams need a different approach.

Cloud-native systems assume change will happen and account for it in their design.

Teams handle this by:

Isolating components so failures stay contained
Rolling out updates in stages
Validating changes continuously instead of waiting until the end

Large-scale platforms follow this model. They start in small environments, expand gradually, and include rollback mechanisms at every stage.

This approach allows teams to release updates without putting the entire system at risk.

Rethinking Risk in a Connected System

Once teams design systems to support continuous change, their approach to risk has to change as well.

MedTech organizations have traditionally tried to reduce risk by controlling system boundaries and limiting dependencies. That becomes harder as systems connect to external services and operate in real-world environments, especially when they support SaMD functionality.

External services change. Platforms update. Users behave in ways teams don’t fully anticipate.

Trying to remove that uncertainty slows development and leads to rigid systems. Instead, teams focus on detecting issues early, limiting the impact, and recovering quickly. You can see this in how teams release and operate their systems. They use techniques such as progressive deployment, automated testing, and strong release pipelines to manage change as it happens.

The discussion also challenged the idea that MedTech operates under uniquely high risk. Other industries face similar stakes. A failure in a large-scale commerce system (e.g., if the checkout function at Amazon.com stops working) can have immediate and serious consequences, even if human lives are not at stake.

The difference is how those organizations respond. They build systems that handle change well, rather than trying to avoid it.

Control Through Architecture, Not Exhaustive Oversight

If teams can’t prevent every issue, the question becomes how they maintain control as systems evolve. As systems become more dynamic, traditional control models start to break down.

The panel highlighted how this becomes especially clear in cloud-based environments.

Underlying services change constantly. Teams can’t track and validate every change manually, especially when their systems depend on external components.

Control comes from how the system is designed.

Teams define clear boundaries between components and limit how changes propagate across the system.

They also decide where review is necessary and where automation is sufficient.

High-risk changes receive careful review. Routine updates move through automated pipelines.

This allows teams to maintain control without slowing down development. The system absorbs much of the complexity, instead of pushing it onto the teams managing it.

Observability as a Core Capability

When teams stop trying to control every part of the system, they need clear visibility into how it behaves.

That includes monitoring system performance, detecting anomalies, and identifying behavioral changes. It also means understanding how users interact with the product in real-world conditions.

Teams often learn the most from how the system behaves outside controlled environments. Internal testing can’t possibly capture every scenario.

This becomes even more important in environments like Bring Your Own Device (BYOD), where users access the system on their own phones, tablets, or computers, each with different operating systems, configurations and update cycles.

Without visibility, teams discover issues late. With it, they can respond early and adjust before problems spread.

Architecture and Regulatory Alignment

As systems become more distributed, teams need to clearly define what part of the medical device is and what sits outside it.

They must map dependencies and show how external components interact with the system, especially for SaMD components under regulatory oversight.

Without that clarity, it becomes difficult to answer basic questions during audits or submissions.

Where does the system boundary sit?
What happens when an external service changes?
How is risk controlled?

A structured, risk-based approach helps teams answer those questions directly. Clear boundaries make it easier to explain how the system works, how teams detect issues, and how they respond when something goes wrong.

Aligning Teams Around How Systems Work

Technology alone doesn’t solve the challenges of building, managing, and explaining these systems.

Teams need to align engineering, quality, and regulatory around how the system actually works.

When teams focus only on demonstrating compliance, friction builds. Reviews slow progress. Work moves between functions rather than being resolved within the team.

That disconnect becomes more visible as systems grow and support connected devices and SaMD functionality.

When teams focus on building high-quality systems, compliance follows from the work they already do.

That requires a change in ownership. Engineering teams take responsibility for how the system behaves in real use. Quality and regulatory teams define the constraints, risks, and expectations that shape those decisions.

Teams work more effectively when they make decisions together rather than handing work off between functions.

How Orthogonal Can Help

1. Design Architectures That Support Continuous Change

We help teams move from tightly coupled systems to modular, cloud-native architectures that reduce the impact of change and allow systems to evolve without slowing development.

2. Embed Quality and Regulatory Into Development

We integrate design controls, risk management, and evidence generation directly into engineering workflows so that compliance supports development rather than delaying it.

3. Improve Speed Without Increasing Risk

Through automated testing, progressive deployment strategies, and robust CI/CD practices, we help teams detect issues early and respond quickly to system changes.

4. Increase Visibility Across Complex Systems

We implement observability and product analytics practices that provide real-time insight into system behavior and user interaction, enabling faster diagnosis and better decisions.

5. Align Engineering, Quality, and Product Teams

We work across functions to establish shared mental models, reduce friction, and ensure teams can make decisions confidently within clear system boundaries.

Watch Webinar Recording

Randy Horton, VP of Solutions and Partnerships, Orthogonal