Healthcare Data: The Foundation Under Every AI and Product Decision

This is my front door to healthcare data. If you have read anything else I have written about AI or patient access, you have already run into the same theme, because it shows up everywhere. The model is not the hard part. The product is not the hard part. The data underneath them is. After a decade building products on health data, I have come to treat data as the real foundation, the thing that decides whether everything above it stands or sinks. Everything on this page is about getting that foundation right.

Here is the plain version. Your analytics are only as honest as the data feeding them. Your AI is only as trustworthy as the records it learned from. Your product only works if the data moves when a patient does. Get interoperability, quality, and governance right first, and the rest gets dramatically easier. Skip them, and no dashboard or model will save you. To put the scale in perspective, one large health-data platform normalizes more than 140 million patient records from over 50 different source types, held together by more than 13,000 versioned transforms. That is the size of the plumbing problem hiding under the word data.

The healthcare data value chain

Every use of healthcare data, from a simple report to a predictive model, rides on the same value chain, and each link can quietly break the ones after it.

I picture it as a chain. Raw data lands from dozens of sources. Interoperability makes those sources speak one language. Quality and governance decide what you can trust. Analytics and BI turn it into answers. And only at the end do AI and product decisions sit on top. The mistake I see constantly is teams starting at the last link, buying a model or a dashboard, while the first links are still broken. You cannot report your way out of bad intake, and you cannot model your way out of records that do not link.

A concrete version. I have watched a team stand up a slick executive dashboard, then spend six months explaining why two reports disagreed. The dashboard was fine. The intake feeding it counted the same encounter twice, because two source systems defined an encounter differently and nobody reconciled them. The fix was not in the analytics. It was three links upstream. That is the pattern. When the answer looks wrong, the cause is usually earlier in the chain than where you are looking.

The four problems healthcare data has to solve

Healthcare data is not one problem, it is four, and treating them as one is why so many data strategies stall.

I split the space into four sub-topics, and this whole cluster is organized around them. Analytics and BI is turning data into answers people actually use. Interoperability is getting data to move and mean the same thing across systems. Quality and outcomes reporting is proving, carefully and honestly, that what you deliver is real. And data in community and social care is the hardest frontier, where records are thinnest and the people most affected. The map below is how I think about where to spend. Some of these are foundational and you cannot skip them. Others are where you differentiate.

Why does splitting them matter? Because each problem has a different owner, a different standard of done, and a different failure mode. Interoperability is an engineering and standards problem. Analytics is a product and judgment problem. Quality and outcomes reporting is a governance and integrity problem. Community and social care data is a reach and trust problem. Fund them as one initiative and you will staff it wrong, measure it wrong, and stall. Name them separately and each one gets the attention and the metrics it needs.

Build, buy, or partner, decided one capability at a time

The build-versus-buy question is the wrong shape for data. The real question is build, buy, or partner, and you answer it one capability at a time.

I never answer build or buy for the whole data stack at once. I answer it per capability, because the right call for interoperability plumbing is almost never the right call for your differentiating analytics. Here is the rule of thumb I use. Build the narrow thing that is your edge. Buy the broad, commoditized plumbing. Partner when you need data or reach you cannot generate yourself, especially at the community frontier.

One caution on partnering, because it is where good intentions get sloppy. When you bring in outside data, especially about vulnerable people, you inherit responsibility for how it was collected and what it implies. I keep those engagements principle-first: agree on definitions, consent, and limits before a single record moves. The reach a partner gives you is real, but so is the accountability that comes with it.

Where healthcare data actually breaks

Healthcare data rarely breaks in the analytics. It breaks at the seams, where one system hands off to another.

When a data project fails, I have learned to look at the joints first, not the model. Intake is where bad or missing values enter. Code mapping is where meaning gets lost in translation. Linkage is where one person becomes two records. Handoff is where freshness and context fall away. The analytics layer usually gets blamed, but it is almost always downstream of a seam that failed quietly weeks earlier. The heat map below is where I look, in rough order of how often the real problem is hiding there.

The practical move is to instrument the seams, not just the outputs. Put a check at every handoff: counts in versus counts out, a sample that a value still means what it meant yesterday, an alert when a source changes shape. It is unglamorous monitoring, and it catches the silent failures long before they surface as a number nobody can explain in a board meeting.

A maturity ladder for your foundation

You do not fix a data foundation all at once. You climb it in stages, and skipping a rung is how you fall.

When someone asks where to start, I give them a ladder, not a list. First get visibility: know your sources and what is in them. Then get consistency: shared definitions and codes. Then get trust: lineage and quality checks so people believe the numbers. Then, and only then, get leverage: advanced analytics and AI on top. Most organizations want to jump straight to leverage. The ones that succeed climb in order.

One more rule on the ladder: timebox each rung and show something useful at the top of it. Visibility that takes a year is a failure even if it is thorough, because nobody will fund rung two. I would rather have a rough source inventory in three weeks that proves value than a perfect one in three quarters that loses the room. Climb deliberately, but climb visibly.

Score your own data foundation

Before you fund the next dashboard or model, it is worth an honest score of the foundation it will stand on. Answer these five as they are, not as you wish they were.

My take

If you remember one thing from this page, make it this. In healthcare, the exciting work sits on top, but the value is decided at the bottom. I would rather have a plain dashboard on trustworthy data than a brilliant model on a foundation nobody checked. Data is not the boring prerequisite to the real work. In this field, it is the real work.

From here, the cluster goes deeper. I have written about the metadata architecture that makes data trustworthy, the upstream discipline that decides whether an AI product survives contact with reality, and what it really takes, in data, before you can forecast a patient's health. Start wherever your own foundation is weakest. That is usually the highest-value place to begin.