A single IVF cycle, from initial consultation to transfer or cryopreservation, generates data in at least three structurally distinct systems in most UK fertility clinics. The cycle tracking record, maintained by nursing staff, records the protocol, stimulation progress, and key events. The laboratory information system records hormone assay results. The PACS (Picture Archiving and Communication System) holds scan images. And there is often a fourth system: the electronic medical record, where clinical notes and consultation summaries live independently of all three.
Understanding why these systems are separate, and why that separation has proven so durable, is useful context for anyone working on the problem from either the clinical or the technical side.
These systems were built by different industries
The EMR as a category emerged from administrative healthcare computing in the 1980s and 1990s. Its primary design goals were scheduling, billing, documentation, and regulatory compliance. The clinical note was a record, not a reading tool. The interface was designed to accept and retrieve structured data, not to present a coherent clinical narrative.
Laboratory information systems emerged from a different lineage entirely: analytical chemistry and clinical pathology, where the primary requirement was accurate, auditable transmission of assay results from analyser to clinician. The LIS was optimised for result fidelity and chain-of-custody tracking. It was not designed to contextualise results against a patient's clinical history, because that was the physician's task.
PACS emerged from radiology, where the primary requirement was storage, retrieval, and display of high-resolution image files, with DICOM as the standard transmission format. The PACS infrastructure is built around image storage and workstation display; the clinical metadata associated with an image (who ordered it, in what clinical context, what findings were noted) is attached to the image but not integrated with the clinical record in any meaningful way in most implementations.
These three systems were built by separate vendors, for separate professional communities, with separate technical standards and separate procurement processes. The fact that a fertility clinic uses all three, and that a patient's clinical story requires reading all three together, was not a design requirement for any of them individually.
Why integration projects have been slow
The technology for system integration exists. HL7 FHIR provides a relatively modern standard for clinical data exchange. Most enterprise EMR vendors support some form of API access. The DICOM standard provides metadata fields that could, in principle, carry clinical context. The technical barriers are lower than they were a decade ago.
The practical barriers are a different matter. An integration between a clinic's EMR and its LIS requires both vendors to cooperate on the connection, the clinic's IT staff (or contracted support) to implement and test it, and ongoing maintenance as either system updates. For a large hospital network, this is a manageable investment. For a small independent fertility clinic, it is a significant commitment relative to the available internal capacity.
There is also a trust problem. Clinicians who have worked with systems that have failed to maintain accurate data linkage between records are understandably cautious about relying on automated connections. A lab result that appears in the EMR against the wrong patient, or a cycle record that does not update when the lab result is amended, is a serious problem. The preference for manual cross-referencing, while inefficient, at least keeps the clinician in control of the synthesis.
The specific challenge for fertility data
General EMR-LIS integration is, in principle, a solved problem for high-volume contexts. The specific challenge for fertility data is that the integration needs to be cycle-aware, not just patient-aware. A hormone result tied to a patient identifier is less useful than the same result tied to a patient identifier and a cycle day. The cycle day is the clinical context that makes the value interpretable.
Current HL7 FHIR profiles include observation resources that can carry cycle-day context, but whether a given LIS populates those fields correctly, and whether the receiving EMR displays them usefully, depends entirely on the specific implementation. In practice, most lab result feeds to fertility clinic EMRs carry a calendar date and a patient identifier, and the cycle day context is reconstructed manually by the clinician who ordered the draw and knows what day of the cycle it was drawn on.
The same problem applies to imaging. A monitoring scan performed on day 9 of a stimulated cycle is clinically distinct from the same scan performed on day 9 of a different cycle that had a different protocol. The DICOM metadata does not carry cycle context. The scan note in the PACS may mention it; the EMR record of the appointment may record it; but the structural link between the scan, the cycle record, and the hormone results from the same day is typically held in the clinician's mental model, not in the data systems.
The spreadsheet as a symptom of good clinical instinct
The persistence of the spreadsheet in fertility clinic data management is sometimes described as a failure of technology adoption. This framing is not quite right. The spreadsheet persists because it correctly identifies the actual clinical requirement: a view where the cycle timeline, the hormone values, and the key clinical events are visible together, aligned on a common axis, readable at a glance. That is exactly what the clinical reading workflow requires, and it is what the formal systems do not provide.
The spreadsheet's weakness is that it is maintained manually, is not authoritative, is not shared in real time, and creates a documentation divergence problem when it is updated separately from the formal record. But it correctly models the data structure that clinical reading requires. Any attempt to move away from spreadsheets without providing that combined view will fail, because the clinical need does not go away when the spreadsheet does.
We built Amilis as an explicit attempt to provide the combined view that the spreadsheet provides, without requiring manual maintenance or creating a separate documentation track. Whether that attempt succeeds, and at what scale, is still being determined by the clinics that have tested it. What we know is that the problem the spreadsheet is solving is real and persistent, and that the systems it sits alongside have not made meaningful progress toward solving it from within their own architectural constraints.
What this means for clinic data strategy
A clinic deciding how to manage its data across these three system types faces a genuine choice. One option is to invest in integrations between the existing systems. This makes sense if the clinic has IT support capacity and is committed to a long-term relationship with its current vendors. The integration will need maintenance, and it will not solve the cycle-context problem unless the EMR and LIS implementations support it explicitly.
A second option is to maintain the spreadsheet parallel to the formal systems, accepting the manual overhead as the cost of having a usable combined view. Many clinics currently operate this way and have done so for years. The documentation divergence risk is manageable if it is acknowledged and protocols are in place to keep the formal record authoritative.
A third option is to use a purpose-built patient timeline tool that reads data from the existing systems and presents it in a combined view, without attempting to replace any of them. This is the approach Amilis takes. It does not require the existing systems to be replaced or fundamentally altered; it requires them to export data in usable formats and for that data to be imported into a presentation layer that the clinical team actually reads.
None of these options is universally correct. The right choice depends on the clinic's existing system relationships, IT capacity, patient volume, and tolerance for manual process. What we are confident about is that the problem is worth addressing explicitly, rather than absorbing the cost invisibly into the clinical day.