Platform
One system, built in the order the treatment happens.
FertiliCore is not a general clinical record with a fertility module attached. The couple, the cycle, the oocyte, the embryo and the child are first-class records in one database, and everything else — reporting, integration, governance — follows from that.
The spine
The record follows the patient, not the department.
Every stage below reads the stage before it. The embryology session knows which retrieval it came from; the genetic result knows which biopsy, which embryo and which cycle; the birth record closes back onto the transfer that produced it. That chain is what makes an outcome statistic mean something.
Architecture
Four layers, and what each is responsible for.
The clinical record
Eleven domains and roughly 130 entities, related the way treatment is: a couple owns files, a file owns cycles, a cycle owns retrievals, a retrieval owns oocytes, an oocyte becomes an embryo, an embryo is biopsied, transferred or vitrified, and a transfer becomes a pregnancy and a child.
Clinical modulesThe integration layer
Five independent connectors — HL7 v2, FHIR R4, DICOM, laboratory devices and ART registry submission — each its own service, sharing a message log, an identifier crosswalk and a reliable outbound queue.
IntegrationsThe governance layer
Tenant isolation enforced by the database rather than by application code, an audit trail written by triggers that cannot be bypassed, permissions granted per module and operation, and an approval engine whose decision log cannot be altered.
Security & complianceThe deployment
A set of containers that runs inside your clinic or in a private cloud tenancy you control, on PostgreSQL. There is no shared estate you are obliged to join and no hosting decision of ours that dictates where your patient records live.
DeploymentDesign decisions
Four choices that shape everything else.
These are the decisions that are expensive to reverse later, which is why they were made first.
Structured before searchable
A grade, a diameter, a copy number and a verdict are fields with types and constraints — not sentences in a note. Everything downstream, from a fertilisation rate to a registry return, depends on that decision having been made early.
The database enforces the boundaries
Tenant isolation and the audit trail live in PostgreSQL — row-level security policies and triggers. An application bug, a bad query or a direct connection cannot step around them, because they are not implemented in the application at all.
Nothing talks outward by default
Every connector ships disabled with empty credentials. Integration is something your team switches on deliberately, per transport, after configuring it — not a default posture you have to discover and unwind.
Reports are rendered, not stored
Clinical PDFs are produced on demand, assembled in memory and streamed to the person who asked. No archive of generated patient documents accumulates on disk waiting to be exfiltrated.
Cross-cutting
What every screen inherits.
Multi-tenant isolation at the database
Every clinic-scoped table carries a tenant marker protected by PostgreSQL Row-Level Security. One clinic physically cannot read another's rows — the boundary is enforced beneath the application, not by it.
Append-only audit trail
Database triggers log every insert, update and delete with before-and-after values, the acting user, tenant, IP address and session. The trigger auto-attaches to new tables, so coverage never drifts, and the log rejects updates and deletes.
Role-based access control
Permissions are granted per module, screen and operation, with seeded clinical roles — IVF doctor and nurse, embryology lab, andrology, genetics doctor and lab, patient consultant, viewer — and two-factor authentication required for system administrators.
Approval and sign-off workflows
A templated approval engine routes records such as genetic reports through sequential, unanimous or any-one approver chains with SLA deadlines, reminders, escalation and delegation. Every decision is permanently recorded.
Consent and witnessing records
Consent templates produce consent records that carry signatures, with a per-cycle consent checklist so a missing form is visible before the procedure rather than after it, and a witness-event log against the handling steps that require a second pair of eyes.
Scheduling and daily worklists
A shared resource calendar plus the lists a unit actually runs its morning on — retrievals, transfers, β-hCG due, scans, day-three checks and deferred cases — alongside a call and recall log.
Document retention
Consents, scanned forms and external reports attach to any clinical record and are held in S3-compatible object storage with server-side content sniffing and SHA-256 checksums. Documents are soft-deleted only — deleting a record never destroys its paperwork.
Notifications
A data-driven engine maps clinical events — OPU scheduled, fertilisation result, transfer done, β-hCG reminder, PGT result ready, cryostorage expiry — to recipient roles, templates and channels, with per-user preferences, quiet hours and retry.
Clinical modules
Integration connectors
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.