The starting point for Amilis was a question that took us about six months to ask properly: why do experienced fertility clinicians, working in technology-equipped clinics, choose to maintain patient data in spreadsheets that run alongside their formal EMR? Not instead of the EMR. Alongside it.
The initial, surface-level answer we reached was "because the EMR isn't good enough." That turns out to be partially correct and largely unhelpful. The more useful answer, which emerged from spending time with fertility nurses, consultants, and clinic managers in the first year of building this company, is specific: the spreadsheet persists because it does one thing that the EMR does not do, and that thing is central to the reading workflow of fertility medicine.
The thing the spreadsheet does
A fertility nurse managing a cohort of patients in an IVF cycle needs to see, at a glance, where each patient is in their stimulation. Not just today's values: the trend. The day 6 oestradiol in the context of the day 4 and day 2 values. The follicle count alongside the previous measurement. The protocol changes in relation to the response they produced.
The spreadsheet provides this view because it is a grid: time runs across one axis, data types down the other, and the nurse can read a patient's cycle history as a single visual object. The EMR provides the same data, in almost every case. But it is stored as a series of dated entries, each requiring a separate navigation step to view. Reading the trend requires either printing a set of result pages and laying them next to each other, or holding the previous values in memory while navigating to the current one.
The spreadsheet is slower to update, manually maintained, and not the authoritative clinical record. Nurses know this. They maintain it anyway, because it is the only tool that offers the visual structure their reading workflow requires. This is not resistance to change. It is a rational response to a real gap in the available tooling.
Why this gap has persisted
The EMR category was not designed around fertility medicine's specific reading requirements. It was designed around general clinical documentation: appointment notes, lab results, prescriptions, referrals. The patient's clinical history is a sequence of dated events, each stored as a separate record. This structure is appropriate for a GP practice or a general outpatient setting where each consultation is largely independent.
In fertility medicine, the relationship between events within a cycle is the clinical information. A day-10 follicle count that looks adequate in isolation looks different in the context of a sluggish response on days 6 and 8. An oestradiol level that falls within the reference range on a given day is interpreted against the patient's own previous values and the trajectory of the current stimulation. The static-record structure of most EMRs does not surface these relationships; it stores the data correctly but presents it in a way that requires the clinician to reconstruct the relationships manually on every consultation.
The spreadsheet solves this by being a genuine timeline: a visual representation of the patient's data arranged to make temporal relationships visible. The limitation is that it does this only for the data the nurse has manually copied into it, which may be incomplete, and it requires constant maintenance to remain current. It is also a parallel documentation track that creates a divergence risk if it and the formal EMR are ever at odds.
What we found when we started talking to clinics
When we began talking to fertility clinics about this problem in 2024, we expected to find some variation in how widely spreadsheets were used. We found almost none. Every clinic we spoke to had some version of the parallel spreadsheet. The implementations varied: some were elaborate, some were simple day-by-day grids, some were shared across the nursing team and some were maintained by a single nurse who carried institutional knowledge in a personal file. But the pattern was consistent.
We also found that the clinicians who used these spreadsheets most were not the least technically capable. The most detailed parallel tracking systems we encountered belonged to senior nurses with fifteen or twenty years of fertility nursing experience. They had tried every iteration of the formal EMR available to their clinics, and they maintained the spreadsheet because it worked for the clinical task they were performing.
This observation changed our understanding of the problem. It is not a training or adoption problem. It is a product design problem. The product that should have replaced the spreadsheet has not yet existed.
The complications with simply replacing the spreadsheet
The obvious approach to this problem is to build software that does what the spreadsheet does, but better: structured, maintained automatically, integrated with the formal record. This is roughly what we set out to do with Amilis. It is also harder than it sounds, for reasons that became clear only after we started building.
The first complication is that the data the spreadsheet displays does not all come from one place. The cycle protocol and progress is in the cycle log or EMR. The hormone results are in the LIS or imported into the EMR as a separate record type. The imaging notes are in the PACS or scanned in as PDFs. Assembling them into a single coherent view requires either integrating with multiple source systems, which involves the cooperation of multiple vendors, or accepting imports from those systems and normalising the data manually or semi-automatically.
The second complication is that the cycle-day axis matters more than the calendar-date axis for reading fertility data, and cycle day is not consistently stored as a field in any of the source systems. It is reconstructed from context: the date of stimulation start, the cycle length, the protocol. Storing it explicitly in the source systems is the right long-term answer; in the interim, it has to be calculated or entered.
The third complication is the completeness problem. The spreadsheet is incomplete by design: the nurse puts in what is relevant for the current cycle. A system that pulls from formal records inherits the incompleteness of those records, which reflects real gaps (missed appointments, late results, incomplete historical records from a previous clinic) as well as formatting inconsistencies. Presenting incomplete data usefully, without either hiding the gaps or making the gaps so visually prominent that they overwhelm the available data, is a specific design problem.
What we are building toward, and what we are not
Amilis is an attempt to provide the combined timeline view that the spreadsheet provides, with the data sourced from the formal clinical systems, updated without manual maintenance, and structurally linked to the patient's full record. We are working with a small group of UK fertility clinics in early access, and the version they are using is functional but not comprehensive.
We are not building a replacement EMR. The formal clinical record needs to live in a system that meets the regulatory and documentation requirements for UK clinical practice, and the existing EMRs in our early-access clinics are appropriate for that. What we are building is a reading interface: a way to look at the data that is already in those systems in a format that matches the clinical reading workflow.
We are also not claiming that replacing the spreadsheet with a structured timeline is sufficient to solve the broader data challenges in fertility medicine. It addresses the reading workflow problem. It does not address the documentation workflow problem, the inter-system integration problem in its full complexity, or the question of how historical records from patients who have been treated at multiple clinics are reconciled. Those are harder problems, and several of them are not ones a small early-stage software company can solve on its own.
The spreadsheet problem is a good starting point because it is the sharpest articulation of the reading gap. Fertility clinicians are using a thirty-year-old general-purpose tool to fill a gap in purpose-built clinical software, and they will continue to do so until the purpose-built software offers what the spreadsheet offers. That is where we started, and it is what is driving the early design choices we are making.