Why Fertility Clinics Are Building Custom EHRs (And What That Build Actually Looks Like)

Every morning, before the first retrieval procedure of the day, an embryologist at a mid-size IVF clinic opens three separate systems: the clinic’s EHR for patient records, an Excel sheet for embryo grading, and a standalone lab tracking tool. By 8 am, she’s manually reconciled four datasets. The first patient hasn’t walked in yet.

This isn’t a workflow problem. It’s a data architecture problem, and no off-the-shelf EHR has solved it, because no off-the-shelf EHR was designed with an embryo as a first-class data record.

In 2024, 449,772 IVF cycles were performed in the US. For the first time, more than 100,000 IVF babies were born in a single year (ASRM, 2024). The clinical volume is there. The data complexity is there. The reimbursement pressure, with 17+ US states now mandating IVF coverage, is arriving fast. What isn’t there: an EHR built for this.

This piece is for fertility clinic founders, digital health builders, and multi-site groups who’ve hit the ceiling on what specialty software can do, and are weighing what a custom build actually looks like.

I. Why does fertility medicine need its own EHR architecture?

The short answer: IVF is not an office visit. It’s a 9-phase treatment cycle that generates a different category of clinical data at every step.

Stimulation monitoring. Oocyte retrieval. Fertilization. Embryo culture. Grading. Transfer. Cryopreservation. Outcome tracking. Each phase produces structured data, hormone levels, ultrasound measurements, embryo morphology scores, specimen IDs, tank locations, that has no natural home in an EHR designed for primary care or general ambulatory workflows.

A few specific gaps:

• No embryo-as-record concept. Standard FHIR data models have Patient, Encounter, Observation, and Procedure. None of them map cleanly to “Day 5 blastocyst, Gardner grade 4AA, vitrified 2024-03-12, Tank B Slot 3.” Embryologists build their own schemas in Excel because the EHR won’t hold the data.
• No treatment cycle as an organizing unit. A fertility treatment cycle groups a sequence of clinical and lab events that span weeks across multiple care settings. Generic EHRs don’t have this container. “Each visit exists as a standalone encounter with no native link to the broader stimulation-to-transfer arc.” (CuraVerto, 2025)
• No dual-record patient model. Standard EHR architecture assumes one patient per record. Fertility care requires linked records, patient plus partner, or patient plus donor, with shared outcome history, linked diagnoses, and coordinated scheduling. This requires custom data model work regardless of which platform you start on.
• No dynamic stimulation calendar. IVF dosing adjusts in real time based on each ultrasound and E2/LH result. No off-the-shelf rule engine handles protocol modifications at this granularity.

The fertility EHR software market is currently valued at approximately $188M (2025) and growing slowly, a 2.7% CAGR signal that existing vendors aren’t solving the hard problems (Mordor Intelligence, 2025). The bigger market signal: the IVF software market overall is projected to grow from $1.51B in 2025 to $2.7B by 2032 at 8.65% CAGR (Verified Market Research, 2025). That gap between “what the market needs” and “what purpose-built fertility tools deliver” is exactly where custom builds are winning.

II. What Generic EHRs Actually Miss, And Who Is Building Custom

What does a generic EHR actually miss in a fertility workflow?

The gaps aren’t vague. They’re specific failure modes that show up at the same points in every fertility clinic that’s tried to run on a general-purpose EHR.

Embryology data ends up in Excel. “EMRs have no embryo grading fields. Embryologists maintain their own worksheets for Day 1 fertilization checks, Day 3 cleavage stage grading, and Day 5/6 blastocyst grading.” (Lifelinkr, 2025). This isn’t a workaround, it’s the standard operating procedure at most clinics. The EHR becomes a billing and scheduling tool. The science lives in spreadsheets.

Cryopreservation has no data home. Specimen IDs, vitrification dates, tank locations, thaw protocols, chain-of-custody logging, none of this maps to standard FHIR Specimen or BiologicallyDerivedProduct resources without custom extensions. Clinics managing hundreds of cryopreserved embryos across multiple tanks are doing inventory management in systems not designed for it.

Partner and donor coordination breaks. When a patient’s partner is also a patient, or when a donor is involved, the EHR’s one-patient-per-record model creates parallel charts that don’t talk to each other. Linking outcomes across records requires manual workarounds or custom development either way.

AI integration is blocked upstream. The stimulation response models, embryo quality classifiers, and implantation probability scoring tools that are starting to matter clinically all require structured, queryable embryology data. If that data lives in Excel, there’s no AI layer to build on. The off-the-shelf fertility tools that have started adding AI features are, as one physician-founder put it during a Mindbowser discovery call: “adding AI on an old system, like remodeling an old house, adding a kitchen, adding a bedroom.” The foundation isn’t there.

FHIR API access is locked or absent. Most purpose-built fertility tools (eIVF, ARTis, Mellowood Medical, Vitrify) work for single-site standard protocols. What they don’t offer: open FHIR APIs that would let clinics integrate with payers, labs, wearables, or AI layers. Data goes in, data doesn’t come out.

Who is actually building custom fertility EHRs right now?

Three buyer types are reaching this decision consistently:

Physician-founders who’ve lived the problem. Typically 15-20 years in clinical practice, have watched the EHR problem compound with every scale decision, and have identified a platform opportunity, build the EHR they needed, then commercialize it to other clinics. The build is both internal infrastructure and a product.

Digital health startups building fertility platforms. Wearable cycle tracking companies are expanding into IVF management. Surrogacy platforms that need a donor + recipient linked-record architecture. Fertility benefits platforms (employer-sponsored IVF) that need payer integration and outcome reporting. All of them hit a point where Salesforce Health Cloud or a general FHIR backend doesn’t hold the domain-specific data model.

Multi-site fertility groups scaling past 5 locations. At 3 sites, a purpose-built SaaS tool is manageable. At 5+, consolidated reporting breaks, billing reconciliation across locations becomes manual, and AI integration, stimulation protocol standardization across sites, becomes impossible without a unified data layer. The ceiling is structural, not a configuration problem.

Policy is accelerating this. With 17+ states now mandating IVF coverage, EDI and prior authorization workflows that generic fertility tools don’t support are becoming mandatory operational requirements. Clinics that want to bill insurance for IVF at scale need payer integration infrastructure that purpose-built SaaS tools weren’t designed to provide.

III. When Does a Fertility Clinic Actually Need a Custom-Built EHR?

Not always. If you’re a single-site IVF clinic running standard stimulation protocols with no plans to scale, commercialize, or integrate AI, a purpose-built SaaS tool covers most of your needs. The custom-built answer is for four specific scenarios.

1. Scenario 1: Platform-as-product. You’re building the fertility EHR to sell to other clinics, not just use internally. The data model, API layer, and compliance pathway need to be yours, not a SaaS vendor’s. This is the physician-founder path.
2. Scenario 2: Multi-site consolidation. You’re operating 5+ locations and need consolidated reporting, centralized scheduling, and unified billing across all of them. Purpose-built fertility tools don’t have a multi-tenancy architecture that holds at this scale.
3. Scenario 3: AI integration. You want to build or integrate stimulation response models, embryo quality classifiers, or implantation probability scoring. This requires structured, queryable embryology data, which means owning the data model.
4. Scenario 4: Deep payer integration. You’re operating in states with IVF coverage mandates and need EDI/prior-auth workflows, multi-cycle benefit tracking, and fertility-specific diagnosis coding (N97.x, N46.x, Z31.x) wired into the clinical workflow, not bolted on afterward.

Custom EHR builds at this scope typically run $200K-$800K for the initial platform, depending on complexity. For full cost context across build scenarios, see our EHR software cost guide.

Request an Assessment, we scope fertility EHR builds in one call.

IV. What does the Medplum Foundation give you before writing a line of code?

When Mindbowser builds a fertility EHR, Medplum is the starting point. Here’s what that means practically, not as a pitch, but as a capability inventory.

What’s pre-built on Medplum:

• FHIR R4 native data model, every clinical concept maps to a standard resource
• Auth layer: OAuth 2.0 + SMART on FHIR (required for ONC certification pathway)
• Audit logging, HIPAA-compliant access logs out of the box
• Subscription model, real-time event triggers for lab result routing, stimulation calendar updates, specimen tracking events
• HL7 v2, SFTP, and CCD-A integration layer, connects to legacy lab systems and external EHRs without custom middleware

What you build on top for fertility:

• Appointment resources structured as stimulation monitoring visits with hormone + ultrasound result links
• Observation resources for E2, LH, FSH, and AFC measurements per cycle day
• Procedure resources for retrieval and transfer events with outcome tracking
• Specimen resources extended for embryo/gamete tracking: vitrification date, Gardner grade, tank location, thaw protocol
• ServiceRequest resources for embryology lab orders with PGT result integration

Medplum is ONC Base EHR certification-ready on its 2025 roadmap, is Y Combinator-backed, and currently supports 20M+ patients on its platform. The foundation is production-grade.

What this means for build timelines: A precision medicine platform Mindbowser built on Medplum went from contract to clinical use in 90 days. A surrogacy platform currently in build used Medplum’s custom FHIR resource extension pattern to implement donor + recipient linked-record architecture in under 60 days of development.

For a deeper look at how Medplum compares to Healthie and OpenEMR for this use case: Headless EHR Comparison: Medplum vs. Healthie vs. OpenEMR.

V. What are the six components a custom fertility EHR needs to get right?

Every fertility EHR build eventually comes down to six components. Getting any one of them wrong creates the exact fragmentation the build was supposed to solve.

Component 1: Embryology module.

Day 1 fertilization check, Day 3 cleavage stage grading, Day 5/6 blastocyst grading using Gardner scoring (expansion stage + ICM grade + TE grade). If time-lapse imaging is in scope, the data model also needs to hold morphokinetic parameters. This is the most technically novel part of the build, no standard FHIR resource covers it without custom extensions.

Component 2: Stimulation protocol engine.

A dynamic cycle calendar that adjusts retrieval date projections based on real-time E2/LH levels and ultrasound follicle counts. This is a rule engine problem, not a scheduling problem. The logic: “if Day 6 E2 > 1,500 pg/mL and lead follicle > 17mm, move trigger to tonight”, needs to be configurable per protocol and per physician.

Component 3: Cryopreservation + specimen tracking.

Embryo and gamete ID system with tank location (dewar + canister + goblet), vitrification date, thaw protocol, chain-of-custody logging, and discard consent tracking. For clinics doing PGT (preimplantation genetic testing), this module also needs to hold biopsy results and link them to the embryo record. PHISecure (SecureSphere) handles genetic data de-identification for research sharing.

Component 4: Dual-record patient model.

Patient + partner/donor linked records with shared outcome history, coordinated scheduling, and ICD-10 coding across both records (Z31.x for procreative management, N97.x for female infertility, N46.x for male factor). This requires a relationship layer in the data model, FHIR RelatedPerson resource with custom extensions for fertility-specific linkage types.

Component 5: AI outcome prediction layer.

Stimulation response models trained on clinic-specific cycle data. Embryo quality classifiers using morphology grading inputs. Implantation probability scoring that accounts for endometrial receptivity markers. This layer is where generic off-the-shelf fertility tools are 3-5 years behind, they’re adding AI on top of data models that weren’t designed to feed it. For the AI architecture considerations, see AI-Native EHR Architecture.

Component 6: Fertility-specific payer integration.

Prior auth workflows for IVF under state mandates, multi-cycle benefit tracking, EDI 278 (prior auth) and 835 (remittance) transactions for fertility-specific codes. As state mandates expand, this component moves from “nice to have” to “required to bill.” Most purpose-built fertility tools don’t have it. Custom builds wire it in from day one.

VI. How does Mindbowser approach a fertility EHR build?

The starting point is always the data model, specifically, the FHIR resource extensions needed for embryology, specimen tracking, and dual-record architecture. We scope this in a single technical discovery call.

Accelerators that shorten time-to-clinical-use:

• EHRConnect, turns 6 months of EHR interoperability work into approximately 6 days. Pre-built connectors for Epic, Cerner, Athena, eCW. For fertility platforms that need to exchange data with hospital EHRs or pull lab results from external systems.
• Patient Questionnaire Form, FHIR-compliant intake forms for stimulation monitoring and new patient intake. Configurable per protocol.

Proof points:

• Precision medicine platform, 0 to clinical use in 90 days, 70% patient engagement within 3 months, 60% reduction in documentation time
• Barbados national EHR, $131K, country-scale custom data model, built without Epic or Cerner infrastructure
• EHR integration for a reproductive health platform, obstetrics and childbirth platform, custom EHR integration layer

What stays human in the build: SDOH screening integration, consent management for genetic material, clinical escalation protocols. No accelerator replaces the clinical logic design, that’s done with your team.

Start a Conversation, we’ve built fertility and reproductive health platforms before. We’ll scope yours in one call.