Setup

Pump limits and timing

Declared latency is the request's timing.latency; actual is what the pump really takes (differ them to teach the cost); the interval is how long each rate is held (STANPUMP: 10 s).

Start locks these for the case; the clock can still be changed. Stop sets the target to 0 and halts the clock; the record stays until the next Start.

Pump screen

Site

Typical 2.5 to 4 mcg/mL; above 20 the API refuses the target; 0 stops the infusion.

0.0 mL/hr 0 mg/hr
standby
Target
—
Ce true / pred.
—
Cp true
—
Case clock
00:00
Next request
—
Syringe left
—
Time to empty
—
Simulated (UTC)
—
Segment no command fallback —
  • true Ce
  • Ce predicted by the controller
  • true Cp
  • target
  • pump rate (mL/hr)
  • maximum rate
  • Minutes of case time; redrawn once a second.

Teaching controls

Drug given outside the pump: the record gets a bolus event and the controller gives nothing until the effect site is back at target.

A paused pump reports pump.state: paused and rate 0; the server still plans, projecting the latency at zero, and the pump decides not to run it.

The next response is lost in transit: the pump runs its segment to holdUntil, then the fallback rate, then it would stop and alarm (section 7, rule 4).

The controller is told one concentration while the syringe holds another: the true and predicted curves diverge, and the controller can only be as right as its record.

How long the pump really takes to acknowledge, against the declared timing.latency: a pump that is slower than declared runs the loading rate too long and the effect site overshoots (section 5.5).

Delivery record

What the pump recorded, newest last. This is the history the controller sends; the request itself carries it compacted once it is older than 30 minutes.

TimeEventValueUnitsSource

Nothing recorded yet.

Wire details

The newest exchange, for readers who have scrolled the conversation panel away.

No request yet.

Last request

(none)

Last response

(none)

Exchange log

    About FauxTCI

    FauxTCI is a simulated target-controlled infusion (TCI) syringe pump and its controller, running entirely in this page: no server, no framework, no build step. Set the pump's limits, pick propofol or remifentanil, enter a target, and watch the pump run: the loading infusion, the pause until the effect site peaks, the hand-off to a slowly falling maintenance rate, and what happens on a hand bolus, a pause, a lost response or a wrong syringe. The right-hand panel shows every request the pump sends and every response it receives, because the point of FauxTCI is to show how a pump talks to the controller.

    What the controller is. The controller in this page is a JavaScript reimplementation of the stanpumpR TCI API (docs/tci-api.md): the same request body in, the same response body out, the same algorithm (Shafer and Gregg 1992, as in tciRate()) and the same two drug models (Eleveld 2018 for propofol; Eleveld 2017 and Kim 2017 for remifentanil). It is validated against fixtures generated by the R package at stanpumpR commit 7d2d2f1b7727f39eba313fd8c5deea5b5104d959: the drug models to 1e-10 relative, the API responses to 1e-8 relative, and six 30-minute closed-loop traces to 1e-6 relative in the true effect-site concentration. It is not the R service. The Controller switch in the setup lets the page call a real stanpumpR::run_tci_api() server over HTTP instead, when one is reachable. The pump itself sits behind a small driver interface (js/driver.js: command a rate, read back the volume infused and the pump's state); the page runs a simulated pump, and a real pump plugs in there (a driver set as window.FauxTCI.driver before Start).

    Clinical disclaimer. FauxTCI is a teaching simulation. It is not a medical device, it has not been evaluated by any regulator, and nothing in it is to be used for patient care, for programming a real pump, or for any clinical decision.

    Source: github.com/StevenLShafer/FauxTCI (MIT licence). Version 0.3.0. Drafted by Claude Code, 2026-10-12, at the request of Steven L. Shafer.