Clinical decision support has been around for decades, but getting it to fire at the right moment, inside the clinician's actual workflow, has always been the hard part. That's exactly the problem CDS Hooks solves. If you're asking what is CDS Hooks, the short answer: it's an HL7 specification that lets external services deliver real-time, context-aware recommendations directly within an EHR session, triggered by specific actions a clinician takes.

CDS Hooks builds on top of SMART on FHIR, the same standard that powers secure app-to-EHR connections. Instead of requiring clinicians to leave their EHR and open a separate tool, CDS Hooks brings decision support to them, as cards that appear right when they're ordering a medication, opening a patient chart, or scheduling a procedure. It's a hook-based architecture, meaning the EHR calls out to your service at predefined workflow events, and your service responds with actionable suggestions.

For teams building healthcare applications that connect to EHRs, understanding CDS Hooks matters because it represents the next layer of integration beyond data access. At SoFaaS™ (SMART on FHIR as a Service), we help healthcare innovators handle the complexity of EHR integration so they can focus on building exactly these kinds of capabilities. This article breaks down how CDS Hooks works, what its core components are, and where it fits within the broader FHIR ecosystem.

What CDS Hooks is and who uses it

CDS Hooks is an HL7-published open specification that defines how EHR systems and external clinical decision support services communicate in real time. When you ask "what is CDS Hooks," the practical answer is that it's a web-based API standard that lets an EHR send a request to an external service at specific clinical moments, then receive back structured recommendations the clinician can act on without leaving their workflow.

CDS Hooks turns passive decision support tools into active participants in the clinical encounter, firing only when the context demands it.

The HL7 standard behind it

HL7 formally published the CDS Hooks specification as a companion to SMART on FHIR and FHIR R4. The spec defines how a hook payload is structured, including the patient context, the user's current action, and any relevant FHIR resources. Because it's an open standard, any EHR that adopts it and any service that implements it can interoperate without custom builds on either side. This is what makes CDS Hooks practically significant for teams that need to reach clinicians across multiple EHR environments.

The specification is publicly available through HL7, so your development team can review the exact payload format, hook definitions, and response structure before writing a single line of code. This transparency makes planning and scoping your integration significantly more predictable.

Who uses CDS Hooks today

Healthcare technology teams building clinical decision support tools are the primary users: think chronic disease management alerts, drug interaction checks, care gap notifications, and order set suggestions. EHR vendors like Epic and Cerner have implemented the specification, meaning your service can surface recommendations inside those platforms once you follow the protocol correctly.

Payers, health IT vendors, and digital health startups all use CDS Hooks to deliver timely guidance to clinicians without requiring EHR-side custom development. If your application needs to influence clinical behavior at the point of care, CDS Hooks is the mechanism that makes that possible at scale.

How CDS Hooks works in an EHR workflow

The interaction follows a request-response pattern. When a clinician performs a specific action inside the EHR, such as opening a patient record or placing an order, the EHR fires a pre-configured hook and sends a structured JSON payload to your external CDS service. Your service processes that payload and returns a set of cards, which the EHR renders directly inside the clinician's view.

The request-response cycle

Your CDS service sits outside the EHR and listens for incoming hook requests at a defined endpoint you register during setup. The EHR sends a payload containing the hook type, patient context, and relevant FHIR resources. Your service then responds with structured cards in milliseconds, before the clinician completes their current action.

A slow response from your CDS service can disrupt the clinical workflow, so your infrastructure needs to handle these requests at low latency.

What triggers a hook

Hooks fire at specific clinical moments the EHR vendor has configured. Understanding what is CDS Hooks means recognizing that your service only activates when the context is clinically relevant, which reduces alert fatigue and improves clinician adoption. Common hook types include:

• patient-view: fires when a clinician opens a patient record
• order-select: fires when a clinician chooses a medication or order
• encounter-start: fires at the beginning of a clinical encounter

Key building blocks: hooks, context, and cards

Three core components define how the specification operates: hooks, context, and cards. If you're working through what is CDS Hooks from a technical standpoint, understanding these three building blocks tells you exactly what your service needs to receive, process, and return.

Hooks and context

A hook is a named event that the EHR fires at a predefined clinical moment, such as order-sign or patient-view. Each hook carries a context payload containing the current user, patient ID, and specific FHIR resources tied to that action. Your service reads the context and decides whether a recommendation applies.

The specificity of the context payload is what separates CDS Hooks from generic alerting systems, since your service receives structured clinical data, not just a notification.

Cards and suggested actions

Cards are the structured response objects your service returns to the EHR after processing a hook request. Each card includes a summary, a detail field, and an urgency indicator that tells the EHR how prominently to display it.

You can also attach suggested actions to a card, such as pre-populating an order or linking to a clinical resource. This gives the clinician a direct path to act on your recommendation without leaving their current workflow.

CDS Hooks vs SMART on FHIR and other CDS

CDS Hooks and SMART on FHIR are complementary specifications, not competing ones. SMART on FHIR handles secure app authorization and data access, letting your application read and write FHIR resources from an EHR. CDS Hooks uses that same FHIR foundation but focuses specifically on triggering real-time recommendations during active clinical workflows.

How they differ in practice

When you ask what is CDS Hooks in relation to SMART on FHIR, think of it this way: SMART on FHIR gets your app connected and authorized, while CDS Hooks gets your recommendations delivered at the right clinical moment. A SMART on FHIR app opens in a separate window or panel; a CDS Hooks card appears inline within the clinician's current task, requiring no context switch.

Using both together gives your service the data access of SMART on FHIR and the workflow presence of CDS Hooks.

Traditional CDS tools, such as rule-based alerting systems built directly into the EHR, require vendor-side configuration for every logic change you need to make. CDS Hooks puts that control on your side, so you can update your recommendation logic and card responses without submitting change requests to the EHR vendor or waiting on their release cycle.

Implementing CDS Hooks safely and reliably

Once you understand what is CDS Hooks at a conceptual level, the next challenge is building a service that performs reliably inside a live clinical environment. EHRs time out hook requests quickly, often within 5 seconds, so any delay in your service degrades the clinician's experience and risks your cards never appearing.

Latency and reliability requirements

Your CDS service needs to handle concurrent hook requests without queuing delays. Clinicians open multiple charts and place dozens of orders per shift, which means your endpoint can receive bursts of simultaneous requests during peak hours. Architect your service with horizontal scaling and low-latency data access so responses stay well under the EHR's timeout threshold.

Caching frequently needed FHIR resources locally reduces round-trip time significantly, especially when your logic depends on data that doesn't change between requests.

Security and prefetch configuration

The EHR sends sensitive patient data in every hook payload, so your endpoint must enforce HTTPS and validate the JWT token the EHR includes with each request. You should also configure prefetch templates in your service discovery document, which tells the EHR exactly which FHIR resources to include in the payload, reducing unnecessary data exposure and improving response speed.

Practical next steps

Now that you understand what is CDS Hooks and how its core components connect, you're ready to move from concept to implementation. Start by reviewing the HL7 CDS Hooks specification directly, then map your clinical use case to the hook types that match your specific workflow moments. Identify which FHIR resources your logic depends on and configure your prefetch templates accordingly before you write any service logic. This upfront work keeps your payload lean and your response times fast.

Your CDS Hooks service also needs a solid SMART on FHIR foundation before it can operate reliably inside a real EHR environment. Your service depends on authorized FHIR data access, proper JWT validation, and a low-latency infrastructure that EHRs will trust and call repeatedly during active clinical sessions. Building all of that from scratch requires significant time and specialized expertise most teams don't carry internally.

If you want to skip the infrastructure work, launch your SMART on FHIR app with SoFaaS™ and start connecting to EHRs in days, not months.