The Medical Device Is Never Done: Randy Horton on Cloud, Indirect Control, and the Mindset Shift Medtech Keeps Refusing

Randy Horton is the Chief Solutions Officer at Orthogonal, a firm that specializes in accelerating software as a medical device, digital therapeutics, and connected medical device systems. He co-chairs the cloud computing standards committee at AAMI with Pat Baird of Philips, where the consensus report he helped produce — and the technical information report now up for final vote — will be the first time the FDA has a recognized consensus standard for evaluating cloud-based medical device systems. He has spent his career at the intersection of product management, digital transformation, and regulatory compliance. He was a founding contributor to Quartz, the first open source framework for product management, and was recognized for one of the best published articles of 2021 on adopting cloud in medtech.

What makes him worth listening to is the combination. Randy has built things in unregulated software environments — retail tech, federal IT, early commercial web — and watched a generation of modern engineering disciplines emerge in those industries that medtech has been slow to absorb. He is also one of a small number of people in this industry who can speak fluently in both languages: the language of risk management, design controls, and verification and validation that defines medtech, and the language of continuous integration, chaos engineering, and cloud architecture patterns that defines modern software development. The blind spot he sees from that vantage is the subject of this episode.

I invited him on the show because I keep hearing the same story from medtech CEOs: cloud is the right answer, but they don't know how to get to yes on it. Randy spent the conversation taking that story apart.

[00:18] The Cloud Paradox

The starting point is a fact about the cloud that medtech has not fully reckoned with. Cloud infrastructure is incredibly stable. It is also constantly changing. Those two things are not in tension. They are the same thing.

"They are incredibly good, these cloud providers, at change at scale," Randy said. "The reason the cloud is so stable is because they update it hundreds of times a day."

That is the opposite of how medtech has historically built stability. The traditional model is to lock the system down once it's tested, and then leave it alone — because every change is potentially a significant change, and every significant change carries regulatory consequences. "We are very confident in how well it works, and then we lock it down and we don't touch it again. Or we're very cautious about touching it, because every time you change something, you could make what we call a significant change. There's this concept of insignificant and significant changes, and you can make insignificant changes, but you think they're insignificant and it turns out they're significant. Or you made three insignificant changes which in and of themselves were insignificant, but when you combined them together, created a significant change with an unanticipated consequence."

The cloud's value proposition and medtech's stability model are, in their pure forms, incompatible. That doesn't mean cloud is wrong for medtech. It means the two have to be reconciled — and the reconciliation requires medtech to do something it has resisted: accept that the device is no longer fully in its hands.

[00:21] Indirect Control

The concept Randy keeps returning to is one most medtech executives have not internalized.

"Step one is you have to stand up and almost like you're in a therapy group and say, hi, my name is Randy Horton and I have indirect control of the computers that I'm using for my medical device. My medical device depends on computers I do not directly control. I do not get to say when changes happen to them. And that's okay because there's this way we can do it, which is you do this crazy idea called take a risk-based approach."

Indirect control is not a bug in the cloud arrangement. It is the defining feature. If you accept it, there are patterns and methods to design around it. If you don't accept it — if you keep operating as though your team controls the infrastructure your device runs on — then you're either going to be too conservative to use the cloud at all, or too cavalier when you do use it.

[00:22] When the Cloud Isn't Right

The honest version of the risk-based approach includes deciding not to use the cloud when the function can't tolerate indirect control. Randy's example is direct.

"If you have a wearable defibrillator for 30 days after surgery — you are not gonna put the function that says, oh, you're having a heart attack and I'm making the decision to give your heart a shock. You're not gonna put that in the cloud, 'cause you might not have access to the cloud."

The decision-making function for whether to deliver a shock cannot sit in a system you don't control. It has to live on firmware or embedded computing, where the connectivity question doesn't come up. Other functions in the same product can use the cloud — patient data aggregation, post-event analysis, fleet monitoring — but the time-critical, life-or-death decision can't.

This is the test medtech should be applying to every architectural decision: how much indirect control can this specific function tolerate? Not the product as a whole. Each function, individually.

[00:22] What the Three Hyperscalers Agreed On

One of the more surprising moments in the conversation was Randy's account of getting AWS, Microsoft Azure, and Google Cloud in the same room.

"We actually had Amazon, Microsoft and Google's medtech gurus, their cloud medtech gurus, all in the room — was how aligned they were. The solutions are not like you have to have these medtech-only models. You just take traditional cloud architecture models and pick some of the more conservative ones. You just put more of the buffers in place. It's the same thing as good cloud design is good medical device cloud design. You're just deciding where you can and can't have risks and how much you're willing to spend to do mitigations around them. How many failovers do you have?"

The three biggest cloud providers in the world independently arrived at the same conclusion: medtech does not need a special version of the cloud. It needs the conservative version of the regular cloud, applied with risk-based discipline. That's a meaningful finding, because it removes one of the standard excuses for inaction — "the cloud isn't built for medical devices" — from the table.

[00:24] The Medical Device Is Never Done

The mindset shift required to use the cloud well is the hardest part of the conversation. Randy named it directly.

"What you need to assume is — we need to stop thinking that when we release our medical device, it's done, and move to a mindset that the medical device is never done. And you never know on any given day for certain that the medical device you had at 8 AM is not the one you have at 8 PM."

The AAMI committee debated whether to call this revalidation or more proactive and aggressive post-market surveillance. The political weight of the first term is significant in this industry, so the committee landed on language that would actually move through standards-setting and FDA recognition. But the underlying activity is the same.

"You need to constantly be proactively kicking the tires on your cloud-based medical device systems to see if they're still working, so you can quickly identify an issue. You can't prevent a change from happening — if Microsoft deployed a change that broke something in your medical device that wasn't supposed to, but it just, you know, complicated systems, it happened. You can't prevent that from happening, but you can spot it really fast and fix it. And if that's good enough, then you can put it in the cloud."

This is the discipline cloud-native software companies have been refining for two decades. It is genuinely new for medtech. And it is also, Randy argued, the only mindset that makes cloud safe for medical devices in practice.

[00:28] Risk Versus Quality

I pushed back on Randy at one point in the conversation. The framework he was using — risk matrices, probability times impact, ordinal scales — is a framework I have problems with.

"What do you think we would gain if we changed the conversation from risk to quality and performance? Because when I hear risk in cloud computing or in cybersecurity, I'm thinking, okay, you've designed something, you're done, and now something bad might happen in the future and you need to prevent for it. But you can't redesign the system. When I think you're talking about is do good design and have high quality engineering, and many medtech firms might not have that capacity yet, and so they don't know where the flaws can sit in the system."

Randy agreed, and named the lineage of the argument. "This is the classic Deming total quality management debate. Don't fix the bugs at the end of the engineering line. Continually improve the process. And that's the most effective way to ferret stuff out."

This is the deeper version of the cloud conversation, and the place where the conversation about cloud bleeds into a conversation about how medtech builds software in general. The risk paradigm assumes a finished artifact. The quality paradigm assumes a process. Cloud-based medical devices are processes, not finished artifacts — which means risk-management practices designed for finished artifacts are increasingly insufficient on their own.

[00:32] The Insularity Problem

Randy's most pointed argument, and one of the sharpest moments in the conversation, is about medtech's relationship to other industries.

"I do think one error we make, and this is a genuine error in medtech, is we're a little too insular by nature, and we think nobody else has the same challenges we do. So therefore we can't learn from other industries enough."

He named the usual exceptions — aerospace, automotive, nuclear weapons, other safety-critical regulated industries — and then made the harder argument: medtech has things to learn from unregulated industries too. The example he gave is Netflix's invention of chaos engineering: a discipline born from the fact that Netflix's streaming service depends on internet, devices, and infrastructure it doesn't control, and they had to figure out how to test for failures they couldn't predict.

To medtech people who say yes, but those companies don't face the consequences we do, Randy offered a hypothetical.

"I'll offer you two scenarios where you're in the hot seat. One, you worked on a medical device, quality processes weren't up to snuff, and you had a recall, and you now have to face the FDA — or worst case, like in a really high-profile case, Congress, explaining why you screwed up. Would you rather have that, or would you rather be responsible for the operational stability of the shopping cart in amazon.com and have to explain to Jeff Bezos why amazon.com purchase click isn't working for two hours?"

Both of us picked the FDA. The point of the hypothetical isn't that consumer tech is harder than medtech. The point is that the people running consumer tech operate under real and significant pressure, and they've developed methods that work. Refusing to learn from those methods because the industry is unregulated is a choice, and it has a cost.

[00:35] The Language Gap

The communication failure between tech and medtech is partly a vocabulary problem.

"We speak different languages. We use the same words and mean very different things with them. Validation or verification have very different meanings in the software world than in the regulated medtech world. And so we kind of talked past each other, which is a problem, 'cause tech companies sometimes don't know how to speak medtech or understand the core principles of medtech."

This is what tech engineers run into when they walk into a medtech building. "We've, by and large, not done a good job of explaining to people when they come in why we have all these rules. So you say, oh, we're gonna get all these great software people from these amazing companies, and they're gonna come in and we're gonna get all digital and modern. And those people come in and they bang their head on the walls for months because they're being told, you have to follow this rule, and you have to do this, and you have to do that. And nobody ever says why. It's a rule because it's a rule."

The fix is not to lower the rules. The fix is to communicate the why. Randy's preferred line for tech engineers is one of the sharpest formulations in the episode.

"You don't slam code into grandma's pacemaker. When I talk to tech people, I'm like, okay, so this code, it's good. Yeah, no, it's really good. Okay, I'm putting it in your mom's pacemaker. They're like, well, wait, why? Well, I'd wanna test it again. Well — there you go."

Tech people get it immediately when the stakes are named. Medtech just rarely names them.

[00:43] The Quality Systems Engineer

Orthogonal's structural response to all of this is a role they've built into their development teams that doesn't exist in most medtech organizations: the quality systems engineer.

"Our view is take a modern software team — developer, testing automation, and a product owner who sort of owns requirements and driving and prioritizing things — and get them together to build software and medical device software just like anywhere else. But you introduce a new role we call the quality systems engineer, and it literally is a fusion of the roles of systems engineer and quality engineer with a capital Q, from day one. And their job is to drive all those medtech-specific things as a core part of the development team. So from day one, every discussion you're considering all these other factors, and all of those things, these extra layers of requirements we have around risk management and cybersecurity and human factors — we do all of that analysis and documentation within the core tools we use for all of our other software."

This is the practical version of the argument. The traditional medtech model puts quality, cybersecurity, and human factors on parallel teams with parallel documentation — and then asks engineers to coordinate across them. The integrated model puts those concerns inside the development team, in the same tools, traceable as a byproduct of the work itself.

This is the move that lets you actually realize the cost savings modern software practices promise. Randy noted that in some of his past work the gains were significant — 50% reductions in support costs, 80% reductions in project overruns. He was careful not to overpromise the same numbers for medtech (the contexts aren't identical), but the underlying mechanism is the same. Integrated quality work is cheaper than bolted-on quality work, and it produces better outcomes.

[00:53] What's Next: The CMS Bottleneck

The closing turn of the conversation was an answer to a question I had not specifically asked but kept circling. If cloud and modern software practices are coming to medtech, what's the next constraint?

Randy's answer named a shift that has not yet gotten the attention it deserves.

"What's fascinating to me is that, by and large — this is a gross over-generalization — but we talked to medtech CEOs who've been in the industry for a while. They say the FDA used to be the problem for innovation. The FDA is really no longer the problem. CMS is the problem. We've done far better on revolutionizing how we can get to safe and effective devices than we have on how we're going to pay for what they can do."

He pointed to a new pattern he's seeing in connected device companies: building narrowly focused telemedicine practices around their own products, because the existing chronic-disease care infrastructure can't support patients at home with new technologies. The companies are spinning up their own clinical support and billing infrastructure to make the device viable. That is a business model innovation as much as it is a technology innovation, and it speaks to the fact that the bottleneck on connected medtech is no longer regulatory clearance. It's reimbursement and integration into care delivery.

What This Means for the People Building Medtech

The argument Randy made by the end of the conversation is one that medtech needs to absorb whether or not it likes the framing.

The cloud is not going away. Continuous integration is not going away. The fact that medical devices increasingly depend on infrastructure their manufacturers don't directly control is not going away. The choice in front of the industry is whether to accept those facts and build for them, or to keep operating as though the old model is still viable.

The methods to build for them exist. They are not exotic. They live in industries medtech has decided not to learn from, and they live in standards bodies medtech has not always actively engaged with. The AAMI work Randy is co-chairing is one of the first serious attempts to give the FDA a recognized consensus standard for evaluating cloud-based medical devices. When it's finalized, one of the standard excuses for not using the cloud well — that the FDA hasn't defined good — will be gone.

The harder change is the one Randy named at the top. The medical device is never done. The sooner medtech accepts that, the better the products will be — and the safer the patients will be who use them.

Connect with Shannon: LinkedIn: https://www.linkedin.com/in/shannonlantzy/

Connect with Randy: LinkedIn: https://www.linkedin.com/in/randyhorton/ Orthogonal: https://orthogonal.io/