Drug Utilization Review (DUR) is the process of evaluating a prescription against a patient's complete clinical picture before it reaches the dispensing stage. It's one of those terms that clinicians use daily and developers encounter once, usually right before a stakeholder says "we need to add DUR."
This guide explains what DUR actually checks, why the categories matter, and how to think about it as a system you're integrating via API.
What DUR is Not
DUR is not a spell-checker for drug names. It's not a lookup table. And it's not something you can approximate with a static interaction database and a boolean flag.
A real DUR engine reasons across multiple data dimensions simultaneously: the drug itself, the patient's age and weight, their active medication list, their known allergies, the prescriber's credentials, and known therapeutic duplications. The output is a set of findings, each with a severity, a description of the risk, and a clinically actionable recommendation.
The 6 Standard DUR Categories
Federal law (OBRA '90) defines the minimum categories that pharmacists must review. Modern digital health platforms are expected to automate these checks at the point of prescribing, not just at dispensing.
1. Drug-Drug Interactions
The most well-known category. Two drugs can interact at multiple levels: pharmacokinetic (one affects how the other is metabolized, typically through CYP enzyme pathways) or pharmacodynamic (additive or antagonistic effects at the receptor level).
The classic example: warfarin + metronidazole. Metronidazole inhibits CYP2C9, slowing warfarin metabolism, causing INR elevation of 30-50%. This is a high-severity, well-characterized interaction that should always fire.
A useful DUR API surfaces this as:
{
"type": "drug_interaction",
"severity": "high",
"description": "Warfarin + Metronidazole: CYP2C9 inhibition. Expected INR elevation 30-50%.",
"recommendation": "Reduce warfarin dose 25-50% during metronidazole course. Monitor INR closely."
}
2. Allergy Screening
Cross-referencing the prescribed drug against the patient's documented allergy list. This includes direct matches (patient is allergic to amoxicillin, prescription is amoxicillin) and cross-reactivity (patient is allergic to penicillin, prescription is amoxicillin, a beta-lactam with known cross-reactivity in ~1-10% of cases).
3. Dose Range Validation
Is the prescribed dose within the accepted therapeutic range for this patient? This isn't a single number. It's a range that shifts based on age, weight, renal function, indication, and route of administration.
A 500mg TID metronidazole prescription is appropriate for an adult with normal renal function. For a patient with CrCl below 30 mL/min, you'd want dose reduction. The system should know the difference.
4. Patient Profile Analysis
This is the catch-all for contraindications that don't fit neatly into other buckets. Examples:
- Age-related concerns (Beers Criteria medications in elderly patients)
- Pregnancy or lactation contraindications
- Condition-specific contraindications (NSAIDs in patients with active GI bleeding)
5. Duplicate Therapy Detection
Is the patient already on a drug that serves the same therapeutic purpose? Two SSRIs, two ACE inhibitors, two statins. These combinations are rarely intentional and always worth surfacing.
6. Prescriber Credential Verification
Does the NPI on this prescription belong to a real, active provider? Is their DEA registration valid for the controlled substance being prescribed? This check closes the loop on prescriber fraud and expired credentials.
How to Integrate DUR via API
The arxio /v1/clinical-review endpoint accepts a single POST with the drug, patient demographics and allergies, active medications, prescriber NPI, and prescription details. The response returns all 6 categories, each with a status (clear or flagged) and an array of findings.
The integration pattern that works best in production:
- Trigger at prescribe time, not at dispense time. If your workflow has a "confirm prescription" step, that's where the DUR call goes.
- Block on
highseverity, warn onmoderate. Don't surface everyinfo-level finding to the prescriber. It degrades the signal. - Store the full DUR response alongside the prescription record. You'll need it for audit trails and compliance.
- Design your UX for a 200ms nominal case and a 2-second tail case. DUR services can have latency.
Why LLM-Backed DUR?
Static rule databases (like those from FDB or Wolters Kluwer) are comprehensive but inflexible. They can't reason about novel drug combinations, they don't adapt to clinical context, and they require expensive licensing.
An LLM-backed DUR engine can evaluate the clinical significance of an interaction in context, weighing the patient's specific conditions, the indication for the new drug, and the severity of the interaction, and generate a recommendation that a pharmacist would actually find useful rather than dismissing as noise.
This is the bet arxio is making: that a fast, accessible, context-aware DUR check is more valuable for the 90% of platforms that currently have zero safety checking than a perfect but inaccessible enterprise solution.
The arxio API is in early access. If you're building a pharmacy platform, telehealth tool, or EHR integration, get started free and we'll set you up with credentials.
This post is educational. It does not constitute medical advice.