Fertility Clinic Software: What Breaks at Scale and What to Build Instead

Why fertility clinic software makes or breaks a high volume IVF group

It is 6:40 on a Saturday and the monitoring bay is full. Fifty five patients get drawn before 8:30. The REI on service scans follicles and calls out counts by ovary and size while a medical assistant types them somewhere. Estradiol and LH post from the reference lab around 10:15. By noon two nurse coordinators have to reach every one of those patients with a dose change, a stay the course, or a trigger time down to the minute. The artifact holding it together is a workbook called Stim Tracker Feb v4 FINAL, on a shared drive, open on two machines at once. One is a stale copy.

Downstairs the lab runs a parallel universe. Witnessing happens on RI Witness or Matcher, embryo grading lives in the embryologist's own sheet, PGT-A biopsies ship to Cooper Genomics or Natera and come back as PDFs somebody retypes, and cryo positions live on a laminated tank map with pencil corrections. Out front, eIVF or IDEAS holds demographics and some cycle data, Epic or athenahealth holds the practice side, EngagedMD holds consents. Nothing reconciles. The financial counselor quotes a multi cycle package out of a fourth spreadsheet.

None of these people are careless. One transcription slip moves a trigger by twelve hours or puts the wrong straw in the wrong goblet, and their system treats a cycle as a folder of documents rather than a living object with a state machine. Off the shelf ART software documents a cycle after it happened. You need software that runs the cycle while it is happening.

Problem one: the monitoring day has no single source of truth

A stim cycle is decisions made on partial data under a hard clock. Day 6 estradiol comes back at 1,840, the scan shows nine follicles over 12mm on the right and six on the left, the patient is on 225 of Gonal-F and 150 of Menopur, and someone decides by 11:30 whether to coast, drop the dose, or trigger tonight. In the clinics we have built for, that decision touches four systems and a phone call, and the record of why it was made ends up as a free text nursing note nobody can query later.

eIVF and IDEAS store the values. They do not model your protocol. They do not know that your group coasts above a threshold your medical director set, that your antagonist start rule differs from the practice you acquired last year, or that a poor responder on a mini stim gets a different call list. The protocol lives in a senior nurse's head, and when she is out, the day gets slower and the calls get inconsistent.

A custom build makes the cycle a first class object. One screen per monitoring day: scan measurements entered once by ovary and size bucket, labs pulled by HL7 or FHIR interface the moment they resolve, protocol rules evaluated live, a ranked call queue telling the coordinator who needs a call and what changed. Every dose change writes an immutable audit row with the values that were on screen when it was made. AI does real work here: draft the call script from the actual numbers and protocol, so the coordinator edits thirty seconds of text instead of composing from scratch fifty five times before lunch. The physician still decides. The software refuses to let the decision get lost.

Problem two: chain of custody breaks at the seams between systems

Your witnessing system is excellent inside the lab. RI Witness will not let an embryologist open two patients' dishes at one station. But the chain does not start or end at the bench. It runs from retrieval through fertilization check, day 3 and day 5 grading, biopsy, shipment to the genetics lab, result return, thaw, and transfer. Every hop is a place where an identifier gets retyped.

The genetics handoff is the worst of it. Three weeks after you ship a biopsy tray, a euploid result arrives as a PDF keyed to the genetics lab's tube ID, not your embryo ID. Someone maps them by hand. If the mapping is wrong you transfer the wrong embryo, and there is no version of that story that ends well.

A custom platform gives every gamete and embryo a durable identifier from the moment it exists, and keeps a lineage graph: which oocyte, which sperm source, which fertilization method, which grading events, which biopsy, which shipment manifest, which result. Ingestion gets built per genetics lab, because each formats differently, and document extraction is genuinely useful here. Parse the report, match on tube ID and accession, then hold the match for an embryologist to confirm rather than auto committing it. The typing disappears and the confirmation stays. Off the shelf tools cannot do this: they do not own both ends of the handoff.

Problem three: cryo storage is an unpriced liability

Most clinics cannot answer three questions quickly: how many straws are in tank four, which belong to patients who stopped paying storage fees in 2021, and which have a signed disposition consent on file. The tank map is a printed grid. Storage billing runs on an anniversary date somebody set by hand. Consents sit in EngagedMD or a scanned PDF folder. These three facts have never been in the same place.

That gap is where the lawsuits live, and where real money leaks. Annual storage billed at a few hundred dollars per patient, times several thousand patients, times the share that quietly falls off the invoice run, is worth building software to protect.

A custom build treats cryo inventory as a ledger: tank, canister, goblet, cane, position, occupant, every move written as a transaction rather than an edit. It joins that ledger to the billing anniversary and the consent state, so the abandoned specimen report becomes a query instead of a project. It ingests LN2 level and alarm telemetry so a tank event has a timestamped record rather than a recollection. Forecasting helps plainly: project capacity against retrieval volume so you order the next dewar before your techs start stacking canes creatively.

Problem four: donor matching runs on tribal knowledge

If you run a donor egg or donor sperm program, the matching logic is real and it is nowhere in your software. FDA donor eligibility under 21 CFR Part 1271 requires infectious disease testing inside a defined window, and anonymous sperm donors carry a quarantine period. CMV status has to match or the recipient consents in writing. Carrier screening has to be cross referenced so a donor and a recipient partner carrying the same condition never get matched. Phenotype preferences, family limits, and ID disclosure sit on top.

Today a donor coordinator holds this in a spreadsheet with a CMV column and a memory of who is near their family limit. eIVF was not designed as a donor bank. It has no concept of a match rule, an eligibility clock, or a family limit counter.

A custom build encodes eligibility as rules with dates attached, so a donor whose testing aged out drops out of the matchable pool automatically instead of being caught by a person on a good day. Carrier cross matching runs against the recipient couple's panel results and produces a hard exclusion list, not a suggestion. Family limits decrement on reported live birth. The coordinator stops being the constraint engine and reviews a shortlist that already satisfies them.

Problem five: SART reporting eats a coordinator alive every spring

SART CORS submission is an annual reckoning with data you should have captured cleanly in real time. Instead a coordinator spends weeks chasing outcome fields nobody entered and calling OB offices for delivery data. Off the shelf systems export what they hold, which is the problem: if a field was never required at the point of care, no export fixes it. A custom build enforces the SART and CDC data model at capture, so the fields the submission needs are the fields the coordinator fills during the cycle, validated then, with the outcome loop closed by structured pregnancy follow up rather than a phone call in March. Reporting becomes a file you generate, not a season you survive.

What this costs and how long it takes

Across 2,000 plus projects, Digital Heroes sees a focused first release land at $60,000 to $130,000 and ship in 12 to 16 weeks. In this category that release is usually the cycle engine plus the monitoring day workflow, running alongside your existing system rather than replacing it. Full platforms, cycle plus embryology plus cryo ledger plus donor plus billing plus reporting, run $150,000 to $400,000 phased over 6 to 12 months.

What pushes price up here specifically: HL7 or FHIR interfaces to reference labs and to Epic or athenahealth, each priced as its own integration. Witnessing integration with RI Witness or Matcher, vendor dependent and sometimes a negotiation before it is an engineering task. Per vendor PGT result ingestion, because Cooper Genomics and Natera and Igenomix do not agree on a format. Audit trail and electronic signature rigor at 21 CFR Part 11 standard, plus the validation documentation your CAP and CLIA inspector will ask for. And migration: fifteen years of embryo and cryo records out of eIVF or IDEAS, the hardest line item on the page, because the source data has gaps you discover only by migrating it.

Build versus buy, honestly

Buy the off the shelf tool if you are a single site doing under roughly 300 retrievals a year, your donor work is referral only, you bill insurance rather than running refund programs, and your lab director is genuinely comfortable with the workbook. eIVF and IDEAS are real products maintained by people who know ART. Rebuilding demographics and scheduling just to own them is a bad trade at that scale.

Build when three signals show up together. First, you are multi site or acquiring, and each site's protocols differ enough that no vendor configuration screen reconciles them. Second, your highest value operations, the donor program, the refund program, the cryo ledger, already live outside the vendor's product in spreadsheets, so you are already maintaining custom software with none of the safety and no audit trail. Third, you asked your vendor for a change that matters to margin and got a roadmap answer measured in years. At that point the vendor is not your system of record. Your spreadsheets are.

How to choose a developer for fertility clinic software

Ask them to model an embryo on a whiteboard before you talk price. If they draw a table with a grade column, they have not built this. The right answer involves lineage from oocyte and sperm source, an event stream of grading and biopsy and freeze and thaw, and a cryo position that is a transaction history rather than a field you overwrite. Domain data modeling decides this category and it shows in ten minutes.

Make them name integrations they have actually shipped. Not HL7 in the abstract: which reference labs, which EMR, whether they have gotten a witnessing vendor to return their calls, how they handled a PGT lab that only sends PDFs. A team that has done it will have opinions about specific vendors being difficult, because they are.

Ask what they will hand your CAP inspector. Audit trails, role based access, e signature handling, and validation documentation are deliverables with hours attached, and a developer who has never sat through an inspection will not budget for them. Get code ownership, repository access, and the deployment path in writing in the same conversation.

Then ask what they would refuse to build first. Anyone who says yes to the whole platform in release one is selling you a twelve month gap between payment and value, in a clinic that has patients starting stims next Monday.