Skip to content
FertiliCore

Clinical module

Three ways the record answers a question

FertiliCore reports in three layers. Nine read-only dashboards compute clinic KPIs and charts from the live record, 33 letterhead PDF documents are rendered on demand by a dedicated worker and streamed without ever being stored, and 12 Excel exports deliver raw clinical datasets for offline analysis.

  • Nine built dashboards spanning the whole treatment pathway
  • Thirty-three letterhead PDF templates, English and Turkish twins
  • PDFs rendered in memory and never persisted at rest
  • Twelve Excel exports preserving legacy reporting continuity

Why three layers rather than one report builder

The three audiences for clinical data want different artefacts. A clinic director wants a KPI on screen in five seconds, a patient wants a signed letterhead document, and a quality lead preparing a registry return wants the underlying rows in a spreadsheet. FertiliCore serves each with a purpose-built layer instead of forcing all three through one generic report builder. The dashboards are purely descriptive analytics with no data entry, refreshed on demand, and the rates they present map to the measures a clinic uses for SART and ESHRE-style benchmarking and for statutory returns.

Nine dashboards, one per stage of the pathway

Each dashboard is a read-only screen that pulls its data when opened, renders a row of KPI cards followed by distribution and monthly-trend charts, and offers a manual refresh. Monthly trends cover a rolling window of recent months. Coded values such as cycle type, result and anaesthesia are resolved to readable labels, and unspecified values are shown as unspecified rather than silently dropped. Every chart and table renders an explicit empty state when the underlying data is absent, so a sparse dataset reads as sparse rather than as zero.

  • Clinic Statistics: patients, cycles, OPUs, embryos, frozen embryos, transfers, with cycles by type, by month and by status
  • OPU Statistics: procedure and patient counts, completions and cancellations, oocytes retrieved and mature, average per OPU, maturity rate, with breakdowns by status, month, sperm source and anaesthesia
  • Embryology Statistics: sessions, oocytes, mature and fertilised counts, fertilisation rate, total, frozen and transferred embryos, with insemination method, monthly volume, disposition and final assessment day
  • Transfer Statistics: transfers, patients, embryos transferred, average embryos per transfer, average endometrial thickness, cancellations, with distributions by embryo count, month, transfer day and difficulty
  • Pregnancy & Birth Outcome Statistics: monitored, clinical and ongoing pregnancies, outcomes, live births, stillbirths, losses, neonates, plus clinical pregnancy, live-birth and multiple-pregnancy rates
  • PGT Statistics: tests, patients, embryos tested, resulted tests, normal, abnormal and no-diagnosis counts with normal and abnormal rates, by result, month, PGT type and sample type
  • Andrology Statistics: analyses, patients, measured parameters and abnormal parameters, with a per-parameter table carrying unit, counts, average and the WHO 2021 reference range
  • Cycle Monitoring Statistics: monitoring records, cycles and patients monitored, hormone and ultrasound coverage, average oestradiol, endometrium and follicle count
  • Cryo Statistics: oocyte and sperm freeze sessions, straws frozen, thaw sessions, oocyte and embryo survival rates, active tanks and tank occupancy

Rates computed, never asserted

Every percentage on these screens is derived from the clinic's own records at the moment of the request. Maturity rate is mature oocytes over oocytes retrieved. Fertilisation rate comes from the embryology session data. Clinical pregnancy, live-birth and multiple-pregnancy rates come from the pregnancy and neonatal records described in the pregnancy module. Because they are computed rather than entered, they cannot drift from the underlying record, and they change as the record is completed.

Thirty-three letterhead documents, rendered on demand

Clinical documents are authored as HTML and CSS templates and rendered to PDF by a standalone worker built on WeasyPrint, kept deliberately separate from the clinical API so that document rendering scales independently and the typesetting toolchain stays out of the application services. The clinical API records the request and asks the worker to render synchronously over a message queue; the worker queries the live clinical tables, builds the document, and replies with the bytes. Every document carries the clinic letterhead, a patient and header block, and a signature and footer block.

  • Discharge summaries for the IVF file and the full file overview
  • Embryology discharge summaries for fresh cycles and for frozen-embryo transfer
  • Andrology documents: semen analysis with the WHO 2021 parameter table, IMSI and standalone MSOME
  • PGT documents: per-embryo results, array-CGH copy-number drill-down, monogenic and confirmation reports, HLA typing
  • Cytogenetic and molecular documents: sperm FISH and aneuploidy, QF-PCR, DNA profile, Y-microdeletion, fragile X, thrombophilia panel
  • Operative notes and karyotype and counselling documents, which render today with reduced detail pending schema work

Nothing written to disk

The PDF worker holds no storage. It renders the document into memory, replies with the bytes, and the API streams them straight to the user without writing a file. There is no report archive to secure, no orphaned PDF sitting in a volume containing a named patient's genetic result, and no retention policy to enforce over generated documents. Documents are always regenerated from the current record, which also means a reprint reflects any correction made since the last print rather than reproducing a stale copy. A record of the request itself is kept; the rendered document is not.

Raw data out, without losing the old reports

The Data Export screen downloads raw clinical datasets as Excel workbooks for ad-hoc and offline analysis. These exports are not new inventions: they re-implement long-standing stored-procedure extracts over the current schema, so a centre migrating from a legacy system keeps the reports its staff already trust and its historical reporting continuity survives the migration. Forty-seven legacy procedures were analysed and ported in that work, and twelve are surfaced on the export screen today. Five are whole-clinic dumps that take no parameters; seven are scoped to a patient file or a cycle, entered inline.

  • Clinic Raw Data Export: the consolidated clinic-wide clinical extract
  • Embryology Raw Data Export: the laboratory dataset
  • Transfer & Pregnancy Data: embryo-transfer cycles with their pregnancy data
  • Cryopreservation reporting dataset: the structure required by the national health authority's freezing return, one example of statutory reporting
  • OPU Procedures List: the oocyte pick-up procedure register
  • Per-patient: cycle details, non-IUI cycle count, previous IVF attempts, infertility history, andrology evaluation
  • Per-cycle: monitoring hormone values and a monitoring summary

Field level

What the record actually holds.

Structured fields, not a free-text note — which is what makes the reporting and the registry returns downstream possible.

Volume and throughput measures

  • Patients, treatment cycles and clinic visits
  • OPU procedures completed and cancelled
  • Embryology sessions and embryos created
  • Embryo transfers and cancelled transfers
  • Freeze and thaw sessions by material type

Laboratory quality measures

  • Oocyte maturity rate, mature over retrieved
  • Average oocytes per retrieval
  • Fertilisation rate from session data
  • Embryo disposition: transferred, frozen, discarded
  • Embryos by final assessment day
  • Oocyte and embryo cryosurvival rates

Transfer practice measures

  • Average embryos transferred per procedure
  • Distribution of single versus multiple embryo transfers
  • Transfers by day, cleavage versus blastocyst
  • Average endometrial thickness in millimetres
  • Transfer difficulty distribution

Outcome measures

  • Clinical pregnancy rate
  • Live-birth rate
  • Multiple-pregnancy rate
  • Outcome mix by type and by month
  • Deliveries by mode, neonates by sex
  • Pregnancies by fetus count

Genetics and andrology measures

  • PGT tests, embryos tested and resulted tests
  • Normal, abnormal and no-diagnosis result rates
  • Tests by PGT type and by sample type
  • Semen analyses and patients analysed
  • Parameter measurements normal or abnormal against WHO 2021

Stimulation and storage measures

  • Monitoring records per cycle and per patient
  • Coverage of hormone panels and ultrasound findings
  • Average oestradiol, endometrium and follicle count
  • Monitorings by stimulation day
  • Active tanks and tank occupancy rate
  • Stored material by content type

Common questions

Which success rates does the system compute, and how are they defined?

The pregnancy dashboard computes clinical pregnancy rate, live-birth rate and multiple-pregnancy rate; the laboratory dashboards compute oocyte maturity rate and fertilisation rate; the PGT dashboard computes normal and abnormal result rates; and the cryo dashboard computes oocyte and embryo thaw survival rates. Each is derived from the clinic's own records at the moment the screen is opened, using the milestone flags stored on the pregnancy and outcome records. The system reports what a clinic's data says, and publishes no benchmark figures of its own.

Can reports be produced in English as well as Turkish?

Yes. The patient-facing documents exist as matched English and Turkish twins, including the IVF discharge summary, the embryology discharge summaries for both fresh and frozen-transfer cycles, the semen analysis, MSOME and several of the PGT reports. The twins share the same data layer and letterhead, so the two versions of a document carry identical content in different languages. The requested language is part of the render request.

Are generated PDFs stored anywhere?

No. The rendering worker holds no storage: it builds the document in memory, replies with the bytes, and the clinical API streams them directly to the user without writing a file. A record of the request is kept, but the document itself is not persisted anywhere at rest. In practice that removes an entire class of exposure, since there is no archive of patient-identifiable clinical PDFs to secure or to purge, and every reprint reflects the current state of the record.

Can the dashboards be filtered to a date range?

Not from the screen today. The dashboards present the full clinic dataset and offer a manual refresh; the only time-bounded views are the monthly trend charts, which cover a rolling recent window supplied by the backend. The underlying endpoints do accept optional from and to bounds, and several export endpoints do the same, so date-scoped views are a matter of surfacing an existing capability rather than building one.

How does data get out for a registry submission or an audit?

Through the Excel export layer. Five whole-clinic dumps cover the consolidated clinical dataset, the embryology dataset, transfer and pregnancy data, the cryopreservation return structure and the OPU procedure register; seven further exports are scoped to a patient file or a cycle. Each is downloaded as a date-stamped workbook with a formatted header row, ready for the analysis or the reformatting a particular return requires.

Continues into

See FertiliCore against your own workflow

A working walkthrough with one of our clinical engineers — patient file to live-birth outcome, plus the integration and deployment questions your IT team will ask. No obligation, and no sales script.