Custom clinical decision support software
Clinical decision support software alerts a healthcare professional at the moment it matters: an interaction between two medicines, the protocol step that goes with this presentation, a lab value that falls outside the agreed range, a record that is incomplete. The starting point is fixed and does not change anywhere on this page: the healthcare professional makes the diagnosis and takes the treatment decision, and the software brings information to their attention at the right moment. Appfront builds that alerting layer to measure, alongside or on top of the system where the work already takes place.
What clinical decision support is and is not
Clinical decision support is the umbrella term for software that brings together recorded knowledge and data from the patient record and presents something visible from it at a specific moment. In practice the applications fall into four groups. Medication monitoring checks a prescription for interactions, duplicate medication, dosage, contraindications and hypersensitivities. Protocols and guidelines bring the next step into view at the point it becomes relevant, rather than in a document someone looks up afterwards. Signalling looks at measurements and combinations of values and reports when they fall outside an agreed range or change too quickly. Record checks spot that a mandatory field is empty, that a check has been skipped, or that a result has not yet been reviewed.
What these four share is the form: at a fixed point in the workflow, the system compares this patient's data with a set of rules and shows the outcome to the person acting at that moment. What they do not share is the risk attached to them, and that difference later determines both the design and the regulatory framework.
It also varies slightly from setting to setting. In a hospital, most of the gain lies at the moment of prescribing and in following up results. In a GP practice, it more often concerns repeat medication, check-ups that lapse, and spotting patients who drop out of view. In long-term care it centres on agreements that must hold across many staff and many shifts, where it is the carer rather than the doctor who sees the alert. In mental health care the emphasis is more often on monitoring agreed steps in a care pathway than on laboratory values. These differences determine who the user is, and therefore what an alert should look like and how much may be asked of someone at the moment it appears.
What it is not should be clear first. Decision support does not make a diagnosis, does not make a treatment decision, and does not replace professional judgement. On this page we also do not claim any effect on care outcomes: what an alert delivers depends on the content of the rule, the moment it appears and the healthcare professional using it. A supplier who promises you such an effect is promising something they cannot build into software.
Is this the right page for you? This page is about the alerting layer itself. If you are looking for a broader care system, with record keeping, planning, billing or a client portal, start with building care software. If your question is mainly about demonstrably meeting requirements, with recording, authorisations and audit trails at its core, then care compliance software is the better starting point.
The healthcare professional decides, not the software
The software does not make a diagnosis or a treatment decision. It shows what is known and why it stands out now. The judgement stays with the professional who signs.
Timing determines the value
The same alert is useful while prescribing and useless in a list of next week's appointments. Decision support is therefore first and foremost a question of timing.
No source, no signal
What the system cannot read from the record as current, it cannot assess either. Here the integration is not a precondition but half the product.
Why most alerts get dismissed
Nearly every decision support project sooner or later hits the same snag: alerts are raised, and they get dismissed. Not out of unwillingness or incompetence, but because the behaviour makes sense given what the system shows. A rule that warns for every theoretically possible interaction mostly warns in situations the prescriber already knows, has consciously accepted and is already monitoring. Someone who receives a hundred alerts that do not apply learns to dismiss the alert before reading it. From that point on, the hundred-and-first, which does matter, gets exactly as much attention as the rest.
The cause is rarely the knowledge source and almost always the lack of context. A generic rule knows that drug A and drug B together call for attention. What the rule does not know is that this patient has been taking that combination for months, that the indication explains the combination, that the dose has been adjusted, that the check the alert asks for was done last week, or that a colleague already reviewed the same alert an hour earlier. All of that is in the record. It just is not in the rule.
On top of that, dismissing an alert usually goes nowhere. In many systems an ignored alert disappears without a trace, at most with a counter attached. Yet precisely that is the most useful information in the whole system: every override is a healthcare professional telling you the rule does not fit here. If that reason is recorded, categorised and read periodically, you have a plan for sharpening the rules. If it is not, every discussion about alerts becomes a matter of opinion.
The content of the alert itself matters too, and that is often overlooked. A useful alert tells you at a glance what is going on, why that conclusion was reached and which data from this record it rests on, with the source of the rule included for anyone who wants to check. It also offers the logical next actions, so the healthcare professional does not have to navigate three screens further to act on the information. And when an alert is overridden, it asks for a reason from a short, meaningful list rather than an empty text field everyone skips. An alert that only says something is there shifts the work to the user; an alert that shows what it is based on gives that user something to judge with. Here too the division of roles does not change: the software supplies the justification, the healthcare professional draws the conclusion.
From more alerts to fewer, but more serious ones
The solution is not to warn more cleverly at the same volume, but to warn less. That calls for differentiation by severity. A small share of the rules justifies an interruption that the user cannot get past without giving a reason. The vast majority should be passive: a marker on screen, a line in an overview, a colour next to a value, something that stands out without bringing the work to a halt. Anything that fits neither category does not belong in the workflow but in a periodic overview for whoever reviews the record, such as the pharmacist or the quality officer.
In addition, suppression based on the record helps: an alert that has already been assessed for this patient and this prescription does not return as long as nothing changes, and an alert that is structurally rejected at department level goes onto the review list rather than onto the screen. That is not a technical trick but a substantive decision, and therefore a decision that the clinical content governs, not the builder. Measurement is part of this: for each rule, how often it fires, for how many different patients, how often it is acted upon, and for which reasons it is rejected. Without those figures from your own system, any claim about its effect is an assumption.
What a clinical decision support system must be able to do
These components are connected. Monitoring without context produces noise, rules without maintenance go out of date, and logging without feedback turns a log file into an archive nobody reads. In all six cases the same applies: the outcome is information for the care provider, who decides for themselves what happens.
Medication monitoring with context
Checks for interactions, duplicate medication, dosage and contraindications, where the known data about this patient either suppresses the alert or makes it more serious.
Protocol at the point of care
The step from the guideline appears on the screen where the work is being done, with room to deviate with justification and with the source shown alongside.
Flagging of abnormal values
Reference ranges per patient group, the trend alongside the individual measurement, and a route to the person who can act on it at that moment.
Record review and completeness
Missing fields, unassessed results and skipped checks, presented as a worklist rather than as an interruption.
Rule management with versioning
Each rule has an owner, a traceable source, an effective date and a history, so it is possible to see afterwards what applied at any given time.
Logging of what was shown
Which alert, to whom, at what moment, what was chosen and for what reason. This is the basis for accountability and for refining the rules.
The integration with the source system determines whether it works
Clinical decision support is rarely the hardest part of a project. The rules are usually documented somewhere, in a guideline, a formulary or a local working agreement. Where things get stuck is whether the system has the right data at the right moment, and whether the answer lands on the screen the clinician is actually looking at. That is an integration question, and in practice it determines whether you have built a useful tool or a second screen nobody opens.
There are roughly three levels. The first is a periodic export from the source system: simple to achieve, but by definition after the fact, so only useful for overviews and follow-up review. The second is event-driven: the source system sends a message when a new prescription, a new result or an admission occurs, and the decision layer responds. That is useful for flagging, but the healthcare professional has to see the answer somewhere else. The third is the only level at which genuine decision support arises: the source system calls a service at the point of care and displays the answer within its own screen. In that case the timing is determined not by your application but by the work process.
Technically this often runs over HL7 version 2 messaging, which is still very common in Dutch healthcare organisations, or over FHIR where the source system offers it. For calling the logic from within the workflow, CDS Hooks is an open pattern designed precisely for this. More important than the choice of standard is whether your vendor permits this type of integration, which data is available, and whether you are allowed to write anything back. A read-only integration without write-back means that the assessment of an alert ends up outside the record, and is therefore invisible to the next clinician.
Two things are consistently underestimated. The first is coding: as long as allergies, indications or laboratory results arrive as free text, no rule can reliably depend on them. Coded data, using a shared terminology such as SNOMED CT for clinical concepts and LOINC for laboratory tests, is a precondition, not a bonus. The second is time: a call made while prescribing has a hard limit within which the answer must arrive, otherwise the user waits or the alert disappears unnoticed. An absent response should therefore itself be visible, because a silent failure in a safety function is more dangerous than a failure everyone can see.
Two things belong in the integration design from the outset rather than at handover. The first is authorisation: an alert contains patient data, so who sees it should follow from the treatment relationship and role, not from the fact that someone happens to have the screen open. The second is minimisation: retrieve what the rule needs and not the entire record, because every extra field you copy becomes a field you must secure, retain and eventually delete. For logging the reverse applies: for the alert itself, log generously, meaning what was shown, to whom, on what basis and what was chosen. That is exactly the information you need when reviewing an incident, and at the same time the information that makes it possible to refine the rules.
- Current data, not an export from last night
- A call at the moment of action, not afterwards
- Coded data instead of free text
- Writing back what was shown and chosen
- A hard time limit for the response
- Visible failure: no response is also an alert
- Agreements with the supplier of the source system
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Who maintains the rules when the guideline changes
A set of rules is not a finished deliverable but a living document. Guidelines are revised, forms are amended, a medicine is withdrawn from the market, a local working agreement becomes national or vice versa. A system not designed for this ages without anyone noticing, and that is the most troublesome form of ageing: the alerts keep coming, they simply are no longer correct. The question of who maintains the rules therefore belongs in the design and not in the maintenance contract afterwards.
The first design decision is to keep the rules out of the code. If the content of a rule is embedded in the software, every change to a guideline requires a software release, and a developer becomes the gatekeeper of clinical content. That is an uncomfortable role for both parties. A workable approach separates the engine, which retrieves data, evaluates conditions and presents the result, from the content, which is held in a manageable form that the subject-matter owner can access. The precise form depends on who manages it: a pharmacist with time and affinity for the work can do more than a committee that meets twice a year.
The second decision is ownership per rule. Not per system, per rule: a name, a discipline, a source the rule comes from with its version, an effective date, and a point at which it is reviewed again. If the source changes, every rule that refers to it appears on a list. Without that reference, every review is manual work, relying on someone to remember from memory which rules have been affected.
The third decision concerns rollout. A new or changed rule should first run in shadow mode, invisible to clinicians, against real data, so that it is clear in advance how often it would fire and for which type of patient. A rule that would fire dozens of times a day is not ready. In addition, every change should have a record of who proposed it, who approved it, and from when it applied. This is not bureaucracy: when reviewing an incident, the only sensible question is which rule version was active at that moment, and therefore what information the clinician did or did not have in front of them. Here too the division of responsibility does not change: the system records what it displayed, and the clinician remains the one who made the decision.
Finally, a practical warning for the tender or project budget. Homegrown clinical decision support rarely fails during the build. It fails the following year, when the person who knew the rules has moved on to something else and no one has been formally assigned to maintain them. Assign that responsibility before you begin. If the protocol spans multiple steps and clinicians, this directly affects the configuration of care pathway software; if the focus lies on medication, it concerns pharmacy software.
Medical device or not, and what that means
This is the part where you need a specialist, and so we only describe what is set out in public government sources. Software with a medical purpose may fall under the European rules for medical devices. The Dutch central government summarises the condition as follows: software is a medical device if the manufacturer describes that the software directly controls a medical device, provides information on patient care that leads to better decisions, or supports the treatment of the patient. Decision support sits by definition close to the last two descriptions. That is not a detail at the side of your project; it is a design starting point.
The framework is the European Medical Device Regulation, Regulation (EU) 2017/745, known as the MDR, which according to the Dutch Health and Youth Care Inspectorate (IGJ) became applicable on 26 May 2021. The regulation has four risk classes: class I as the lowest, followed by IIa, IIb and III as the highest. The manufacturer is itself responsible for correctly determining that class. For the content of this page, the most important point, again in the wording of the central government, is this: software that provides information used for decisions for diagnostic or therapeutic purposes falls, for example, in class IIa, and where decisions based on that information could lead to a deterioration of a person's health, the software falls in the higher risk class IIb. Higher classes are subject to stricter requirements in the CE marking procedure, and a conformity assessment body, the notified body, assesses the product and does or does not issue an MDR certificate. See the central government's explanation and the IGJ's supervision.
For construction, that means three things. There are requirements for the product itself: MDR Annex I, among other things, stipulates that software must be developed in line with the state of the art, taking risk and information security into account. There are requirements for the documentation surrounding it, including risk analysis and clinical evaluation; the IGJ names precisely those two as recurring weak points among manufacturers. And there is supervision: the IGJ monitors compliance and can enforce it. The practical consequence for your planning: you build that documentation alongside the development from the start, because reconstructing afterwards what was weighed during development is considerably more expensive than recording it at the time.
There is a separate route for healthcare providers that manufacture and use medical devices in-house. The IGJ states in its intervention policy that the requirements of the MDR and the IVDR do not apply where in-house manufactured medical devices meet the requirements of Article 5(5) of those regulations. This is explicitly not a back door: the article sets out conditions, and the route concerns manufacturing and using within your own institution. If you wish to rely on it, have your eligibility verified in advance.
If your decision support uses a model that learns from data rather than fixed rules, the European framework for artificial intelligence also applies. That is Regulation (EU) 2024/1689, which, according to the European Commission, entered into force on 1 August 2024 and became applicable on 2 August 2026, with an extended transition period until 2 August 2028 for high-risk AI built into products already covered by European product legislation. More on this can be found at AI Act compliance software and on the European Commission's page.
This is not legal advice. Whether your software qualifies as a medical device and in which class it falls depends on the intended purpose you define as manufacturer and on how the software is used. Agree this with a notified body or a specialist in medical device regulation before you build, not afterwards. What we contribute at the table is the translation into design: which part of the desired functionality increases the risk, and whether that part is truly needed to solve the problem.
Building alongside the care system, or within it
The first question is not whether you build, but what your current supplier already offers. Medication monitoring in a prescribing system is a mature product with a maintained knowledge base behind it. Rebuilding that is rarely sensible, if only because you then also have to maintain the knowledge base. The same applies to standard checks that every institution needs.
Building alongside the existing system becomes interesting in four situations. When the rule is specific to your organisation or population and no supplier is going to build it. When you need to combine data from several systems and the source system does not know the other source. When you want to adjust faster than your supplier's release calendar allows. And when the signalling crosses the boundaries of organisations, so that none of the systems involved sees the whole picture.
Building within, meaning configuring inside the existing system, is better when that system has a usable rules engine, and certainly when the alert must appear in a screen you cannot reach from outside. The latter is more often decisive than the functional comparison. In any case, keep the scope small: the more limited the medical purpose you define, the lighter the process that follows. A worklist for the pharmacist has different consequences than an interruption in the prescribing screen, even if the underlying rule is identical. And in both cases the division of roles remains unchanged: the software alerts, the healthcare professional makes the diagnosis and takes the treatment decision.
- Define the intended purpose before you choose functionality
- The manufacturer determines the risk class and bears responsibility for it
- A higher class means a notified body becomes involved in the process
- Build risk analysis and clinical evaluation in from the very beginning
- In-house manufacturing follows its own route with its own conditions
- If the model learns from data, the AI framework applies as well
- Have qualification and classification checked by a specialist
Frequently asked questions about clinical decision support
No. The software does not make a diagnosis or take a treatment decision. It brings information to attention at the right moment: a possible interaction, a step from a protocol, a value outside the agreed range, or a record that is incomplete. The healthcare provider assesses that information, weighs it against everything else they know about this patient, and decides. The system records what it displayed and what was chosen, so it can later be traced which information was available. We also do not claim any effect on care outcomes: what an alert achieves depends on the content of the rule, the moment it appears, and the professional who works with it.
It can, and with decision support that question is rarely theoretical. The national government describes software as a medical device when the manufacturer indicates that the software directly controls a medical device, provides information about patient care that leads to better decisions, or supports the treatment of the patient. The framework is the European Medical Device Regulation, Regulation (EU) 2017/745, applicable since 26 May 2021 according to the IGJ. There are four risk classes and the manufacturer determines which one applies. Software that provides information for decisions with diagnostic or therapeutic purposes, for example, falls under class IIa, and under the higher class IIb when those decisions could lead to a deterioration of someone's health. This is not legal advice: have qualification and classification checked by a notified body or a specialist.
By creating fewer of them and substantiating them better. An alert should take into account data from the record that the healthcare provider already knows: has this patient been using the combination for longer, does the indication explain it, was the requested check carried out last week, has a colleague already assessed the same alert. Distinguishing by severity also helps: a small number of rules justify an interruption, the vast majority should be passive, and the rest belongs on a worklist for whoever reviews the record. Then measure, per rule, how often it fires, how often it is followed, and for what reason it is overridden. Every override is a healthcare provider telling you the rule does not apply here.
That depends mainly on what your supplier permits. There are three levels. A periodic export is simple but always retrospective, so it is only useful for overviews. Event-driven messaging, often according to HL7 version 2 or via FHIR, is nearly real-time but shows the answer outside the screen where work is being done. Only at the third level does genuine decision support arise: the source system calls a service at the moment of action and displays the answer itself, a pattern for which the open standard CDS Hooks exists. Preconditions are coded data rather than free text, a hard time limit for the response, and the ability to write back what was displayed and chosen.
Someone named and accountable must be appointed before the system goes live. In practice that means the content of each rule is held outside the software in a manageable form, every rule has an owner and a traceable source with a version, and when that source changes, every rule that refers to it appears on a review list. A changed rule first runs silently alongside the live one, against real data, so you can see in advance how often it would fire. Every change is recorded: who proposed it, who approved it and from when it applied, because when investigating an incident the question is which version of the rule was active at the time. Home-built decision support rarely goes wrong at the build stage, but in the year that follows.
Start by checking what your current supplier already offers. Medication safety checking within a prescribing system is a mature product with a maintained knowledge base behind it, and rebuilding that means taking on that knowledge base too. Building alongside the existing system becomes worthwhile when the rule is specific to your organisation or population, when you need to combine data from several systems, when you need to adjust faster than the release calendar allows, or when the alerts cross organisational boundaries. Configuring within the existing system is better when that system has a usable rules engine, or when the alert has to appear on a screen you cannot reach from outside. In either case, keep the scope small.
Related services
Custom healthcare software development
If your requirements go beyond the alerting layer, covering record keeping, scheduling, billing or a client portal, start with custom healthcare software development. That page covers the broader picture; this one is only about the decision support itself.
Healthcare compliance software
If the question is really about demonstrably meeting requirements, with logging, authorisations, retention periods and audit trails at its core, healthcare compliance software is a better fit than a decision layer.
Patient intake software
Many checks start with what was or was not asked during intake. If data is missing there, no rule can be built on it. See patient intake software.
Start with the alerts you are missing now
Tell us which three signals you would want today, which system the data for them comes from, and who will manage the rules afterwards. Those three answers usually show whether this is configuration in your current system, a separate layer alongside it, or first a conversation about qualification as a medical device. In all three cases the starting point is the same: the software alerts, and the healthcare professional makes the diagnosis and takes the treatment decision.