Rebuilt from a system that had already been used for twenty years.

Most clinical software is designed by people who have read about the workflow. This one began the other way round — from a system already in daily use in an IVF and genetics laboratory, carrying the accumulated shape of how the work is really done: the fields clinicians actually fill in, the pick-lists they had extended, the reports they printed every week, and the twenty years of patient records behind them.

That system had aged the way successful clinical software does. It worked, it was trusted, and it had become nearly impossible to change. Integrating a new analyser was a project. Adding a language was not realistic. Meeting a modern data-protection review meant explaining architecture decisions made before the requirements existed.

So we rebuilt it — not as a fresh idea about IVF software, but as the same clinical understanding expressed on a foundation that can move. A modern application stack, a properly normalised clinical schema on PostgreSQL, isolation and audit enforced by the database, a standards-based integration layer, and three languages. What carried over was the part that took twenty years to learn: what an IVF unit actually needs to record.

FertiliCore is in active development, and we are candid about that. Some of the clinical record is modelled and served but does not yet have its own data-entry screen. Some things a large clinic will ask for — billing and revenue cycle, a patient-facing portal, barcode or RFID witnessing hardware at the bench, a donor registry — are not there today. Those pages on this site say so, and the comparison pages say so next to the competitors that have them. We would rather you found out from us than in month three of an implementation.