What EHR Integration Actually Takes: A Field Guide to Going Live with L&D Data

The integration conversation in an obstetric AI evaluation usually gets eight minutes near the end of the meeting, and it is almost always the part that determines whether the project ships. Below is what the work actually involves, written for the people who will have to do it.

The Data You Need Is Not All in the Same Place

Labor and delivery is unusual among specialties in how much of its clinically important data lives outside the standard FHIR resources. A risk model for the labor course wants:

• Demographics and pregnancy context: Patient, Condition, and the pregnancy-specific observations: gravidity, parity, estimated due date, gestational age.
• The labor course: cervical exams, station, fetal presentation, membrane status, contraction pattern. In Epic these live substantially in Stork flowsheet rows.
• Vitals and labs: Observation, with the timestamps intact. A blood pressure without its recorded time is not usable for trend work.
• Medications: MedicationAdministration for oxytocin and magnesium, where dose and rate history matter more than the fact of administration.
• Fetal monitoring: the hardest category. Waveform data typically does not traverse FHIR at all and requires a separate path through the monitoring vendor or archive.
• Events: Encounter and Procedure for admission, delivery, and operative intervention.

The Sequence That Works

1. Vendor program and app registration

Before any technical work, the application has to exist in the EHR vendor’s ecosystem: registered, with its scopes declared, and listed where a customer’s analyst can find it. For Epic that means the developer program and a Showroom listing; the equivalent exists for other vendors. Read-only scope requests move faster through review than write-back, and starting read-only is usually the right call.

2. Authorization architecture

Two patterns, and the choice has consequences. SMART on FHIR user-facing launch carries the logged-in clinician’s context and permissions, which is appropriate when a human is looking at a specific patient. Backend services authorization, using asymmetric client authentication, runs without a user and is what population-level or continuously updating workloads require. Most L&D products end up needing both: backend for the unit-wide view, user launch for the patient-level one.

3. Non-production first, and expect to stay there

Sandbox environments validate that your code is correct. They do not validate your mappings, because sandbox data is synthetic and tidy. A customer’s non-production environment with a refreshed copy of real data is where you find out that your dilation mapping is wrong. Budget real time here.

4. Security review

This runs in parallel and is frequently the critical path. Expect SOC 2 Type II, a completed HECVAT or equivalent questionnaire, penetration test results, a signed BAA, and a documented data flow showing exactly what leaves the network and where it goes. Having these ready before you are asked can compress the timeline by a month.

5. Mapping validation with a clinician in the room

Do not validate mappings against a specification. Validate them against a chart. Take twenty recent labor courses, extract what your integration sees, and have an L&D nurse or physician compare it line by line to what actually happened. This step finds the errors that no amount of schema checking will: the exam that was documented twice, the unit that is centimeters at one site and something else at another, the oxytocin rate recorded in a place your query does not reach.

6. Shadow mode before anyone relies on it

Run the full pipeline against live data with the output visible only to the project team. You are checking two things: that the data arrives completely and on time, and that the model’s behavior on this population resembles its behavior in validation. Both failure modes are common and neither is visible in a test environment.

The Failure Modes Worth Planning For

• Latency, not availability. An API that responds in eight seconds is fine for a chart review and useless for a unit-wide board that refreshes continuously. Ask about rate limits and response times in the customer’s actual environment, under load, not in the sandbox.
• Silent upstream change. A flowsheet template gets revised, a row is retired, and the field your model depends on starts arriving empty. Nothing errors. Monitor the completeness of every required element, per site, and alert on it. This is the single most valuable piece of operational instrumentation in a clinical integration.
• Backfill assumptions. Documentation catches up in bursts, especially after a busy shift. A model that assumes the record is current at the moment it reads it will draw conclusions from a partially written chart.
• Timezone and clock drift. Unglamorous and responsible for a surprising share of trend-calculation bugs.

What Makes the Difference

The successful integrations share one trait: a named clinical informaticist on the customer side who knows how their unit documents. Not a project manager, not an interface analyst, but someone who can answer why cervical exams look different on nights than on days. That person is worth more to the timeline than any amount of vendor tooling.