The embryologist in a fertility clinic occupies a specific position in the clinical workflow: they are the closest observer of the embryo's development from fertilisation through to transfer or cryopreservation, and they produce structured records that carry forward into the patient's clinical history. What they need from a data platform is not the same as what a consulting gynaecologist needs, and the two requirements are often in tension when software decisions are made at the clinic management level.
This article is based on conversations we have had with embryologists in fertility clinics, mostly in the context of exploring what data visibility problems they encounter day to day. It is not a survey. It is a qualitative account of a consistent set of concerns that came up repeatedly and that informed how we think about the patient-side data that surrounds the laboratory workflow.
The timing constraint that shapes everything
IVF laboratory work operates on biological timelines that do not accommodate administrative delays. A fertilisation check is performed at a specific interval after insemination; an embryo grading observation is recorded at a defined developmental stage; a freeze or transfer decision has a window that closes. The data associated with each of these events needs to be recorded and accessible within that window.
This constraint means that the data entry workflow for laboratory records needs to be extremely low-friction. Any system that requires navigating multiple screens to record an embryo grade, or that does not autosave entries in real time, or that requires confirmation steps before information is committed, will be worked around. Embryologists under time pressure will find the fastest recording route available to them, which in practice often means a paper form, a whiteboard, or a separate laboratory management spreadsheet, with data transferred to the formal system when time allows.
The gap between when data is generated and when it is formally recorded is a data quality problem. It is also a clinical information problem, because other members of the clinical team may attempt to access laboratory data during that gap and find either nothing or an earlier state that does not reflect current information. Designing for the actual time constraints of laboratory work, rather than for an idealised workflow, is the starting point for any system that aims to serve embryologists.
The reference data they need to see, and where it currently lives
Before an embryo transfer, the embryologist needs context from the clinical side: the patient's age, the stimulation protocol used in the current cycle, the day of trigger and oocyte retrieval, the insemination method, and the previous cycle history if this is a second or third attempt. Some of this information is in the formal EMR. Some is in the nursing cycle log. Some is in a clinical summary that may or may not have been updated before the laboratory handover.
In a well-coordinated clinic, this information is communicated verbally at a morning handover or written on a printed cycle sheet. This works when everyone is present and when the information is accurate at the time of printing. It fails when a result changed after the sheet was printed, when a team member is absent, or when the laboratory receives a patient whose cycle has taken an unexpected path.
The embryologist is essentially a data consumer as well as a data producer, and the data they consume most reliably from the clinical side is the cycle history: what protocol was used, when key events occurred, what the hormone trajectory looked like through stimulation. Having that information on a timeline that the laboratory can access without navigating through the clinical EMR, without requesting a printout, and without relying on verbal handover is not a luxury. It is a basic operational requirement for a high-volume laboratory.
Record formats: the problem with free text
Embryo grading involves structured assessments: cell count, fragmentation percentage, symmetry, blastocyst grade. These should, in principle, be recorded as structured fields that are consistently interpretable across time and across different staff members. In practice, many fertility clinic data systems record them as free text notes within a consultation or laboratory record, which means that extracting and reviewing them longitudinally requires reading through notes rather than querying structured fields.
The practical effect of this is that when a patient returns for a second IVF cycle and the clinical team wants to review the embryo quality from the previous cycle, they are reading through narrative records rather than looking at a structured grade alongside the cycle and patient data. The information is there, but the format makes it harder to use than it should be.
We are not claiming that free text should be eliminated from laboratory records. Observational notes about atypical embryo development or laboratory conditions are legitimately narrative and do not lend themselves to structured fields. The distinction between structured fields for graded assessments and narrative fields for observations is worth maintaining explicitly in any data entry design. Confusing the two produces records that are difficult to read back.
Cycle-to-cycle comparison: the most frequent request
The single most consistent request we heard from embryologists in our early conversations was the ability to compare results between cycles for the same patient. Specifically: oocyte yield, mature oocyte count, fertilisation rate, blastulation rate, and the number of embryos suitable for transfer or cryopreservation. These are the numbers that inform stimulation protocol adjustments for a subsequent cycle, and they are the numbers most likely to be scattered across separate cycle records that require active retrieval.
This is not a complex data requirement. It is five to eight numeric values per cycle, requiring nothing more than consistent data entry and a view that groups them by cycle for the same patient. The barrier to having this is not technical; it is the absence of consistent structured data entry over time, combined with systems that do not present cycle-level summaries in a single view.
When we describe the Amilis patient timeline to embryologists, the cycle-comparison view is the aspect that generates the most immediate recognition. Not because it is technically sophisticated, but because it is a straightforward answer to a question they have been working around for years.
What we are not building for this group
It is worth being clear about what a patient timeline addresses and what it does not, relative to the specific needs of an embryology laboratory. The Amilis timeline organises and presents clinical data for reading; it is not an embryology information system (EMIS or dedicated EMS). It does not replace witness protocols or identity verification steps. It does not integrate with time-lapse imaging systems. It does not manage cryostorage records or tank inventories.
These are distinct requirements, and some of them require dedicated software that the laboratory will continue to use regardless of what the clinical side uses for patient data organisation. What we aim to address is the information asymmetry at the handover points: the places where the embryologist needs clinical context that is currently difficult to access, and the places where laboratory results need to be visible to the clinical team without requiring a dedicated LIS query.
The embryologist's position in the clinical workflow is central enough that designing for their needs at the data handover points has a disproportionate impact on overall data quality. When the data moves cleanly in both directions, the clinical record that accumulates over a patient's treatment course is substantially more useful than when it does not.