Who Actually Does the Work in an IVF EMR Integration

Integration gets sold as something done to a clinic. A vendor connects the systems, data starts flowing, and the clinic carries on.

Some of it genuinely works that way. A meaningful share does not, and the part that does not is almost always work your own team has to do. Not because the vendor is offloading it — because nobody else can do it.

This is what each side actually owns, phase by phase, and where the surprises sit.

”HL7-compatible” does not mean plug-and-play

Start here, because it explains why there is any labour at all.

HL7 v2 is not a fixed contract between two systems. It is a framework with a great deal of local variation, and conformant implementations differ from each other in ways that matter:

• Which optional fields get populated. A field one system always sends may be one the other never reads.
• Which code systems are used for the same clinical concept. Two analysers can both report the same assay under different codes.
• How segments are ordered and repeated. Technically valid, practically different.

So two systems can both legitimately claim HL7 support, exchange a message that passes validation, and still produce a wrong or empty value in the record. The message arrived; the meaning did not.

This is why “we support HL7” and “we have integrated with that device” are different statements, and why field-level validation against real messages from your instruments — not from documentation — is part of every integration. It is also why the work cannot be entirely pre-built. The variation lives in your specific devices and their specific configuration.

MedART speaks HL7 v2.x including ADT, ORM and ORU message types, FHIR R4, and DICOM, which means the standards work is done. The mapping to your instruments is the part that remains, and it is shared.

Discovery: only the clinic knows what is really in the lab

The first phase is inventory, and it is the one where clinic knowledge is irreplaceable.

MedART integration engineers map every device, data source and required report, producing a gap analysis within the first week of engagement. What they are mapping, though, is what the clinic tells them exists — and the gap between the documented estate and the operating one is usually wider than anyone expects.

Three things only your team knows:

What is actually in use. Asset registers lag reality. A device listed as active may have been replaced; one nobody mentioned may be producing results that end up in patient records.

What is about to change. An analyser due for replacement in six months should not be the first interface built. That decision belongs to whoever controls the equipment budget, and it needs to surface during discovery rather than after.

Which outputs matter clinically. Not everything a device can emit needs to reach the EMR. Deciding what is signal and what is noise is a clinical judgement, and getting it wrong in either direction is costly — a missing field discovered after go-live, or a record cluttered with data nobody reads.

The practical step is straightforward and worth doing before a vendor asks: walk the lab and list every device that produces a number or an image that ends up in a patient record. That list, with model numbers, is the single most useful thing a clinic can bring to a first integration conversation.

Validation is clinical work, not IT work

This is the line most proposals blur, and the one that causes the most schedule slip.

In a MedART implementation, connectors are configured, data flow is tested end to end, and every field is validated with your lab team. Read that last clause as a resourcing requirement, because that is what it is.

Confirming that an oestradiol result landed on the right patient, against the right cycle, with the right units and the right reference range, is not something an IT lead can sign off. It needs someone who knows what the value should look like — an embryologist, a senior nurse, a lab manager. Those people have clinical workloads, and validation competes with them.

What that means in planning terms:

1. Named people, not a department. “The lab will validate” is not a plan. Validation needs specific individuals with the authority to sign off.
2. Allocated time, not goodwill. If validation happens in gaps between clinical duties, it takes weeks longer than the vendor’s estimate assumed — and the estimate will be blamed.
3. Real cases, not test data. Synthetic messages confirm the pipe works. Only real results confirm the mapping is right.

Clinics that treat validation as a scheduled clinical activity finish roughly on plan. Clinics that treat it as an IT task that the lab will glance at are the ones where go-live moves.

The parallel run nobody budgets

Before cutover, MedART integrations are parallel-run against the existing system. It is the right way to do it, and it has a cost that rarely reaches the internal plan.

A parallel run means both paths are live at once. For its duration, some work is genuinely being done twice — results arriving through the new interface and still being handled the established way, so the two can be compared. That is the entire point: you find the discrepancies while the old process is still catching them.

It is also, unavoidably, a period of extra effort for the people doing it. Not double workload across the clinic, but real duplicated effort at specific points, concentrated on the staff who are already doing the validation.

Two things make it go badly. Cutting it short because the numbers look right in week one, which is when only the straightforward cases have been through. And not telling the staff who will absorb it, which turns a planned phase into a grievance.

How long it runs depends on the specific system, the standard it speaks and the data volumes involved — the same variables that govern the build. What matters is that it appears in the plan as a phase with named people attached, rather than as a week that gets compressed when something else slips.

Go-live is a start date, not an end date

MedART integrations are monitored for 30 days after go-live to catch edge cases, with integration health visible on a single dashboard. That window exists because of how interfaces actually fail.

They rarely fail loudly. A feed that stops delivering usually produces no error anyone sees — just an absence. Results stop appearing, and someone notices days later when a clinician asks where a value went. Compare that to an application crash, which announces itself immediately, and the asymmetry is clear: the failure mode of an interface is silence.

Which makes two questions worth settling before go-live rather than after:

• Who looks at integration health, and how often? A dashboard nobody opens is not monitoring.
• What is the escalation path when a feed stops? Specifically, who at the clinic is called, and what the interim process is while it is restored. A lab that has no fallback to manual entry for a day is more exposed than one that does.

Neither question is difficult. Both are much easier to answer in advance than during.

Settle these before signing

A short list, and the honest answer to each is what you want in the contract or the statement of work rather than in an email thread:

1. Which specific devices are in scope, by model — and what happens to one discovered later.
2. Who supplies sample messages from each device, and by when.
3. Who provides network access to the instruments, and whether that needs anyone outside the clinic.
4. Which named clinical staff validate, how much time is allocated, and who signs off.
5. How long the parallel run is planned for, and who absorbs the duplicated effort.
6. What monitoring looks like after the initial window, and who is called when a feed stops.
7. What happens when a device cannot be integrated — because some older instruments genuinely cannot, and that is a replacement conversation, not an integration one.

A vendor who answers all seven plainly, including the parts that land on your side, is describing a project they have run before. One who answers everything with reassurance is describing a proposal.

For what each connection actually carries — direction, standard and payload across analysers, imaging, incubators and witnessing hardware — see everything an IVF EMR has to talk to. That piece is the what; this one is the who.

If you are earlier than this and still deciding whether to move at all, why fertility clinics outgrow the systems they started on covers replacement scope — what data moves, which processes get redesigned, and how a clinic keeps running through it. That is a different question from the integration labour described here.

The full connector inventory sits on the integrations page, and the hormone and imaging detail behind sections one and three is on the Laboratory module.