Deployment
Your infrastructure, your jurisdiction, your schedule.
Most fertility software is now cloud-only, which means the vendor's hosting decision becomes your data-residency answer. FertiliCore takes the opposite position: the software goes where your records already are.
On-premise
Everything inside the clinic.
The full stack runs on your own hardware, on your own network. Nothing about routine clinical work depends on an internet connection, and your patient records never leave the building unless you choose to send them somewhere.
- Your servers, your network, your backup regime
- Continues working through an internet outage
- Simplest answer to a data-residency requirement
- Suits hospital IT departments that will not accept SaaS
Private cloud
Your tenancy, your region.
The same containers deployed into a cloud account in your clinic's name, in the region you nominate. You keep the commercial relationship with the hosting provider and the ability to move; we operate the software inside it.
- Cloud account and region of your choosing
- No pooled estate shared with other clinics
- Elastic capacity without a hardware refresh
- Managed operation available under agreement
What you are running
Boring, documented, replaceable parts.
Nothing here is exotic, and that is the point. Your IT team can staff it, your DBA recognises it, and none of it is a proprietary format that makes leaving expensive. The clinical schema is plain PostgreSQL — readable, queryable and yours.
- Application
- ASP.NET Core, EF Core
- Clinical API and platform services
- Interface
- Vue 3, TypeScript
- Single-page application in the browser
- Database
- PostgreSQL 15
- Row-level security, JSONB, no vendor lock
- Messaging
- RabbitMQ
- Between services and the report worker
- Cache
- Redis
- Sessions and hot reference data
- Object storage
- S3-compatible
- Attachments — MinIO or your own bucket
- Reporting
- Dedicated worker
- Renders clinical PDFs on demand
- Packaging
- Docker containers
- Reproducible across environments
Getting there
Nobody switches an IVF unit over on a Friday.
The risk in replacing a clinical system is never the installation. It is the twenty years of history, the reports that have to keep reconciling, and the cryo inventory that must remain correct throughout.
- 01
Assessment
We look at what you run now — the clinical system, the hospital record, the analysers, the genetics lab — and produce a written statement of what maps cleanly, what needs work and what we cannot do.
- 02
Historical data
Legacy clinical data is extracted, converted and reconciled into the new schema, with the original identifiers retained on every migrated record so any row can be traced back to where it came from.
- 03
Configuration
Roles, permissions, clinic-specific pick-lists, report letterhead and the connectors you actually need. The admin-configurable lists that ship empty are filled with your vocabulary, not a guess at it.
- 04
Parallel running
The new system runs alongside the old one while your team validates that the numbers reconcile — cycle counts, outcome rates, cryo inventory — before anything is switched off.
Localisation
Three languages, including right-to-left.
The interface, validation messages and clinical reference lists are translated into English, Turkish and Arabic — with Arabic laid out right-to-left rather than mirrored badly. Server-side messages resolve from a translation catalogue keyed to the request locale, so a validation error arrives in the user's language rather than the server's, and English is always the fallback when a translation is missing.
Deployment questions
Do you offer a hosted, multi-tenant subscription like most vendors?
Not as the default. FertiliCore is multi-tenant by architecture, but the deployment model we sell is your own environment — on-premise or a private cloud tenancy in your name. That is a deliberate choice: for many of the clinics we work with, the residency and control questions are the deciding ones.
What hardware do we need for an on-premise installation?
Considerably less than clinics expect. The stack is containerised and a single well-specified server handles a typical unit's workload, with the database being the component worth investing in. We size it against your cycle volume, user count and imaging load rather than quoting a generic minimum.
Can we migrate from our existing IVF system?
That is the normal case rather than the exception, and the product itself began as a migration from a long-running clinical system with two decades of accumulated records. Historical data is converted into the new schema with original identifiers retained on every row, so a migrated record can always be traced back to its source.
Who applies updates, and can we defer them?
Because the deployment is yours, updates are applied on a schedule you agree to rather than pushed to you. Clinics commonly hold a release until after a busy retrieval week or a registry submission deadline. We support that; the trade-off is that you are responsible for not falling too far behind.
What happens to our data if we stop being a customer?
It is already in your possession — in your PostgreSQL instance, in your object storage, in your backups. There is no extraction request to submit and no export window to meet, because we were never holding it. The schema is documented and the database is a standard PostgreSQL one.
Tell us what you are running today
Your current system, your hospital record, your analysers and where your data is allowed to live. We will come back with a deployment shape and an honest view of the migration.