EHR-native, third-party or custom clinical decision support: which should you choose?
Health systems and digital health teams have three ways to put decision support in front of clinicians: rules built in the EHR's own engine, a third-party CDS product with licensed content, or a custom CDS service. The choice decides who maintains the logic, whether it works across EHRs, who carries FDA and ONC duties and who sees override data.
Should clinical decision support be EHR-native, third-party or custom?
Quick answer
Pick EHR-native rules when the logic is simple and lives in one EHR, a third-party CDS product when you want licensed content that someone else keeps current, and a custom CDS service when the logic is your own and must run across EHRs. Agnotic Technologies builds custom services and the delivery layer for licensed content.
| Criterion | EHR-native | External service |
|---|---|---|
| Where the logic runs | Inside the EHR's rule engine | In the vendor's or your own service, called from the EHR |
| Who updates the content | Your analysts, on your schedule | Third-party: the publisher. Custom: your clinical and engineering team |
| Works across EHRs | No: rebuilt in each EHR | Third-party: where the vendor has connectors. Custom: wherever CDS Hooks or SMART launch is supported |
| FDA device question | Assess the function you build | Third-party: the vendor's analysis for its product. Custom: yours, as the developer |
| ONC source attributes | Entered by your team in the certified EHR | Supplied by the publisher or by you for display in the EHR |
| Access to override data | Through the EHR's own reports | Through feedback calls the service receives, if the EHR sends them |
| Per-site configuration | Built once per EHR instance | Configured per site, with shared logic |
| Testing new versions | In the EHR's test environment | In your own pipeline plus the EHR's test environment |
What they are
What is EHR-native
Alerts, order sets and reminders built in the EHR's own rule engine by the health system's analysts. They run inside the EHR with direct access to the chart, and the health system writes and maintains the logic.
What is External service
Logic that runs outside the EHR and returns advice to it, typically as CDS Hooks cards or a SMART app. A third-party product supplies licensed clinical content and keeps it current; a custom service runs logic you own, built for your workflow or product.
Key differences
Who keeps the clinical content current?
With EHR-native rules, your analysts do, and content drifts when guidelines change and no one owns the update. A third-party product moves that job to a publisher with its own review cycle. A custom service makes it your team's job again, with version control, clinical sign-off and tests for every change. Decide the owner before the first rule ships.
Which option travels across EHRs?
An external service, if the EHRs support the standards. CDS Hooks, published by HL7 and now at version 2.0.1, lets an EHR call a CDS service at defined points such as patient-view or order-sign and display the cards it returns. EHR-native rules do not travel: each EHR needs its own build, test and maintenance.
How does FDA's non-device CDS test apply to each option?
FDA's Clinical Decision Support Software guidance, finalized in January 2026, explains which CDS functions are excluded from the device definition by the criteria in section 520(o)(1)(E) of the FD&C Act. The test applies to the software function, whoever builds it. A third-party vendor answers it for its product; a custom service puts that analysis on you as the developer, so plan it with the design.
Who supplies ONC source attributes?
45 CFR 170.315(b)(11) requires certified health IT to support source attributes for decision support interventions. For evidence-based interventions they include the bibliographic citation, the developer of the intervention, the funding source of its technical implementation, and its release and revision dates. With an external service, the publisher or your team must supply those values so the EHR can show them.
Can you see why clinicians override alerts?
Override data shows which rules help and which are noise. CDS Hooks 2.0.1 defines a Feedback API through which a service learns whether its suggestions were accepted or overridden, with override reasons. With EHR-native rules, that data stays in the EHR's reports; with an external service, you receive it directly if the EHR sends feedback.
When to use each
When to use EHR-native rules
- The logic is simple: a value, a missing order or an overdue screening.
- Everything runs in one EHR and will stay there.
- Your analysts already build and test rules in that engine.
- You do not need the logic in another product or setting.
When to use External CDS service (third-party or custom)
- Third-party: you want licensed content, such as drug or guideline rules, kept current by its publisher.
- Custom: the logic is your own intellectual property or your product's core feature.
- Custom: the same logic must run in more than one EHR.
- Either: you need override data and outcomes outside the EHR's reports.
Where do clinical decision support choices go wrong?
1. No content owner. Native rules are built for a project and never reviewed again.
2. A third-party product with no local tuning. Alerts fire for workflows your clinicians do not use.
3. A custom service without clinical governance. Engineers change logic without clinical sign-off and version records.
4. Source attributes left blank. The EHR cannot show where an intervention came from.
5. No override data. Feedback is not enabled, so no one can tell which alerts are ignored.
6. The FDA question asked late. A custom function is designed first and assessed against the non-device criteria after launch.
7. One EHR assumed forever. Logic built natively has to be rebuilt when a second EHR arrives.