A medical device can pass each individual setup check and still enter operation with an invalid configuration. A user may replace an accessory after calibration, resume a partially completed workflow after a power interruption, or mistake a saved setting for a verified current condition. The engineering problem is not simply remembering which screen was open. It is deciding which evidence still supports readiness.
Interrupted setup deserves its own interface and control requirements. This article focuses on the boundary between setup and operation: how a device represents readiness, invalidates earlier checks and helps a user recover without silently accepting stale evidence. The examples below are proposed engineering scenarios, not descriptions of an Outer Reef product or test result.
1. Define readiness as evidence, not workflow progress
A completed checklist is not necessarily proof that the device is ready now. For each prerequisite to operation, identify the condition being established and the evidence used to establish it. An accessory-presence sensor establishes something different from a user confirming that an accessory is correctly installed. Neither necessarily establishes that the accessory is appropriate for the selected procedure.
Build a readiness record that distinguishes configuration values from verified conditions. A stored calibration coefficient may remain available while its applicability has expired. A selected operating mode may persist while the connected hardware has changed.
FDA's human-factors overview explicitly includes setup, calibration and maintenance within the device user interface. It also describes the interaction between what people perceive, how they interpret it and how the device responds. Readiness therefore needs both a machine-enforced meaning and a user-understandable presentation.
2. Map interruptions to the conditions they invalidate
Do not assign one universal response to every interruption. A temporary display timeout may leave the physical configuration unchanged. Removing a sensor may invalidate its calibration relationship. Restarting the controller may erase a volatile check result even when the accessory remains attached.
Use an interruption table during architecture review:
| Example event | Question to resolve | Possible recovery requirement |
|---|---|---|
| Accessory disconnected during setup | Can the device establish whether the same accessory returned? | Invalidate accessory-dependent checks until identity and installation are established. |
| Power lost during calibration | Was a complete result committed, or only intermediate data? | Reject incomplete results and provide a controlled restart path. |
| Operating mode changed after setup | Do earlier checks apply to the new mode? | Repeat only the checks whose assumptions changed. |
| User returns after a pause | Could physical conditions have changed without detection? | Require an appropriate inspection or repeat measurement before operation. |
These are candidate responses, not universal device requirements. The appropriate behavior follows from intended use and the consequences of accepting an invalid condition. Repeating every check may appear conservative, but unnecessary repetition can create burden and encourage workarounds.
3. Give the controller and interface one readiness model
A display should not announce readiness while the control subsystem still considers setup incomplete. Define the authoritative owner of readiness and the messages that communicate changes to other components. Include what happens when those messages are delayed or communication is lost.
Separate a request to advance from confirmation that a prerequisite has passed. Pressing a continue control should not itself prove that a sensor is stable or a calibration result has been accepted. Where a user confirmation is the intended evidence, preserve that distinction in the requirements and records.
For a distributed device, specify how the interface recognizes an outdated status response. A sequence identifier or configuration revision can help associate a response with the setup attempt it belongs to. The broader medical-device software architecture and verification guide provides context for these hardware-software interface contracts.
4. Make persistence transactional
Saving progress introduces its own failure modes. If power disappears while calibration data is being written, the next startup must distinguish a complete accepted result from a partial update. Define the commit boundary and how incomplete records are detected.
Associate saved evidence with the configuration that made it meaningful. Depending on the device, that association may include accessory identity, software revision or a relevant operating condition. Retaining a result without its applicability information can make recovery look successful while removing the basis for trusting it.
Storage integrity alone is insufficient. A record can be intact and still be inappropriate for the current setup. Recovery logic should evaluate both whether the record is complete and whether its assumptions remain valid. Avoid automatically restoring an operation-enable state merely because it was active before shutdown.
5. Tell users what changed and what to do next
A recovery message should explain the actionable condition rather than expose an internal state code. A generic setup-failed message forces the user to guess whether to reconnect hardware, repeat a measurement or restart the entire workflow.
Distinguish retained information from conditions requiring confirmation. For example, an interface might preserve the selected mode while clearly indicating that an accessory-dependent check must be repeated. Do not use a completed progress indicator to imply that all prerequisites remain valid.
FDA's guidance description on applying human factors and usability engineering identifies intended users, uses and use environments as central considerations in minimizing use errors and resulting harm. Apply that framing to recovery: can the intended user understand the next action under the actual lighting, attention and workflow constraints?
6. Separate software verification from user understanding
Automated tests can establish that a disconnect invalidates a readiness flag. They cannot establish that a user understands why operation is unavailable or correctly performs the recovery action. Plan evidence for both questions.
At the software and integration levels, inject interruptions at meaningful boundaries: before a measurement completes, during storage and after a status update has been sent but before the interface receives it. Check that old responses cannot restore invalid readiness.
For formative usability evaluation, observe whether representative users recognize that setup has been interrupted and identify which work must be repeated. Ask them to act on the interface rather than explain a screen in isolation. A user who can describe a warning may still proceed incorrectly when several tasks compete for attention. Such evaluation informs design; it does not by itself establish completion of formal human-factors validation.
7. Test recovery sequences, not just isolated events
Failures often emerge from combinations. Consider a disconnect followed by a mode change, or a restart followed by a delayed response from another subsystem. Also test repeated interruptions during recovery itself.
Define expected outcomes before execution. Useful acceptance questions include whether operation remains inhibited when evidence is invalid, whether recovery preserves unrelated valid settings and whether the interface presents the current reason for inhibition rather than an obsolete one.
Record the hardware configuration and software build used for each test. Where identity or persistence is involved, capture the relevant stored record before and after the event. Logs should help reconstruct the transition without becoming the only means of determining whether the device behaved correctly.
8. Preserve the recovery contract through production changes
A substituted accessory, revised sensor or firmware update can change what setup evidence means. Include recovery behavior in change-impact review rather than assuming that a stable connector or unchanged screen guarantees compatibility.
Production and service instructions also need a clear boundary. A manufacturing calibration should not be confused with a user setup check, and a service action should not leave the device apparently ready when installation verification is still required.
The design-review deliverable is a traceable contract: each readiness prerequisite has an evidence source, defined invalidating events and a justified recovery path. Connect that contract to the physical interface work described in industrial design for medical devices. The result is a setup workflow whose progress indicators, stored records and control permissions agree about what is actually ready.
