Healthcare Software Development
Custom healthcare & medical software: SaMD, clinical decision support, and cloud apps.
Explore Healthcare Software DevelopmentClinical Decision Support Development
We build clinical decision support that fires inside the clinician workflow: CDS Hooks services, SMART on FHIR sidebar apps, and rules engines with evidence a clinician can inspect. Multi-EHR, tuned against alert fatigue, and built to stay on the right side of the FDA's non-device line.
Clinical Decision Support A clinical decision support system that reaches
A clinical decision support system that reaches
the clinician at the moment of the decision.
Saga IT builds clinical decision support software: CDS Hooks services the EHR calls, SMART on FHIR sidebars that open with the patient in context, the rules engines that run your guidelines, the write-back that turns a decision into discrete data, and the registration and review each EHR vendor requires. Your clinical content stays yours. We build everything that makes it fire, on every EHR you run.
CDS Hooks & SMART sidebars
cards the EHR asks for, apps that open in context, write-back
Where it fires
patient-view, order-select, order-sign: the hook is the design
Device or not
the FDA non-device criteria, designed in from the first card
Care gaps, three EHRs
one longitudinal record, one rule set, Epic, Allscripts, Oracle Health
What We Build
Clinical decision support software, delivered as six kinds of work
Clinical decision support is only useful if it reaches the clinician at the moment of the decision, says something they can act on, and can be trusted enough to stay switched on. Each of these is its own engineering problem.
CDS Hooks services that fire inside the EHR
A CDS Hooks service is a FHIR-secured endpoint the EHR calls at a defined moment in the clinician workflow, and it answers with cards: a suggestion, a warning, or a link to a SMART app. We build the service, the prefetch templates that keep it fast, and the card logic that decides when to stay silent. Discovery document, hook registration, and the security review the EHR vendor runs before it will call you.
- CDS Hooks 2.0
- FHIR R4
- Prefetch
- Cards
What we deliver
- Discovery endpoint and per-hook services with FHIR prefetch so the EHR sends the data instead of you fetching it
- Cards with suggestions, overrides, and app links; the override reasons feed the tuning loop
- JWT validation of the EHR as caller, and a feedback endpoint that records what clinicians did with each card
- Hook coverage for patient-view, order-select, order-sign, encounter-start, encounter-discharge, appointment-book
- Load-tested against real EHR call volume, because a slow CDS service is a disabled CDS service
SMART on FHIR sidebar apps for richer decisions
Some decisions need more than a card: reconciling a diagnosis list, choosing a protocol, reviewing a cohort. For those we build SMART on FHIR apps that launch in the EHR sidebar with the patient already in context, read what they need through the FHIR API, and write the outcome back as discrete data rather than a note nobody codes from.
- SMART App Launch
- PKCE
- Write-back
- Epic · Oracle Health
What we deliver
- EHR launch with patient and encounter context, standalone launch for back-office review
- PKCE authorization, refresh tokens, and scopes trimmed to what the app reads
- Discrete write-back: Condition to the problem list, encounter diagnosis, structured notes
- Sidebar shells that match the host EHR so clinicians do not feel they left it
- App registration, security questionnaire, and go-live collateral for each EHR vendor
Prior authorization through CDS Hooks: Da Vinci CRD and DTR
The largest production use of CDS Hooks is not clinical at all. HL7 Da Vinci Coverage Requirements Discovery is a CDS Hooks service the payer exposes: the EHR fires order-select, the CRD service answers with the coverage rules for that order, and a card launches Documentation Templates and Rules, a SMART app that fills the payer questionnaire from the chart. We have stood up the full CRD and DTR stack end to end and validated the loop, and CMS-0057-F now requires payers to expose exactly this API.
- Da Vinci CRD
- DTR
- CMS-0057-F
- order-select
What we deliver
- CRD service implementation: order-select and order-sign hooks, coverage lookup, card responses with DTR launch links
- DTR SMART app: Questionnaire retrieval, CQL-driven prefill from FHIR data, attestation and submission
- Full Da Vinci stack deployment: CRD server, DTR server, FHIR server, request generator, KeyCloak, validated end to end
- Provider-side integration so orders carry the coverage answer before they are signed, not after they are denied
- CMS-0057-F Prior Authorization API alignment for payers, on the FHIR APIs the rule mandates
One CDS service, every EHR you run, and the data written back
CDS Hooks and SMART on FHIR are standards, so the service and the sidebar are built once. What is not standard is everything around them: app registration and security review per vendor, which hooks each EHR actually fires, what prefetch it honours, and which resources an app is allowed to write. We build the service once and carry it through each of those, so one codebase is live on every EHR you run.
- App registration
- Write-back
- Per-vendor hooks
- Epic · Oracle Health · MEDITECH
What we deliver
- App registration, security questionnaire, and go-live collateral for Epic, Oracle Health, MEDITECH, and the ambulatory platforms
- Per-vendor hook and prefetch mapping, so one service degrades gracefully where a hook is not exposed
- Write-back adapters: Condition to the problem list, encounter diagnosis, structured notes, per-vendor governance
- A sandbox for each EHR so your clinical team can test rules before the vendor review, not after it
Rules engines that execute your guidelines, and show their work
The rules are yours: which guidelines, which thresholds, which patients. The engine that runs them is software, and we build it. Eligibility services in Clinical Quality Language (CQL) or plain code that answer "does this rule apply to this patient right now" in milliseconds at hook time, with every rule versioned and every card carrying a link to the source your clinical team chose. That link is what keeps most CDS on the non-device side of the FDA line.
- CQL
- FHIR Clinical Reasoning
- Evidence links
- Versioned rules
What we deliver
- CQL execution against FHIR data, so your quality measures and care-gap definitions run exactly as written
- Eligibility services that evaluate rule applicability per patient in milliseconds, inside the hook latency budget
- Evidence linking: every card carries the citation your clinical team assigned, reviewable in one click
- Rule versioning and audit, so you can say which logic produced which card, for whom, and when
- Drug-interaction, duplicate-order, and dosing checks wired to the knowledge source you licence
Instrumentation that makes alert fatigue measurable
A CDS system that fires too often gets ignored, then disabled, and most programs find out from a complaint. We instrument every card with its outcome and override reason through the CDS Hooks feedback endpoint, build the suppression logic so a card does not fire twice in an encounter or for a documented exception, and put the override-rate dashboard in front of your CDS committee. Which rules to retire is their call. That they can see it is ours.
- Feedback endpoint
- Override analytics
- Suppression
- Governance packet
What we deliver
- The CDS Hooks feedback endpoint wired from day one: accepted, overridden, ignored, and why
- Override-rate dashboards per rule, per service line, per clinician role, built for your committee
- Suppression logic: once per encounter, never for a documented exception, silence budgets per rule
- An A/B harness for card wording and timing, measured against acceptance rate
- A governance packet template: what fires, why, how often, and who can change it
Where It Fires
The CDS Hooks a clinician actually hits
A hook is the moment the EHR pauses to ask your service a question. Choosing the right one is most of the design: the same rule at the wrong hook is noise.
| Hook | When it fires | What the EHR sends | Typical decision support |
|---|---|---|---|
| patient-view | Chart opened | Patient, encounter, user | Care gaps, risk flags, overdue screenings |
| order-select | Order chosen, before signing | Draft orders as FHIR resources | Duplicates, cheaper equivalents, prior-auth needs |
| order-sign | Orders about to be signed | Final order set | Interactions, dosing, contraindications |
| encounter-start | Visit begins | Encounter, patient | Protocol enrollment, documentation prompts |
| encounter-discharge | Discharge in progress | Encounter, conditions, meds | Follow-up scheduling, readmission risk |
| appointment-book | Appointment being booked | Appointment, patient | Pre-visit labs, prep instructions |
Building decision support on AWS? Procure the build through AWS Marketplace.
Procure through AWS Marketplace and draw down your committed AWS spend (EDP). No new vendor onboarding, no new paperwork.
Links to the AWS Marketplace listing ↗ Device or Not
Building clinical decision support that stays non-device
The FDA revised its Clinical Decision Support Software guidance in January 2026. Whether your CDS is regulated as a medical device turns on four criteria, and two of them are design decisions we make on your behalf.
| 520(o)(1)(E) criterion | Non-device CDS | Software as a Medical Device |
|---|---|---|
| Input | Displays or analyzes medical information: labs, problems, meds, notes | Acquires, processes, or analyzes a medical image, an IVD signal, or a waveform |
| Output | Supports or recommends to a healthcare professional | Provides a specific directive or acts without a professional in the loop |
| Reasoning | Shows its basis so the professional can review it independently | Hides the basis, or the professional cannot practically review it |
| Urgency | Not intended for time-critical decisions where review is impossible | Time-critical output the professional must act on immediately |
| Where we build it | This page | Our SaMD practice, IEC 62304 and ISO 14971 |
When the intended use crosses the line, on purpose or by scope creep, the work moves to our medical device software development practice, which follows IEC 62304 for the lifecycle and prepares the design history file. Our IEC 62304 compliance guide covers what that involves.
Multi-EHR
One decision support service, every EHR you run
CDS Hooks and SMART on FHIR are standards, so the service and the sidebar are built once. What differs per vendor is registration, the security review, which hooks fire, and what an app is allowed to write back.
Ep
Epic
CDS Hooks at patient-view, order-select, and order-sign; SMART sidebar with problem-list write-back; app review and security questionnaire.
OHOracle Health
CDS Hooks through the Oracle Health developer program, SMART launch from PowerChart, discrete write-back where the platform allows it.
MdMEDITECH
Expanse supports SMART on FHIR launch and a CDS Hooks surface; scope and write-back are narrower and shape the design.
VdVeradigm
FHIR R4 with SMART launch on the ambulatory platforms; CDS delivered through the Unity API where hooks are not exposed.
Atathenahealth
SMART on FHIR apps through the athenahealth Marketplace, with CDS surfaced in the encounter workflow.
eCeClinicalWorks
FHIR R4 and SMART launch; decision support delivered as sidebar apps against the healow and EHR APIs.
Healthcare integration delivered for
A Pattern We Have Shipped
Closing care gaps at the point of care, across three EHRs
The most common request we get is the same one under different names: the plan or the analytics team knows a patient has an open gap, and the clinician with the patient in front of them does not.
The hook
A patient-view CDS Hooks service checks the patient against an eligibility engine when the chart opens and returns one card per open gap, ranked, with the guideline it came from. No card if there is nothing to say.
The sidebar
Accepting a card launches a SMART on FHIR sidebar that shows the evidence, lets the clinician document an exception, or reconcile the diagnosis, and writes the outcome to the problem list as a discrete Condition.
The data
Gap logic runs against the longitudinal record, assembled from FHIR where the EHR exposes it and from C-CDA documents where it does not, so the same rules fire identically on Epic, Allscripts, and Oracle Health.
The loop
Every card reports its outcome through the feedback endpoint. Gaps closed, exceptions documented, and cards ignored all flow to the quality team's own dashboard, so tuning and retiring rules stays with the people who own the rules.
The full walkthrough, including the write-back design and why structured notes are not enough, is in Closing Care Gaps in the EHR Workflow.
Have a guideline that should fire in the workflow, or a CDS program that clinicians have stopped trusting? Let's scope it.
Talk to a Clinical Decision Support Engineer Case Studies
Clinical Decision Support in Production
Three delivered engagements, from a patient-view care-gap service across three EHRs to the full Da Vinci prior-authorization loop. Step through each to see the hook, the logic, and what the clinician saw.
Care-Gap Cards at Chart Open, Across Three EHRs
A value-based care organisation knew which patients had open gaps; the clinician with the patient in front of them did not. A patient-view CDS Hooks service now evaluates the longitudinal record when the chart opens and returns one ranked card per open gap, with the guideline it came from. Accepting a card launches a SMART on FHIR sidebar that documents the exception or reconciles the diagnosis and writes it to the problem list as a discrete Condition. The same service fires identically on Epic, Allscripts, and Oracle Health.
Chart Opens
// hook: patient-view
"hook": "patient-view",
"context": { "patientId": "…" },
"prefetch": { "conditions": Bundle,
"observations": Bundle }
"hook": "patient-view",
"context": { "patientId": "…" },
"prefetch": { "conditions": Bundle,
"observations": Bundle }
Eligibility
openGaps(record, {
measures: ["COL", "HBD", "SPC"],
asOf: encounter.date
})
// 2 open, ranked, each with its citation
measures: ["COL", "HBD", "SPC"],
asOf: encounter.date
})
// 2 open, ranked, each with its citation
Cards
One Longitudinal Record from FHIR and C-CDA
Care-gap logic is only as good as the record it runs on, and no single EHR held the whole patient. Two of the three platforms exposed FHIR R4; the third exposed C-CDA documents. We built the assembly layer that normalises both into one longitudinal record, reconciles duplicate problems and results across sources, and exposes it as FHIR so the same CQL rule set evaluates every patient the same way regardless of which system they were last seen in.
Three Sources
// per patient, per source
Epic → FHIR R4 $everything
Allscripts → C-CDA CCD document
Oracle → FHIR R4 $everything
// C-CDA sections mapped onto FHIR
Epic → FHIR R4 $everything
Allscripts → C-CDA CCD document
Oracle → FHIR R4 $everything
// C-CDA sections mapped onto FHIR
Normalise
reconcile(sources, {
identity: "MPI",
dedupe: ["Condition", "Observation"],
codeSystems: ["SNOMED", "LOINC", "ICD-10"]
}) // one Patient, one timeline
identity: "MPI",
dedupe: ["Condition", "Observation"],
codeSystems: ["SNOMED", "LOINC", "ICD-10"]
}) // one Patient, one timeline
One Record
Da Vinci CRD and DTR, Stood Up End to End
Prior authorization is the largest real-world use of CDS Hooks, and most teams have never seen the whole loop run. We deployed the full HL7 Da Vinci reference stack for a supplier-side pilot: the CRD server as the coverage service, the DTR server and questionnaire app, a FHIR server, the request generator that plays the EHR, and KeyCloak for auth, then validated the order-select to submission flow end to end. It is the same shape CMS-0057-F now requires of payers.
order-select
// EHR fires the CRD hook
"hook": "order-select",
"context": { "draftOrders": Bundle,
"selections": ["DeviceRequest/cpap-1"] },
"prefetch": { "coverage": Bundle }
"hook": "order-select",
"context": { "draftOrders": Bundle,
"selections": ["DeviceRequest/cpap-1"] },
"prefetch": { "coverage": Bundle }
CRD Service
// coverage requirements, as a card
"summary": "Prior auth required: CPAP",
"indicator": "warning",
"links": [{ "type": "smart",
"label": "Complete documentation" }]
"summary": "Prior auth required: CPAP",
"indicator": "warning",
"links": [{ "type": "smart",
"label": "Complete documentation" }]
DTR
Frequently Asked Questions
Common Questions
Clinical decision support software is software that delivers patient-specific information, recommendations, or alerts to a clinician at the point of care, inside the workflow where a decision is being made: at order entry, when prescribing, when a chart is opened, or when an encounter ends. It ranges from a drug-interaction check to a guideline-driven care-gap recommendation to a diagnostic aid. Modern clinical decision support software integrates with the EHR through CDS Hooks and SMART on FHIR rather than living in a separate system the clinician has to remember to consult.
A clinical decision support system (CDSS) is software that puts patient-specific knowledge in front of a clinician at the moment of a decision: alerts, order sets, reminders, reference links, and risk scores, delivered inside the EHR workflow. It has two halves. The clinical content (which guidelines, which thresholds, which patients) is the health system's or the vendor's, and their clinicians govern it. The software that delivers that content is what we build: the CDS Hooks service the EHR calls, the SMART on FHIR sidebar, the rules engine that evaluates the content, the write-back, and the instrumentation that shows whether clinicians act on it.
CDS Hooks is an HL7 standard that lets an EHR call an external service at defined moments in the clinical workflow (the hooks: patient-view, order-select, order-sign, encounter-start, encounter-discharge, appointment-book) and receive cards in return: a suggestion, a warning, or a link to launch a SMART on FHIR app. The EHR sends FHIR data with the request through prefetch, the service applies its logic, and the card appears in the clinician’s workflow without leaving the EHR. Epic, Oracle Health, and MEDITECH all support CDS Hooks, each with its own registration and security review.
It depends on what it does, and the FDA revised its guidance on exactly this in January 2026. Under Section 520(o)(1)(E) of the FD&C Act, clinical decision support software is not a device if it meets all four criteria: it does not acquire or analyze a medical image or a signal from an in vitro diagnostic or signal acquisition system; it displays or analyzes medical information; it supports or recommends to a healthcare professional rather than deciding for them; and it lets the professional independently review the basis for the recommendation so they do not rely primarily on it. Fail any one, most often the fourth by hiding the reasoning, or the first by analyzing an image or waveform, and it is Software as a Medical Device under FDA oversight. We build the software to the non-device criteria by design, so your logic can show its basis on every card, and hand off to our SaMD practice when the intended use crosses the line.
Two ways, usually together. CDS Hooks services register with Epic and are called at supported hooks with FHIR prefetch data; Epic renders the returned cards in the clinician’s workflow. SMART on FHIR apps register through Epic’s developer program and launch in the sidebar with patient context, reading through the FHIR API and writing back discrete data such as problem-list entries. Both go through Epic’s app review and security questionnaire before go-live, which we prepare as part of delivery. Our Epic integration page covers the broader platform; this page covers the CDS layer on top of it.
CDS Hooks is push: the EHR calls your service at a workflow event and shows the card you return, with no user interface of your own. SMART on FHIR is pull: a user (or a card) launches your app, which then reads and writes through the FHIR API with its own screen. Most real clinical decision support uses both: a CDS Hooks card catches the moment, and a SMART app handles anything that needs more than a sentence and a button.
By measuring it from day one and treating a high override rate as a bug. Every card we ship reports whether it was accepted, overridden, or ignored, and why, through the CDS Hooks feedback endpoint. Each rule has a silence budget and suppression logic so it does not fire twice in an encounter or for a documented exception. Rules that clinicians override more than they accept get rewritten or retired at a scheduled review, with the retirement criteria written down before go-live so the decision is not political later.
Yes, and it should when the decision produces data. A CDS Hooks card can carry a suggestion the clinician accepts with one click, which the EHR applies as an order or a documented action. A SMART on FHIR app can create a Condition on the problem list, add an encounter diagnosis, or post a structured note through the FHIR API. Which resources each EHR lets an app write, and under what governance, differs by vendor, and that is usually the first design question we settle.
A single CDS Hooks service with one or two hooks, prefetch, and a small rule set is typically 8 to 12 weeks from kickoff to the vendor security review, with the EHR’s own app review adding time we do not control. A SMART on FHIR sidebar with write-back and a rules engine is a 4 to 6 month build. Multi-EHR delivery adds a registration and review cycle per vendor, not a rebuild, because the service and the app are the same behind each.
Related Services
Explore More Services
Keep reading
Related resources
Talk to a Clinical Decision Support Engineer
From a first CDS Hooks service to a multi-EHR decision support platform. Bring the guideline, we will build the workflow.
- 15 min conversation
- Healthcare IT engineers, not sales
- Reply within one business day
Book a 30-min call · or email us and we'll reply within one business day.
Intent
Details
Contact