CDS Adoption Barriers: Singapore Hospital Monitoring Guide

A peer-reviewed study published this week in PLOS Digital Health examined why primary care clinicians in the US ignore clinical decision support (CDS) alerts for chronic pain management [3]. The findings matter for Singapore hospitals deploying clinical AI: the gap between "system deployed" and "system used" is where governance actually happens. We've seen this pattern across imaging AI, sepsis alerts, and now—according to fresh evidence—opioid stewardship tools.

This post is for hospital CIOs, clinical informatics teams, and AI governance leads in Singapore who need to move beyond deployment checklists to adoption monitoring.

Key takeaways

  • Alert fatigue is measurable: The PLOS study found that CDS use varied significantly by clinician role, EHR workflow integration, and alert design—factors Singapore hospitals can instrument [3]
  • Deployment ≠ adoption: Medicare is now proposing outcome-linked payment models for clinical AI, signaling that regulators expect post-deployment monitoring [12][13]
  • Safety taxonomies help: A new clinician-built benchmark (MedFailBench) categorizes medical AI failures by severity and safety gate type, offering a template for local monitoring [7]
  • MDCalc's quality ratings: A major clinical calculator platform just launched bias and validity scoring for 800+ tools, demonstrating how third-party governance scales [11]
  • Singapore hospitals need adoption metrics: Track who uses the tool, when, and what they do with the output—not just accuracy on held-out test sets

Why do clinicians ignore clinical decision support alerts?

The PLOS Digital Health study on chronic pain CDS identified several factors associated with low adoption [3]:

  • Workflow friction: Alerts that required clinicians to leave their current EHR screen or navigate to a separate module were used less frequently
  • Role mismatch: Nurses and medical assistants had different usage patterns than physicians, suggesting that CDS design often assumes a single user persona
  • Timing: Alerts triggered at the wrong point in the clinical workflow (e.g., during triage rather than prescribing) were dismissed
  • Trust deficits: Clinicians who had previously encountered incorrect or irrelevant alerts were less likely to engage with subsequent recommendations

We've observed similar patterns in Singapore health systems deploying sepsis prediction models and radiology AI. A model with 0.92 AUC that fires alerts during ward rounds—when the clinical team is focused on handover—will be ignored. A discharge risk tool that requires three extra clicks to access the underlying data will be bypassed.

The lesson: adoption is a design problem, not just a machine learning problem. Singapore hospitals that treat CDS deployment as a software release rather than a sociotechnical intervention will see low uptake, alert fatigue, and eventual abandonment.

What does the US payment model shift mean for Singapore?

Medicare's Centers for Medicare and Medicaid Services (CMS) signaled this week that it wants to "build a standardized payment structure for clinical software and AI that factors in their impact on patient outcomes" [13]. This is a significant departure from the current fee-for-service model, where clinical AI is bundled into existing billing codes or paid as a capital expense.

For Singapore hospitals, the implications are:

  1. Outcome monitoring becomes mandatory: If payers (whether government or private insurers) start linking reimbursement to AI performance, hospitals will need continuous monitoring infrastructure—not just pre-deployment validation
  2. Vendor accountability shifts: The proposed CMS framework suggests that AI vendors, not just hospitals, may be responsible for demonstrating ongoing clinical benefit
  3. Adoption metrics matter: A tool that clinicians don't use can't improve outcomes, so adoption rates become a governance metric alongside sensitivity and specificity

Singapore's Ministry of Health has not announced similar payment reforms, but the trajectory is clear: regulators globally are moving from "is the model accurate?" to "does the model improve care?" Our clinical AI services now include post-deployment monitoring frameworks that track both technical performance and clinical adoption.

How should Singapore hospitals measure CDS adoption?

Based on the PLOS study [3], recent safety benchmarks [7], and our deployment experience, we recommend tracking:

### 1. Alert interaction rate by role and shift
- What to measure: Percentage of alerts acknowledged, dismissed, or acted upon, segmented by clinician role (physician, nurse, pharmacist) and time of day
- Why it matters: Low interaction rates signal workflow friction or trust deficits; variation by role suggests the tool wasn't designed for all users
- How to instrument: EHR audit logs, supplemented by quarterly clinician surveys

### 2. Time-to-action for high-severity alerts
- What to measure: Median time from alert firing to clinical action (e.g., ordering a test, adjusting a medication), for alerts flagged as urgent
- Why it matters: A sepsis alert that takes 45 minutes to act on is a workflow failure, not a model failure
- How to instrument: Link alert timestamps to order entry timestamps in the EHR

### 3. Override patterns and documentation quality
- What to measure: When clinicians override or dismiss an alert, do they document why? Are override reasons consistent with clinical guidelines?
- Why it matters: High override rates with poor documentation suggest either model miscalibration or inadequate clinician training
- How to instrument: Structured override reason fields (not free text), reviewed monthly by clinical informatics

4. Failure taxonomy alignment

The MedFailBench preprint [7] proposes a clinician-built failure taxonomy that labels medical AI errors by severity (1–5) and safety gate type:

  • Missed urgent escalation (e.g., sepsis alert fails to fire)
  • Unsafe remote dosing (e.g., medication recommendation ignores renal function)
  • Unsafe discharge reassurance (e.g., chatbot tells patient with chest pain to stay home)
  • Evidence fabrication (e.g., LLM cites nonexistent studies)
  • Unsafe protocol deviation (e.g., imaging AI recommends off-guideline follow-up)

Singapore hospitals should map their CDS failures to this taxonomy (or a locally adapted version) to identify systemic risks. We covered failure taxonomies in a previous post on clinical AI safety monitoring; the MedFailBench framework offers a standardized vocabulary for incident reporting.

What about clinical calculator quality ratings?

MDCalc, a widely used clinical calculator platform, announced this week that it's launching quality ratings for over 800 calculators, assessing bias, validation quality, and clinical utility [11]. This is significant because:

  • Third-party governance scales: Hospitals can't individually audit every risk score and calculator they use; centralized quality ratings reduce duplication
  • Bias assessment is operationalized: MDCalc's ratings include demographic subgroup performance, addressing a key gap in current clinical AI governance
  • Singapore hospitals use these tools: Many of the calculators on MDCalc (e.g., CHADS₂-VASc, MELD score) are embedded in local EHR workflows

We recommend that Singapore clinical informatics teams:

  1. Inventory all calculators and risk scores currently in use (including those hard-coded in EHR order sets)
  2. Cross-reference with MDCalc ratings or equivalent third-party assessments
  3. Flag high-risk, low-validation tools for local re-validation or replacement
  4. Document calculator provenance in the hospital's AI inventory (required under emerging HSA guidance)

This aligns with Singapore's PDPA and HSA compliance requirements for clinical AI, which expect hospitals to maintain an auditable record of all decision support tools.

Why this matters in Singapore

Singapore's healthcare AI ecosystem is maturing rapidly. The Health Sciences Authority (HSA) has clarified its AI-SaMD exemption pathway, and public hospitals are deploying imaging AI, sepsis prediction, and LLM-based documentation tools at scale. But deployment velocity has outpaced governance infrastructure.

The US evidence on CDS adoption [3] and the emerging payment reforms [12][13] suggest that the next phase of clinical AI governance will focus on post-deployment performance and clinical utility—not just pre-deployment validation. Singapore hospitals that build adoption monitoring into their AI governance frameworks now will be better positioned for:

  • Regulatory audits: HSA and MOH are likely to ask for evidence of ongoing monitoring
  • Clinical safety: Low adoption or high override rates are early warning signs of model drift or workflow mismatch
  • Vendor accountability: Contracts with AI vendors should include adoption and outcome metrics, not just technical specifications

We've worked with institutional partners in Singapore to design post-deployment monitoring dashboards that track alert interaction rates, override patterns, and failure taxonomies. These dashboards sit alongside traditional MLOps metrics (data drift, model performance) and feed into quarterly governance reviews. If your hospital is deploying CDS or predictive AI and doesn't yet have adoption monitoring, start a conversation with us.

What to do next

If you're responsible for clinical AI governance at a Singapore hospital:

  1. Audit your current CDS tools: Identify all clinical decision support systems, risk calculators, and AI-enabled alerts currently in production
  2. Instrument adoption metrics: Work with your EHR vendor or IT team to extract alert interaction rates, time-to-action, and override patterns from audit logs
  3. Map failures to a taxonomy: Adopt the MedFailBench framework [7] or a locally adapted version to categorize incidents and near-misses
  4. Benchmark against external quality ratings: Cross-reference your calculators with MDCalc's new quality scores [11] or equivalent third-party assessments
  5. Build adoption into vendor contracts: Require AI vendors to provide adoption dashboards and commit to minimum usage thresholds

FAQ

What's the difference between deployment monitoring and adoption monitoring?

Deployment monitoring tracks whether the AI system is running correctly (uptime, latency, data quality). Adoption monitoring tracks whether clinicians are actually using the system and acting on its recommendations. A model can have perfect technical performance but zero clinical impact if clinicians ignore it.

How do I know if my CDS alert rate is too high?

There's no universal threshold, but warning signs include: (1) override rates above 70%, (2) median time-to-action exceeding clinical guidelines, (3) clinician complaints about alert fatigue, (4) declining interaction rates over time. Compare your metrics to published benchmarks and conduct quarterly clinician surveys.

Should Singapore hospitals wait for HSA guidance on post-deployment monitoring?

No. HSA's AI-SaMD guidance already expects ongoing performance monitoring for regulated devices, and the Singapore Model AI Governance Framework recommends continuous validation. Building monitoring infrastructure now will make future compliance easier and improve clinical safety today.

How does this relate to LLM governance in healthcare?

The same principles apply: deployment ≠ adoption. If you're piloting an LLM for clinical documentation or patient triage, track how often clinicians edit or override the model's output, and map failures to a safety taxonomy. We covered LLM-specific governance in our posts on ambient clinical documentation and RAG evaluation.

Sources

[1] NIST AI Risk Management Framework. National Institute of Standards and Technology. https://www.nist.gov/itl/ai-risk-management-framework

[2] The deployment of ProKnow for cloud-based clinical research in radiotherapy. PLOS Digital Health, 2026-07-17. https://journals.plos.org/digitalhealth/article?id=10.1371/journal.pdig.0001131

[3] Factors associated with chronic pain clinical decision support use in primary care. PLOS Digital Health, 2026-07-16. https://journals.plos.org/digitalhealth/article?id=10.1371/journal.pdig.0001032

[4] MedFailBench: A Clinician-Built Open-Source Benchmark for Medical AI Safety Boundary Inspection. arXiv preprint, 2026-07-16. https://arxiv.org/abs/2607.15166v1

[5] MDCalc is scoring the clinical calculators used by millions of doctors. STAT News, 2026-07-17. https://www.statnews.com/2026/07/17/mdcalc-quality-ratings-clinical-algorithms-for-bias-validity/

[6] Medicare wants to shake up how it pays for clinical AI. STAT News, 2026-07-16. https://www.statnews.com/2026/07/16/medicare-shake-clinical-ai-rpm-payments-health-tech/

[7] CMS signals intent to revamp how it pays for clinical software and AI. STAT News, 2026-07-16. https://www.statnews.com/2026/07/16/cms-to-revamp-payments-for-clinical-software-ai/