AAMI TIR115: A Practical Guide for Medical Device Companies Using the Cloud

Your medical device is designed to stay still. Your cloud is designed to move.

That conflict has sat unresolved in the medical device industry for a decade. Every manufacturer running a connected device has felt it. Your quality system says you evaluate a change, verify it, validate it, then deploy it. Your cloud provider deploys thousands of changes a week, tells you about almost none of them, and does not offer you the option to decline.

In September 2026, AAMI published TIR115:2026, Guidance for the appropriate use of public cloud computing to enable medical device functions. It supersedes AAMI CR510:2021. BioT took part in the working group that produced it, alongside Philips, Medtronic, Abbott, Becton Dickinson, Boston Scientific, ResMed, Google, Microsoft, Amazon, and FDA/CDRH.

This is what it says, what it does not say, and what it changes for you.

What TIR115 is, and what it is not

TIR115 is a Technical Information Report. AAMI states in the document itself that TIRs are not subject to the formal approval process a standard goes through, that they are voluntary, and that their application rests entirely with the professional judgment of the user.

What it gives you. A consensus vocabulary you can use in a submission instead of inventing your own. A structure for qualifying a cloud provider as a supplier. A documented rationale for your risk file showing you considered current industry practice rather than improvising.

What it does not give you. No presumption of conformity. It is not a harmonised standard in the EU and it is not an FDA Recognized Consensus Standard today. No reduction in any existing FDA or MDR requirement. No substitute for your own risk analysis, a point the document makes repeatedly. No coverage outside the United States, which Annex E scopes out explicitly. No auditor checklist, also excluded in Annex E. And no detailed rule for deciding when a given cloud resource belongs to the device rather than to the environment, which Annex E lists as future work.

In practice, no auditor will assess you against TIR115. They will assess you against ISO 13485 clause 7.4 and against your own procedures. TIR115 is useful because it tells you what a credible answer to those questions now looks like.

The two halves of a cloud-connected device

The central idea in TIR115 is a line you draw through your own architecture.

On one side sits the medical device system, the MDS. These are the components explicitly identified in your regulatory submission as part of the device. Your firmware. Your dosing algorithm. Your clinician application. Your AI model.

On the other side sits the medical device digital environment, the MDDE. These are the computing components required for the device to work that are not regulated as part of the device. Compute. Storage. Networking. The database engine. The operating system on the patient’s phone. The browser a physician uses to open your portal.

TIR115 is direct about the rule. Every computing component must be classified by the manufacturer as one or the other. It cannot be classified as neither, and it cannot be classified as both. Drawing that boundary and defending it is the manufacturer’s job.

This matters because of what follows from it. A component inside your MDS is under your change control and your verification. A component in your MDDE is something you purchase, qualify, and monitor. Those are two completely different operating models, and most manufacturers today have components sitting in a grey area where neither applies properly.

Where this sits next to SaMD and MDDS

This is the question most people ask first, so it is worth settling early. SaMD, MDDS, MDS and MDDE are not four competing classifications. They answer two different questions.

SaMD and MDDS answer: is this software a device, and what class? That is a question about intended use, and regulators own it.

MDS and MDDE answer: given that you have a device, where does the device end and the infrastructure begin? That is a question about architecture, and until TIR115, nobody had given you words for it.

Three consequences are worth stating plainly.

Your SaMD is always part of your MDS. Without exception. If it is described in the submission, it is inside the device system.

MDDS is a United States word. FDA defines a Medical Device Data System in 21 CFR 880.6310, and the 21st Century Cures Act removed certain of those functions from the device definition. The EU has no equivalent term, which leads a lot of European teams to assume the concept does not reach them.

It does, by a different legal route. MDCG 2019-11 reaches a closely analogous line at Decision step 3: software is only medical device software if it acts on data beyond “storage, archival, communication, simple search, lossless compression.” Annex I(c) of the same guidance puts it plainly: information systems intended only to transfer, store, convert, format or archive data are not qualified as medical devices in themselves.

The mechanisms differ, and the difference matters if you sell on both sides. In the EU that software is not qualified as a device at all. In the US, 880.6310 still defines MDDS as a device type, with the Cures Act removing certain functions from the device definition and enforcement discretion covering others. Same instinct about where data handling stops being clinical. Two different ways of getting there. We walked through the US side of this in detail in When Is Your Cloud Platform MDDS vs SaMD.

Neither regulation names the infrastructure layer. FDA refers informally to a “general-purpose computing platform.” MDR gets closest in Annex I, Section 17.4, which requires manufacturers to set out minimum requirements concerning hardware, IT network characteristics and IT security measures needed to run the software as intended. That is the MDDE, described in EU language, four years before AAMI named it. The gap TIR115 fills is a vocabulary gap, and it exists on both sides of the Atlantic.

One trap to avoid. FDA enforcement discretion over an MDDS function does not make that function part of your MDDE. The TIR’s test is what you wrote in the submission. If you described it there, it is MDS, whatever the enforcement posture on the underlying function.

Your cloud provider is a supplier, not a component

Here is where TIR115 breaks with how a lot of technical files are written today.

Many manufacturers document their cloud infrastructure as off-the-shelf software, or as SOUP under IEC 62304. TIR115 says that is the wrong frame. Components of the digital environment should not be treated as SOUP. A cloud service is not a component you integrate and then control. It is a service you purchase from a supplier who controls it, changes it on their own schedule, and keeps running after your release is frozen.

So the governing clause is not IEC 62304. It is ISO 13485 clause 7.4 and 21 CFR 820.50. Purchasing controls. Supplier qualification.

Annex A of the TIR walks through it, and the consequence is stated without softening: if there is a failure on the supplier side, from a regulatory standpoint, the manufacturer is accountable.

Table 1 of the TIR lists what you are expected to evaluate in that supplier. Historical stability and usage data. How the supplier manages the risk of change. Service level agreements assessed against your device’s non-functional requirements. The supplier’s internal testing and change control. Experience with medical devices. Performance metrics covering data integrity, uptime, resilience and bug reporting. Documentation and audit rights.

Read that list against a hyperscaler and the problem becomes obvious. TIR115 says it directly: a cloud service provider generally cannot be audited by a third party in the way a supplier of physical parts can be. The evidence Table 1 asks for largely does not exist in a form you can put in a file.

You can stop validating every cloud change

This is the most consequential paragraph in the document, and it is easy to miss.

TIR115 says manufacturers using cloud computing “need to shift to a model that assumes the cloud environment changes frequently, at a high volume, and often with little or no advanced notice or approval by the device manufacturer.” It calls the traditional technique of evaluating one change at a time “increasingly impractical.”

Read plainly: the consensus position of this working group is that gating every cloud change through your device change control is not the right answer, and trying to do it is not a sign of a strong quality system.

But this is a trade, not a release. You give up per-change validation. You take on four things in exchange.

Architect so cloud changes cannot reach the safety-critical path. The TIR’s own example is a wearable defibrillator. The function that detects a cardiac event and delivers therapy must never depend on a cloud resource, because losing the connection means losing the therapy. The function that analyses the same patient’s historical waveform data to improve the algorithm can sit on the same cloud resource safely. Same device, same resource, two different answers, driven by how the output is used.

Classify the infrastructure correctly and manage it as a purchased service. That is the MDS and MDDE boundary doing real work, not paperwork.

Operate compensating controls. A staging environment that mirrors production as closely as possible. An automated regression suite. Infrastructure as code, so a prior environment can be recreated to reproduce a complaint. Planned, periodic full regression testing, because the risk is not any single change but the cumulative effect of hundreds of small ones that individually looked harmless. Active monitoring of supplier change notifications. A device and data continuity plan.

Keep your judgement. The TIR is explicit that a cloud resource should never be assumed to carry negligible risk. Each one is evaluated on its own.

The short version: you can stop validating every cloud change. You cannot stop watching.

What an auditor will actually ask you for

Strip the document down and four artefacts come out of it. These are the things worth building, and they are the things an auditor can hold.

1. A documented MDS and MDDE boundary, with the rationale for each classification.
2. A cloud supplier qualification file, structured around the categories in Table 1, with the evidence you were able to obtain and an honest account of what you could not.
3. A change monitoring process, covering how supplier change notifications reach you, who assesses them, and what triggers action.
4. A periodic regression plan, with a defined cadence, a defined scope, and results retained.

None of these are new regulatory requirements. All four are things you could already have been asked for under ISO 13485 7.4 and 21 CFR 820.50. What TIR115 adds is a defensible description of what each one should contain when the supplier is a cloud provider.

Where a platform sits in this picture

TIR115 anticipates companies like BioT, and names the pattern. Annex D, Question 3 describes cloud service providers that offer a narrower, specialised set of services and in turn run their own general-purpose computing on resources bought from a hyperscaler.

That is three parties, not two.

The hyperscaler supplies general-purpose cloud. It is not meaningfully auditable by you. It changes on its own schedule. It carries no regulatory accountability for your device.

The medical device cloud platform supplies the layer in between. This is where BioT sits, and it is a different kind of supplier. BioT operates an ISO 13485 certified quality management system. BioT maintains an IEC 62304-compliant Design History File and issues an SBOM per release. BioT can sign a quality agreement, can be audited by a customer, and manages change under controlled release with notice. The platform layer is certified and audited at BioT: HITRUST r2, SOC 2 Type II, ISO 27001 and ISO 27799, with AWS Advanced Technology Partner status. Deployment is either into the customer’s own AWS account or onto a BioT-managed account with a dedicated environment for production, with hosting available in the US, EU and Asia.

The manufacturer owns the device, the clinical function, the submission, and the accountability. That does not move. It never moves.

A platform does not sit on one side either

Here is the part that catches people out, and it is worth getting right.

TIR115 classifies components and usages. It does not classify vendors. So a platform does not land neatly in your MDDE. It splits, and the split is yours to decide and document.

Take BioT as the worked example. Device connectivity and ingestion, data storage, the data model engine, the API gateway, authentication and audit logging, and the runtime that executes plugins are general-purpose computing. They are not specifically clinical, and the same services serve any device. Those sit in your MDDE.

But the plugin code you write runs your clinical logic. The data model as you configure it defines your clinical data. And if you name the clinician portal in your submission as the device user interface, that portal is inside your MDS, even though BioT built it. The TIR’s test is what the submission says, not who wrote the code. The same reasoning appears elsewhere in the document: components of the digital environment should not be treated as SOUP, and SOUP is always part of the device system. A supplied component you have treated as SOUP has already been classified.

Platform component	Usually sits in	Why
Device connectivity and data ingestion	MDDE	Generic transport, not clinical
Storage, data model engine, API gateway	MDDE	General-purpose, serves any device
Authentication, authorization, audit logging	MDDE	Generic platform service
The plugin execution runtime	MDDE	A general-purpose execution environment
The plugin code you write	MDS	Performs your device’s clinical function
The data model as you configure it	MDS	Defines your device’s clinical data
The clinician portal as deployed for your device	Usually MDS	Named in your submission as the user interface

This matters more than it first appears. When a supplied component lands inside your MDS, you cannot manage it as a purchased service you merely monitor. It is inside your device. You need design and verification evidence for it.

That is precisely what a hyperscaler cannot give you, and it is why BioT maintains an IEC 62304-compliant Design History File, issues an SBOM per release, and operates a certified quality management system. Not as credentials. As the evidence a customer needs the moment part of the platform crosses into their device.

A platform supplier worth having holds evidence for both sides of the line. Infrastructure and security evidence for the environment. Design and lifecycle evidence for the components that end up inside the device.

The split, against what TIR115 asks of you

Mapped against the four things TIR115 asks you to take on, the split is specific:

TIR115 asks you to	BioT provides at the platform layer	You still own
Draw and defend the MDS/MDDE boundary	Documented platform architecture and component inventory to draw the line against	The classification decision and its rationale in your submission
Qualify your cloud supplier	A supplier that can be audited, with a QMS, a DHF, an SBOM and current certifications	The qualification file, and qualification of any other supplier you use
Monitor and absorb cloud change	Controlled release with notice, a staging environment, and the platform-layer regression suite	Regression of your own device functions, and your change assessment process
Run periodic full regression	Platform-layer regression evidence you can reference	Your own regression plan, cadence and records

The honest framing is the useful one. A platform does not make your device compliant, and nobody should tell you otherwise. What it does is move a defined set of infrastructure work, and the evidence that goes with it, to a supplier who can actually produce that evidence when your submission needs it. Everything above the platform layer stays yours.

Where to start

If you are running a connected device in the cloud today, three things are worth doing this quarter.

Draw the boundary. Take your architecture and classify every computing component as MDS or MDDE. The exercise is uncomfortable, which is the point. The components that are hard to place are the ones carrying unmanaged risk.

Open your cloud supplier file and read it against Table 1. Be honest about what evidence you have and what you do not.

Decide your regression cadence, and write down why that interval is the right one for your device’s risk profile.

TIR115 did not change your obligations. It described, for the first time with industry consensus, what meeting them looks like when the ground underneath your device moves every day.

Working through this on your own device

None of this is a one-afternoon exercise. Drawing the boundary, qualifying a cloud supplier that cannot really be audited, and setting a regression cadence you can defend are all judgement calls. You make them now and explain them later, to someone who was not in the room.

If you are doing that work at the moment, we are happy to sit down and go through it with you. Your architecture, where your own MDS and MDDE split falls, and what evidence you would need from whoever supplies your cloud. That conversation is worth having whether or not BioT turns out to be the right fit for you.

Book a meeting with our team

BioT took part in the AAMI Cloud Computing Working Group that produced TIR115. For our earlier write-up on the working group’s formation, see Setting a Standard for Cloud Computing in Medical Devices. For the cost side of running this yourself, see Build vs Buy: Medical Device Cloud Platform Cost Comparison.

AAMI TIR115:2026 is available from AAMI. This article is commentary, not a substitute for the document or for regulatory advice.