Why Downtime Behavior Is Part of Dosing Safety
A dosing service is not safe merely because its model produces appropriate recommendations when every connection works. A service can also encounter an unavailable model, a delayed laboratory result, a broken interface, or a mismatch between what the user sees and the data used for calculation. In these conditions, an old or incomplete recommendation can appear more trustworthy than an explicit warning. Safe operation therefore depends on defining what the service does when it cannot establish that a recommendation is current and valid.
Fail-safe behavior does not mean displaying the same generic error for every problem, nor does it mean automatically substituting a default dose. The appropriate response depends on the failure, the clinical consequences of acting on incomplete information, and the site's approved procedures. The service should prevent an unsupported model recommendation from being mistaken for a usable one while preserving a clear route for clinical care.
The design assumes that the service has defined required inputs, a way to identify the patient and the intended dosing decision, and a clinical owner responsible for approving fallback procedures. The earlier material on clinical data quality checks, missing inputs, and EHR workflow integration provides relevant foundations. Here the central issue is operational: how the service detects a problem, changes its behavior, and tells the user what to do.
Define States Before Defining Messages
A useful design distinguishes at least four operational states. Available means the service has completed its checks and can present a recommendation for the stated context. Degraded means a nonessential capability is impaired, but the service can still safely provide the functions permitted in that condition. Withheld means a recommendation cannot be generated or verified because a required input or check has failed. Unavailable means the service cannot complete the calculation or reliably communicate its result. A site may use different labels, but each state must have an unambiguous definition and behavior.
Do not use “degraded” as a softer label for any problem. If a missing value is required by the model or by a safety check, the service must not silently proceed as though the value were valid. A nonessential component may fail without preventing a recommendation only when that degraded mode has been explicitly assessed and approved. The service should record which checks passed, which failed, and which functions were disabled.
Freshness limits are input-specific, not universal. A recent measurement may still be inappropriate if it is for the wrong patient, has been corrected or superseded, or does not match the intended clinical context. Conversely, an older value may be acceptable only if the model and the approved workflow explicitly permit it. The service should distinguish a measurement's clinical time from its arrival time in the system: a late-arriving result may describe an earlier event and is not made current by arriving now.
Turn Failure Rules Into a Testable Decision Process
Before calculating or displaying a recommendation, the service should determine whether the required data and system functions are usable. The rules should be specific enough that two implementations given the same system state produce the same decision. The following process is one compact way to express them.
Confirm the patient, medication or dosing context, evaluation time, and required model and data versions. If identity or context is uncertain, withhold the recommendation.
For every required input, verify presence, source, units, clinical timestamp, and applicable quality rules. Reject unknown timestamps and measurements later than the evaluation time unless a separately specified clock-skew rule resolves the discrepancy.
Verify that the model execution, data mapping, and result delivery functions needed for this decision are available and have passed their required checks.
Present a recommendation only when all required checks pass. Otherwise enter the defined withheld or unavailable state; use a degraded state only for an approved, nonessential failure.
Show the failure and its consequence, provide the approved next action, and record the event and relevant timestamps for later review.
This order matters. A service should not display a dose first and add a warning after discovering that its inputs are stale. The gating decision must precede presentation of the recommendation. If the system loses the ability to confirm that an output reached the EHR or that its context remains valid, it should not imply successful delivery.
Worked Example: Checking a Delayed Measurement
Suppose a hypothetical service is evaluated at 14:00. Its approved rule for one required laboratory measurement allows a maximum age of 6 hours. The measurement timestamp is 09:30, and its value and patient identity have passed the other required checks. Is the measurement fresh enough under this rule?
The age is calculated from the clinical measurement time, not the time the record arrived in the service:
The timestamp is known, it is not later than the evaluation time, and \(0 \leq 4.5 \leq 6\). Thus it passes this particular freshness check. This conclusion does not by itself establish that the full recommendation is valid; all other required inputs and service checks must also pass.
Now suppose a record is stamped 14:20 while the evaluation time remains 14:00. Then \(a_j=-0.33\) hours. Since \(a_j<0\), the strict rule rejects the timestamp; the service must not treat the negative age as satisfying the upper limit. It should flag a timestamp or clock issue and follow its defined withheld-state behavior unless an approved clock-skew procedure resolves the discrepancy.
Notices and Fallbacks Must Support a Safe Next Action
A useful notice states what failed, what that means for the displayed recommendation, and what the user should do next. “System error” alone does not tell a clinician whether a dose is current, whether a retry is safe, or whether another route is available. A clear notice should avoid implying that a recommendation exists when it was not calculated or verified.
For example, a notice might say: “No current model-informed recommendation is available. The required laboratory result is delayed, so a dose was not calculated. Follow the site-approved dosing pathway or contact the responsible clinical service.” The specific pathway and contact must be appropriate to the site and medication; the software should not invent clinical instructions. If the service can identify the failed dependency without exposing misleading technical detail, it should name the relevant data or function and its last verified time.
A fallback is not simply an older model output. Reusing a cached recommendation is appropriate only if a documented policy explicitly permits it for the specific use, sets a validity period, verifies that the patient and clinical context have not changed, and presents the output with its original calculation time and status. Otherwise, an old output should be clearly marked as historical or withheld from action. The safer default is not to convert an unverified cached result into an apparently current recommendation.
Worked Example: Service Outage With a Cached Result
In a hypothetical clinic, the dosing service becomes unavailable at 10:00. The EHR has a cached recommendation calculated at 07:00. The site's written policy permits a cached recommendation to remain actionable for no more than 2 hours, and it requires the service to verify that the patient's relevant inputs have not changed. At 10:00, the result is 3 hours old, and the service cannot check for changed inputs because its data connection is down.
The age exceeds the configured limit: \(10{:}00-07{:}00=3\) hours, which is greater than 2 hours. The required context check is also unavailable. Therefore, neither condition for actionable reuse is met. The service should not present the cached recommendation as current or suggest that it was newly calculated.
A suitable notice would state that the dosing service is unavailable, identify the cached result as historical and not validated for current use, and direct the clinician to the site's approved alternative pathway. The precise alternative is governed by clinical policy; the software should not substitute a generic or guessed dose. The service should record the outage and the attempted access so that the event can be reviewed.
Partial Failure, Retries, and Recovery
Partial failure requires particular care because some parts of the screen may continue to work. For example, the patient record may load while a required laboratory feed is delayed; the calculation may complete while result delivery to the EHR fails; or the model may be available while an input mapping is not. The interface should identify which functions remain available and which are not. A green indicator for the overall service is misleading if the calculation for this patient is blocked by a missing required input.
Retries can be useful for transient technical failures, but they do not repair stale or invalid data. A retry should be bounded, should not create duplicate orders or recommendations, and should make clear whether a new calculation was completed. If a user submits a request again, the system should distinguish a repeat request from a new clinical decision and prevent accidental duplicate actions. Once service resumes, recovery should not silently turn a previously withheld recommendation into an order; the user must receive an appropriately current result in the established workflow.
Worked Example: A Required Data Feed Is Delayed
Suppose an illustrative dosing model requires a current renal-function input. At 16:00, the patient's medication list is available, but the laboratory interface reports that the latest required result was measured at 08:00. The site's approved maximum age for this input is 4 hours. The model service itself is working normally.
The input age is \(16{:}00-08{:}00=8\) hours. Since \(8>4\), the required input fails the configured freshness check. The model's technical availability does not make the input clinically current, so the recommendation must be withheld. The service should identify the delayed laboratory data as the reason, avoid displaying a dose as actionable, and direct the clinician to the site-approved pathway for obtaining or using appropriate information.
If a new result arrives at 16:10 with a measurement timestamp of 15:30, its age at an evaluation performed at 16:10 is \(40\) minutes. It may pass the freshness criterion, provided the timestamp is valid and every other required check passes. Arrival at 16:10 alone would not be sufficient if the result's measurement time were unknown or later than the evaluation time.
Comparing Fail-Safe Strategies
| Strategy | Potential advantage | Risk and appropriate constraint |
|---|---|---|
| Fail open: display a recommendation despite a failed check | Maintains apparent continuity and may avoid interruption. | Can make stale or incomplete information look valid. Use only if a specific degraded mode has been clinically assessed and approved; never bypass required safety checks by default. |
| Fail closed: withhold the recommendation | Prevents an unverified model output from appearing actionable. | Can delay access to model support. Pair it with a clear, approved alternative pathway rather than leaving the clinician without direction. |
| Reuse a cached result | May provide continuity during a brief interruption. | Safe only under explicit validity, context, and labeling rules. Without them, a cached result can be mistaken for a current calculation. |
| Retry or queue the request | Can recover from temporary technical failures. | Does not correct bad inputs and may duplicate actions. Bound retries, define delivery status, and prevent unintended duplicate orders. |
No single strategy is correct for every failure. The appropriate choice follows from the clinical risk and the approved operational policy. In particular, “fail closed” describes the model recommendation being withheld; it does not mean that the user's broader clinical work should stop. A well-designed service pairs the withheld state with a practical, governed route to care.
Common Failure Modes and Limitations
A common mistake is to treat the most recently received record as the newest measurement. This reasoning ignores the distinction between event time and arrival time: a record can arrive late and describe an old measurement. The correction is to check the measurement timestamp against the evaluation time and the input-specific freshness limit, while separately monitoring when the record arrived.
- Allowing negative ages through the freshness check. Checking only \(a_j \leq \tau_j\) admits future-dated records. Require a known timestamp and \(0 \leq a_j \leq \tau_j\), with separately defined handling for any clock skew.
- Showing a cached result without its status. A previous calculation is not automatically valid for the current decision. Apply explicit reuse rules or label it non-actionable historical information.
- Using a generic alert for different failures. A delayed input, unavailable calculation, and failed delivery have different implications. State what failed and whether a current recommendation exists.
- Treating successful calculation as successful delivery. If the EHR did not receive or display the result reliably, do not claim that the recommendation was delivered.
- Assuming all failures can be solved by retrying. Retries may help transient outages but cannot make stale data fresh or correct a patient mismatch.
These controls cannot eliminate every operational risk. A status message may itself fail to reach the user, upstream timestamps may be wrong, and clinical circumstances can change after a calculation. The service therefore needs monitored dependencies, tested failure transitions, and clear clinical ownership of the fallback policy. Its notices should report what the system knows, not claim certainty it cannot establish.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions below.
- At 12:00, a required measurement has timestamp 12:15 and a permitted maximum age of 3 hours. Does it pass a strict freshness check? Explain.
- A model calculation succeeds, but the service cannot confirm that the result reached the EHR. What should the service avoid claiming?
- Why is a result received five minutes ago not necessarily a fresh measurement?
- Name two conditions that should be satisfied before a cached recommendation is allowed to remain actionable.
- What information should a useful notice provide when a required data feed is delayed?
Solutions. (1) No. Its age is \(12{:}00-12{:}15=-0.25\) hours, so it violates \(0 \leq a_j\); the future timestamp must be investigated or handled under a separately approved clock-skew rule. (2) It should not claim that the recommendation was delivered or is available in the EHR; it should indicate uncertain or failed delivery and follow the defined recovery procedure. (3) Arrival time is not measurement time: the record may have been measured much earlier, so freshness depends on its clinical timestamp and the applicable limit. (4) Examples include a documented validity period, verified unchanged patient context and inputs, and clear labeling with calculation time; the site's policy must specify the required conditions. (5) It should identify the delayed data or failed dependency, explain that the recommendation is withheld or cannot be verified, and state the approved next action.