Questions we are asked, answered without hedging.

A clinical information system built specifically for IVF and assisted reproduction, including reproductive genetics. It covers the treatment journey end to end — patient file and infertility work-up, treatment cycles and stimulation monitoring, oocyte retrieval, embryology, andrology, PGT and the wider genetics laboratory, cryostorage, pregnancy follow-up and live-birth outcome — with the reporting and integration layers around it.

IVF and assisted-reproduction centres, and in particular those that operate a reproductive-genetics laboratory in house rather than sending PGT to a reference laboratory. It suits units that need their data to stay on their own infrastructure, and those working in English, Turkish or Arabic.

Omnicore Stratejik Teknolojiler Ltd. Şti., an engineering company at TÜBİTAK Marmara Teknokent in Gebze, Kocaeli, Türkiye. FertiliCore is a ground-up rebuild of a clinical system that had been running real IVF and genetics laboratories for around two decades.

It is in active development and in use, and we would rather be plain about what that means. The clinical record is broad and deep, but some of it is modelled and served through the API without yet having its own data-entry screen. Some things a large clinic will expect — billing, a patient portal, witnessing hardware, a donor registry — are not there at all. Each page on this site says which is which.

Considerably deeper than a PGT verdict field. It models array-CGH results chromosome by chromosome per embryo including segmental imbalances sized in megabases, blastomere results scored nucleus by nucleus, marker-level allele tables for monogenic and HLA cases, FISH cytogenetics and sperm FISH, QF-PCR, Y-chromosome microdeletion, fragile-X repeat sizing, thrombophilia genotyping and DNA-fingerprint contamination exclusion.

WHO 2021 semen parameters with their reference ranges, day-2, day-3 and day-4 embryo grade catalogues, and Gardner blastocyst grading held as three separate fields — expansion, inner cell mass and trophectoderm — rather than as a free-text string. A number of other pick-lists ship deliberately empty for the clinic to populate with its own vocabulary.

Not as hardware, and we do not intend to build it. The system holds a witness-event log, consent templates with signatures and a per-cycle consent checklist. Our position is that a clinic should choose its witnessing system on the merits of the hardware, and expect its clinical record to work alongside whichever it chooses. If you run a specific system, tell us which and we will be specific about what integration involves.

No. The system records a sperm source, but there is no donor registry, no donor screening and consent workflow, no anonymous-versus-known distinction, and no donor-to-recipient matching or quarantine. If donor work is central to your practice this is a genuine limitation.

The laboratory device connector imports morphokinetic data from time-lapse incubators alongside analyser results. FertiliCore does not compute an embryo-selection score of its own — where a score arrives from the incubator or its own software, it is stored against the embryo rather than generated by us.

Not in the usual sense. It is deployed into infrastructure you control — on-premise inside the clinic, or in a private cloud tenancy in your own name — as a set of containers on PostgreSQL. There is no shared hosted service that your records are pooled into.

In your database, in your environment, under your backup regime. Multi-tenant isolation is enforced by PostgreSQL row-level security rather than by application code, and every change is written to an append-only audit trail by database triggers that record the acting user, tenant, address and session.

That is the normal case rather than the exception. Historical clinical data is extracted, converted and reconciled into the new schema with the original identifiers retained on every migrated row, so any record can be traced back to where it came from. How straightforward it is depends mostly on what export your current vendor will give you.

Nothing needs to happen — it is already in your possession, in a standard PostgreSQL database with a documented schema. There is no extraction request to file and no export window to meet, because we were never the ones holding it.

HL7 v2.5.1 messaging over MLLP for ADT and ORU, a FHIR R4 REST facade, DICOM and DICOMweb for imaging, ASTM and HL7 ORU for laboratory analysers and time-lapse incubators, and a national ART registry submission connector. Each runs as its own service so one misbehaving feed cannot affect the clinical application.

No. Every connector ships disabled with no endpoint and no credential configured, behind a master switch that is also off. Listeners bind no socket and watch no folder until an administrator configures and explicitly enables them.

Possibly, but do not assume it. The connector is a general submission mechanism — it assembles the dataset from the clinical record, validates it before queueing and delivers it with retry and per-submission status — but it is proven against one registry rather than many. Ask us about yours specifically and we will give you a straight answer rather than a roadmap promise.

Per clinic rather than per user, quoted against your cycle volume, sites, the modules in scope and the integrations you enable. Implementation and data migration are quoted separately and explicitly. Both annual-licence and perpetual-licence models are available.

Because the range between a single-site unit without a genetics laboratory and a multi-site group running in-house PGT is wide enough that any published figure would mislead most readers. We would rather scope it and give you a number you can defend internally.

English, Turkish and Arabic, with Arabic laid out right-to-left. Translation reaches server-side validation messages and clinical lookup values, not only the front-end strings, and English is the fallback wherever a translation is missing.