The Radiology Layer Nobody Talks About (And Every AI Tool Depends On)

Every few weeks, there’s a new AI product promising to catch the nodule, flag the fracture, turn a dictation into a clean, structured report, or reprioritize your worklist so the urgent case surfaces first. The conversation around AI in radiology has almost entirely been about what the model does: how accurate, how validated, how fast. Almost nobody is talking about what has to happen before any of it works.

Detection algorithms, generative reporting tools, worklist triage engines; all of them are only as good as the data that reaches them. The right prior study, the right patient match, the right structured measurement, the right referral priority, at the right moment. If that connectivity layer isn’t solid, it doesn’t matter whether the AI sitting on top is analyzing an image, drafting a report, or ranking a queue; it is working with incomplete information, or it’s not getting fed at all.

Look at where the major imaging vendors are actually investing, and the pattern is consistent. Sectra ships its VNA with a dedicated interoperability platform (the Connectivity Hub) specifically because “standards-based” doesn’t mean “consistent.” HL7 v2 to CDA, DICOM SR to CDA, patient identity reconciliation across archives with different IDs; someone has to reconcile all of it, continuously, or the data arriving at any given endpoint is unreliable. Laurel Bridge built an entire product line (Compass, Navigator, Waypoint) around routing, tag morphing, and prior-fetching because getting the right exam to the right radiologist across disparate PACS and VNA environments is a harder problem than it looks from the outside. Visage is explicit that its AI Accelerator program only works because the platform was “architected for interoperability” from the start rather than bolted on as a closed system.

They are selling what makes AI possible to deploy at scale, whatever form that AI takes, detection, reporting, or workflow orchestration.

Vendor-neutral archives were supposed to solve lock-in. Store everything in a standards-based format — DICOM, HL7, WADO, XDS — and in theory you’re free to swap PACS, viewers, or reporting tools without a migration project. That promise is real, but it solves the storage layer. It doesn’t solve the layer above it.

The lock-in that actually slows departments down today lives in the integration layer, not the archive. If your connectivity engine only knows how to talk to one specific PACS-RIS-EMR combination, replacing any single piece of that stack means re-plumbing everything around it: every routing rule, every tag mapping, every custom interface someone built years ago and nobody wants to touch. That’s lock-in with a standards-compliant archive sitting right there. The integration layer matters as much as the archive it feeds. A connectivity engine built to normalize across many PACS, RIS, EMR, and AI vendors, not just the ones you happen to run today, is what actually delivers the vendor-neutral promise. Swap a PACS, add a new AI reporting tool, onboard a site running a completely different stack, and the broker absorbs that change instead of forcing a rebuild.

This is the thinking behind KailoHub. It isn’t an archive, and it isn’t an AI model; it’s the connective tissue that sits between all of it. Every referral, measurement, and report that moves through KailoFlow (structured reporting) and KailoAir (reporting platform) runs through KailoHub first. It’s built to do the same job for AI outputs, whether that’s a detection algorithm’s finding, a generative reporting tool’s draft, or a worklist engine’s priority score, routing all of it into the right workflow, at the right site, without someone manually reconciling the handoff.

The reason this matters beyond Kailo’s own stack: KailoHub is also deployed as a standalone broker, purpose-built for radiology’s specific mess: DICOM tag complexity, structured reports, multi-site prior reconciliation, rather than retrofitted from a generic engine like Rhapsody, Mirth Connect, or Cloverleaf. Multi-site groups running it that way are solving the exact problem Sectra and Laurel Bridge are solving from their own corners of the market: making the connective tissue strong enough that whatever sits on top of it; a structured reporting platform, a dictation AI, a triage algorithm, next year’s tool nobody’s built yet, actually gets fed properly, and doesn’t require ripping out the plumbing to add it.

You feel the gap long before you feel the benefit of any AI tool. It’s the prior study that doesn’t auto-populate because it lives on a different archive with a different patient ID. It’s the measurement that has to be retyped from the modality into the report because the structured data never made the trip. It’s the referral that sits in a fax queue instead of routing straight into the RIS, invisible to whatever worklist logic is supposed to be prioritizing it. Every one of those is a connectivity failure, not an intelligence failure, and every one is exactly what needs solving before any AI, of any kind, can add value.

If your department is evaluating an AI tool right now, for detection, for reporting, for worklist management, the sharper question usually isn’t “how accurate is the model.” It’s “what does this tool need to see, and can our systems actually get it there, consistently, at scale, across every site we run, without locking us into today’s stack.” That’s an interoperability question before it’s an AI question, and it’s the one worth asking first.

The algorithms will keep improving, and so will the reporting tools and worklist engines built on top of them. The connective tissue is what decides whether any of that improvement reaches a patient.