The feedback we collected over six months of conversations with fertility nurses and consultants was not, in the end, about software features. It was about the relationship between data and clinical thinking. The tools that exist in most fertility settings today are built around a specific assumption: the primary act is recording, and the secondary act is retrieving. What we heard consistently was that the opposite is true in practice.
Clinicians spend more time reading records than writing them. The consulting room moment is a reading moment. A good consultation preparation is a search-and-synthesis task, not a filing task. When the tools are optimised for the wrong direction, the cost falls on the clinician.
The entry screen versus the reading screen
When clinical software is designed around data entry, the interface optimises for capture fields: dropdown menus, date pickers, text areas, save buttons. This is necessary functionality. But the dominant use pattern in a busy fertility clinic is not entry; it is finding the right information before the patient walks in.
Every fertility nurse we spoke to described some version of the same routine: opening two or three systems before a consultation, pulling relevant values, sometimes copying them onto paper or into a note document to build a picture of where the patient currently stands. The software facilitates capture but not comprehension.
This is not a criticism of any individual product. It reflects a design prioritisation that most clinical software makes: the data entry workflow gets optimised first; the reading workflow receives whatever remains of the design effort.
Three requests that came up in almost every conversation
The first was temporal context. A hormone value is useful. The same value placed in its cycle phase context, next to the patient's previous two readings, is considerably more useful. What clinicians described wanting was not more data but data ordered in a way that reflects how they think about it.
The second was single-screen patient history. When a clinician has to navigate between a cycle log in one system, a lab results panel in another, and a folder of scan notes in a third, the cognitive load compounds in ways that are difficult to measure from the outside. The friction is not dramatic; it is a slow accumulation of small delays and partial pictures. What they asked for was one screen showing everything relevant to the patient they were about to see.
The third was explicit connections between data types. If a patient had an ultrasound scan on the same day as a hormone blood draw, the clinician wants to see those side by side. A scan finding means something different depending on where it sits in the patient's cycle. When the data lives in separate systems, those relationships are invisible and must be reconstructed mentally each time.
A routine from a small clinic in the Midlands
One nurse consultant described her morning routine with enough specificity that it is worth repeating here. She typically has twelve appointments in a morning session. For each patient, preparation means pulling the most recent cycle record, identifying the current phase, checking the last hormone results, and noting any imaging from the previous six weeks.
In her current setup, this takes between fifteen and twenty-five minutes per patient when the data is scattered, and under five minutes when it happens to be concentrated in a single printout or previous note. The variability is the problem. She does not know which patients will require the longer preparation until she has already started looking.
She was not asking for an algorithmic summary or a system to interpret the data for her. She was asking for the data to be visible in one place, in the right order, before she opened the door.
What a reading-first interface actually requires
The structural argument is straightforward: if the purpose of capturing clinical data is to support future decisions, the interface should be designed around the moment of decision, not the moment of entry. In practice, this means asking different questions during product design.
Not "what fields does the system need to capture?" but "when a clinician is reviewing this patient's history under time pressure, what do they need to find in the first thirty seconds?" Those two questions produce very different software.
It also means being honest about density. A timeline that tries to show everything at once is not useful; neither is one that hides information behind too many clicks. The clinicians we spoke to were consistent on this point: they wanted a fast high-level read with a clear path to detail when they needed it. Scroll depth and click count matter more than most clinical software teams acknowledge.
Where we are not there yet
The feedback shaped the design direction for Amilis, but we are not suggesting the platform resolves every request we heard. The timeline format is a strong default; different clinicians read data in different ways, and some prefer tabular comparison or structured notes alongside the visual view. The timeline works best when data is reasonably complete and consistently entered; partial records are handled, but the reading experience is less clean when key fields are missing.
We are also not saying that data tools are the only obstacle. Consultation time pressure, staffing levels, and the volume of clinical work in a busy fertility unit all contribute to the strain that showed up in these conversations. A better data interface does not resolve those. What it can do is remove the preparation burden that currently falls on the clinician in the minutes before a patient arrives.
The fertility nurses and consultants we spoke to have been answering the question of "what does a clinician need to see?" through workarounds for years. They build paper summaries, copy values into notes, maintain parallel spreadsheets alongside the formal systems. What they described wanting is software that has been designed to ask the same question they have, and to answer it before they have to ask it themselves.