Security & compliance
Guarantees, not assurances.
Clinical software is asked to promise a great deal about isolation and accountability. FertiliCore moves those promises into the database, where they hold whether or not the application behaves.
Isolation the application cannot bypass
Multi-tenancy is implemented as PostgreSQL row-level security. Each clinic-scoped table carries a tenant marker and a policy that restricts every read and write to the tenant in the current session. Because the rule lives in the database, an application defect cannot leak across the boundary — the query simply returns nothing. Shared reference data such as roles, permissions and navigation is deliberately tenant-independent.
An audit trail written by the database
History is captured by triggers, not by application code, so there is no code path that forgets to log. Each entry holds the action, the affected row, the changed values before and after, and the acting user, tenant, address, agent and session. The trigger attaches itself to newly created tables, so coverage cannot erode over time. The log is append-only and rejects updates and deletes at the database level.
Least privilege, per module and per operation
Permissions are granted at the intersection of a module, a screen and an operation, with a set of IVF-specific roles seeded and fully editable per clinic. Screens a user cannot access are not merely hidden — the data behind them is refused. Global search honours the same boundary: a category the user cannot view is never queried at all, so search cannot become a side channel. System administrator accounts require two-factor authentication.
Sign-off that cannot be rewritten
The approval engine routes a record through a defined chain — sequential, unanimous or any-one — with deadlines, reminders, escalation and delegation. Approve, reject, request changes, escalate and cancel are all recorded, with a mandatory reason on the negative outcomes, and the decision log is append-only. Genetic reports carry a dedicated approve permission distinct from the right to edit them.
Access control
A permission model that matches the org chart.
An embryologist does not need to edit a pregnancy record; a genetics registrar should be able to author a report but not sign it. FertiliCore ships with roles that already reflect how an ART unit is actually staffed, and every one of them is editable.
Seeded roles
| Module | Covers | Operations |
|---|---|---|
| PATIENT | Patient list, partner link | Read · Create · Update · Delete |
| RECORDS | Work-up, anamnesis, exams, diagnoses, OHSS | Read · Create · Update · Delete |
| CYCLE | Cycles, monitoring, stimulation protocol | Read · Create · Update · Delete |
| OPU | Retrieval procedure, follicle data | Read · Create · Update · Delete |
| EMBRYOLOGY | Embryos, observation, biopsy, transfer, freeze | Read · Create · Update · Delete |
| ANDROLOGY | Spermiogram, MSOME, male evaluation | Read · Create · Update · Delete |
| GENETICS | PGT, FISH, aCGH, karyotype, reports | Read · Create · Update · Delete · Approve |
| PREGNANCY | Follow-up, outcome, birth | Read · Create · Update · Delete |
| CRYO | Tanks, storage map, freeze sessions | Read · Create · Update · Delete |
| LAB | Tests, lot tracking, ultrasound | Read · Create · Update · Delete |
| REPORT | Clinical reports, statistics, statutory returns | Read · Run/export |
Data handling
Fewer copies, fewer problems.
Most clinical data leaks are not break-ins. They are a forgotten export directory, a report archive nobody owns, a credential in a configuration file.
Reports are not archived
Clinical PDFs are assembled in memory on request and streamed to the person who asked for them. No library of generated patient documents accumulates on disk.
Secrets are write-only
Integration credentials and API keys are encrypted at rest and never returned in plaintext by the administration API. The interface shows them as set or unset; they can be replaced but not read back.
Documents outlive records
Attachments are soft-deleted and retained for medico-legal reasons. Content type is determined server-side rather than trusted from the browser, and a checksum can be held per file.
Object storage, not the database
Uploaded files live in S3-compatible object storage — your MinIO instance or your own bucket — keeping large binaries out of the clinical database and its backups.
Search respects permission
The global search queries only the categories the current user is entitled to see. An unauthorised category is never searched, so results cannot hint at records the user could not otherwise open.
Nothing leaves by default
All five integration connectors ship disabled with empty endpoints and credentials, behind a master switch that is also off. Outbound traffic starts when your team decides it does.
What we do not claim
FertiliCore holds no security certification, and we will not imply one. What we offer is a set of controls that are demonstrable — you can inspect the row-level policies, read the audit schema, and watch a deletion fail against the log — and a deployment model that keeps your data inside your own compliance perimeter. If your accreditation process needs evidence from us, ask for it directly and we will provide what we have.
Questions from information-security reviews
Where is our patient data physically held?
Wherever you decide. FertiliCore is deployed into infrastructure you control — inside the clinic or in a private cloud tenancy in your name. We do not operate a shared platform that your records are pooled into, so questions of jurisdiction and residency are answered by your own hosting choice rather than ours.
Can a clinic on a shared installation see another clinic's data?
No. Every clinic-scoped table carries a tenant marker guarded by a PostgreSQL row-level security policy, so the isolation is applied by the database on every query. It is not a filter the application remembers to add — a query that omitted it would still return nothing belonging to another tenant.
What exactly does the audit trail record?
Every insert, update and delete: the action, the table and row, the values before and after (updates store only the fields that actually changed), the acting user, the tenant, the IP address, the browser and the session. Password fields are explicitly excluded from capture.
Could someone delete the audit trail to cover a change?
Not through the application, and not through the database either. The audit log and the login log are append-only, enforced at database level: updates and deletes against them are blocked. The trigger that writes the log is also attached automatically to any new table, so audit coverage does not quietly drift as the schema grows.
Is FertiliCore certified against a specific standard?
We make no certification claims. FertiliCore is designed to support the controls that clinical data-protection regimes and clinic inspections ask for — isolation, accountability, least privilege, retention — and to give your compliance team the evidence to demonstrate them. Certification of a deployment depends on the deployment, and we support your process rather than substitute for it.
What happens to a document when a clinical record is deleted?
Nothing. Attachments are soft-deleted only and retained for medico-legal reasons — deleting a clinical record never destroys the paperwork associated with it. Files carry a server-side sniffed content type and an optional SHA-256 checksum so a substituted document is detectable.
Send us your security questionnaire
We would rather answer a hundred specific questions than make one broad claim. Send the document your compliance team uses and we will complete it.