Write Down What the Device Means Before Choosing a Protocol

Event/State/Command Modeling Worksheet

Use this before choosing any protocol, to write down what the device means; the mapping to standards comes last. Systems and interoperability engineers fill it in with clinical or process specialists; “Decide What the Device’s Data Means Before Choosing the Protocol” works it on the automated probe reprocessor.

Fill in the rows from top to bottom. Use the words the device’s users use. Leave the last row until every other row is complete.

The Event/State/Command Modeling Worksheet: define what the device means first, and map to standards last.

Element	What to record	Entries
Events	Each thing that happens, named in the user’s words (cycle started, chemistry test failed, specimen aspirated, bed-exit alarm raised), with its trigger, its fields, and who consumes it
States	Each state the device and its key objects can be in (idle, running, faulted, awaiting release), the allowed transitions between them, and which transitions are safety rules the device enforces locally
Commands	Each instruction the device accepts from outside, who may send it, how the device validates it, and when the device refuses it
Measurements	Each value, with its units, range, resolution, and the method that produced it
Settings	Each configurable parameter, who may change it, and how the device records a change
Identities	Which identities from the Device Identity Matrix each event and measurement carries
Time	The clock each record uses, how that clock is synchronized, and how a record shows that its time may be wrong
Quality and calibration	How each value shows its quality, and the calibration state behind it
Context	The patient, specimen, or workflow association each record needs before it means anything
Provenance	Whether each value was measured, entered, inferred, or derived, and its transformation history
Failure semantics	What each event or command means when it arrives late, twice, out of order, or not at all
Standards mapping (last)	The standard, profile, or interface each element maps to, with its version, and the elements that don’t map to anything yet

Element

What to record

Entries

Events

Each thing that happens, named in the user’s words (cycle started, chemistry test failed, specimen aspirated, bed-exit alarm raised), with its trigger, its fields, and who consumes it

States

Each state the device and its key objects can be in (idle, running, faulted, awaiting release), the allowed transitions between them, and which transitions are safety rules the device enforces locally

Commands

Each instruction the device accepts from outside, who may send it, how the device validates it, and when the device refuses it

Measurements

Each value, with its units, range, resolution, and the method that produced it

Settings

Each configurable parameter, who may change it, and how the device records a change

Identities

Which identities from the Device Identity Matrix each event and measurement carries

Time

The clock each record uses, how that clock is synchronized, and how a record shows that its time may be wrong

Quality and calibration

How each value shows its quality, and the calibration state behind it

Context

The patient, specimen, or workflow association each record needs before it means anything

Provenance

Whether each value was measured, entered, inferred, or derived, and its transformation history

Failure semantics

What each event or command means when it arrives late, twice, out of order, or not at all

Standards mapping (last)

The standard, profile, or interface each element maps to, with its version, and the elements that don’t map to anything yet

If a row can be filled in only by naming a protocol, the model isn’t finished. Keep these definitions in the device’s own model, and design the transport as a part the team can replace without changing them.