医疗云成熟度模型：大多数医疗系统跳过的五个阶段

Most health systems will tell you they are “in the cloud.” What that usually means is that they moved a rack of on-premise servers into a cloud provider’s data center, kept the application architecture exactly as it was, and then watched the monthly bill climb instead of fall. Being in the cloud, in that sense, is a little like a car being in a garage. You have changed where the thing sits without changing anything about the thing itself.

This is the most common and most expensive misunderstanding in healthcare cloud strategy: treating the cloud as a destination you either reach or you do not, when it is really a progression through five distinct stages, each one unlocking capabilities the stage before it could not support. I think of it as a cloud maturity model, and the organizations that get real value from their cloud spending tend to know exactly which stage they are on and what the next one actually requires. The ones that stall, and a great many are stalling right now, usually got there by trying to jump ahead to something a vendor sold them.

Here is how the five stages tend to play out across healthcare organizations.

By Michael Blackman, MD, MBA Chief Medical Officer, Greenway Health®

Stage one: Relocation.

This is the cheapest move and the one with the smallest payoff. Most organizations begin by picking up the servers in their data center and setting them down, more or less unchanged, on cloud infrastructure. The industry calls this lift-and-shift, and it is the fastest way to put a cloud milestone into a board update.

It also tends to raise costs in the first year

, since a virtual machine running around the clock in someone else’s data center is rarely cheaper than the hardware you had already bought and paid off. The application behaves the way it always did. You are renting from a cloud provider now instead of running your own boxes, and for a while that is genuinely most of what has changed.

Stage two: Optimization.

This is where the spending starts to make sense, because teams begin using the parts of the cloud that actually justify the price of admission. Self-hosted databases give way to managed ones. Rarely-touched data moves off expensive block storage onto cheap object storage. Capacity scales itself down at three in the morning instead of sitting idle and fully billed. The applications underneath are usually still monolithic, though, which is the part people tend to gloss over when they report that the migration is finished.

Stage three: Cloud-native refactoring.

This is the stage that actually changes what an organization can do, and it is the one most health systems never fully reach. The monoliths get broken into smaller services, teams move to an API-first posture, and FHIR-native data exchange replaces the nightly batch files and the one-off interfaces that most integration still depends on. Done properly, integration stops being a project you finish and becomes something you just have. It gets skipped for reasons that have nothing to do with skill, or rather, nothing to do with the skill of the people being asked to do it. The work is genuinely hard, it reaches into teams, contracts and clinical workflows all at once, and since there is no vendor you can pay to do it for you, it keeps sliding onto next year’s roadmap, year after year.

Stage four: The data platform.

This phase only opens up once the refactoring work is done. It centers on a curated, governed data layer that the whole organization draws from, instead of every application reaching into the EHR on its own terms. Governance moves here as well, to the platform level: lineage, versioning, audit, and access handled once, rather than reinvented inside each separate tool. This is the layer that makes analytics and AI work at any real scale, because every tool ends up reading from the same governed source instead of its own private copy of the truth. Most health systems would like what this unlocks. Far fewer have been willing to fund the year or more of plumbing work it takes to get there.

Stage five: Adaptive operations.

Very few healthcare organizations are anywhere close to this. Cost management runs continuously here instead of as a quarterly scramble, infrastructure adjusts to demand on its own, and the architecture can take on agentic AI and real-time clinical decision support without a fire drill every time. I have seen maybe a handful of systems operate at this level, and none of them skipped the stages underneath to get there, which is really the whole point I am building toward.

The cost of skipping ahead is where this gets expensive. A health system sitting at stage one or two will, with the best intentions, go out and buy something that really belongs at stage five. Usually, it is an agentic AI tool, or a population health engine that takes a clean, governed data layer as a given when the organization has not built one. The capability shows up, lands on plumbing that cannot hold it, and the integration team improvises whatever brittle connections are needed to get the demo working. Eighteen months later those same connections are behind the outages and cost overruns that somebody now has to explain to the board. I have watched this play out more than once. In every case the organization had bought for a stage it simply had not reached yet.

None of this means an organization has to spend a decade marching through all five stages in strict order before it is allowed to do anything interesting. The more useful instinct is to meet every impressive vendor demo with one question before any other: whether your own architecture is actually sitting at the stage the tool takes for granted. Almost anything performs well in a demo, on clean data, in a controlled setting. Whether it survives contact with your real systems depends far more on the stage you are at than on the tool itself, and the demo, by its nature, is never going to be the place where that mismatch shows up.

What sets apart the organizations that handle this well is mostly where they put their money. They fund the middle stages, the refactoring and the data-platform work, even though that work never makes for a good announcement. And they judge any new purchase against the stage they are honestly standing on, even when the roadmap slide claims they are further along. The payoff for getting it right is mostly invisible, since it shows up as the outages and overruns that never happen, which I will admit is a hard thing to walk into a budget meeting and ask money for.

Photo: Natali_Mis, Getty Images

Vallikranth Ayyagari Vallikranth Ayyagari is a technology leader with more than a decade of experience designing cloud-based platforms, data-integration systems, and interoperability solutions across large healthcare and clinical IT organizations. His work focuses on FHIR-native microservices, real-time healthcare data exchange, and the cloud data architectures that make analytics and agentic AI viable in clinical settings. He is the author of peer-reviewed and industry publications on healthcare data integration, including work on FHIR and cloud APIs for healthcare interoperability, the Model Context Protocol for agentic AI, and FHIR-native architecture in healthcare IT. He writes and speaks on the architectural decisions that determine whether healthcare technology programs scale or stall.

This post appears through the MedCity Influencers program. Anyone can publish their perspective on business and innovation in healthcare on MedCity News through MedCity Influencers.

Click here to find out how