Applying AAMI TIR115: Where MedTech Teams Should Start

Randy Horton

Published on: November 11th, 2026

AAMI TIR (Technical Information Report) 115:2026, Guidance for the appropriate use of public cloud computing to enable medical device functions, gives MedTech manufacturers new guidance for a challenge that has become difficult to avoid: medical devices increasingly depend on cloud infrastructure that manufacturers do not operate and only indirectly control.

Orthogonal played a leadership role in developing TIR115. Chief Solutions Officer Randy Horton co-chaired the AAMI Cloud Computing Working Group, while VP of Regulatory & Quality Megan Graham and Founder and CEO Bernhard Kappe also contributed significantly to the guidance.

Now that TIR115 is published, manufacturers have a more practical question: What should they do with it?

We sat down with Randy to get his perspective on where teams should start, which parts of the guidance matter most in practice, and where organizations may have the most work to do.

Start with why cloud requires a different approach

Randy’s first recommendation is simple: get TIR115, read it, and become familiar with it. But he also recommends resisting the temptation to treat it as another document that one function can review and turn into a checklist.

The challenges that TIR115 addresses cross engineering, quality, regulatory, risk management, and cloud operations.

At the center of that problem is indirect control. A manufacturer may choose to make its medical device dependent on computing infrastructure operated by another company. (i.e. the public cloud) That provider can change the infrastructure even though the medical device manufacturer did not initiate the change.

The manufacturer, however, remains responsible for the device’s safety and effectiveness.

Randy believes understanding that underlying issue is more important than getting overly focused on the wording of an individual sentence in the guidance. Once a team understands why and how indirect control matters, the other questions that TIR115 raises begin to make more sense.

What does the device depend on? Which resources are actually part of the medical device? What sits outside that boundary? What happens if an external dependency changes or fails? And how should a manufacturer manage a risk it cannot eliminate simply by controlling its own software?

Those are not questions for engineering alone.

Randy recommends having quality, regulatory, cloud and software architecture leaders review the guidance together. Each group sees a different part of the problem. Cloud and DevOps teams understand how the infrastructure operates and changes. Quality teams understand supplier controls and the QMS. Regulatory teams understand what needs to be documented and justified. Software and systems teams understand how the device behaves when its dependencies fail.

Applying TIR115 means connecting those perspectives rather than handing the guidance from one department to another.

Join the TIR115 Readiness Checklist Waitlist

Book a Cloud Readiness Conversation

Be clear about what you control and what you depend on

One concept that helps teams make those distinctions is the boundary between the Medical Device System (MDS) and the Medical Device Digital Environment (MDDE).

TIR115 defines the MDDE as computing resources required for the proper function of the medical device system but not regulated as part of the MDS. Common examples include general-purpose cloud resources such as compute, storage, and networking.

That distinction is more than terminology.

If teams are not clear about where the MDS ends and the MDDE begins, it becomes harder to make consistent decisions about risk, validation, supplier management, change control, and regulatory documentation.

Drawing the boundary forces the team to identify what it directly controls as part of the device and what parts it relies on that are not legally incorporated within the medical device.

From there, the next question is whether those external dependencies are tolerable risks for the functions they support.

Randy sees the risk-based approach in TIR115 as one of its most important practical concepts. Instead of starting with, “Can we put this function in the cloud?” teams should ask what happens if the cloud resource changes, becomes unavailable, slows down, or behaves differently than expected.

For some functions, the resulting risk may be manageable. Others may require additional architectural or operational controls. In some cases, a team may conclude that a particular function should not rely on an indirectly controlled resource at all.

The key is to make that decision deliberately and early enough to influence the design.

Cloud supplier management is not the same as managing a traditional supplier

Supplier management is where the practical difference between cloud and more traditional medical device supply chains becomes particularly visible.

Randy used a simple example during our conversation.

Imagine a supplier delivers physical components for your medical device to your facility. A truck arrives with the parts. Before those components enter inventory or make their way into a medical device, the manufacturer can inspect them and decide whether or not to accept them.

A pause exists between the supplier providing a product and that product becoming part of the medical device.

Cloud does not give manufacturers that pause.

A cloud provider can update a service or underlying infrastructure, and the environment supporting the medical device will often change without the manufacturer first approving a new component or software release.

TIR115 addresses this by treating public cloud as a purchased service and by applying supplier-management principles to the relationship with the cloud service provider.

But that does not mean a MedTech company can manage a hyperscaler in exactly the same way it manages a smaller component supplier.

Most manufacturers will have limited ability to dictate how AWS, Microsoft, Google, or another large cloud provider operates its underlying platform.

Randy’s advice is to be realistic about that and focus on the controls the manufacturer can put around the dependency.

Can the architecture limit the impact of a provider change? Can the team detect when a service begins behaving differently? Does testing provide enough coverage to identify a problem? Can the device continue operating safely if a service becomes unavailable? Can it recover?

The goal is not to eliminate every cloud-related risk. Nor does avoiding public cloud eliminate infrastructure risk. After all, traditional data centers have their own fair share of common failure modes.

The goal is to understand where control actually sits and design accordingly.

Design for change instead of assuming the environment will stay still

Once a team decides a cloud dependency is appropriate, it must account for another reality: the cloud will keep changing.

That has implications throughout the product lifecycle.

A manufacturer cannot assume that because the device was tested against a particular cloud environment at release, that environment will remain unchanged for the product’s life. Providers continually (i.e. in a frequency of minutes, hours and days) update infrastructure, services, operating environments, and other resources.

TIR115 therefore connects cloud architecture with testing, change management, and postmarket monitoring.

Teams can design architectures that reduce the effect of individual cloud changes, use staging environments to evaluate behavior before changes reach the device where possible, automate testing, and perform planned regression testing to catch effects that may accumulate across multiple changes.

Randy emphasized that the same thinking needs to continue after release.

Manufacturers should monitor their cloud dependencies assuming change is ongoing. One or two provider updates that don’t affect the device don’t mean the next update will behave the same way.

A practical exercise Randy recommends is taking a real cloud failure and running a simulated postmortem against your own product.

There are plenty of documented cloud outages and service failures to choose from. Pick one that is relevant to your architecture and ask what would have happened if it affected your device.

Would you have detected the failure? How quickly? What would the device have done? Could a patient have been affected? Would the system have recovered? Who within the organization would have been responsible for responding?

That exercise can reveal far more than simply confirming that a cloud risk procedure exists. It tests whether the organization actually understands how its device behaves when an external dependency fails.

Three questions for MedTech leaders

When we asked Randy what he would want a MedTech leadership team to examine about its cloud approach, he came back to three areas.

1. What risks are specific to the way we use the cloud, and how have those risks influenced the design of our device?

Identifying a cloud dependency is only the beginning. Teams should be able to explain what could go wrong because of that dependency and where the design addresses those risks.

2. How are we monitoring those dependencies after release?

Cloud infrastructure will continue to change. Manufacturers need a way to recognize when those changes affect the assumptions on which the device was designed, tested, and released.

3. If a cloud dependency changes or fails, how will we detect it and recover?

That includes understanding both the technical response and the potential effect on the device and patient.

These sound like straightforward questions, but answering them may require input from engineering, quality, regulatory, cloud operations, risk management, and leadership.

If those groups give different answers, or no one can answer with confidence, that is a useful place to start.

The issue TIR115 highlights offers important lessons beyond public cloud

TIR115 specifically addresses public cloud computing.

But the work also brought a broader pattern into focus.

Medical devices increasingly depend on third-party-operated computing. Public cloud is one example, but similar questions can arise with EHR integrations, patients’ own smartphones, third-party APIs, machine-learning services, large language models, and agentic AI systems.

What carries over is the underlying question of indirect control enabled by distributed computing.

A manufacturer has a device that depends on technology someone else operates or changes. How should the manufacturer identify the resulting risk? What can it control directly? What needs to be monitored? And what happens when that external dependency changes?

Randy believes this pattern will become increasingly important as medical device software becomes more connected and more dependent on third-party computing.

TIR115 gives MedTech teams a concrete framework for addressing the problem in public cloud today. It may also help the industry develop better ways to think about indirect control, as the same challenge appears in other parts of the medical device ecosystem.

Continue the discussion at our AAMI TIR115 webinar

On November 18 at 11 AM CT, Randy will moderate a live discussion on AAMI TIR115 Is Here: What MedTech Teams Need to Know About Public Cloud Computing.

He’ll be joined by Bill Reid, Healthcare and Life Sciences Lead in Google’s Office of the CISO; Megan Graham, VP of Regulatory & Quality at Orthogonal; and Bernhard Kappe, Founder and CEO of Orthogonal.

Together, they’ll look at what the new guidance means for MedTech teams and how manufacturers can begin applying it to cloud-based medical devices, including indirect control, MDS and MDDE boundaries, risk-based cloud and supplier management, and designing for continuous change.

If your organization is developing SaMD, connected devices, or other cloud-enabled medical device systems, join us for the discussion.

Register for the TIR115 Webinar

AAMI TIR115:2026: Guidance for the Appropriate Use of Public Cloud Computing to Enable Medical Device Functions

Published by the Association for the Advancement of Medical Instrumentation (AAMI), TIR115 provides guidance for managing public cloud computing used to support regulated medical device functions.

Get AAMI TIR115:2026