Continuity of care is not a patient experience metric. It is an architectural constraint.

Most health systems measure continuity by asking patients how it felt. Did you have to repeat your history? Did your specialist have your GP's notes? Did the follow-up happen?

By the time a patient answers those questions, the architectural decision that caused the discontinuity was made months or years earlier — in a data model that stores each episode in its own system, an API boundary drawn around a product instead of a pathway, a record structure that captures moments rather than a patient.

A patient sees a GP. Then a specialist. Then a pharmacist. Then a follow-up. Four interactions. Four separate records. Four systems that weren't designed to share a view of the same patient over time. The information exists — it just doesn't flow.

The question most health tech companies are asking is: "how do we get these systems to talk to each other?"

The more fundamental question is: "why did we build healthcare as a collection of episode-specific databases in the first place?"

Interoperability isn't a technical challenge bolted on after the fact. It's the consequence of designing around episodes instead of patients. Every integration project is an attempt to reassemble a continuity that was broken by the original architecture.

The alternative is a longitudinal data model — one where the patient is the entity, not the episode. Where history carries forward by default because it was never split in the first place. Where the API layer exposes the patient's full clinical picture, not a snapshot of one interaction.

That's the architecture being built. Not patient experience improvements on top of fragmented systems. A data layer designed for continuity — because the alternative, the one the industry has been iterating on for twenty years, has measurably failed every patient who's had to explain their own history to the next clinician in line.