Every HealthTech engineering team adding AI to clinical workflows eventually hits the same question. There is a perfectly good HL7 standard (CDS Hooks) for embedding decision-support content into the EHR. Why build an agent layer at all. The answer is not “agents are better.” The answer is that CDS Hooks and AI agents solve different problems, and the right architecture in most production HealthTech systems is a hybrid where the agent layer calls CDS Hooks as one of its tools. This post walks through what each does, when to use which, and the build-vs-buy decision compliance-bound operators actually make.
CDS Hooks is an HL7 specification for embedding decision-support content into the EHR workflow. The mechanics are simple. The EHR fires a hook at a defined workflow point (the clinician opens a patient chart, drafts a medication order, signs a note). The hook sends a structured request to a CDS service. The service returns a structured response with cards (alerts, suggestions, decision-support links). The EHR renders the cards in the workflow.
CDS Hooks brings the strengths of a well-designed industry standard. The specification is stable and version-controlled. The integration is supported by every major EHR (Epic, Cerner, Athena, eClinicalWorks all implement the spec to varying degrees of completeness). The clinical content is auditable, because the rules that produce the cards are explicit. The deployment story is straightforward: stand up a CDS service, register it with the EHR, the EHR fires hooks and renders cards.
For hard-coded clinical rules, CDS Hooks is the right primitive. Drug-drug interaction alerts. Guideline-driven order-set suggestions. Allergy checks. Patient-specific dosing adjustments based on creatinine clearance. Any rule that can be expressed as “given these structured inputs, produce these structured outputs” fits inside CDS Hooks cleanly, and the audit trail is the rule’s source code plus the hook request plus the card response.
The boundary of CDS Hooks is the structured-rule format. A card is a structured payload (a summary, a detail message, suggestions with prefetch hints, links). The content has to be generated by a service that knows how to populate that structure. Some content is not naturally structured.
Three categories show up repeatedly where CDS Hooks runs out of room.
The first is multi-step reasoning over heterogeneous chart data. A rule like “alert on potential drug-drug interaction” is structured input to structured output. A request like “summarize this patient’s chart history relevant to today’s visit, highlighting any chronic conditions whose management has changed in the last 12 months” is not. The reasoning required is not expressible as a deterministic rule; it is a synthesis step over unstructured notes, structured observations, and medication history.
The second is narrative explanation. CDS Hooks cards can carry text, but the text has to be authored. The card system does not generate prose. A clinician who sees an alert and wants to know why the rule fired can click through to a guideline link, but the link is to a static document, not a patient-specific explanation. Operators who want patient-specific narrative (“this patient’s HbA1c trend over the last 18 months suggests reconsidering metformin dosing because…”) are outside what CDS Hooks alone can produce.
The third is conversational follow-up. A CDS Hooks card fires, the clinician reads it, the clinician either acts on it or dismisses it. If the clinician has a question (“does this guideline apply to patients on dialysis?”) there is no path inside CDS Hooks to answer. The card is a one-shot artifact.
These gaps are not failures of the specification. CDS Hooks was designed for structured decision support, and it is excellent at that. The gaps are where an agent layer adds something CDS Hooks cannot.
AI agents in clinical workflows fill the gaps above with three capabilities CDS Hooks does not provide.
Multi-step synthesis. An agent can read a patient’s chart over multiple tool calls (problem list, recent encounters, medication history, recent labs), reason across the synthesized context, and produce an output that no single CDS rule could have generated. The output is patient-specific, context-aware, and (with proper architecture) bounded by the same controls a CDS service would be.
Narrative explanation. An agent can generate prose that summarizes, explains, or contextualizes. Given a CDS Hooks alert that fired (“potential interaction between drug A and drug B”), an agent can produce a patient-specific explanation of why the interaction matters for this particular patient given their other medications and conditions. The explanation is content a clinician would otherwise have to assemble by hand.
Conversational follow-up. An agent can hold a multi-turn conversation with a clinician about a specific patient, answering follow-up questions, drilling into specific data points, and producing additional context on request. The agent is a research assistant on the patient, with the patient’s chart as its corpus.
The cost of these capabilities is the architecture overhead that the cornerstone of this cluster, the HIPAA architecture for production-grade AI agents, walks through in detail. Schema-constrained tool use, BAA-bound LLM providers, redaction at the tool boundary, audit logging, HITL on writes, eval harnesses. None of this overhead exists for CDS Hooks because CDS Hooks does not have the failure modes the overhead is mitigating.
The right framing for build-vs-buy in clinical decision support is: build what CDS Hooks cannot express, buy what it does. Most HealthTech operators end up with a hybrid stack where structured rules are deployed as CDS Hooks services (built in-house or sourced from vendors) and the AI agent layer sits on top, calling CDS Hooks as one of its tools.
The buy side of the decision: when the clinical content can be expressed as structured rules, CDS Hooks is almost always the right deployment surface. The EHR integration is supported. The audit trail is the rule definition plus the hook log. The cost of building a custom UI for the same content is wasted; the EHR already renders cards. If there is a vendor whose CDS Hooks service covers the rule set you need (drug-interaction databases, dosing-decision support, clinical-guideline content libraries), buying is usually cheaper than building.
The build side of the decision: when the clinical content requires synthesis, narrative explanation, or conversational follow-up, you are building an agent layer. There is no off-the-shelf clinical agent that will be tuned to your data, your protocols, and your compliance posture. The build is non-trivial (the entire HIPAA-architecture cornerstone is the architecture you have to land on), but the alternative is “use ChatGPT and hope for the best,” which is not a path that survives a security review.
The hybrid decision: most production systems have both, and the agent calls CDS Hooks as a tool. The pattern is described in the next section.
The architecture that holds up in compliance-bound workflows is a hybrid where the agent layer treats CDS Hooks as one of its tools. The agent does multi-step reasoning, synthesizes context, and at the point where a structured clinical rule applies, the agent calls the CDS Hooks service and integrates the structured response into its output.
A concrete example. A clinician opens a patient’s chart and the patient-summary agent runs. The agent reads the patient’s problem list, recent labs, and current medication list. It is drafting a summary for the clinician’s review. At the point where the agent considers the patient’s current medication list, it fires a CDS Hooks order-select hook against the patient’s data (or against a deterministic rules engine that implements equivalent logic). The hook returns any active drug-interaction or dosing alerts. The agent integrates those alerts into the summary as structured callouts, with patient-specific narrative explanations attached.
The benefits of the hybrid pattern.
The structured rules stay in the rules engine. Drug interactions, dosing thresholds, allergy checks, guideline-based order-set suggestions are deterministic, auditable, and version-controlled in the CDS service. The agent does not re-invent the rule logic; it reads the rule’s output.
The agent stays out of the deterministic-rule business. The HealthTech failure mode of “the LLM said the patient is allergic to penicillin and we should reconsider amoxicillin” gets shifted to “the deterministic allergy-check rule fired, and the agent is explaining the rule’s output.” The clinical-correctness liability sits on the rule, not on the model.
The audit trail is layered. Each CDS Hooks call has its own audit log. The agent’s tool call to the CDS Hooks service is captured in the agent’s audit log. The two logs together reconstruct what content was generated, what rules fired, and what context informed the agent’s synthesis.
The deployment story is incremental. An operator who already has CDS Hooks services in place can add the agent layer without disrupting the existing rules infrastructure. The agent is additive. If the agent fails or is rolled back, the underlying CDS Hooks rules still run.
The compliance burden differs materially between CDS Hooks alone and an agent-layered architecture, and the burden is worth being explicit about during build-vs-buy planning.
CDS Hooks compliance burden. The CDS service is a HIPAA-covered system that receives PHI from the EHR via the hook payload. It needs the standard Security Rule technical safeguards: access control, audit controls, integrity, authentication, transmission security. If you use a third-party CDS vendor, you sign a BAA with them. The audit trail is the hook request and response log, plus the rule definitions, plus the rule version history. The risk surface is bounded by the rule format: the service can only return what its rules can produce, and the rules are inspectable.
AI agent compliance burden. Everything above, plus the model layer. The LLM provider needs a BAA (or you self-host on BAA-covered infrastructure). PHI handling at the tool boundary needs explicit redaction policy. Tool calls need structured-output enforcement. Audit logs capture every tool call, not just the inputs and final output. Eval harnesses run continuously against the agent’s behavior in production. HITL queues sit in front of any write. The risk surface is wider than CDS Hooks because the model’s failure modes (fabrication, prompt-injection, distribution shift) are different in kind from the failure modes of a rules engine.
The asymmetric implication for build-vs-buy. CDS Hooks is cheaper to add to an existing stack, both in engineering and in compliance overhead. The agent layer is more expensive on both axes. Operators who add an agent layer should have a clear reason it pays for itself (e.g., the synthesis or narrative capability genuinely closes a workflow gap that CDS Hooks alone could not). Adding an agent because agents are interesting is a path to a system that costs more to operate than it returns.
The sequence that holds up for operators who do not yet have either deployed: start with CDS Hooks for the structured-rule use cases, run them in production for at least a quarter to validate the rule set and the audit-trail discipline, then add an agent layer for the synthesis use cases that CDS Hooks cannot cover.
The reasons for this sequence are practical. CDS Hooks is a smaller bite. The integration is well-documented, the EHR support is mature, and the compliance burden is contained. Standing up an agent layer on day one means building the rules infrastructure and the model infrastructure simultaneously, which doubles the engineering load and triples the testing surface.
Operators who try to build an agent layer first often end up with an agent that re-implements rules better suited to CDS Hooks, with a fuzzier audit trail and worse correctness guarantees. The drug-interaction check that should be a deterministic rule becomes a prompt to the model, the model is mostly right, and the day the prompt phrasing changes the interaction-detection rate moves by single-digit percentages for reasons nobody can fully explain. CDS Hooks first, agents on top, is the order that keeps the rules where they belong and the synthesis where it adds value.
Q: What is CDS Hooks?
CDS Hooks is an HL7 specification for embedding decision-support content into the EHR workflow. The EHR fires a hook at a defined workflow point (chart open, medication order draft, note signing), sends a structured request to a CDS service, and renders the service’s response as cards in the clinician’s view. The standard is supported by every major EHR, and it is the right deployment surface for any clinical decision-support content that can be expressed as structured input to structured output.
Q: When should I use AI agents instead of CDS Hooks?
Use AI agents when the clinical content requires multi-step synthesis over heterogeneous chart data, patient-specific narrative explanation, or conversational follow-up. None of these fit cleanly inside the CDS Hooks card format, which is designed for structured rule outputs. Most operators end up with a hybrid where structured rules stay in CDS Hooks services and the agent layer sits on top, calling CDS Hooks as one of its tools for the rule-based components of its output.
Q: Can an AI agent call CDS Hooks as a tool?
Yes, and this is the architecture most production HealthTech systems converge on. The agent does multi-step reasoning and synthesis, and at points where a structured clinical rule applies (drug interactions, dosing thresholds, allergy checks), the agent fires the CDS Hooks service and integrates the structured response into its output. The structured rules stay in the deterministic rules engine, the agent stays out of the rule-replication business, and the audit trail layers the agent’s tool calls on top of the CDS service’s own audit log.
Q: Which is cheaper to deploy in a compliance-bound workflow, CDS Hooks or AI agents?
CDS Hooks is materially cheaper on both engineering and compliance axes. The integration is well-documented, the EHR support is mature, and the compliance burden is bounded by the rule format and the standard HIPAA Security Rule controls. AI agent deployments add a model layer with its own failure modes (fabrication, prompt-injection, distribution shift), which requires BAA-bound providers, schema-constrained tool use, redaction policies, expanded audit logging, eval harnesses, and HITL on writes. Most operators start with CDS Hooks for the structured-rule use cases and add agents only where the synthesis or narrative capability closes a workflow gap CDS Hooks alone cannot.
Q: What is the build-vs-buy decision for clinical decision support content?
Build what CDS Hooks cannot express; buy or build inside CDS Hooks for what it can. Structured rules (drug interactions, dosing decision support, guideline-driven order sets) are well-served by CDS Hooks, and vendors exist for most common rule sets. Synthesis and narrative content require an agent layer, which is a build effort with no off-the-shelf clinical equivalent. The hybrid stack, where CDS Hooks services handle the rules and an agent calls them as tools for the synthesis layer, is the architecture most production systems land on.
CDS Hooks plus an agent layer is the right hybrid for most compliance-bound clinical decision support, but the engineering details (which rules go in CDS Hooks, how the agent’s tool definitions wrap them, how the audit trails compose) benefit from a conversation with a team that has shipped both. We work through these architecture choices regularly in Motomtech’s HealthTech Agentic AI Development engagements, and the underlying Custom Software Development work to stand up the CDS Hooks service is the same kind of work we have shipped for years. If you want to walk through your specific clinical content and where the build/buy lines should sit, grab time on my calendar at cal.com/mirgen-motomtech/quick-intro.
Mirgen Hoxha, CEO, Motomtech.
