When we describe Amilis to a clinician or a clinic administrator for the first time, the question that comes up most quickly is a variation of: "So what does it decide?" The answer is: nothing. The distinction we want to draw clearly, because it matters for how clinics think about what they are actually purchasing, is the difference between a system that organises data and a system that acts on it.
In the current environment, those two types of systems are being conflated in a way that creates genuine confusion about regulatory status, clinical responsibility, and what "AI" actually means in a specific product context.
Two different kinds of software
A system that organises clinical data takes records from multiple sources, structures them into a coherent format, and presents them in a way that a clinician can read efficiently. The clinician sees the data; the clinician makes the decision. The software's intelligence, such as it is, is in structuring and presenting information, not in interpreting or acting on it.
A system that makes clinical recommendations takes data and produces an output that guides clinical action: a suggested protocol, a risk score, a ranked differential. This is a different category of software with different regulatory implications. Under UK Medicines and Healthcare products Regulatory Agency (MHRA) guidance, software that makes clinical decisions qualifies as a medical device. That brings with it assessment requirements, post-market surveillance obligations, and a different level of accountability for what the software outputs.
Amilis is the first kind. It organises. It does not recommend, score, or suggest protocol. That is a deliberate design decision, not a limitation of ambition.
Why the distinction matters clinically
The argument for AI-driven clinical recommendation systems is not wrong in principle: pattern recognition across large datasets can surface things a human reader might miss, and there are genuine use cases in diagnostic radiology, pathology analysis, and similar domains where the data volume exceeds what a human can process in real time.
But fertility clinic data is, in our experience, not primarily a volume problem. A consultant managing a patient through an IVF cycle is tracking a relatively small number of data points across a relatively short timeframe. The problem is not that there is too much data to read; it is that the data lives in too many places, in formats that are inconsistent and disconnected. That is a structuring problem, not an interpretation problem.
When we design Amilis around organisation rather than recommendation, we are making a claim about what actually costs clinicians time. The cost is in finding and assembling the data, not in interpreting it once assembled. A clinician who has been practising fertility medicine for ten years does not need software to interpret FSH trends. She needs the FSH trends to be visible on one screen, correctly dated, alongside the cycle data that gives them context.
What organising actually requires from AI
The term "AI" in Amilis's context refers to the natural language and pattern-matching capabilities we use for tasks like entity recognition across inconsistently formatted records, date parsing across different field formats, and linking records that describe the same event in two different systems. These are structural tasks, not diagnostic ones.
To give a concrete example: when a clinic imports a batch of lab results as a CSV file with non-standard column headers, we use text classification to identify which column contains the assay name, which contains the result value, which contains the draw date, and which contains the patient identifier. This is document-structure understanding, applied to data organisation. The output is a correctly structured record in the patient's timeline. There is no clinical inference happening at any step.
The same applies to how we handle imaging notes. Ultrasound reports from fertility clinics arrive in several different formats depending on the machine and the practice's documentation habits. Parsing those notes to extract the scan date, the clinician's name, and the relevant clinical observations requires some text understanding. The structured output goes onto the patient timeline. The clinician reads the original note and the timeline placement; Amilis does not summarise or interpret what the scan found.
The regulatory and responsibility argument
A clinical software platform that makes recommendations shifts accountability. If a software system suggests a protocol and the clinician follows it, the question of who is responsible for the outcome becomes genuinely complicated. In UK clinical practice, responsibility rests with the qualified clinician, but a recommending system creates a documented recommendation chain that complicates that picture.
By staying firmly in the organising category, Amilis preserves the standard accountability structure: the clinician sees the data, applies their clinical judgement, and makes the decision. The software is a reading aid, not a decision participant. That is a position we hold deliberately, not because we are uncertain about the technology, but because we believe it is the correct design for the problem we are solving and the regulatory environment we operate in.
We are not saying that diagnostic AI systems are inappropriate for clinical settings. There are well-designed, properly assessed tools in areas like embryo morphology grading and cycle outcome prediction that have genuine clinical value. What we are saying is that Amilis is not that kind of system, and that the distinction should be explicit in how we describe it, how clinics evaluate it, and how it is implemented.
What this means for a clinic choosing a data platform
When evaluating any clinical data platform that uses the word "AI," the question worth asking directly is: does this system produce outputs that inform or recommend clinical action? If the answer is yes, the evaluation criteria should include the clinical evidence base for those recommendations, the regulatory status of the software, and the liability implications for the clinic.
If the answer is no, as it is for Amilis, the evaluation focuses on different things: data structure quality, record completeness, readability of the timeline output, integration with the clinic's existing systems, and data governance. Those are the right questions for a system whose job is to organise, and they are the questions we are designed to answer well.
The organise-versus-diagnose distinction is one we will continue to be explicit about as the broader clinical AI space becomes more crowded and more confident in its claims. Clinicians deserve clarity on what a system actually does before they rely on it, and that clarity starts with being precise about the category of problem it is solving.