Why Input Quality Is a Recommendation Gate
A dosing model can execute correctly and still produce a clinically unusable recommendation if its inputs are wrong. A weight in pounds interpreted as kilograms, a laboratory value from the wrong date, or an administration time that conflicts with the recorded dose history can move the calculation away from the patient’s actual situation. Input validation therefore does not establish that the model is correct; it determines whether the information supplied is fit for the model’s intended use.
For a dosing service, validation has a specific operational consequence: it determines whether a recommendation may be made from the current data. A check should not merely return “valid” or “invalid.” It should identify the failed rule, the affected input, and whether the failure blocks the recommendation or permits a result with a clearly bounded qualification. This tutorial focuses on checks on supplied dosing inputs and that availability decision. It does not prescribe how a system should recover missing information.
Specify the Checks Before Evaluating a Patient
A rule is actionable only when its scope and consequence are explicit. For each input, document the expected meaning, data type, unit, allowable design range, plausibility rules, requiredness, and any relationships to other fields. These should be tied to a defined use case and model version. A field labeled “dose” is not sufficiently specified: the rule must say whether it means prescribed dose, administered dose, or dose amount entered for a proposed regimen, and whether it is expressed in milligrams per administration or milligrams per day.
The design range is not simply the set of numbers that a computer accepts. It is the supported domain for the model’s use. Suppose a hypothetical model was validated for adults aged 18–85 years, body weights of 40–150 kg, and creatinine clearance of 20–120 mL/min. An input outside one of those ranges is outside the stated domain even if the model software can calculate a result. That result should not be presented as an ordinary supported recommendation.
Plausibility rules answer a different question. A value can lie within a model’s design range and still be suspect in a particular record. For example, a weight of 80 kg is within the hypothetical range, but it may be implausible if the same encounter contains a recent weight of 8.0 kg for an adult and the decimal point may have shifted. Conversely, a clinically plausible value can lie outside the model’s design range. Plausibility does not expand the domain for which the model has been validated.
Completeness is use-case dependent. If a calculation requires the current regimen, a time-stamped concentration, and a weight, each must be present in an interpretable form. Some fields may be conditionally required: for example, a renal-function estimate may be required only for a model whose dosing equation uses it. “Not required” must not be confused with “missing but assumed normal.” A check should use the specified dependency rules and avoid inventing values.
Consistency checks often involve more than one record. Examples include verifying that a sample time follows the relevant administered dose, that a proposed dose is expressed in the expected unit, and that a dose history does not contain mutually incompatible entries for the same event. The earlier material on aligning doses, samples, and clinical events in time supplies the temporal context for these checks; the validation rule must still state which events and time windows are acceptable for the particular calculation.
Translate Check Results Into Availability
A useful policy distinguishes at least three outcomes: available, available with a qualified status, and unavailable. “Available” means that required checks passed and the inputs fall within the use case’s supported conditions. “Available with a qualified status” is appropriate only when the model specification explicitly allows the detected condition and the resulting limitation can be communicated without implying unsupported certainty. “Unavailable” means the service must not issue a dosing recommendation from the current input set.
A required field that is absent or uninterpretable will ordinarily block a calculation that depends on it. A value outside a critical design range should also block the recommendation unless a separately validated pathway covers that domain. An apparent unit mismatch or contradiction between records should be blocked until its meaning is resolved; selecting whichever value happens to be convenient would convert uncertainty about the input into an unreported modeling assumption. A noncritical warning may allow a qualified result only if the rules establish that the model remains applicable and specify the qualification.
The governing logic can be written as a gate. Let \(C_i\) indicate that check \(i\) passes, for all checks classified as blocking. Then availability requires every blocking check to pass:
Here \(A=1\) means a recommendation is available, and \(A=0\) means it is blocked. Nonblocking warnings should be represented separately; they must not be hidden by the Boolean gate or treated as passed blocking checks.
This rule follows directly from the meaning of a blocking check. If the recommendation depends on every required condition, a single failed condition means the basis for the recommendation is not established. The logical conjunction is therefore false whenever any required check is false. The conclusion is operational, not a statistical claim: it does not say the computed dose is necessarily harmful, only that the system lacks a valid basis to issue it under the specified policy.
Verify that the input set belongs to the intended patient, encounter, and dosing task before evaluating values.
Confirm that each required input is present, interpretable, and expressed in its specified unit and format.
Evaluate supported-domain limits and contextual credibility as separate tests, recording which rule failed.
Check temporal order, dose-history coherence, and other specified cross-field constraints.
Block on any failed blocking condition; permit a qualified result only for conditions explicitly classified as nonblocking.
Worked Applications
Worked Example: A Value Outside the Validated Design Range
Hypothetical case. A fictional adult dosing model is specified for ages 18–85 years, weights 40–150 kg, and creatinine clearance 20–120 mL/min. Its current use case requires all three inputs. A patient record contains age 67 years, weight 38 kg, and creatinine clearance 54 mL/min. Assume the age and laboratory value have passed the configured plausibility and consistency checks.
Design-range assessment. Age passes because \(18 \leq 67 \leq 85\). Creatinine clearance passes because \(20 \leq 54 \leq 120\). Weight fails because \(38 < 40\) kg.
The record is not automatically implausible: 38 kg can be clinically credible for an adult. The failure is specifically that the weight lies below the hypothetical model’s supported design range. The current specification classifies this design-range failure as blocking, so the recommendation is unavailable. The service should not clamp the weight to 40 kg and calculate as though 40 kg had been observed; that would change the patient input without authorization and conceal the unsupported extrapolation.
Worked Example: A Plausibility Failure Despite Passing Range Checks
Hypothetical case. A model accepts adult weights from 40 to 150 kg. The patient is documented as 42 years old and 172 cm tall, with a current encounter weight of 8.2 kg. The unit field says kilograms, and the value is within the numeric type expected by the software.
The design-range check fails because \(8.2 < 40\) kg. A separate plausibility check also fails: an 8.2 kg weight is inconsistent with the adult context and height, and a misplaced decimal or incorrect patient/record association is possible. These are distinct findings. The number should not be changed to 82 kg merely because that value seems more plausible; the data do not establish that 82 kg was measured.
Because the required weight has a blocking failure, no recommendation is available. The validation result should identify the recorded value, unit, failed rules, and blocked status so a clinician can see why no dose was produced. Plausibility checks flag a value for review; they do not determine the correct replacement value.
Worked Example: Conflicting Dose and Sample Times
Hypothetical case. A fictional model is intended to use a trough concentration collected immediately before a scheduled dose. The local rule defines an acceptable sample as one collected no more than 30 minutes before that dose and after the preceding dose. The dose record gives the preceding administration at 08:00 on Monday and the next scheduled administration at 20:00 on Monday. The concentration record is time-stamped 20:10 on Monday and is labeled “pre-dose.”
The time intervals are:
The sample occurs 10 minutes after the stated next dose time, not within the permitted 30-minute pre-dose window. It may be a post-dose sample, or one of the event times or labels may be wrong. The data therefore fail the temporal consistency rule even though each individual timestamp is a valid clock time.
The input set must not be used as a trough for this calculation. Since the sample’s role is essential to the specified model use, this consistency failure blocks the recommendation. The service should report the conflict rather than silently reclassifying the concentration as a trough or changing its time.
Worked Example: Completeness and a Qualified Result
Hypothetical case. A model’s documented use case requires weight and the current regimen to calculate a proposed maintenance dose. A recent serum concentration is optional for this particular calculation, although its absence must be disclosed. The record contains weight 72 kg and a regimen of 500 mg every 12 hours, but no concentration.
Weight and regimen are present and interpretable, so the required completeness checks pass. The optional concentration check records a missing value but does not fail a blocking condition. Under this explicitly stated use case, the model may return a recommendation with the status “available—optional concentration not supplied,” provided that the model specification permits calculation without it. This is not a general rule that concentrations are dispensable; if another use case requires the concentration, the same absence would block that calculation.
The decision depends on the predeclared requiredness rule, not on whether the software can produce a number. If the model were specified to require a concentration, then the missing field would make the recommendation unavailable.
Comparing Validation Strategies and Diagnosing Failure
Field-by-field checks are efficient for errors such as an impossible unit or a value beyond a configured bound. They are insufficient on their own because many dangerous errors are relational: a valid dose and a valid timestamp can still be inconsistent with each other. A complete rule set therefore combines single-field checks with cross-field and temporal checks.
Hard bounds are reproducible and easy to audit, but they can miss unusual yet credible records or flag valid edge cases. Contextual plausibility rules can catch such issues, but require careful specification and can be more dependent on clinical context. Neither replaces the other. A robust design records which type of rule triggered rather than collapsing all failures into an unexplained “bad data” message.
Validation at the source can prevent some entry errors, while a final check at the recommendation service protects against errors introduced by interfaces, unit conversions, or stale data. Relying exclusively on source checks assumes that every upstream system enforces the same rules and that every value reaches the service unchanged. The service should verify critical conditions on the actual values it will use.
Common diagnostic signals include repeated failures for one field, abrupt changes in failure rates after an interface update, a cluster of unit-related outliers, and many records that pass individual bounds but fail cross-field checks. These patterns can indicate a mapping defect or a poorly specified rule, not merely many bad patient records. Conversely, a validation system that almost never flags anything is not necessarily reliable; it may have overly broad limits or missing relationship checks.
Limitations and Implementation Discipline
A validation gate cannot prove that a clinical record is true. It can establish that values satisfy defined rules and that no specified contradiction was detected. A value may pass every check and still have been measured incorrectly or linked to the wrong patient. Validation is therefore a boundary on use, not a substitute for reliable clinical data capture, identity controls, or clinician judgment.
Rules also depend on model and workflow versions. If the supported population or required inputs change, the validation specification must change with them. Store enough detail to audit the decision: the input values and units used, the rule outcomes, the model/use-case version, and the resulting availability status. Do not silently convert a failed check into a pass by truncating, clipping, substituting, or reinterpreting a value.
The practical standard is straightforward: every check has a stated purpose, every failure has a defined consequence, and no recommendation is emitted when a blocking condition is unresolved. Where a result is permitted despite a warning, the scope and limitation must be explicit rather than implied.
Check Your Understanding
Answer each question, then compare with the solutions below.
- A model supports weights from 45 to 140 kg. A patient’s measured weight is 143 kg and appears clinically credible. What type of check fails, and what is the recommendation status if this boundary is blocking?
- A required concentration is recorded as 4.2 mg/L, but the model input specification expects micrograms per milliliter. Is this a completeness, plausibility, or consistency/representation problem? What should happen before recommendation?
- A dose value and a sample time each fall within their individual limits, but the sample is timestamped after the dose although labeled pre-dose. Which check detects the problem, and why can field-level bounds miss it?
- For a use case, weight is required but a concentration is optional. Weight is present and valid; concentration is absent. What determines whether a recommendation is available?
Solutions. (1) The design-range check fails because \(143 > 140\) kg. If the failure is blocking, the recommendation is unavailable even though the value may be plausible. (2) This is a representation or unit-consistency failure: \(1\text{ mg/L}=1\text{ \(\mu\)g/mL}\), so the numeric value can be converted only under an explicit, verified unit rule; the service must not interpret 4.2 as 4.2 micrograms per milliliter without resolving the specified units. (3) A cross-field temporal consistency check detects it. Each timestamp can be individually valid while their ordering contradicts the “pre-dose” label. (4) The predeclared requiredness rule and model specification determine availability. If the absent concentration is truly optional and the model permits its omission, a qualified result may be available; if required, the calculation is blocked.