Clinical Decision Support
Sector: Hospitals, health systems, digital health
The scenario
Imagine a hospital whose commercial decision support system only fires alerts for conditions it was configured for, using the fields its vendor chose to expose. Adding a rule means a vendor request and a long wait.
Then two needs appear. A review shows patients on loop diuretics whose potassium dropped below threshold over several admissions, and no rule was watching for it across that time window. Pharmacy also wants to alert on risky medication combinations in patients with a certain class of conditions, defined in SNOMED CT, not a single ICD code.
What goes wrong without the right tool
- Rules are hardcoded in the application or owned by the vendor, so every new rule is a project.
- Rules can only see the data inside their own module, and can't follow a patient across admissions and time windows.
- Code lists for drug classes and conditions have to be maintained by hand, and go stale silently when the terminology changes.
- It is hard to show a regulator which rules exist, what changed and when.
How Atomik can be used
- Keep the longitudinal data in one place. Encounters, lab results, medications and diagnoses are committed to Atomik as openEHR data, through an integration layer connected to the EMR.
- Write each rule as a stored query. For the drug-electrolyte pattern: one composition query for patients on loop diuretics (using the SNOMED CT expression
<< 387440002 | Loop diuretic |) and one for potassium below threshold in the latest lab result, combined (Combined Queries, a premium feature) so both apply to the same patient. - Run the rules where you decide. Your application or scheduler calls the query through the REST API on the schedule you need, and your alert dashboard or workflow shows the results. Atomik provides the data and the rule evaluation; how alerts reach clinicians is up to your application.
- Let clinical informatics maintain them. Queries are created and edited in the Web Console without programming, and are named, versioned artifacts.
- Let the terminology do the work. Using SNOMED CT expressions instead of code lists means new medications or conditions in the class are included on the next run.
- Show what exists. The query library and its history document which rules are in place and when they changed.
How CaboLabs can help
The integration with the EMR and the modeling of the clinical data are project work that CaboLabs, the builder of Atomik, can help with: see HIS Integration and openEHR Implementation. Atomik doesn't require CaboLabs services.
What this gives you
A library of clinical rules that the clinical team owns and can change without a development cycle, working over the full patient history.
Why Atomik fits
The value is in keeping each patient's whole history in one structured place, so a rule can look across admissions and time windows, and in writing drug and condition logic once as a clinical concept instead of as a list of codes.
Going deeper
What is Clinical Decision Support?
CDS is a set of tools, technologies, and processes that define, manage, and execute rules to generate meaningful clinical content — alerts, recommendations, and reminders — that support clinicians during patient care.
Consider a complete EHR with all of a patient's data. A clinician can access it, but processing that volume of information, combining it with clinical protocols, and correlating events across a timeline is beyond what any person can reliably do under time pressure. CDS automates that correlation.
A simple example: flag a patient for a PAP smear if they are over 40 and haven't had one in two years. One rule, automated, with measurable impact on early cervical cancer detection. Multiply that across dozens of conditions and patient profiles — Atomik serves as the standardized, queryable data source that makes each of those rules possible without rebuilding your data layer every time.