Why Reconstructability Matters
When a dosing recommendation is questioned, the useful question is not simply, “What does the current system recommend for this patient?” It is, “What information and software produced the recommendation at that time, what did the clinician see, and what actions followed?” A current rerun may use corrected laboratory values, a newer model, or different software. It can therefore answer a different question from the one raised by the historical recommendation.
An audit trail is a linked record of relevant events and the information needed to interpret them. For model-informed dosing, it should support reconstruction of both the computational result and the clinical interaction: which patient-data values were used, which model and software executed, what recommendation was returned and displayed, and what the user did next. It is not enough to keep a screenshot or a final dose without the context that gives it meaning.
The record should describe what happened, not infer what must have happened from the current state of the system. In particular, a later corrected value should not silently replace the value used in an earlier run. The earlier value may have been wrong or outdated, but it is still part of the evidence needed to understand that run.
What Must Be Captured
A practical record is built around a unique run identifier and links to related events. For each run, capture the following categories in a form that can be interpreted later.
- Patient and encounter references. Use stable identifiers that link the run to the appropriate patient and clinical encounter. The record should make clear which encounter or treatment episode the recommendation concerned; a patient identifier alone may not distinguish separate dosing decisions.
- Data provenance and values. Identify each source system or record, the relevant observation or order identifier, the value and unit used, and its clinical time. Also capture the time the value entered or was retrieved by the dosing service. A reference to a mutable EHR field alone is insufficient if its historical value cannot be recovered.
- Processed inputs. Record the values actually passed to the model, including units, transformations, and any derived covariates. If a source value is converted, normalized, or excluded, preserve enough detail to explain that operation. The raw source value and the processed value may both be needed.
- Execution identity. Record the model identifier and version, the software/service version, and relevant configuration or parameter-set identifiers. Include execution status and a run or request identifier. If results can depend on a random seed or external service, capture the relevant execution detail when applicable.
- Outputs. Preserve the model result and the recommendation returned by the service, with units, intervals or uncertainty summaries when shown, and any warnings or eligibility messages. Capture what the interface displayed, because the displayed recommendation may be rounded, formatted, or accompanied by information not present in a back-end response.
- User actions. Link the run to events such as opening or viewing the recommendation, accepting it, modifying it, declining it, or requesting another run. Record the actor, the action, the action time, and any entered reason or resulting order when those are part of the workflow.
- Time and event linkage. Record timestamps with a defined time basis, preferably a consistent machine-readable time such as UTC, and retain the source time zone or offset where needed for clinical interpretation. Link events by identifiers rather than relying only on patient and approximate time.
“Capture everything” is not a workable design goal. The goal is to capture the minimum sufficient evidence for a reviewer to answer: which data state was used, which computation ran, what result was returned and shown, and what happened afterward? If a field is omitted, its omission should not make one of those questions unanswerable.
Why the Record Must Preserve the Historical State
The basic reconstruction problem can be expressed as a function. Let \(X\) denote the processed patient inputs, \(M\) the model and parameter set, and \(S\) the software and configuration that execute the calculation. The returned result can be represented as \(R=f(X,M,S)\). A historical result can be reproduced from this representation only if the record identifies the relevant versions and preserves the actual \(X\) used.
This gives a short justification for the core audit fields. If the data later change from \(X_{\mathrm{historical}}\) to \(X_{\mathrm{current}}\), then a current rerun computes \(f(X_{\mathrm{current}},M_{\mathrm{current}},S_{\mathrm{current}})\), which need not equal the historical result. Even if the patient inputs are unchanged, replacing the model or software can change the result. Therefore, a record containing only a patient identifier and a displayed dose does not generally identify the calculation that produced it.
The function notation is an organizing device, not a claim that every service is deterministic. If identical recorded inputs and versions can produce different outputs because of randomness, timing, or an external dependency, the record must capture the additional factor or preserve the exact returned output. In all cases, storing the output is important: it documents what the service actually returned, even if later reproduction is imperfect.
Assign a unique run identifier and link it to the patient, encounter, request, and initiating user or process.
Store recoverable source references and the actual values and units supplied to the calculation, including relevant transformations.
Record model, software, and configuration versions, along with execution status and any additional execution details needed to interpret the result.
Store the returned outputs and the recommendation as displayed, including units, warnings, and rounding where applicable.
Record who viewed, accepted, modified, or declined the recommendation and when, preserving the connection to the run.
Worked Example: Recording a Recommendation Run
Consider a hypothetical dosing service. At 10:14 UTC on 12 May, a clinician requests a recommendation for patient P-204 during encounter E-77. The service uses a trough concentration of 8.2 mg/L collected at 08:00 UTC, a current regimen of 100 mg every 24 hours, and a target concentration range of 9–11 mg/L. It returns a proposed regimen of 125 mg every 24 hours. These values are illustrative and do not describe a real patient or drug.
A useful run record would link the request to run R-5508, patient P-204, and encounter E-77. For the concentration, it would identify the source observation, collection time, retrieval time, value, and unit. For the regimen, it would identify the relevant medication-order version and preserve the dose and interval as processed. The record would identify the model version, such as “PK model 2.4,” the dosing-service version, such as “service 1.8.1,” and the applicable configuration identifier.
It would then preserve the returned recommendation—125 mg every 24 hours—and the displayed target range, units, and any warning text. If the clinician viewed the result at 10:15 UTC and accepted it at 10:17 UTC, those would be separate linked user-action events, not an inferred status attached only to the final order. The record can now answer both what the service recommended and whether the clinician accepted it.
The essential check is not whether every item appears in one database row. The check is whether the identifiers and captured values let a reviewer follow the run from source data to processed input, execution, displayed output, and user action without guessing.
Time, Event Order, and User Actions
Timestamps are meaningful only when their roles are clear. A laboratory result may have a clinical time (when the sample was collected), a record time (when the result entered the source system), and a service time (when the dosing service retrieved it). The recommendation has its own request, execution, response, and display times. A clinician action has an event time as well. Collapsing these into a single “date” can conceal whether a result was available when the recommendation was generated.
Record enough timestamps to distinguish these events, and document the time basis. If systems record local time, retain the time-zone offset or an unambiguous conversion. If events arrive late or are transmitted out of order, keep both the event time and the time the receiving system recorded the event. The audit record should not imply that the order of database arrival is necessarily the order in which clinical events occurred.
User actions are not interchangeable. “Recommendation generated,” “recommendation displayed,” and “recommendation accepted” describe distinct events. A modified regimen should be stored as a separate action or resulting order linked to the recommendation, not as an overwrite of the original model output. This preserves the distinction between the model’s proposal and the clinician’s decision.
Worked Example: Resolving a Data-Availability Question
In a hypothetical case, a recommendation run begins at 14:05 UTC. A renal-function result has a specimen time of 13:40 UTC, a source-system posting time of 14:08 UTC, and a dosing-service retrieval time of 14:10 UTC. The audit record for run R-8130 shows that the service used the prior available value of 72 mL/min, retrieved at 14:04 UTC. The newer result is 60 mL/min.
The timestamps show that the 60 mL/min result existed as a specimen measurement before the run, but was not posted to the source system until after the run began and was not retrieved until 14:10 UTC. The recorded input for R-8130 was therefore 72 mL/min. A later rerun using 60 mL/min may be appropriate for a new decision, but it does not establish that the earlier run used that value.
Without distinct clinical, posting, retrieval, and execution times, a reviewer might mistakenly conclude that the service ignored a value that was already available to it. The record does not decide whether the workflow was clinically appropriate; it establishes the facts needed to assess that question.
Reconstructing a Discrepant Recommendation
When a reported recommendation differs from a later rerun, compare the historical record in a fixed sequence. First verify that the patient and encounter are the same. Then compare source-data references and the actual processed inputs, including units, missing-value handling, and transformations. Next compare model, software, and configuration identifiers. Finally, compare the returned output with the displayed output and review the user-action events. This sequence helps distinguish a different input state from a different execution or a difference in presentation.
A simple data table can make the audit question explicit. “What is in the chart now?” is not equivalent to “What was used then?” The latter requires historical references or captured values.
| Audit question | Evidence to inspect | What an incomplete record may leave unknown |
|---|---|---|
| Which patient and decision? | Patient, encounter, and run identifiers | Whether records from separate decisions were mixed |
| Which data were used? | Source references, captured values, units, and retrieval times | Whether the run used an old, corrected, or transformed value |
| Which computation ran? | Model, software, and configuration identifiers | Whether a later rerun used a different execution |
| What did the service show? | Returned and displayed output, warnings, and units | Whether display formatting changed the apparent result |
| What happened next? | Linked user actions and resulting order | Whether the recommendation was viewed, accepted, or changed |
Worked Example: Distinguishing a Model Output From a Clinical Decision
In a hypothetical record, run R-9201 returns a recommendation of 125 mg every 24 hours at 09:02 UTC. The clinician views it at 09:04 UTC, changes the proposed regimen to 100 mg every 24 hours at 09:06 UTC, and signs the resulting order at 09:08 UTC. The order is later described in a note as “the dosing-service recommendation.”
The audit trail should preserve three distinct facts: the service returned 125 mg every 24 hours; the clinician modified the proposal to 100 mg every 24 hours; and the signed order was 100 mg every 24 hours. The actions should be linked to R-9201 and associated with their times and actor. If the modification reason was recorded, it can be linked as well, but the audit record should not invent a reason from the dose difference.
A log containing only the signed order would incorrectly make it appear that the service produced 100 mg every 24 hours. A log containing only the model output would fail to explain what was actually ordered. Linking the recommendation, modification, and signed order allows the history to be reconstructed without conflating model output with clinical judgment.
Common Failure Modes and Alternatives
- Mutable references without historical values. A link to “latest serum concentration” may return a corrected value months later. Preserve the historical observation identifier and the value used, or ensure the referenced source can return its historical version.
- Version labels that are too broad. Recording only a product name does not identify the model or software execution precisely enough. Capture the specific model and service versions and relevant configuration identifiers.
- Only the final dose is retained. This omits units, target information, uncertainty, warnings, and the distinction between returned and displayed output. Preserve the clinically relevant output payload and presentation.
- Actions are overwritten. Replacing an accepted recommendation with a modified dose erases the sequence. Record separate, linked events so the initial proposal and subsequent decision remain distinguishable.
- Timestamps lack a defined basis. Local clock times without a time zone, or one timestamp used for several different events, can make event order ambiguous. Record event type and a consistent time basis.
- Records cannot be joined reliably. Matching by patient and approximate time alone can associate the wrong request or encounter. Use unique run and event identifiers with explicit links.
A screenshot is useful evidence of presentation, but it usually cannot identify the exact inputs, execution version, or user-action sequence. A conventional application log may record requests and errors but omit the data values or displayed result. Conversely, a complete numerical output without event history does not show whether a clinician saw or acted on it. These approaches can complement one another; none substitutes for a linked record that covers the full recommendation lifecycle.
Reconstruction also has limits. A record can show what was captured and executed, but it cannot recover an input that was never logged, prove that a source value was clinically correct, or establish why a user acted unless that reason was recorded. If an external dependency or non-deterministic calculation prevents exact rerunning, the stored returned output and execution context remain essential evidence. Good audit design makes these limitations visible rather than presenting an uncertain reconstruction as exact.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions below.
- A chart now shows a corrected laboratory value. What evidence is needed to determine which value a past recommendation used?
- Why should a recommendation output, a clinician’s modified dose, and the signed order be recorded as distinct linked facts?
- A service log records a patient ID, a dose, and a timestamp, but no model version or input values. What important reconstruction questions remain unanswered?
- A sample was collected before a recommendation but posted to the source system afterward. Which timestamps help determine whether the dosing service could have used it?
- Why is a screenshot alone usually insufficient to reconstruct a recommendation?
Solutions. (1) The historical observation reference or captured value used by the run, its unit, and its retrieval time are needed; the current chart value alone does not establish the earlier input. (2) They identify the model’s proposal separately from the clinician’s decision and the resulting order, preventing one from being misattributed to another. (3) The actual processed inputs, source-data state, model and software execution, and possibly the connection between the dose and the displayed output remain unknown. (4) Record the sample’s clinical time, source posting time, service retrieval time, and recommendation execution time. (5) A screenshot may show presentation, but ordinarily does not establish the exact data values, transformations, model and software versions, or subsequent user actions.