An application’s device requirements will be checked multiple times during the lifecycle of the application. Checks are triggered when an application starts, when a device is added or removed, when a (relevant) device attribute changes, and even, for some applications, every time a data value is updated.
Device requirements are checked when the application starts. This initial check deter- mines whether the set of connected devices at run time is sufficient for the application. If the requirements are not met, this may indicate that necessary devices are not present or that the patient is in a state that the application can not handle. The check at start time allows the application to inform the caregiver that there is a problem and will prevent the application from starting. If the problem can be resolved, for instance by connecting another device, then the application can be restarted and may pass the check the second time.
Device requirements that hold under a particular set of devices may no longer hold if a device is added or removed. Thus, a check is triggered when devices join or leave the network, possibly with a short delay to prevent problems with a device that fails in a way that causes it to join and leave many times per second.
A device’s settings can significantly change the data outputs even if the patient’s status is unchanged. When settings like EKG filter selection are important to the operation of the application, application developers can specify particular settings that are explicitly
allowed or blocked. If a device starts with an allowed setting but a caregiver changes the setting to one that is blocked while the application is running, this check will inform the application that the setting is no longer acceptable. The application may continue running, perhaps with degraded capabilities, alert the caregiver to change the setting back to one that is acceptable, or halt with an alarm.
Similarly, applications may incorporate algorithms that are only valid for particular ranges of vital signs. An arrhythmia detection algorithm might only work if the heart rate is between 30 and 300. If the monitoring device reports a value outside of this range, whether it’s a valid reading or an error, then the device requirement check will fail and the application will receive a notification that the vital sign is outside of the acceptable range.
Checking Device Requirements. Device requirements can be checked at several
points in a workflow: at application start time, whenever a device is added or removed, when a device attribute changes – including setting changes or addition or removal of de- vice modules, or every time any data value is updated. These options are listed roughly in order of increasing computational cost. Checking device requirements, especially be- havioral requirements, every time a data value is updated may not be possible. Data values can be updated many times per second and checking the requirements may take several seconds. In OpenICE, we leave it up to the application to determine which de- vice requirements must be checked when. As an example, the infusion safety interlock requires heart rate, oxygen saturation, and respiratory rate and requires fresh data ele- ments at least every five seconds. The application subscribes to these data elements for
the relevant patient and maintains a timer that will trigger an alert if no updates are seen for five seconds. In this example, the device requirements are checked continually as the application runs. This accommodates devices that do not specify their data update frequency and also works correctly with unreliable networks – the safety interlock works when the network is working well enough and fails safely when the network performance is not adequate.
There are two types of device requirements and two types of device models. Device requirements can be a set of arithmetic constraints or a set of CTL constraints. Arithmetic constraints operate on variables and numeric constants, evaluate to a boolean, and are assumed to be side-effect free. The four combinations of device requirement and device model types are shown in Figure 5.3.
Static DM Behavioral DM
Constraint DR arithmetic make CTL, model check
CTL DR make automata, model check model check
Figure 5.4: Combinations of Device Model and Device Requirements Types
When checking a set of constraint device requirements against a set of static device models (with no behavioral device models), it is sufficient to replace the variables in the requirements with the corresponding static assignments from the device models and then evaluate the resulting expressions. If the device model asserts that x = 2 then the requirementx≤3 is replaced with 2≤3 and evaluates totrue.
To check CTL device requirements against the same set of static device models requires first generating a set of automata from the device models and then checking the device requirements against the generated models.
requires making CTL formulas from the device requirements. These CTL formulas assert that the expression in the arithmetic constraint always holds in the model. These formulas are then checked using model checking.
Finally, CTL device requirements are checked against behavioral models using model checking, specifically the UPPAAL model checker.