Why Input Validation Comes Before Calculation
A dosing algorithm can return a precise-looking recommendation from an incorrect input. A weight entered in pounds but interpreted as kilograms, a laboratory result attached to the wrong patient, or a missing value replaced by an undocumented default can all make the calculation internally consistent and unsafe to use. Input validation is the set of checks that determines whether data satisfy the specified format and requirements for use by a calculation.
Validation is not the same as deciding whether a patient is suitable for a model, nor is it a judgment that a value is clinically plausible. The earlier material on detecting out-of-domain patients addresses whether a patient belongs to the intended application domain. Here the question is narrower: are the inputs correctly represented, complete where required, and internally linked so the calculation can interpret them as intended? A value can be correctly formatted and within a permitted data range yet still warrant a separate clinical review.
A useful design treats validation as a gate, not as a collection of warnings that can be overlooked. Let \(V_j\) denote the result of required check \(j\), with \(V_j=1\) when that check passes and \(V_j=0\) otherwise. The calculation may run only when every required check passes:
This rule is a design invariant: a failed or unknown required check must not be interpreted as a pass. The system should identify the failure, withhold the calculation, and record an actionable reason. It should not silently substitute a value, guess a unit, or discard a conflicting record.
Specify Checks in an Input Contract
Write the contract field by field. For each field, specify whether it is required, its representation, its units if quantitative, any allowed range defined by the data or model interface, and how it is linked to the patient and encounter. “Weight must be valid” is not an adequate rule. “Weight is required, numeric, reported in kilograms, and between the interface limits of 20 and 250 kg” is testable. Those limits here are hypothetical interface limits, not a claim that every value inside them is clinically plausible.
Separate the main checks so their purposes remain clear:
- Presence and type: Is each required field present and represented in an accepted form? A blank string, a text value in a numeric field, and an explicit missing-value code should not be treated as interchangeable unless the contract says how to handle them.
- Units: Are units explicitly supplied or otherwise unambiguously established by the interface? Can they be converted to the calculation’s canonical units without guessing?
- Permitted range: Does a numeric value lie within the specified interface or model-input bounds? A range check catches certain entry or transmission errors; it does not establish clinical plausibility.
- Timestamp: Is the timestamp parseable, does it have a defined time zone, and does it satisfy required ordering rules for the events represented?
- Identity: Do the patient and encounter identifiers agree across fields and source records that will be combined?
A field that is not required should have an explicit missing-data rule too. It may be ignored, or it may prevent a particular calculation; that decision belongs in the contract. It should not be left to ad hoc behavior at run time. In particular, absence of a required value is not permission to use a population average, a previous value, or a default unless a separately specified and authorized rule explicitly requires that action.
Worked Example: Converting a Value With Explicit Units
A hypothetical interface accepts weight in kilograms and specifies an allowed interface range of 20 to 250 kg. An incoming record gives weight as 154 lb. Determine whether the value can be converted and checked against the contract.
Check the unit. The source explicitly reports pounds, so no unit needs to be inferred. Use the exact conversion \(1\text{ lb}=0.45359237\text{ kg}\):
The pound units cancel, leaving kilograms. Rounded to four significant figures, the canonical value is 69.85 kg. It satisfies the hypothetical interface range because \(20\text{ kg}\leq69.85\text{ kg}\leq250\text{ kg}\). The value can therefore pass the unit and range checks, assuming its other required checks also pass.
If the same record contained the number 154 without a unit, conversion would not be justified: the contract would require a known unit, and the system should block the calculation or request correction. The fact that 154 could be interpreted as either pounds or kilograms does not resolve the ambiguity.
Missing Fields and Range Checks
Validation should distinguish at least three outcomes for a required field: valid, invalid, and missing. “Invalid” includes such cases as a nonnumeric string where a number is required, a number outside the specified bounds, or an unrecognized unit. Missing means no usable value was supplied. This distinction improves both correction and monitoring: the response to a blank field may differ from the response to a value that cannot be parsed.
Range checks need a stated source and purpose. A bound may be imposed by the accepted data format, the model interface, or an explicit system requirement. It should not be presented as a general biological or clinical safety boundary unless it was established for that purpose. Also check representation before comparing values: a text string such as “unknown” is not a number, and a non-finite value such as \(+\infty\) cannot pass merely because a programming comparison behaves unexpectedly.
Do not use range checks as a substitute for unit checks. A value can fall inside a broad numeric interval while being expressed in the wrong unit. Conversely, a converted value can lie outside the interface bounds, which should be reported as a range failure after conversion. The order matters: parse the value and unit, convert using an approved conversion, then check the canonical value against the stated bounds.
Worked Example: A Missing Required Field and an Out-of-Range Value
A hypothetical dosing interface requires age and serum creatinine (SCr), with age recorded as an integer from 18 through 90 years. The incoming record contains age 94 years and leaves SCr blank. What should the validator do?
Age check. The value is present and is an integer, so it passes the presence and type checks. It fails the stated interface range because \(94>90\). This is a contract failure, not a conclusion about the patient’s physiology.
SCr check. The required field is blank, so it fails the presence check. No SCr value can be supplied by assumption or by carrying forward a previous record unless such a behavior is explicitly part of an authorized, separate rule.
Decision. Since both a required range check and a required presence check fail, the gate condition is false:
The calculation must not run. A useful diagnostic identifies both failures: “Age 94 years is outside the configured interface range 18–90 years” and “Required SCr value is missing.” The system should not report a dose based on the one field that happened to pass.
Timestamp and Identity Checks
A timestamp is meaningful only if its representation and time basis are known. The contract should specify an accepted format, whether a time zone is required, and which event the timestamp describes—for example, sample collection, result entry, or dose administration. These are not interchangeable events. If timestamps lack a time zone, a value near a date boundary can be interpreted differently by systems in different locations.
When the calculation depends on event order, state the order explicitly. For example, if a result must have been collected no later than the dosing decision, require \(t_{\text{collection}}\leq t_{\text{decision}}\), after both times have been parsed into a consistent time basis. If the ordering condition fails, block that record and report the specific conflict. Do not silently change a timestamp to make the order work.
Identity checks should likewise be explicit. A patient identifier is not interchangeable with an encounter identifier: the patient identifies the person, while the encounter identifies the relevant visit or episode in the system. Before combining a measurement with a dosing request, compare both identifiers wherever the data contract requires them. Matching only on name, date of birth, or a partial identifier is not a safe substitute for the defined linkage rule.
Worked Example: Conflicting Identity and Event Time
A hypothetical dosing request is for patient P104 in encounter E22 at 14:30 UTC on 12 May. The attached laboratory record is labelled patient P140, encounter E22. Its collection time is 15:10 UTC on 12 May, explicitly in UTC. The contract requires an exact match on both identifiers and requires collection time to be no later than the decision time.
Identity. The encounter identifiers match, but the patient identifiers do not: P140 is not P104. Thus the identity check fails even though one identifier agrees.
Time ordering. Both timestamps use UTC, so they can be compared directly. The collection time is 15:10 and the decision time is 14:30 on the same date:
The required condition \(t_{\text{collection}}\leq t_{\text{decision}}\) fails by 40 minutes. Both checks therefore fail, and the record must not be used in the calculation. The diagnostic should state the patient-identifier mismatch and that the collection time is later than the decision time. It should not select a different patient’s record or reinterpret the timestamp without an authorized correction.
Designing the Validation Gate
A reliable implementation checks each input against the same versioned contract and records which checks ran and their outcomes. The check sequence can be organized so later checks do not operate on uninterpretable data: first parse fields and units, then convert to canonical units, then apply numeric bounds, then verify timestamps and identities across records. If parsing fails, do not attempt a numeric range comparison on the unparsed value.
Check that each required field is present and has an accepted representation. Mark missing and malformed values distinctly.
Confirm explicit units and convert through approved rules to canonical units. If the unit is absent or ambiguous, stop that field’s validation.
Check configured ranges, timestamp formats and ordering, and patient and encounter matches.
Run the dose calculation only if every required check passes. Otherwise withhold it and return actionable failure reasons.
This sequence does not mean every failure has the same cause or remedy. A missing field may require data entry; an unknown unit may require source-system clarification; and a mismatched identity may require correction of the record linkage. Give the user enough information to locate and correct the problem, while avoiding unnecessary disclosure of sensitive information in logs or alerts.
Testing should include ordinary valid records as well as boundary cases: each permitted endpoint, just-beyond-boundary values, blank fields, malformed numbers, unsupported units, timestamps with missing or conflicting time zones, events in the wrong order, and mismatched patient or encounter identifiers. For a range \([L,U]\), for example, test \(L\), \(U\), a value below \(L\), and a value above \(U\). This confirms whether the implementation matches the written rule rather than an accidental programming convention.
Failure Modes, Alternatives, and Limits
The common mistake is to treat validation as a warning layer: “The weight looks unusual, but the system can calculate and someone can review the result.” That reverses the purpose of a required pre-calculation gate. If a required input fails its contract, the calculation has not established that it used the intended data. The correction is to block calculation for required failures and give a specific reason. A warning is appropriate only for a condition that the contract explicitly defines as non-blocking.
Another failure is silent repair: interpreting an unlabelled number as the most likely unit, filling a blank with a prior value, or choosing one of two conflicting records. Such behavior can hide the very data problem validation is intended to expose. Automated conversion is appropriate when the source unit is known and the conversion rule is explicit, as in the pounds-to-kilograms example. Guessing is not conversion.
Compared with a single broad “valid/invalid” check, field-level checks produce more useful diagnostics and make it easier to test each rule. Compared with allowing calculation and relying on a later review, a blocking gate prevents malformed input from generating a recommendation in the first place. However, strict checks can also block legitimate records if the contract is poorly specified or inconsistently implemented across systems. Use version-controlled rules, clear messages, and review of recurring failure patterns to distinguish data-quality problems from defects in the contract.
Input validation has limits. Passing all checks means only that the record meets the specified interface requirements; it does not prove that the values are true, clinically appropriate, or safe for a particular patient. A syntactically valid value may still be implausible or clinically concerning. Those judgments require separate safeguards and clinical review. Keeping these layers distinct makes each one easier to specify, test, and audit.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions.
- A required weight field contains 70, but no unit is provided. The interface expects kilograms. Should the value pass validation? Why?
- A contract permits an age from 18 through 90 years. Does age 90 pass the range check? Does age 91?
- A required laboratory value is absent, but a value from the previous encounter is available. Can the validator silently use it?
- A sample timestamp is 09:00 UTC and the dosing decision is at 08:30 UTC on the same date. The contract requires sample collection no later than the decision. Does the time check pass?
- A laboratory record has the correct encounter identifier but a different patient identifier from the dosing request. Can it be used because the encounter matches?
Solutions. (1) No. Without a known unit, the value is ambiguous and cannot be converted or confirmed to be in the required unit; the system should report the missing unit and block the calculation. (2) Age 90 passes because the stated range includes both endpoints: \(18\leq90\leq90\). Age 91 fails because \(91>90\). (3) No, not unless an explicit authorized rule permits that source and defines how it is selected. Otherwise the required field is missing. (4) No. Both times are in UTC, and \(09{:}00>08{:}30\), so the required ordering fails. (5) No. The patient identifier must match; an encounter match does not resolve a patient mismatch. In each case, the conclusion follows from the stated contract, not from an unrecorded assumption.