Data360 Is Easier Than They Say

A physician-architect’s view — from 42 years at the bedside to the cloud. The platform is not hard. It is hard without intent. Here is what changed when we gave it a clinical question to answer.

For 42 years I have practiced medicine, and for most of them the same problem shadowed me from one institution to the next: the data existed, but never where I needed it, in the form I needed it, at the moment I needed it. Charts in one system. Imaging in another. Claims behind a firewall. Research cohorts assembled by hand. Every clinical question became a small expedition.

I started taking this seriously at Brigham and Women’s Hospital in 1990, building one of the early EMRs and studying Total Quality Management — Deming, Juran — well enough to publish on quality management in interventional radiology. A conviction took root then that I have never let go of: the system itself is the patient. If we cannot get the right information to the right person at the right time, we cannot move the outcome. Every chapter since — “any image, anytime, anywhere” in 2006, the SEHA work in 2015, the Quintuple Aim today — is the same book.

Its thesis is simple. The bottleneck is never the data. It is the platform that should expose the data, and the workflow that should act on it.

What Actually Changed

From MuleSoft integrations to a live MCP

For most of two years on Data 360, our way into the platform ran through MuleSoft. We built integrations. We wrote APIs. We had real success. But every clinical problem still ran the same gauntlet: a question from me, weeks — sometimes months — of work by architects and engineers, and an answer that, even when it arrived, often missed the clinical nuance that made it worth asking. The translation losses were real, and they were expensive.

In May 2026 the MIMIT Data Cloud MCP went live, and the slope of the curve changed. The core Data 360 primitives — Data Lake Objects, Data Model Objects, Calculated Insights, Segments, Identity Resolution, Activations — became directly callable in natural language against the live tenant. Not a demo. The production environment, answering in the room.

Before, a clinical question became a ticket to data engineering, then weeks or months of work, then an answer that often missed the point. Now, a clinical question is driven against the platform in real time and returns in minutes or hours — as an answer, an artifact, or a live activation.

For a small organization, that is a profound shift. We do not have an army of data engineers; we are agile by necessity. We sit on Data Cloud, Marketing Cloud, and Health Cloud, driven by AI — Claude, Claude Code, Cowork — and questions that used to take a quarter now resolve in an afternoon. We are doing, in days, things that institutions with hundreds of analysts have not done in years.

“Data360 Is Hard”

It is not hard — it is hard without intent

I have heard leaders say it, and the complaint travels: Data 360 is hard to use, not fully understood, too big and too abstract to be worth the climb. Let me push back, plainly.

Data 360 is not hard. Data 360 without intent is hard. The platform is enormous because the surface area of enterprise data is enormous. Walk in without a clinical question, without a measurable outcome, without an ontology of your own, and yes — you will drown. You will stand up DMOs nobody queries. You will build Segments that activate nothing. You will declare victory because the platform is “deployed.”

Pair it with three things and the same platform turns elegant:

With those in place, the unified data structure stops being a tool you operate and becomes an ecosystem you think inside of. You stop thinking about the platform. You start thinking about the answer.

A caveat earned in practice: schema is not meaning. Claude reads relationships well when the schema makes them plain — and struggles exactly where a bright new analyst would, where the relationship lives in a business process no diagram captures. That gap is not a flaw to hide. It is the roadmap. It is the work we are in now: an ontology layer over the DMOs, reusable segment patterns instead of one-off improvisation, guardrails for safe querying, and temporal semantics so the system understands how data behaves across time.

Outcome Transformation, Not Digital Transformation

Move the metric, not the milestone

This is why I have retired the phrase “digital transformation.” It is a process noun. It measures inputs — we deployed X, migrated Y, modernized Z — and never asks whether a patient was better off. Its success criteria quietly exclude the only thing that matters.

Outcome Transformation puts the result back at the center. Victory is not that the platform was deployed. Victory is that the metric moved. The artifacts — DMOs, Calculated Insights, Segments, Agents — are intermediate and, frankly, disposable. The metric is the goal. That is the same line running through TQM in 1990, the Quintuple Aim today, and Data 360 now — one idea wearing three decades of technology.

The Agentic Enterprise on a Data360 Foundation

Slideware becomes something you run on a Tuesday

When the data layer is unified, callable, and ontology-aware, the agentic enterprise stops being slideware and becomes something you run on a Tuesday. Agents that triage. Agents that activate. Agents that close care gaps without a human routing the work. ROI stops being theoretical because the foundation has stopped being fragmented.

We are a small organization, and we have proven this at our scale. The architecture is portable. It works for any health system willing to commit to the same three things: a clean foundation, a motivated operator, and the willingness to put a metric above a milestone. The era of waiting weeks for a clinical question to come back as a chart is over.