The concept of a longitudinal patient timeline is straightforward enough that it is often treated as a minor implementation detail rather than a significant design challenge. If you have a patient identifier and a set of dated clinical events, you put them in chronological order and you have a timeline. The conception is simple; the execution at clinical scale is not.
We have been building the Amilis patient timeline for a specific domain: fertility and gynecology clinics, where the data types include cycle phase records, hormone assay results, and imaging observations. This domain has characteristics that make longitudinal representation harder than it looks from the outside, and those characteristics shaped almost every design decision we have made.
The irregular temporal structure of fertility data
Most clinical timelines are designed around calendar time: events are placed at their calendar date and the axis proceeds linearly from left to right. This works adequately for many clinical contexts. In fertility medicine, it creates a structural problem.
A stimulated IVF cycle runs for approximately ten to fourteen days from stimulation start to trigger. Between cycles, there may be one to three months of rest, hormonal preparation, or waiting. A patient in treatment over eighteen months might have three to five active cycles separated by longer rest periods. On a linear calendar axis, the three monitoring appointments in week one of a cycle are compressed together, and the subsequent three-month gap before the next cycle occupies three times the visual space of the clinically active period.
For the clinician reviewing this patient, the relationship between events within a cycle is what matters most. The day-9 FSH level is relevant to the day-9 scan. Both are relevant to the previous cycle's day-9 data. Placing these events on a continuous calendar axis, separated visually by the same blank space that represents the inter-cycle rest period, obscures the clinical structure rather than clarifying it.
Our approach to this is a two-axis representation: the macro timeline showing cycle periods and the gaps between them, and the micro view showing the day-by-day event structure within each selected cycle. The macro view answers the question "where are we in this patient's treatment journey?" The micro view answers "what happened, day by day, in this specific cycle?" Switching between them needs to be fast enough to support a consultation preparation workflow, where the clinician may move between several patients in a short time.
Variable completeness is the default state
A clinical timeline that only works with complete, consistently formatted data is not useful in a real clinical setting. Fertility clinic records are incomplete in predictable ways: lab results arrive late or with non-standard formatting, imaging notes have varying levels of detail depending on the sonographer, historical records from previous clinics arrive in formats that do not map cleanly to the current system's structure.
The design question is not "how do we enforce completeness?" but "how do we represent partial data in a way that is still useful and does not mislead the clinician?"
Our answer is explicit representation of gaps. When a data type is missing for a period, the timeline shows the gap rather than smoothing over it. A missing day-3 blood draw shows as an absent marker on the day-3 position, not as an interpolated or estimated value. The clinician sees that the data is not there; they can decide whether that matters for the consultation in front of them. A timeline that hides incompleteness would be actively harmful in a clinical context.
This decision has a downstream consequence: the timeline's utility scales with the completeness of the data it holds. A patient with two years of consistently entered records produces a timeline that is highly readable. A patient whose records were imported from a legacy system with inconsistent formatting produces a timeline with more gaps and ambiguities. We do not resolve this tension by manufacturing completeness; we address it by making the import and entry workflow as low-friction as possible, so that the baseline level of record completeness improves over time.
Multi-format data from a single clinical event
A monitoring appointment in a stimulated IVF cycle may generate a blood draw (resulting in a lab report), an ultrasound scan (resulting in a sonographer's note and an image file), a clinical note from the reviewing consultant, and a medication adjustment recorded in the cycle log. These are four separate records describing a single clinical event, and they may arrive in four different formats from up to three different source systems.
Linking them correctly on the timeline requires identifying that they all describe the same event, even when the date formats differ, the patient identifier varies between systems, or the appointment time is logged at the time of the blood draw in one system and at the time of scan review in another. This is an entity resolution problem at the record level, and it is one of the areas where text processing is genuinely useful: identifying that "Patient J. Hargreaves, 14/11/2025" and "Hargreaves J, 2025-11-14" are the same patient record on the same date.
We do not always get this right automatically. Our approach is to surface ambiguous linkages for manual review by clinic staff rather than silently merging records that might be different patients or different dates. The risk of incorrectly merging two different patients' records is categorically more serious than the inconvenience of a staff member confirming a manual link once. This is a design choice with a real operational cost, but it is the right one.
The reading experience under clinical time pressure
A timeline that is technically accurate but slow to read has limited clinical value. The clinician preparing for a consultation has five to ten minutes, not thirty, and the timeline must deliver its key information in the first thirty seconds of reading.
This requirement shapes almost every visual design decision. The number of visible rows on the default view, the size of event markers, the typography of key values, the visual weight of cycle phase bands versus individual event markers, the contrast between different data types: all of these trade off against each other, and the reference point for every trade-off is the same: can a clinician read this patient's story in thirty seconds under pressure?
The honest answer is that we do not always get this balance right on the first attempt. Some clinicians find the default density too high; others want more data visible without drilling down. We have learned that the default view is less important than the speed of moving from the default to a detail view when needed. A timeline that opens at moderate density but lets the clinician drill into a specific cycle in two clicks is more useful than one with a perfect default that requires five clicks to find the relevant detail.
What we are still working on
The timeline representation for patients who have treatment history across multiple clinics remains a significant open problem. Record formats, patient identifiers, and date conventions vary enough between clinics that automated reconciliation of multi-clinic histories is unreliable. Our current approach is structured manual import with staff review, which works but does not scale. This is an area we expect to improve as we build more import mappings for common clinical software used in the UK fertility sector.
The question of how much history to show by default is also unresolved. A patient with four years of records has a long timeline; showing all of it by default creates visual noise. Defaulting to the most recent twelve months is a reasonable heuristic but not universally correct. The right answer probably varies by consultation type, and we have not yet designed a mechanism for the clinician to set their default view preference in a way that persists across sessions without adding configuration overhead.
These are real limitations, worth stating clearly. The timeline works well for the core use case: a fertility clinic with one to three years of consistently entered records, reviewing a patient who has been seen at the same clinic throughout. That covers the majority of consultations in the clinics we work with. The edge cases are genuinely hard, and we are working on them incrementally.