Longitudinal Clinical Records: Design Principles for Identity, Time, and Versioning

A longitudinal clinical record captures the full health history of an individual across time, care settings, and data sources — not just the data from a single encounter or system. The U.S. ONC frames the goal precisely in its definition of patient matching: linking one patient's data within and across health systems to obtain a comprehensive view of that patient's health care record [1]. Designing a clinical data repository to deliver genuine longitudinality means solving three overlapping problems, each an architectural decision with long-term consequences for data quality and query correctness: patient identity resolution across systems with different identifier domains, temporal modeling that distinguishes when something happened from when it was recorded, and data versioning that preserves the record's evolution without destroying earlier states.

Identity Resolution: The Record Is Only as Complete as the Linkage

Patient identity is the most operationally critical of the three. A longitudinal record is only as complete as the organization's ability to correctly link data from disparate sources to the same individual — and the evidence says this is genuinely hard. The ONC's Patient Identification and Matching report found that while health systems can achieve high match rates within a single organization, rates drop sharply when matching records across organizations, and it documents the operational reality architects must design for: duplicate detection, and correction processes that typically require merging records [2].

The architectural response is a Master Patient Index (MPI) treated as a first-class service, not an EHR feature:

• Matching algorithms: production MPIs combine deterministic matching (exact or rule-based agreement on identifiers and demographics) with probabilistic approaches (weighted, field-level comparison producing match scores with review thresholds). The ONC report examined both approaches across the industry and — tellingly — declined to prescribe one, because the right calibration depends on the population, the data quality of the sources, and the cost the organization assigns to false merges versus missed matches [2].
• Merge and unmerge as designed operations: identities will be merged in error and split in error; the MPI must support both directions with full traceability, and the CDR must define what happens to clinical data linkage when the MPI changes its mind. In our experience, unmerge is the case that separates real MPI designs from optimistic ones — it is rare, high-stakes, and impossible to retrofit cleanly.
• A stable canonical subject key: the MPI exposes a stable subject identifier that the CDR uses as its canonical patient key, keeping source-system identifiers as cross-references. Matching decisions live in the MPI; the CDR references, but never adjudicates, identity.

Underinvesting here produces the failure modes that undermine the CDR's core value proposition: duplicate records fragmenting the longitudinal view, care gaps where history exists but isn't linked, and population analytics that quietly count the same person twice.

Temporal Modeling: One Event, Three Timestamps

Clinical data carries multiple timestamps, and conflating them corrupts the record in ways that surface only later — in a medico-legal reconstruction, a research query, or a quality measure that silently used the wrong clock. The general problem is well described in the bitemporal modeling literature: as Martin Fowler puts it, there is a difference between the actual history (when things were true in the world) and our record of that history (when we learned and stored them) — a distinction tracing back to Snodgrass's valid time and transaction time, and standardized in SQL:2011 [3]. Healthcare adds a third dimension whenever data flows between systems: the time it entered this repository, as opposed to the source system.

openEHR encodes these distinctions natively: observations structure their data as events each carrying its own time, compositions carry their clinical context timing [4], and the change-control model stamps every committed version with a mandatory audit whose commit time is set by the receiving system [5]. But the standard only provides the slots — in our experience, the most common integration defect in longitudinal projects is pipelines that default every timestamp to "now," collapsing three clocks into one at ingestion. Mapping effective and recorded times explicitly from each source, and validating that they differ where they should, belongs in the integration layer's definition of done.

Versioning: Preserving the Record's Evolution

The third pillar is refusing to destroy the past. A longitudinal record must reflect corrections, amendments, and evolving understanding without erasing what was previously recorded and acted upon — because a clinician who made a decision on Tuesday's data deserves a record that can prove what Tuesday's data said. openEHR's change-control model provides this structurally: every composition is a versioned object, each commit creates a new immutable version linked to its predecessor with a mandatory audit, and earlier states remain reconstructable rather than overwritten [5]. Whatever platform you choose, the design principle stands: versioning is a property of the record, not a feature of the application — if point-in-time reconstruction depends on application-level history tables built per use case, longitudinality will erode with every new integration.

Where CaboLabs Fits

Identity, time, and versioning are exactly the three problems CaboLabs engineers when we build longitudinal data platforms. Our openEHR-native clinical data repository, Atomik, was designed around them: an MPI with deterministic and probabilistic patient matching built for multi-source deployments, native openEHR temporal semantics on every composition and event, and contribution-based versioning that preserves every state of the record with full audit. Around the product, our consulting practice covers MPI strategy and matching calibration, integration pipeline design that maps source timestamps correctly, and CDR architecture across openEHR, FHIR, and HL7.

If your longitudinal view has gaps you suspect are identity problems, your analytics can't tell event time from load time, or you're designing a clinical record meant to stay trustworthy for decades, talk to us at cabolabs.com — longitudinality is designed in at the start, and we know where it breaks.