Move the Question, Not the Data

Most healthcare interoperability still works one way: copy the data. Records get duplicated into a warehouse, pushed to an HIE, replicated into a vendor cloud, exported for an analytics tool. Every copy is another place PHI lives, another governance review, another integration to maintain, and another lag between when something happens to a patient and when anyone can act on it.

There is a better default, and it is not new in computer science: move the question, not the data. Send the computation to where the data already sits, and return only the answer.

The copy-the-data tax

When the answer to “which of my diabetic patients are overdue for an eye exam?” requires first shipping those patients’ records somewhere else, you pay a tax three times over:

• Risk. Every copy widens the breach surface. The safest record is the one that never left.
• Latency. Batch extracts and overnight syncs mean you learn about a care gap days after the encounter that created it.
• Governance drag. Each new destination is a new data-sharing agreement, a new access-control story, a new thing to audit.

What moving the question looks like

The pattern shows up across computing as federated query, edge computation, and privacy-preserving analytics. Healthcare has been slow to adopt it for two practical reasons: data is fragmented across many systems, and identity is hard — you cannot answer a population question if you cannot tell whether two records are the same person.

So the prerequisites are clear. Before the question can travel, you need feeds you can trust and identities you can resolve, at the boundary, before anything moves.

How HDIM applies the principle

HDIM is built as three tiers that keep identified data inside the customer boundary while still producing cross-organization intelligence:

• Data Quality Monitor (DQM) — the entry point. It scores inbound and outbound feeds across five dimensions and gates feed and identity readiness, so the question only ever runs against data that is fit for it. Try the interactive feed-grader.
• Data Motion Platform — the customer-boundary runtime. It runs care-gap detection and HEDIS quality-measure workflows on DQM-validated signals, under identity and consent controls, inside your environment. Explore the HEDIS measures it evaluates.
• Atlas Nexus — the operator tier. It receives only operator-safe aggregates — deny-list enforced, de-identified, with a small-cell floor (k ≥ 11) — so operators can triage cross-customer evidence without seeing patient-level PHI.

The through-line: identified processing happens at the boundary; only validated, aggregate signals travel outward. PHI does not have to leave the customer environment for the organization to get answers.

Why it matters

• Data sovereignty. The customer keeps custody of identified data. Architecture, not just policy, enforces the boundary.
• A smaller surface. Fewer copies means fewer places a breach can happen and less to attest to in a review.
• Speed. Evaluating measures as events arrive, in place, is closer to real time than waiting on the next batch export.
• Trust. “We do not move your patients’ records out of your environment to answer this” is a sentence both a CISO and a clinician can get behind.

See it for yourself

The idea is easier to believe when it is clickable. Each of these runs on synthetic data:

• DQM feed-grader — watch quality scoring gate a feed before measurement.
• HEDIS measure explorer — see which measures apply and the care gaps they surface.
• ROI model — an illustrative model from your own inputs (not an audited claim).
• Live demos — DQM, the Data Motion Platform, and Atlas Nexus across the wedge.
• For investors — the category bet and what is proven versus modeled.

Move the question, not the data. It is a better default for a system built on the most sensitive records there are.