Unit tests lie to you. They tell you the ventilator’s serial parser works. The infusion pump’s dose calc is within spec. The monitor’s SpO2 algorithm passes on canned waveforms. All true, all useless the moment those devices sit next to each other around a real patient.
That’s where System Integration Testing (SIT) happens. It sits in the messy seam between components. Timing drifts. Protocols only half match. Alarms can cascade in ways no one predicted. The EMR may drop a value because a timestamp arrived three seconds early.
That’s the whole point of building a bay that behaves like an ICU. At Impelsys, we use our ISO 13485 medical device testing labto bring these devices together, recreate clinical scenarios, and test how the entire system behaves, especially when things don’t go as expected.
We reproduce the seam, then stress it.
Inside Our Simulated ICU: How We Set Up for System Integration Testing
You can’t validate medical device interoperability by poking one device on a bench. The behavior clinicians actually complain about — nuisance alarms during a code, a pump that stops trending in the central station when the network hiccups, a ventilator high-priority alarm that never makes it to the nurse call — only shows up when everything’s talking at once.
So we build for that.
Inside the simulated ICU testing environment: Connected medical devices, patient simulators, and clinical systems used for end-to-end integration testing.
Around a single simulated bed we set up a multi-parameter patient monitor pulling ECG, SpO2, NIBP, IBP, EtCO2 and temperature; a mechanical ventilator; large-volume and multi-channel syringe pumps; a defibrillator; a patient warming/cooling unit; an enteral feeding pump; and depending on the scenario a CRRT machine, an anesthesia machine, or a transport ventilator for the edge cases we don’t want biting us later.
Physiology gets driven by a patient simulator — Fluke ProSim on the vitals side, an IngMar ASL 5000 for the lung — so scenarios are scripted and repeatable, not knobs and vibes. Everything wires into a bedside gateway speaking HL7 v2, IHE PCD-01, and ISO/IEEE 11073, then up to a central monitoring station, a nurse call system, and an EMR test instance.
The whole bay sits on a medical-grade switch behind an isolation transformer and a UPS, with an NTP (or PTP, when we can get it) time server keeping every clock in step. Clock sync matters way more than people think, right up until you’re trying to reconcile a trend line at 03:14:07 and three devices disagree on what that even means.
What SIT Looks Like in Practice: Testing Connected Medical Devices
We run scripted clinical scenarios end-to-end — sepsis bundle, rapid deterioration, code blue, ventilator weaning — and verify that every number the simulator emitted made it through device → gateway → central station → EMR without loss, without silent transformation, and with timestamps that agree across the chain. This is where medical device software testing meets real-world interoperability, as we verify how connected systems exchange and process data.
Alarm behavior gets its own pass against IEC 60601-1-8: a high-priority alarm on the ventilator shouldn’t get masked by a medium-priority nag from the feeding pump, and annunciation to the central station and nurse call has to land inside the latency budget we wrote into the design inputs.
Then we start breaking things.
Yank the switch link mid-scenario, throttle bandwidth to something ugly, drop DNS, brown the UPS out — because the real ICU has bad days and the system’s supposed to fail in a way we predicted.
Every result traces back to a design input and a risk control per ISO 14971, the standard for medical device risk management, which is really the point of the exercise: SIT isn’t just “does it work,” it’s evidence that the mitigations we claimed actually mitigate.
From Test Results to Traceable Evidence
The paperwork is the deliverable auditors care about. SIT protocols with expected vs actual, deviation reports for anything that drifted, and a traceability matrix stitching design inputs → risk controls → verification runs into the DHF — which is what an ISO 13485 auditor opens first.
Software items land under IEC 62304 in the same folder, so unit, integration, and system-level verification all live under one traceable umbrella instead of scattered across tools. This traceability is an important part of medical device verification and validation.
The lab will never fully be an ICU — no patient anxiety, no nurse doing four things at once, no cleaning cart clipping a cable at 2am. But a well-built simulated bay helps us catch integration failures that would otherwise announce themselves on a real patient, and that’s the trade we’re paying for.
Authored by Vincent Emerald.
