Handling Missing Inputs in Deployed Dosing Systems

Why Missing Inputs Need an Explicit Workflow

A dosing system can receive many inputs but does not need every possible patient characteristic for every calculation. The important question is not simply whether a field is blank. It is whether the particular model and use case can produce a valid, sufficiently safe recommendation without that information. A missing body weight may prevent a calculation in one use case, while a missing genotype may be irrelevant in another—or may require a different validated model path.

A missing input is therefore a decision point, not an invitation to silently substitute a value. The system should identify what is absent, determine whether it is necessary for the requested calculation, and take a defined action: request data, proceed using an approved path, or withhold the individualized recommendation. This tutorial focuses on that operational decision. It does not replace clinical data quality checks, which establish whether an observed value is plausible and usable.

Definition: A required input is an input that must be available and valid for a specified model and use case to generate an authorized recommendation. A conditional input is required only when a stated condition or model branch applies. An optional input may be absent without invalidating the recommendation, but only if the model and workflow have been validated for that absence. These labels belong to a specific model, version, and use case; they are not universal properties of a data field.

Represent the Input State Before Choosing an Action

“Missing” can describe different situations with different remedies. A value may not have been collected, may be temporarily unavailable, may be stale for the intended decision, may be invalid, or may genuinely not apply. The system should preserve these distinctions rather than collapse them into a single blank. For example, “no allergy recorded” is not necessarily the same as “confirmed no known allergy,” and an absent dose time is not a dose time of zero.

A useful classification begins with the model’s documented input requirements. For each use case, specify the required inputs, any conditional requirements and their triggering conditions, optional inputs, acceptable units and ranges, and any rules for time relevance or approved alternative sources. A field can be optional for one endpoint but required for another. Likewise, a feature used by the model may be optional only when an approved reduced-input calculation is available; it is not optional merely because software can be made to run without it.

The system should also distinguish data availability from clinical meaning. “Not applicable” can be a valid state if the model specification defines what that means. “Unknown” usually means the value cannot be established from the available information. Neither state should be converted to a numerical value unless a documented, validated rule explicitly permits it.

Operational rule: A recommendation may proceed only when the inputs satisfy the requirements of an approved model path. If a required input is absent, invalid, or outside its permitted time window, the system must not silently replace it with a default, an old value, or an assumed “typical” value. It should request a suitable input or withhold the individualized recommendation.

A Decision Framework for Missing Inputs

A compact way to describe the decision is to let \(R\) be the set of required inputs for the selected model path, \(O\) the set of optional inputs, and \(C\) the conditions that determine whether conditional requirements apply. Let \(x_j\) be the value of input \(j\), and let \(V_j\) indicate whether that value is available, valid, and sufficiently current for the use case. The model can be called only if every applicable required input passes its checks.

\text{Ready} = \left(\bigwedge_{j \in R} V_j\right) \land \left(\bigwedge_{k \in R_C(C)} V_k\right)

Here, \(R_C(C)\) denotes the conditional inputs required under the observed conditions. Optional inputs do not appear in this gate, but their absence is harmless only under a validated model path that permits it. “Ready” means the specified input gate is satisfied; it does not guarantee that the model is appropriate for every clinical circumstance or that a recommendation must be followed.

When an optional input is absent, there are two defensible routes. The system may use a separately validated reduced-input model or branch, if one is specified. Alternatively, it may evaluate a documented range of plausible values and proceed only if the output remains within a pre-specified safe decision criterion. The latter requires a justified range and a clinically meaningful criterion; it is not a license to try arbitrary values until the output looks acceptable.

Identify the missing state.
Report which input is absent and whether it is unknown, not collected, stale, invalid, or not applicable. Do not infer that one state means another.

Check the use-case requirements.
Determine whether the input is required, conditionally required, or optional for this model path and decision.

Choose an authorized action.
For a missing required input, request or retrieve an allowed value, or withhold the individualized recommendation. For an optional input, use only an approved reduced-input path or specified robustness rule.

Communicate and record the outcome.
State whether the recommendation was generated, what input was missing, what fallback was used, and what action is needed next. Do not make a withheld result look like a normal recommendation.

Worked Examples

Worked Example: Missing a Required Sample Time

Consider a hypothetical Bayesian dosing service that estimates an individual concentration-time profile from a prior dose history and a measured drug concentration. Its specified input set requires the dose amount, dose administration time, sample concentration, and sample collection time. A clinician enters a dose of 500 mg at 08:00 and a concentration of 8.0 mg/L, but the collection time is unavailable.

The recorded dose and concentration are not enough to determine the time from dose to sample. Suppose, purely for illustration, that this hypothetical model would predict 10.0 mg/L at 2 hours after dosing and 6.0 mg/L at 8 hours. The same measured concentration of 8.0 mg/L therefore cannot be interpreted against the model without knowing when it was collected. The missing time affects the relationship between the observation and the concentration-time profile; it is not a cosmetic field.

Because sample time is required, the input gate fails: \(V_{\text{sample time}}=0\), so the required-input conjunction is false. The service should request the collection time from an authorized source if available. If it cannot be established, it should withhold the individualized forecast and explain that the sample time is required. It should not assume a standard collection time or use the current time as a substitute. This conclusion follows from the stated model requirements, not from a claim that every dosing calculation always requires a sample time.

Worked Example: An Optional Input With a Validated Fallback

Suppose a hypothetical service has two validated paths for a fictional medicine. The primary path uses genotype; a separately validated reduced-input path is authorized when genotype is unavailable. The reduced-input path takes the patient’s other required data and predicts a recommended daily dose of 450 mg. For this example, the prespecified robustness check also evaluates the primary model over the allowed genotype categories and gives doses from 440 mg to 460 mg. The approved decision criterion is that predictions remain within 25 mg of the reduced-input result.

The largest deviation is \(460-450=10\) mg, and the smallest is \(450-440=10\) mg. Both are below the specified 25 mg tolerance. Thus the sensitivity check is satisfied:

\max_{g \in G} |D(g)-450\text{ mg}| = \max(10\text{ mg},10\text{ mg}) = 10\text{ mg} < 25\text{ mg}

If all required inputs are valid and the reduced-input path is authorized for this use case, the service may provide its 450 mg recommendation and disclose that genotype was unavailable and the reduced-input path was used. The conclusion does not follow merely because the range happened to be narrow: the range, model path, and tolerance must be established in advance. If genotype were required by the only approved path, the system could not re-label it as optional after seeing these results.

Worked Example: A Stale Value Does Not Satisfy a Current Requirement

A hypothetical dosing workflow for a fictional renally cleared medicine requires a renal-function estimate no more than 30 days old. A record contains an estimate of 72 mL/min/1.73 m² from 92 days ago, and no more recent value is available. The system specification permits no carry-forward beyond 30 days.

The number is present, but it fails the stated time-validity condition: \(92\text{ days}>30\text{ days}\). For this use case, it must be treated as unavailable for the required-input gate. The system should request a current result through the permitted workflow. If that cannot be obtained, it should withhold the individualized recommendation and clearly identify the missing current renal-function input.

It would be incorrect to proceed simply because the old value is numeric or because it appears plausible. The time rule is part of the model’s specified input conditions. Nor should the software substitute a population-average value unless a separately validated and authorized path explicitly allows that approach. This example illustrates a key distinction: having a stored value is not the same as having an eligible value.

Why Defaults and Statistical Imputation Are Not Automatic Solutions

A default can make an interface appear complete while concealing that the system lacks information. A typical weight, a presumed dose time, or a default genotype may shift the recommendation while giving the user no indication that an assumption was made. Defaults are appropriate only when the meaning, source, validation, and display of that default are defined for the use case. Otherwise, the correct action is to preserve the missing state and follow the request-or-withhold rule.

Statistical imputation is also not automatically a safe runtime fallback. Methods developed to analyze incomplete datasets do not, by themselves, show that a particular substituted patient value is suitable for generating an individual dose. A model may support marginalization over uncertainty or a validated reduced-input prediction, but that capability must be part of the approved method and its intended use. A system should not treat a generic imputation method as permission to manufacture a point value.

When considering whether it is safe to proceed without an optional input, examine both the prediction and the decision it supports. A small change in a predicted concentration might still cross a dose-selection boundary; conversely, varying an input might change a numerical prediction slightly without changing the supported action. The robustness criterion should therefore be expressed in terms relevant to the use case, established before deployment, and tested across the relevant missing-input patterns.

Diagnostics, Alternatives, and Limitations

A well-specified workflow makes failure visible. Useful operational checks include counting how often each input is absent by source and use case, identifying repeated requests that cannot be fulfilled, and verifying that a missing required input never produces a normal recommendation. Monitor whether fallback paths are used as intended and whether users can distinguish a reduced-input result from a full-input result. These checks can reveal a poor data interface, an unclear requirement, or a fallback being used more often than anticipated.

Approach	When it is appropriate	Main risk if used incorrectly
Request the missing input	The value can be obtained from an authorized source in time for the decision.	Repeated requests without a workable source can delay care or train users to ignore prompts.
Withhold the individualized recommendation	A required input is unavailable, or no approved fallback can support the decision.	The interface may leave users uncertain unless it explains the reason and next step.
Proceed with a validated reduced-input path	The path is approved for the specific missing-input condition and use case.	An unvalidated “simplified” calculation may produce unjustified confidence.
Use a default or imputed value	Only when an explicitly specified, validated method authorizes it and the system communicates its use.	A fabricated point value can hide uncertainty and alter the recommendation.

No single action is right for every missing field. Requesting data is not always feasible; withholding may prevent a system-generated recommendation but does not itself decide what clinical care should occur. A reduced-input path may be reliable only for the population and conditions for which it was evaluated. Even a robust prediction check cannot compensate for a wrong patient, an inappropriate model, or an input that is misinterpreted. These are reasons to make the workflow explicit, not reasons to improvise a fallback.

Common Mistakes

Calling a field optional because the software accepts a blank. Interface behavior does not establish that the model is valid without the field. Use the model and use-case specification.
Confusing absent with negative, zero, or not applicable. Preserve the actual data state. Assign a numerical value only through an authorized, defined rule.
Using a stale value because it is the only value available. Apply the time-validity requirement; if it fails, treat the input as ineligible for that path.
Assuming a small prediction change means a safe decision. Check the prespecified decision criterion, including dose boundaries or other action thresholds relevant to the use case.
Displaying a withheld result like a completed recommendation. State that no individualized recommendation was generated, identify why, and indicate the required next step.

Key takeaway: Missing-input handling is part of the model’s decision specification. Define required, conditional, and optional inputs for each use case; permit only validated fallback paths; and make requests, withholding, and assumptions visible to the user.

Check Your Understanding

For each question, identify the justified system action and the reason.

A model requires the current dose and the time it was administered. The dose is available, but its administration time is not. May the system assume the scheduled time?
A required laboratory value is present but lies outside the use case’s specified recency window. Does its presence satisfy the input requirement?
A genotype field is missing. The specification includes a validated reduced-input path for this circumstance. What should the system communicate if it uses that path?
A model output changes by only 2% when an optional value is varied, but this change crosses a dose-selection boundary. Is that sufficient evidence to proceed?

Solutions. (1) No, unless the specification explicitly authorizes scheduled time as a valid substitute. The required administration time is unavailable, so the system should request it or withhold the individualized result. (2) No. The value is stale for this use case and therefore fails the stated eligibility condition; request a current value or withhold the recommendation. (3) It may proceed through the authorized path if all that path’s requirements are met, and should identify that genotype was unavailable and the reduced-input path was used. (4) No. The percentage change is not the relevant safety criterion by itself. Crossing a dose-selection boundary means the action may differ, so the prespecified decision criterion is not met unless the use case explicitly establishes otherwise.