Clinical decision support tools are now a routine presence across primary and secondary care settings, embedded in prescribing workflows, flagging abnormal results, suggesting differential diagnoses, and prompting referrals. Yet for all the attention given to whether these tools work, remarkably little attention has been paid to a more basic question: what happens to their output once a clinician has seen it? In most cases, it disappears. An alert fires, a clinician acknowledges it, and the clinical record contains no trace that the interaction ever occurred. This gap between the growing sophistication of clinical decision support and the inconsistency with which its output is captured in the clinical record has real consequences for patient safety, medico-legal accountability, and the ability of health systems to learn from how clinicians actually use these tools.

What clinical decision support output actually looks like in practice

Clinical decision support (CDS) output is not a single type of information. A review published in BMC Medical Informatics and Decision Making identifies several distinct categories of CDS output that clinicians encounter during routine care: differential diagnosis suggestions, drug interaction and contraindication warnings, dosing alerts, risk stratification scores (such as sepsis or deterioration scores), preventive care reminders, and referral or investigation recommendations.

The format of these outputs varies considerably depending on how deeply the CDS tool is integrated into the medical record system. Medical record systems with embedded CDS can deliver alerts directly within prescribing, ordering, or documentation workflows, appearing as interruptive pop-ups, passive banners, embedded order sets, or pre-built templates. Tools that operate outside the medical record system and feed output back via an interface introduce additional complexity, since the output must cross a system boundary before it can be recorded anywhere.

As generative large language models (LLMs) enter medical record environments, the range of CDS output types is expanding further, now including narrative summaries, structured recommendations, and real-time documentation suggestions generated from consultation content. In one systematic review of 196 studies using LLMs with real-world medical record data, clinical decision support accounted for the largest proportion of identified use cases at 62.2 per cent, reflecting its prominence in the reviewed literature.

The three ways practices currently handle decision support documentation

Across primary and secondary care settings, three broad approaches to documenting CDS output can be observed in practice.

Ignoring the output entirely. The alert fires, the clinician reads it, and nothing is recorded. This is the most common outcome for low-priority or frequently recurring alerts. Research on alert fatigue at Vanderbilt University Medical Center found that the distinction between actionable and non-actionable CDS alerts is a critical determinant of whether any output reaches the clinical note. When alerts are perceived as irrelevant or interruptive, dismissal without documentation is the default response.

Informal narrative capture. The clinician incorporates the substance of a CDS recommendation into free-text notes without attributing it to a tool. A note might record that a drug interaction was considered and a dose adjusted, without indicating that a CDS alert prompted the review. This approach preserves some clinical reasoning in the record but creates no retrievable data about CDS engagement, and makes it impossible to audit whether specific tools influenced specific decisions.

Structured or flagged entry. The CDS output is logged as a discrete data point, either automatically by the medical record system when an alert fires, or manually by the clinician as a coded entry. The Merck Manual's overview of medical record-based CDS notes that medical record systems can record when CDS prompts are delivered and whether they were acted upon, which supports measurement of guideline adherence. This capability depends entirely on how the CDS system is configured and whether the medical record system is designed to capture that data.

Each approach has a practical rationale. Ignoring output is often a time-management response to high alert volumes. Narrative capture reflects clinical habit and the primacy of the free-text note in most documentation cultures. Structured entry requires medical record infrastructure that many settings do not yet have.

Why documentation approaches vary between practices

The variation in how CDS output is documented is not arbitrary. It reflects genuine differences across four dimensions: medical record capability, workflow design, clinical culture, and regulatory clarity.

Medical record capability is perhaps the most concrete constraint. A systematic review of randomised controlled trials of medical record-integrated CDS drew a meaningful distinction between CDS systems where both input and output functions are built into the medical record system, and those that operate as external services. Where CDS operates outside the medical record system, its output may never be captured in the clinical record at all. The review explicitly excluded systems that collected data separately from the medical record, highlighting this as a structural documentation gap.

Workflow design determines whether documenting CDS output requires additional steps from the clinician or happens automatically. A JAMIA Open study evaluating CDS tools built on Fast Healthcare Interoperability Resources (FHIR), Clinical Quality Language (CQL), and SNOMED CT across an academic medical centre found significant variation in how accurately CDS recommendations fired across different care settings, with false-positive rates varying between the emergency department and outpatient practices. Where CDS fires inaccurately or inconsistently, clinicians adapt by developing informal workarounds that rarely include formal documentation.

Clinical culture shapes what clinicians consider worth recording. In settings where CDS is perceived as a background check rather than a clinical input, there is little professional norm around documenting its output. A mixed-method case study of CDS adoption across a multisite health system found very low uptake of CDS tools despite educational outreach, reflecting how organisational and cultural factors can suppress engagement with CDS entirely, let alone documentation of its output.

Regulatory clarity is currently limited. No universal standard mandates how CDS output must be documented in the clinical record, and guidance from professional bodies and health systems remains fragmented. A nationwide survey of mobile CDS use found that clinicians' subjective experience of CDS tools in real-world settings varies substantially, a finding consistent with the absence of standardised documentation expectations.

The medico-legal implications of recording — or not recording — decision support prompts

The medico-legal stakes of CDS documentation are significant and not yet fully resolved in most jurisdictions.

The core tension is this: if a CDS tool flagged a clinically important alert and the clinician acted on it, the absence of any record of that alert may make the clinical reasoning appear less thorough than it was. Conversely, if the clinician deviated from the alert's recommendation, the absence of a recorded justification may be difficult to defend if the outcome is later disputed.

Several specific questions arise.

Does undocumented CDS output constitute an incomplete clinical record? There is currently no definitive legal answer to this question in most jurisdictions. The general principle that clinical records should reflect the reasoning behind clinical decisions suggests that where a CDS tool materially influenced a decision, its role should be traceable.

What does the absence of a logged alert mean in a disputed outcome? Research on distributed CDS system failures describes how architectural choices, including clock drift, timing-related data availability problems, and asynchronous processing across partner systems, can cause CDS alerts to fail silently. If an alert that should have fired did not, and no monitoring was in place to detect the failure, the clinical record will show no alert and no response. This creates a documentation gap that may be indistinguishable from a situation where the alert fired and was ignored.

Does documenting the alert create additional liability exposure? This concern is sometimes raised by clinicians. The logic runs that if a CDS alert is recorded and the clinician then deviated from it, the record creates evidence of a departure from a flagged recommendation. In practice, clinical governance experts more commonly identify the opposite risk: the absence of documented reasoning for an override is harder to defend than a recorded clinical justification.

The evidence base here is still developing. The medico-legal implications of AI-assisted decision support documentation have not yet been tested extensively in case law across most European jurisdictions, and the specific obligations on clinicians remain unclear in many settings.

How Medical Device Regulation shapes the documentation question

The regulatory classification of a CDS tool has direct implications for documentation expectations, though the pathway from regulation to clinical record-keeping practice is not always obvious.

Under the EU Medical Device Regulation (MDR), software that meets the threshold for classification as a medical device, broadly software intended for a medical purpose including diagnosis, prevention, monitoring, or treatment, carries specific obligations for manufacturers. These include clinical evaluation, post-market surveillance, and maintenance of a technical file. For CDS tools that qualify as medical devices, manufacturers must demonstrate that their output is clinically valid and that the system performs as intended.

For clinical environments deploying these tools, the MDR classification of a CDS system creates an indirect documentation expectation. If the tool is a regulated medical device, its use in clinical decision-making is part of the patient's care pathway, and the clinical record should reflect that care pathway. This does not translate into a specific mandated documentation format, but it does strengthen the argument that CDS output from a regulated tool should be traceable in the clinical record.

The AHRQ Clinical Decision Support Innovation Collaborative (CDSiC), which completed four years of work in 2024 developing evidence-based, interoperable, and publicly available CDS, identified best practices for using CDS to improve clinical decision-making. Its work on shareable and interoperable CDS is directly relevant here. Interoperability standards such as CDS Hooks and FHIR are designed to support CDS output flowing between systems in a structured, auditable way, which is a prerequisite for consistent documentation.

What structured documentation of clinical decision support would actually require

Moving from informal, inconsistent capture to structured documentation of CDS activity would require changes at both the medical record and workflow level. The components of a structured approach include:

• Discrete data fields within the medical record system to record that a CDS alert fired, what it recommended, and when

• Attribution metadata identifying which tool generated the output, which version was running, and what the specific recommendation was

• A record of the clinician response, whether the recommendation was accepted, modified, or overridden

• A justification field for overrides, capturing the clinical reasoning that led the clinician to deviate from the suggestion

• An audit trail linking the CDS output to the specific encounter and patient record

Medical record-integrated CDS systems that use pre-built evidence-based templates and embedded care pathways can automate some of this capture, but only where the CDS is sufficiently integrated with the medical record system to generate structured data rather than unstructured alerts.

The workflow cost of this approach should not be underestimated. Research on AI implementation in hospital medicine found that poorly implemented digital tools increase clinician workload and burnout, even when their intended purpose is to reduce burden. Adding mandatory documentation fields for CDS output without simplifying the surrounding workflow risks creating exactly this outcome. The same paper emphasises that AI tools must be embedded into clinical reasoning processes through intentional workflow design, a principle that applies directly to documentation.

A qualitative evaluation of an AI-enabled CDS system for surgical blood ordering found that clinicians anticipated increased verification burden as a concern. This reflects a broader pattern in which structured documentation requirements are experienced as additional tasks rather than workflow improvements, unless the interface design actively supports them.

The override problem: when clinicians deviate from decision support recommendations

Clinicians routinely and appropriately override CDS alerts. Research on drug safety alert overrides in computerised physician order entry systems found that a substantial proportion of overrides are clinically justified. The alert fired correctly, but the clinician had patient-specific reasons to proceed regardless. The problem is not that overrides occur. It is that the reasoning behind them is almost never recorded.

A qualitative study of alert fatigue involving junior doctors across Australian hospitals found that alert fatigue operates on a continuum, influenced by alert design, institutional norms, information overload, and individual clinician characteristics including prior experience with specific alerts.

This matters because the override record is arguably the most clinically and medico-legally significant piece of CDS documentation. A clinician who accepts a CDS recommendation and acts on it has had their decision supported. A clinician who overrides a recommendation is exercising independent clinical judgement, and that judgement, if it later proves to have been incorrect, is what will be scrutinised. The absence of a recorded override rationale means that the clinical record shows only the decision, not the reasoning.

Analysis of override behaviour at Vanderbilt used GPT-4 to summarise free-text override comments left by clinicians, finding that where comments were captured at all, they revealed clinically coherent reasoning that could inform CDS optimisation. Comment capture is inconsistent and often optional, meaning the most valuable documentation is the least reliably obtained.

What good practice looks like now, before standards catch up

No universal standard yet governs how CDS output should be documented in the clinical record. In the absence of such a standard, a set of practical questions can help practices assess and improve their current approach.

Questions for individual clinicians:

• When a CDS alert influences a clinical decision, is that influence traceable in the note?

• When a CDS recommendation is overridden, is the reasoning for that override recorded?

• Is there a distinction in documentation practice between alerts from regulated medical devices and those from unregulated tools?

Questions for practice leads and clinical governance:

• Does the medical record system capture which CDS alerts fired during an encounter, and whether they were acted upon?

• Is there a consistent approach across the practice to documenting CDS output, or does it vary by clinician?

• If a patient outcome were disputed, could the practice demonstrate what CDS tools were in use, what they recommended, and how clinicians responded?

• Are CDS tools that qualify as medical devices under MDR identified as such, and is their use documented accordingly?

Structural considerations:

• CDS tools that are deeply integrated into the medical record system are more likely to generate auditable documentation than those operating as external services.

• Override comment fields, even when optional, create an opportunity to capture clinical reasoning that would otherwise be lost.

• Distributed CDS architectures introduce failure modes, including silent alert suppression, that require active monitoring to detect. Documentation gaps may reflect system failures rather than clinician behaviour.

Current practice in most settings falls well short of what structured CDS documentation would require. The gap between the sophistication of the tools being deployed and the consistency with which their output is recorded represents a genuine patient safety and governance risk, one that is likely to attract increasing regulatory and professional attention as AI-assisted clinical decision support becomes more prevalent and more consequential.

Frequently asked questions

▶ What types of output do clinical decision support tools produce?

Clinical decision support tools produce several distinct types of output during routine care. These include differential diagnosis suggestions, drug interaction and contraindication warnings, dosing alerts, risk stratification scores, preventive care reminders, and referral or investigation recommendations. As large language models enter medical record environments, the range is expanding to include narrative summaries, structured recommendations, and real-time documentation suggestions generated from consultation content.

▶ How do clinicians currently document clinical decision support output?

Three broad approaches are observed in practice. The first is ignoring the output entirely, which is the most common response to low-priority or frequently recurring alerts. The second is informal narrative capture, where the clinician incorporates the substance of a recommendation into free-text notes without attributing it to a tool. The third is structured or flagged entry, where the output is logged as a discrete data point, either automatically by the medical record system or manually by the clinician. Most settings rely on the first two approaches.

▶ Why does documentation of clinical decision support output vary so much between practices?

The variation reflects genuine differences across four dimensions. Medical record capability determines whether the system can capture structured CDS data at all. Workflow design determines whether documentation requires additional steps from the clinician or happens automatically. Clinical culture shapes what clinicians consider worth recording. Regulatory clarity is currently limited, with no universal standard mandating how CDS output must be documented in the clinical record.

▶ What are the medico-legal risks of not documenting clinical decision support alerts?

If a clinical decision support tool flagged an important alert and the clinician acted on it, the absence of any record may make the clinical reasoning appear less thorough than it was. If the clinician deviated from the alert's recommendation without recording a justification, that deviation may be difficult to defend if the outcome is later disputed. Clinical governance experts more commonly identify the absence of documented reasoning as the greater risk, rather than the act of recording the alert itself.

▶ Can a clinical decision support alert fail silently without the clinician knowing?

Yes. Research on distributed clinical decision support system failures describes how architectural choices, including clock drift, timing-related data availability problems, and asynchronous processing across partner systems, can cause alerts to fail silently. If an alert that should have fired did not, and no monitoring was in place to detect the failure, the clinical record will show no alert and no response. This creates a documentation gap that may be indistinguishable from a situation where the alert fired and was ignored.

▶ How does EU Medical Device Regulation affect clinical decision support documentation?

Under the EU Medical Device Regulation, software intended for a medical purpose, including diagnosis, prevention, monitoring, or treatment, may qualify as a medical device. Where a clinical decision support tool carries this classification, its use in clinical decision-making forms part of the patient's care pathway. This strengthens the argument that output from a regulated tool should be traceable in the clinical record, though no specific mandated documentation format currently exists.

▶ What would structured documentation of clinical decision support activity actually require?

Structured documentation would require discrete data fields within the medical record system to record that an alert fired, what it recommended, and when. It would also require attribution metadata identifying the tool and version, a record of the clinician's response, a justification field for overrides, and an audit trail linking the output to the specific encounter and patient record. Medical record-integrated clinical decision support systems can automate some of this capture, but only where the tool is sufficiently integrated to generate structured data rather than unstructured alerts.

▶ Why is documenting clinical decision support overrides particularly important?

The override record is arguably the most clinically and medico-legally significant piece of clinical decision support documentation. A clinician who overrides a recommendation is exercising independent clinical judgement, and that judgement is what will be scrutinised if the outcome is later disputed. Research using GPT-4 to analyse free-text override comments found that where comments were captured, they revealed clinically coherent reasoning that could also inform future tool optimisation. Comment capture is currently inconsistent and often optional.

▶ Does adding structured documentation requirements increase clinician workload?

It can. Research on AI implementation in hospital medicine found that poorly implemented digital tools increase clinician workload and burnout, even when their intended purpose is to reduce burden. A qualitative evaluation of an AI-enabled clinical decision support system for surgical blood ordering found that clinicians anticipated increased verification burden as a concern. Adding mandatory documentation fields without simplifying the surrounding workflow risks creating exactly this outcome.

▶ What practical steps can practices take now to improve clinical decision support documentation?

Practices can start by checking whether the medical record system captures which alerts fired during an encounter and whether they were acted upon. Clinical decision support tools that are deeply integrated into the medical record system are more likely to generate auditable documentation than those operating as external services. Override comment fields, even when optional, create an opportunity to capture clinical reasoning that would otherwise be lost. Practices should also identify which tools qualify as medical devices under the EU Medical Device Regulation and document their use accordingly.