$188 Billion in AI Healthcare Spending — and Most of It Sits Unused
Sixty-two percent of digital health venture funding now flows into AI. The global AI-in-healthcare market is projected to reach $188 billion by 2030. Every conference stage is occupied by someone demoing a new clinical AI model — predicting sepsis, flagging drug interactions, identifying radiological findings faster than any human could.
And yet, the adoption numbers tell a different story.
Most clinical AI products sit unused. Not because they don't work. Not because hospitals didn't buy them. But because clinicians won't open another app.
This is the fundamental mistake that AI health companies keep making: they build standalone dashboards. Beautiful, data-rich, technically impressive dashboards — that nobody uses. The real path into the hospital isn't through a new screen. It's through the screen clinicians are already looking at. AI must be embedded at the point of decision, not parked in a separate tab.
That path has a name: CDS Hooks.
The Dashboard Graveyard
Walk through any mid-size hospital's IT department and ask about their clinical AI tools. You'll hear the same pattern repeated: enthusiastic pilot, promising early results, executive buy-in, deployment — and then a slow fade to irrelevance.
The reasons are structural, not motivational:
- Workflow disruption: Clinicians context-switch over 70 times per hour. Asking them to leave their EHR, open a browser, navigate to a dashboard, and interpret AI output is asking them to add context switch number 71. They won't do it.
- Login fatigue: Yet another username and password. Another SSO flow. Another MFA prompt. In a 12-hour shift, the last thing a nurse or physician wants is one more authentication wall between them and patient care.
- Alert blindness: Clinicians already suffer from notification overload. The average EHR generates hundreds of alerts per provider per day. Adding a separate dashboard with its own alerts doesn't solve the signal-to-noise problem — it makes it worse.
- No EHR integration: Standalone dashboards often require manual data re-entry or, at best, a delayed batch sync. The AI recommendations arrive minutes or hours after the clinical decision has already been made.
The result? Over 90% of standalone clinical AI dashboards see less than 10% clinician adoption after six months. The technology works. The workflow doesn't.
This isn't a training problem. It isn't a change management problem. It's an architecture problem. And it has an architectural solution.
What CDS Hooks Actually Is
CDS Hooks is an HL7 specification for embedding clinical decision support directly into the EHR workflow. Not alongside it. Not linked from it. Inside it.
The core idea is event-driven clinical decision support:
- The EHR fires a hook at specific clinical decision points — when a chart is opened, when a medication is ordered, when a prescription is signed.
- Your service receives context — patient ID, the medication being ordered, relevant FHIR resources — as a standard HTTP POST.
- Your AI runs inference and returns structured response cards that appear inline in the EHR interface.
- The clinician sees the recommendation without leaving their workflow. No app switching. No separate login. No extra tab.
This is the difference between AI that clinicians could use and AI that clinicians do use. CDS Hooks eliminates every adoption barrier that kills standalone dashboards: no context switch, no login, no notification channel to monitor, no data re-entry.
The Hook Points That Matter for AI
CDS Hooks defines several standard hook events. Each one represents a moment in the clinical workflow where AI can add value — if it shows up at the right time:
patient-view
Fires when a clinician opens a patient's chart. This is your opportunity to surface AI risk scores, care gaps, and proactive recommendations before the clinician even begins their assessment. Example use cases: 30-day readmission risk, chronic disease progression alerts, overdue screenings or vaccinations.
order-select
Fires when a clinician selects a medication or procedure to order. This is the moment for drug interaction checks, formulary alternatives, and AI-powered dosing suggestions. Your model has access to the patient's current medications, allergies, lab results, and the proposed order — everything needed for intelligent recommendations.
order-sign
Fires when the clinician is about to sign and finalize an order. This is the final safety checkpoint: prior authorization prediction, duplicate order detection, contraindication warnings. It's the last moment to prevent an error before it enters the medical record.
encounter-discharge
Fires when a patient is being discharged. Perfect for AI-powered follow-up recommendations, readmission risk scoring, medication reconciliation alerts, and care transition checklists. This hook point is critically underused — discharge is where most care coordination failures happen.
Each of these hooks represents a decision point where clinicians are already pausing to think. CDS Hooks puts your AI into that pause, not into a separate workflow they need to remember to check.
How It Works Technically
The CDS Hooks specification is refreshingly simple. It's REST-based, uses FHIR for clinical data, and can be implemented as a lightweight HTTP service.
Step 1: Discovery
Your service exposes a /cds-services endpoint that tells the EHR what hooks you support:
GET /cds-services
{
"services": [
{
"hook": "patient-view",
"title": "AI Readmission Risk",
"description": "Predicts 30-day readmission risk using ML model",
"id": "readmission-risk",
"prefetch": {
"patient": "Patient/{{context.patientId}}",
"conditions": "Condition?patient={{context.patientId}}",
"encounters": "Encounter?patient={{context.patientId}}&_count=10&_sort=-date"
}
}
]
}Step 2: Hook Invocation
When the hook event fires, the EHR sends an HTTP POST to your service with the clinical context and any prefetched FHIR data. Your AI model runs inference on this data.
Step 3: Return Cards
Your service responds with Cards — structured UI elements that the EHR renders inline. Cards can be informational, warnings, or actionable suggestions:
{
"cards": [
{
"uuid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"summary": "High Readmission Risk: 78%",
"detail": "This patient has a 78% predicted probability of 30-day readmission based on 3 prior admissions in 90 days, active CHF diagnosis, and recent medication non-adherence.",
"indicator": "warning",
"source": {
"label": "AI Readmission Model v2.1",
"url": "https://your-ai-service.com/docs"
},
"suggestions": [
{
"label": "Order post-discharge follow-up within 48 hours",
"uuid": "suggestion-1"
}
],
"links": [
{
"label": "View Full Risk Analysis",
"url": "https://your-smart-app.com/launch",
"type": "smart"
}
]
}
]
}Prefetch vs. Live FHIR Query
The prefetch field in your discovery response tells the EHR which FHIR resources to include in the hook invocation. This is the preferred approach — the EHR sends the data you need, eliminating a round-trip. For more complex queries or when the prefetch data isn't sufficient, your service can make its own FHIR API calls using the fhirServer and fhirAuthorization provided in the hook request. The tradeoff: prefetch is faster but limited to what you can express in a FHIR query template; live queries are flexible but add latency.
CDS Hooks + SMART on FHIR = The Extensible EHR
Here's where the architecture becomes truly powerful. CDS Hooks handles the quick inline decision — a risk score, a warning, a suggestion that takes two seconds to read. But what happens when the clinician wants to dig deeper?
Notice the "type": "smart" link in the card response above. That link launches a SMART on FHIR application directly inside the EHR — typically as an embedded iframe. The clinician clicks "View Full Risk Analysis" and gets a rich, interactive AI-powered experience without ever leaving their EHR session.
This is the best of both worlds:
- CDS Hooks for zero-friction, inline decision support — the AI equivalent of a Post-it note on the chart.
- SMART on FHIR for deep, interactive AI capabilities — the full dashboard experience, but embedded inside the EHR, with single sign-on, shared context, and no workflow disruption.
Together, they form the extensible EHR platform. The EHR provides the workflow chassis. Your AI provides the intelligence. Neither needs to replace the other.
A clinician opens a chart, sees a CDS Hooks card warning about high sepsis risk, clicks through to your SMART app for a detailed breakdown of contributing factors, adjusts the treatment plan, and returns to the EHR — all without opening a new browser, entering credentials, or losing context. That's the experience that drives adoption.
The Business Case: Hospitals Buy Integration, Not Replacement
If the clinical argument isn't enough, consider the commercial reality.
Hospitals don't buy AI that replaces their EHR. They buy AI that integrates with their EHR. The EHR is the center of gravity for every clinical workflow, every billing process, every compliance requirement. It's not going anywhere.
The major EHR marketplaces — Epic App Orchard, Oracle Health (Cerner) Marketplace, MEDITECH Greenfield — are all built on SMART on FHIR and CDS Hooks. These aren't optional nice-to-haves. They are the required integration protocols for listing your application.
- Epic requires SMART on FHIR for App Orchard listing. CDS Hooks integration is available for clinical decision support use cases.
- Oracle Health supports CDS Hooks natively and promotes SMART apps as the standard extensibility model.
- The ONC Cures Act mandates standardized API access using FHIR — the same foundation that CDS Hooks builds on.
If your AI product doesn't speak these protocols, you face a stark reality: you cannot sell to hospitals at scale. You'll be stuck in one-off integrations, custom HL7v2 interfaces, and integration projects that take 12–18 months per health system. Your competitors who built on CDS Hooks will deploy in days.
This isn't a technology choice. It's a go-to-market strategy.
How to Build Your First CDS Hook
The barrier to entry is lower than you think. A basic CDS Hooks service can be built in a weekend with a Python or Node.js backend. Here's the practical roadmap:
1. Implement the Discovery Endpoint
Create a GET /cds-services endpoint that returns your service catalog. Define which hooks you support, what data you need prefetched, and a human-readable description of your service.
2. Handle Hook Invocations
Create a POST /cds-services/{service-id} endpoint. Parse the incoming FHIR context — patient demographics, conditions, medications, the specific order being placed. This is standard FHIR resource parsing.
3. Run Your Inference
Pass the clinical data to your AI model. This is your existing ML pipeline — nothing changes here. Whether you're running a scikit-learn model, a TensorFlow serving endpoint, or calling an LLM API, the inference step is independent of CDS Hooks.
4. Return Cards
Format your model's output as CDS Hooks cards with appropriate indicators (info, warning, critical), actionable suggestions, and optionally a SMART app link for deeper interaction.
5. Test with the CDS Hooks Sandbox
The CDS Hooks Sandbox provides a simulated EHR environment where you can register your service and test hook invocations without needing a real EHR. It's the fastest way to validate your implementation.
The entire integration surface is two HTTP endpoints. If you've built a REST API before, you can build a CDS Hooks service. The hard part isn't the integration protocol — it's building an AI model worth integrating.
The Bottom Line
The healthcare AI industry has a distribution problem, not a technology problem. Models are getting better every quarter. What isn't getting better is adoption — because the industry keeps building dashboards that clinicians won't use.
CDS Hooks solves the distribution problem by eliminating the adoption barriers entirely. No new app. No separate login. No workflow disruption. Your AI shows up exactly where and when the clinician needs it — inside the EHR, at the point of decision.
If you're building healthcare AI and you're not building on CDS Hooks, you're building a demo, not a product. The hospitals that are actually deploying AI at scale — not piloting it, not evaluating it, but using it in production — are doing it through embedded decision support, not standalone dashboards.
The dashboard era in clinical AI is over. The embedded era has begun. The only question is whether your product will be part of it.
Building interoperable healthcare systems is complex. Our Healthcare Interoperability Solutions team has deep experience shipping production integrations. We also offer specialized Healthcare Software Product Development services. Talk to our team to get started.