The moment that exposes a clinic’s integration gaps is not a demo. It is a registry submission.
Someone sits down to complete a cycle record and finds the embryology data in one platform, the clinical outcome in another, and the medication history in a third. Every individual system worked. The record still has to be assembled by hand, by a person cross-referencing screens, weeks after the events happened.
This article is an inventory of what has to connect in an IVF laboratory, and — the part usually left out — what each connection actually carries and which direction it flows.
Orders out, results back: the analyser interface
The hormone analyser is the highest-volume interface in a fertility clinic and the one most often installed at half capacity.
A complete integration is bidirectional, and the two directions are separate messages. The order leaves the EMR as an HL7 ORM message telling the analyser what to run on which sample. The result returns as an ORU message that attaches to the right patient and the right cycle without anyone typing it. MedART speaks HL7 v2.x including ADT, ORM and ORU message types, alongside FHIR R4, and integrates with the analysers fertility labs actually run — Abbott ARCHITECT, Roche cobas, Siemens ADVIA among them.
What clinics frequently buy instead is the return half only. Results flow back; orders are still keyed into the instrument by a technologist. That configuration is cheaper, it demonstrates well, and it leaves two failure modes in place: a sample run against the wrong order, and a discrepancy between what the EMR believes was requested and what the analyser actually did.
During a stimulation cycle, where oestradiol values drive the next dose, both matter. The detail of hormone-result handling and critical-value alerting sits on the Laboratory module; what matters here is the direction question — ask any vendor whether the interface is one-way or two, and treat “we integrate with that analyser” as an incomplete answer.
Images are a different problem from results
Ultrasound is where integration plans tend to be vague, because an image is not a value.
A hormone result is a number with a unit and a reference range — small, structured, and easy to attach to a record. A follicular scan is a DICOM object with its own metadata, its own storage requirements, and its own viewer expectations. The two travel over different pipes and the second is meaningfully heavier.
MedART supports DICOM so scans land in the patient record rather than in a parallel imaging archive that clinicians open separately. The practical distinction worth holding in an evaluation: ask whether images are stored in the record or linked from it. Both are legitimate, they have different implications for retrieval years later, and vendors describe both as “integrated”.
The lab systems that do not speak HL7
Here is where standards-based thinking runs out, and where most integration plans quietly under-scope.
HL7 and DICOM cover the clinical-pathology and imaging worlds well. A large share of an embryology laboratory sits outside both.
Time-lapse incubators — Vitrolife EmbryoScope+, Geri and equivalents — produce morphokinetic annotations and continuous imaging in vendor-specific formats. The connection is typically an export or an API rather than a clinical message, and the scoping question is what actually transfers: the grades and annotations, or the underlying imaging too.
Witnessing hardware — RI Witness, Matcher, barcode scanners — produces identity-verification events at the bench. These are not results; they are attestations that the right sample was in the right hands at a given moment, and they belong attached to the cycle’s chain-of-custody record.
Cryo monitoring is telemetry rather than transactions: tank temperature, LN₂ level, humidity, battery, arriving continuously rather than per patient. It connects to samples only through storage position, which is why the position record has to be right before the monitoring data means anything.
Andrology instruments — CASA systems — and controlled-rate freezers sit in the same category: real devices producing real data over device-specific channels.
The through-line is that “does it integrate?” is the wrong question for this group. The right one is what does the device emit, in what format, and who has built that connection before? Where a device is not on a vendor’s list, the honest answer is conditional: if it speaks HL7, FHIR, DICOM or HTTP, it can be connected — which is a statement about capability, not about a connector that already exists.
We drew the boundary between these systems in what your EMR should and shouldn’t be tracking in the IVF lab. That piece is about which system should own which record. This one is about what physically has to reach the EMR, and in what shape.
Out of house: the PGT round trip
Genetic testing is the only interface in this inventory that crosses an organisational boundary, and it behaves differently for that reason.
A biopsy leaves the clinic for an external genetics laboratory. Results return days or weeks later — by which time the embryos are vitrified and sitting in a tank. The reference laboratory has its own identifiers, its own reporting format, and its own turnaround.
Three things have to hold for that round trip to close cleanly:
- Identifier alignment. Your embryo identifier and the reference lab’s sample identifier must be reconcilable without a human deciding which is which.
- Result-to-embryo, not result-to-patient. A PGT result belongs to one specific embryo in one specific storage position, not to the cycle in general. An interface that attaches it at patient level has lost the information that makes it actionable.
- A record that survives the gap. Weeks pass between biopsy and result. Anything held in a person’s head during that window is a single point of failure.
Latency is not the problem here — everyone expects the wait. Reconciliation is.
What each connection actually carries
Pulled together, the inventory looks like this. Direction is the column most integration discussions skip.
| System | Direction | Typically speaks | What breaks without it |
|---|---|---|---|
| Hormone analysers | Both ways | HL7 v2.x (ORM / ORU) | Orders keyed by hand; results transcribed |
| Ultrasound / imaging | Inbound | DICOM | Scans live in a separate archive |
| Time-lapse incubators | Inbound | Vendor export or API | Grades re-entered from the incubator screen |
| Witnessing hardware | Inbound (events) | Device-specific | Custody attestations sit outside the cycle record |
| Cryo monitoring | Inbound (telemetry) | IoT / device API | An excursion cannot be linked to affected samples |
| Genetics / PGT lab | Both ways, high latency | Report exchange | Results reconciled to embryos by hand |
| Andrology (CASA) | Inbound | Device-specific | Semen analysis retyped into the record |
Read the right-hand column as a list and a pattern appears: every missing interface converts into manual transcription, and every manual transcription is a place where the record and reality can drift apart. That is the actual cost of an under-scoped integration — not inconvenience, but a cycle record nobody can fully trust at submission time.
For the wider argument about clinical, lab and financial data ending up in separate systems, see how to manage fragmented data in IVF clinics.
Where clinics get surprised
Four things reliably come up late, and all four are easier to handle at scoping than at go-live.
The instrument inventory is longer than anyone thinks. Ask the lab to list every device that produces a number or an image that ends up in a patient record. It is routinely more than the clinical team expects, and older instruments are often the ones with the least convenient outputs.
Ageing devices may have no usable output at all. An analyser that predates network connectivity cannot be integrated on any standard. That is a replacement conversation, not an integration one, and it is better to have it during evaluation than during implementation.
Integration work is shared, not delivered. The vendor builds and tests the interface. Someone at the clinic confirms which instruments are in scope, arranges network access, supplies sample messages or exports from each device, and validates results before sign-off. A vendor who implies otherwise has either done this before and is simplifying, or has not. The full division of labour — who supplies what, who validates, and who is called when a feed stops — is set out in who actually does the work in an IVF EMR integration.
Timelines vary by system, not by project. Standard HL7, FHIR and DICOM interfaces are well-trodden. A vendor-specific incubator export or an external genetics reporting format is not, and the honest answer depends on the device and the data volumes involved.
The full connector inventory across lab, communication, device and cloud categories sits on the integrations page. For the broader evaluation frame around laboratory software, IVF lab management software covers the selection criteria.
The short version
An IVF EMR does not replace the laboratory’s systems. It has to receive what they produce, attach it to the right cycle, and hold it in a form that can be reported on.
Judge that on direction and payload rather than on a connector count. For every device that matters: which way does the data flow, what exactly does it carry, and what happens on the day it does not arrive. A clinic that can answer those three for its own instrument list is doing better than most, and will not be assembling cycle records by hand at submission time.
Topics
Product Implementation Lead · CSPO®, CSM®
Ravi Chhajed is a Product Implementation Lead specializing in healthcare SaaS, including EMR and IVF systems. He focuses on clinical workflow automation and AI-enabled product delivery. Ravi holds the Certified Scrum Product Owner (CSPO®) and Certified ScrumMaster (CSM®) certifications, bringing an agile approach to delivering and implementing clinical software.