Point a device at it and see what a reasoning engine makes of five minutes.

Two doors

Send what you already emit, or send JSON. Nothing else is required of you.

The interval is yours to choose between one and ten minutes, set when you mint your key. Five is the default, and it exists so the interval is a testable variable rather than an assumption.

What comes back

Not an inbox. The response is the point.

• Per metric: sample count, minimum and when it occurred, maximum and when, first, last and mean, with the MDC term resolved against the published standard and flagged when it cannot be.
• Text and enumerated values collapsed into runs, so a single transition to keep-vein-open between two stretches of normal infusion is the thing you see rather than the thing buried in ten identical rows.
• Cumulative counters are never differenced. They reset on reprogramming, so first and last are reported with a counter_reset flag instead of a fabricated volume.
• What the reasoning engine concluded, what it cited, and what it could not assess and why. A reader that cannot tell normal from not-measured will average the two.

Timestamps that carry no time of day, or that all land on the same instant, are reported as such rather than silently accepted. That failure produced a wrong-but-plausible answer here once, and the correction is now permanent.

Claimed versus observed

A vendor’s IHE Integration Statement names profiles. It does not say which transactions, which options, or against which revision of the Technical Framework. Statements in the field range from naming five profiles with no transaction numbers and “HL7 Not Applicable”, to naming every transaction explicitly. Same claimed profile, very different amounts of information.

So the response also tells you what you actually sent. Not a verdict. Nothing here fails.

• Which of the nine IPEC events you sent, and which never appeared, against Table X.1.2-1 of the Rev 1.4 supplement.
• Every pump status and mode value, classified by where it comes from. Rev 1.4 collapsed MDC_PUMP_STAT to two values and moved the clinical detail into MDC_PUMP_MODE. Rev 1.1 did not. Shipping products emit a third set. A value is reported as current, superseded, vendor, or traceable to nothing we hold. Nothing is rejected.
• Whether MSH-21 agrees with your trigger event. The trigger says what shape the message is. MSH-21 is where you state which profile you believe you are conforming to. When they disagree, both are reported and neither is chosen.
• Your delivery events correlated into pairs. Rate change, secondary start, secondary-to-primary, KVO transition, and the one case that may be a genuine ending.

One thing we find that no validator will. IPEC Rev 1.4 carries KVO in MDC_PUMP_MODE. Shipping products carry it in MDC_PUMP_STAT. Same clinical event, two incompatible encodings, both defensible against their own source. If your stream mixes them, the response says so.

These readings are ours, not the standard’s, and the response says so on every send. Table X.1.2.1-3 in the Rev 1.4 supplement is titled Clinical Scenarios. It illustrates. It does not prescribe, and nothing in the supplement requires a receiver to correlate a Stop with a following Start at all. Every receiver infers this independently, from worked examples, and arrives somewhere slightly different. That is the gap this sandbox exists to show. The NIST DEV tool validates a message you paste into a box. This reports what a system does across a window.

A companion, for the other half of the problem

This sandbox measures one device against the published tables. It does not help you choose between vendors, and it does not address the thing that actually goes wrong at scale: a hospital does not deploy one pump, it deploys several hundred at once onto a wireless network nobody tested for that.

Infusion pumps on hospital networks is an open, vendor-neutral scoring sheet for exactly that question. Score up to three vendors side by side across capability, wireless performance, server architecture, interoperability, and a measured wireless test protocol. Free, no sign-in, nothing collected. There is no standard for this and no notified body to ask, which is the whole reason it exists.

The rules, which are short

Simulator or generated output only. Never a real patient. The endpoint refuses anything carrying a patient name, a birth date or an identifier outside a published synthetic allowlist, and it refuses it before the payload is stored, logged or read by a model. A refusal names the field path, never the value.

Nothing you send is retained. Compute, reason, return, discard. One line per event goes to the server log: a fixed marker, whether it was a key mint or a send, and the organization name you supplied. No payload, no field, no value, ever.

Synthetic, not de-identified. Those are different categories carrying very different risk. Data that was never about a person is not protected health information at all. De-identified data invites a provenance question neither party can audit.

Why a manufacturer would bother

For twenty years every argument for device connectivity has been made to hospitals, and it has failed, because the benefit lands on the hospital and the cost lands on the manufacturer. This is the version where the manufacturer gets something directly.

• A live cloud target to test against, today, that is not a loopback and not your own staging server.
• Cheapest while you are still in development. A cleared device cannot add a data interface without change control. A device still in the lab builds one in as a design decision.
• Your device data in a published reasoning demonstration, in a document going to a standards body.

Nobody is named without written consent. Silence is not consent, and a company that connects and says nothing appears in no published count.

Ingest specification (PDF, 14 pages) Reference client The argument behind it Tell me you connected Version 0.4, 31 August 2026. Section 10a documents the conformance block the endpoint returns. GET /device returns current behavior and needs no key.