You have an EHR integration to build and no reliable access to the system you are integrating with. The sandbox is shared, the windows are scheduled, and every test cycle depends on a coordination call with someone else's team. The engineering is not the constraint. The calendar is — and the calendar belongs to a vendor whose incentives do not include your delivery date.
That was the position HeartSciences was in when their AI-ECG platform had to integrate with a major EHR vendor's system. The integration required bidirectional HL7 messaging alongside FHIR OAuth flows, each with per-hospital configuration differences that only surface during live testing. The standards do not settle those differences: a systematic review of FHIR in health research (JMIR Medical Informatics, 2022) found that most implementations layer additional terminologies and site-specific profiles on top of the base resources, which leaves the actual integration surface decided per hospital rather than by the specification. ML LABS built a full EHR API simulator that replicated the targeted workflows at the protocol level, so HL7 message handling, FHIR session management, and per-organization field mappings could be developed and tested before sandbox access existed at all.
A simulator is a spike with a long half-life. It is the cheapest possible instrument for finding out what you do not yet know about a system you must integrate with — and unlike a spike, it keeps paying after the answer arrives, because it becomes the regression harness for the integration it de-risked. That is the argument of this article, and it is the same argument the cloud backend it was built for makes about seams generally: they are cheap to design and expensive to retrofit.
graph LR
A["EHR Simulator"] -->|"HL7 Orders"| B["AI-ECG Platform"]
B -->|"HL7 Results"| A
A -->|"FHIR OAuth"| B
B --> C["Per-Org Config<br/>Profiles"]
C --> D["Integration<br/>Test Suite"]
style A fill:#1a1a2e,stroke:#e94560,color:#fff
style B fill:#1a1a2e,stroke:#ffd700,color:#fff
style C fill:#1a1a2e,stroke:#0f3460,color:#fff
style D fill:#1a1a2e,stroke:#16c79a,color:#fffWhat The Simulator Replicated
This was not a generic FHIR mock server. It replicated the specific behaviors the platform depended on — the ones that would otherwise have required vendor sandbox access to discover.
On the HL7 side, the EHR sends an order message when a physician requests an ECG interpretation and the platform responds with result messages carrying the AI analysis. The simulator replicated that bidirectional flow including per-organization message behavior, validating observation segments carrying RR intervals and waveform measurements, placer order number tracking that links results back to originating orders, and diagnosis segments carrying the billing codes revenue cycle systems depend on. The messaging layer that had to satisfy all of it is the bidirectional HL7 result-delivery system, and the standard gives it very little help: an analysis of HL7 v2 optionality (JAMIA, 2009) counted 4,132 data elements in the standard result message with 85% designated optional, which is precisely why two hospitals' "compliant" messages disagree.
On the FHIR side, the vendor's integration requires per-organization authentication, where each hospital authenticates through its own endpoint. The FHIR R4 specification (HL7, 2024) and the SMART App Launch framework (HL7 FHIR, 2024) define the substrate and the launch handshake; what they do not define is which credentials, certificates, and enabled features a given hospital binds to them, and that is the part a simulator has to carry. The simulator replicated those security boundaries — including adversarial scenarios where requests attempt to cross organizational boundaries — verifying tenant isolation under conditions that would otherwise only surface in multi-organization production. It also maintained per-organization configuration profiles mirroring production variation, so configuration-driven parsing logic could be built without access to any hospital's live EHR instance. All of it then became the foundation of the integration test suite: unit tests across every organization configuration, end-to-end tests from order receipt through AI processing to result delivery, catching parsing regressions on each commit before they could reach a hospital-specific code path that only runs in production.
The simulator's value was never in replicating the vendor's API surface. It was in replicating the per-organization behavioral differences that only surface during live integration testing.
The Variations That Surfaced
Three patterns account for most of the rework the simulator absorbed, and each one is a single field that looks like a footnote during setup.
Patient identifier formatting. Two hospitals on the same vendor sent the identifier in the same HL7 field, but one zero-padded the medical record number to a fixed width and the other left it variable. A parser that worked end to end for the first site would mismatch results to the wrong patient at the second. The per-org profiles exposed that on the first integration test rather than during clinical validation.
Ordering provider representation. One site populated the field with an internal directory ID, another with a national provider identifier, and a third with a free-text initial-and-surname string. Each needs different lookup logic to attribute the AI interpretation back to a clinician. Without per-org profiles, the platform would have inherited whichever convention the first hospital used and produced unattributable results everywhere else.
The unsolicited result workflow. Some sites expect results only in response to an explicit order message; others expect results to flow as soon as an interpretation is available, with no preceding order. Invert that assumption and the receiving system either drops the result or queues it for manual reconciliation — and the symptom, a missing result in the EHR view, is indistinguishable from a transport failure until someone reads the message logs. Encoding both behaviors as named profiles meant the routing logic was tested against the variation up front instead of patched after a hospital reported missing studies.
That is also the heuristic for whether a candidate integration warrants a simulator at all: count the behavioral toggles per site that the vendor's documentation leaves underspecified. Single digits, and ordinary configuration handles it. Dozens — across identifier conventions, message timing, segment optionality, and authentication binding — and sandbox iteration alone will not converge, because each window is spent discovering variation rather than validating against it. The simulator changes what the scarce sandbox time is for: sessions stop being first-pass parsing tests and become validation passes against work already known-good, with every divergence feeding straight back into the simulator profile so the next iteration catches it without more vendor time. The semantic layer makes the same case — a mapping review of EHR semantic issues under FHIR (JMIR, 2024) found organizations continue to enter clinical information as free text or local terminologies rather than standardized codes, with no single bridging approach emerging, which means the variation you must handle is discovered, never specified.
When A Simulator Won't Help
A simulator is not a substitute for validation against the real system, and it does not make an undocumented API knowable. Where the target's surface is actively changing or genuinely undocumented, a simulator encodes your guesses and hands them back to you with a passing test suite, which is worse than no test suite.
The question that decides it is whether the external dependency is a scheduling bottleneck or a knowledge bottleneck. Simulators solve the first and can disguise the second. If nobody on the project can describe what the target system does when a required field is absent, building a simulator will not tell you — it will only make the wrong answer run faster.
First Steps
- Simulate the blocking surface, not the API. Start with the workflows that gate development and carry the most per-organization variation. A complete mock of an EHR is a year of work that nobody asked for.
- Calibrate on every real interaction. Each sandbox session should end by updating the simulator's profiles with whatever behavioral difference it revealed. An uncalibrated simulator drifts into fiction.
- Build the test suite on top from day one. The durable value is regression coverage across every per-organization profile, long after the sandbox stops being scarce.
Simulate The Blocking Integration
Simulate the specific behaviors that block development — per-organization field mappings, bidirectional message workflows, authentication binding — rather than waiting on a sandbox window for each iteration, then calibrate against real interactions and keep the regression suite the simulator makes possible. On this integration the binding constraint was never engineering complexity — it was iteration speed imposed by a dependency ML LABS did not control, and the simulator converted an external constraint into an internal one that could be scheduled.
This is what a de-risking engagement is supposed to produce before anyone commits build budget: not a slide deck, but a working artifact in your stack that proves the hard path is walkable. The AI system design engagement is built to that shape — the architecture, a written build plan, a fixed-price quote for the build, and a working spike running against your real constraints, with the fee credited toward the Build that follows. Whether the risky part of your integration is a scarce sandbox, an undecided data path, or a workflow nobody has written down, the answer is the same: build the smallest thing that makes the risk visible, and do it before the budget is committed rather than after.
References
- Vorisek, C. N., et al. Fast Healthcare Interoperability Resources (FHIR) for Interoperability in Health Research: Systematic Review. JMIR Medical Informatics, 2022.
- Sujansky WV, Overhage JM, Chang S, Frohlich J, Faus SA. The Development of a Highly Constrained Health Level 7 Implementation Guide to Facilitate Electronic Laboratory Reporting to Ambulatory Electronic Health Record Systems. Journal of the American Medical Informatics Association, 2009.
- Amar, F., April, A., and Abran, A. Electronic Health Record and Semantic Issues Using Fast Healthcare Interoperability Resources: Systematic Mapping Review. Journal of Medical Internet Research, 2024.
- HL7 International. SMART App Launch Implementation Guide. HL7 FHIR, 2024.
- HL7 International. FHIR R4 Specification. HL7 International, 2024.
