Hospital AI Needs Somewhere to Run
A hospital doesn't get AI by wanting AI. It gets AI by having somewhere to run it, someone accountable for it, and infrastructure nobody's talking about in the clinical AI content.
I own healthcare AI sites.
I own IBM Power and AS400 sites.
For a while, those two groups of properties had never once linked to each other.
That's a weirder gap than it sounds. Clinical AI content talks about governance, patient safety, adoption. IBM Power content talks about hardware, IBM i modernization, upgrade planning.
Nobody was answering the question that actually connects them: where does the hospital's AI system run, and does the infrastructure underneath it support what the clinical team wants to do.
The Gap Was Obvious Once I Looked
IBM's been baking AI into Power hardware and IBM i tooling. That's not a secret, it's their public roadmap.
Meanwhile my healthcare AI properties, AIHealthcareNow.com and AIMedicineNow.com, were writing about clinical AI governance and adoption with basically nothing about the infrastructure layer underneath any of it.
Data locality. Local inference. Whether an IBM i shop actually has a path to run modern AI tooling without ripping out systems that already work.
That's an infrastructure story, and I had the sites to tell it. I just hadn't connected them yet.
Building the Hub and Spokes
AIHealthcareNow.com became the hub. One central piece on AI-ready healthcare infrastructure, pinned to the homepage and its category page so it wasn't just floating out there.
Then the spokes, each one written for the audience actually reading that specific site: a hospital-infrastructure piece on AIHealthcareNow itself, a clinical-governance piece on AIMedicineNow, a Power 11 IBM i upgrade-planning piece on AS400IBMSystem, a Power S1112 local-inference piece on the Power11 subdomain, and an IBM Bob modernization piece on AS400Software.
Six properties, one real connective idea running through all of them, with actual working links back and forth instead of six standalone articles that happen to share a topic tag.
Then I Sent It to the Wrong Site
This is the part I'd leave out if I were writing this to look smart.
The Power S1112 healthcare piece was supposed to go on power11.as400system.com. It went, at first, to power11.as400ibmsystem.com instead.
Similar names. Different sites. Different content architectures underneath them entirely.
Good news: it got caught before it did real damage, and the fix wasn't a copy-paste job. The correct subdomain uses a completely different content pattern, so the article had to be properly adapted into that site's actual data structure, not just moved over.
While I was in there fixing it, I added a Healthcare AI glossary entry with real links out to the clinical governance content, fixed a mobile table that was running too narrow, and fixed glossary links that were rendering in plain black text instead of looking like links at all.
None of that would have happened if the first attempt had landed on the right site and I'd just moved on.
The Link I Didn't Add
There was an obvious-looking link target for the new glossary entry: a domain called AIHealthcareToday.com. Right name, right topic, felt like it belonged.
It didn't resolve. Not from my machine, not from the server.
I could have linked it anyway and assumed it would come back online eventually. I didn't. A campaign built around connecting real infrastructure to real clinical need doesn't get to publish a dead link and call the cluster complete.
So it's just not linked. If that domain ever comes back, it's a candidate for a future, verified addition. Not an automatic one.
What the Numbers Actually Say Right Now
After the campaign, the cluster's inventory grew across all six properties, and the corrected Power11.AS400System subdomain ended up with 83 public items and a 22-term glossary layer it didn't have before.
I want to be honest about what that is and isn't. Those are inventory counts. Pages exist, they're in the sitemap, they're in the federation catalog, they returned HTTP 200 when I checked.
Whether that actually earns rankings, clicks, or AI citations for AI-ready healthcare infrastructure and the related terms is a separate question, and it's too early to answer it. That's exactly why this campaign has its own open tracking entry instead of a victory lap.
The interesting part of this build wasn't the six articles. It was catching the wrong subdomain before it stuck, and refusing to link a domain that didn't actually answer when I called it. Small checks. They're the difference between a cluster that's real and one that only looks real until somebody clicks through.
Explore Related Research
Browse our documented case studies, experiments, and systems.