Drug Utilization Review (DUR): Process, Rules & Automation

Drug Utilization Review (DUR) is a systematic process for evaluating medication use against predefined clinical, safety, utilization, and benefit criteria. In U.S. pharmacy and payer workflows, DUR can happen before a prescription is dispensed, while therapy is in progress, or after claims have accumulated.

For technology teams, the important part is the decision layer behind the review. Prescription, patient, medication, claims, and benefit data are evaluated against rules that can identify potential drug interactions, duplicate therapy, inappropriate utilization, formulary restrictions, or cases requiring further review. CMS describes Medicaid DUR as an ongoing program that uses prospective and retrospective review and interfaces with claims-processing systems.

What Is Drug Utilization Review (DUR)?

Drug Utilization Review (DUR) is a rule-based process that evaluates prescription, patient, medication, claims, and benefit data against predefined criteria. In U.S. pharmacy and PBM systems, DUR rules can identify conditions such as drug interactions, duplicate therapy, dose or duration issues, refill violations, quantity limits, and formulary restrictions.

When a rule matches, the DUR system generates a defined outcome, such as an alert, manual-review request, claim response, or downstream workflow action. The decision is based on the configured rule set and available data; cases requiring clinical judgment can be routed to an authorized reviewer.

Typical DUR checks include:

• Drug-drug interactions and contraindications
• Duplicate therapy
• Dose, frequency, and duration
• Early or excessive refills
• Quantity and utilization limits
• Formulary and preferred-drug requirements
• Overutilization or underutilization
• Potential misuse or abuse

How Does Drug Utilization Review Work?

A modern DUR workflow turns medication and claims data into a decision that can be acted on by a pharmacy, payer, PBM, or clinical reviewer.

Data → validation → rule evaluation → alert/decision → review or downstream action → audit

The workflow can be broken down into four stages:

• Data Collection and Validation

The process begins with the data needed to evaluate the medication event. Depending on the workflow, this can include prescription details, patient identifiers and characteristics, medication history, diagnosis or clinical information, benefit data, formulary information, and prior claims.

At the pharmacy-claims layer, standardized transactions are important because pharmacy providers, payers, processors, and other participants need consistent formats for eligibility, claim billing, prior authorization, and related transactions. NCPDP's Telecommunication Standard provides this transaction framework for electronic pharmacy claims.

Before evaluation, systems need to validate required fields, normalize identifiers, and confirm that the data is usable for the specific rule being evaluated.

• Rule Evaluation

The validated data is evaluated against the DUR criteria. A rule might compare a medication with the patient's existing medications, check quantity against a configured limit, determine whether a refill occurs too early, or evaluate whether a drug requires a specific benefit condition.

The important distinction is that the system is evaluating configured criteria, not independently determining what treatment is clinically appropriate. Clinical criteria and benefit policies must be defined and governed by the organization responsible for the DUR program.

• Alert and Decision Generation

When a rule matches, the system generates the configured outcome. Depending on the workflow, that may be an alert, a claim response, a request for additional information, a manual-review case, or another operational action.

Not every match should result in an automatic denial. High-risk or clinically ambiguous cases may need pharmacist or authorized reviewer intervention before a final action is taken.

• Review and Resolution

Cases requiring human intervention are routed to pharmacists, clinicians, or authorized operational reviewers. The reviewer can assess the underlying information, document the intervention, and record the resulting action.

The outcome should remain traceable to the data evaluated, the rule or policy version used, the decision produced, and any subsequent intervention.

Types of Drug Utilization Review

DUR is classified by when medication use is evaluated within the medication-use lifecycle. The timing determines what data the system has available and what type of decision or intervention it can support.

The three types are:

1. Prospective DUR

Prospective DUR evaluates medication use before dispensing. In a pharmacy or claims workflow, the system evaluates the incoming prescription against available patient, medication, and benefit data before the transaction is completed.

Typical rules check drug-drug interactions, therapeutic duplication, allergies, contraindications, dosage, duration, and other configured safety criteria.

2. Concurrent DUR

Concurrent DUR evaluates medication use while therapy is ongoing. The system uses data accumulated during treatment to identify conditions such as continued overutilization, underutilization, or other configured utilization issues.

The key difference from prospective DUR is the evaluation point: prospective DUR evaluates an upcoming medication event, while concurrent DUR evaluates utilization as treatment progresses.

3. Retrospective DUR

Retrospective DUR evaluates historical claims and utilization data after medication use has occurred. Systems can analyze patterns across members, prescriptions, providers, drugs, and time periods to identify utilization issues or opportunities for intervention.

CMS describes retrospective DUR as claims-based analysis that can identify inappropriate utilization, dosage or duration issues, therapeutic appropriateness concerns, overuse, abuse, fraud, and opportunities to improve generic utilization.

Drug Utilization Review vs. Drug Utilization Evaluation

Drug Utilization Review (DUR) and Drug Utilization Evaluation (DUE) both assess medication use against defined criteria, but they typically serve different operational goals. DUR focuses on identifying and acting on medication-use issues, while DUE is more focused on evaluating utilization patterns and measuring opportunities for improvement.

Here’s how they compare:

The distinction is primarily about purpose and workflow, not separate technology stacks. Both can use the same underlying claims, medication, rules, reporting, and analytics infrastructure.

DUR System Architecture

A production DUR platform is not just a rules engine. It is an integration and decisioning system that has to move healthcare data through evaluation while maintaining security, traceability, and operational controls.

A typical architecture contains: Pharmacy / Claims Systems → Data & Drug Sources → DUR Decision Layer → Alert / Workflow Layer → Reviewer or Downstream Claims Action

The main components are:

• Pharmacy and claims data sources: Prescription and transaction data used to initiate or support a review.
• Patient and medication data: Medication history and other information required by specific criteria.
• Drug and clinical databases: Drug identifiers, interaction information, clinical criteria, and related reference data.
• Rules/decision engine: Evaluates incoming data against configured DUR criteria.
• API and integration layer: Connects pharmacy, payer, PBM, clinical, and downstream systems.
• Alert and workflow services: Routes matches to alerts, manual review, escalation, or other actions.
• Audit and logging layer: Records rule changes, evaluations, decisions, and operational events.
• Monitoring and analytics: Measures rule performance, intervention volumes, false positives, and utilization patterns.

What Rules Power a DUR System?

A DUR system evaluates incoming medication, patient, claims, and benefit data against rules that determine whether a transaction or utilization pattern requires an action. In practice, these rules typically fall into three categories: clinical and safety, utilization management, and formulary or benefit rules.

Here are the three main rule categories:

• Clinical and safety rules: Detect potential medication-related risks such as drug-drug interactions, drug-disease contraindications, therapeutic duplication, allergies, dose or frequency thresholds, and duration limits.
• Utilization management rules: Enforce defined utilization policies such as quantity limits, refill-too-soon thresholds, maximum frequency, age restrictions, overutilization thresholds, and coverage-period limits.
• Formulary and benefit rules: Evaluate coverage requirements such as preferred versus non-preferred drugs, step therapy, prior authorization, and benefit-specific quantity or duration restrictions.

Data and Integration Requirements for DUR

A DUR system needs access to the data required to evaluate each rule. In a production architecture, that typically means integrating pharmacy and claims systems with medication history, drug-reference data, formulary and benefit systems, clinical data, and downstream authorization or workflow services.

The core integrations typically include:

• Pharmacy and claims systems: Prescription, dispensing, eligibility, and claims transaction data.
• Medication and drug data: Medication history, drug identifiers, and drug-reference information used by DUR rules.
• Formulary and benefit systems: Coverage status, preferred products, limits, step therapy, and prior authorization requirements.
• Clinical data: Patient or diagnosis information required for applicable clinical criteria.
• Provider and pharmacy systems: Data needed for dispensing, review, intervention, and follow-up workflows.
• Prior authorization and workflow systems: Services that receive DUR outcomes and handle subsequent actions.
• APIs and interoperability interfaces: Integration points connecting the DUR decision layer with existing healthcare systems.

Security and Compliance in DUR Systems

DUR systems can process protected health information (PHI), so security needs to be built into the architecture rather than added after deployment. HIPAA's Security Rule requires covered entities and business associates to implement appropriate administrative, physical, and technical safeguards for electronic PHI, including its confidentiality, integrity, and availability.

A secure DUR architecture needs controls across data handling, access, communication, and decision traceability. The key areas are:

• PHI Protection: Limit each DUR component to the PHI it actually needs. Avoid sending unnecessary patient data to rule evaluations, logs, analytics systems, or external services.
• Identity, Access Control, and Least Privilege: Use role-based access and least-privilege permissions across DUR applications, APIs, databases, and rule-management systems. Production PHI and claims data should not be accessible to users or services that do not require it.
• Encryption and Secure Data Exchange: Protect PHI in transit and at rest using the organization's approved security controls. APIs and system integrations should require authentication and authorization, with secure communication between pharmacy, claims, payer, PBM, and decisioning systems.
• Audit Logs and Decision Traceability: A DUR system should be able to trace each decision back to the relevant inputs and rule version: Input data → Rule version → Decision → Action. Logs should also capture material rule changes and relevant user or system actions. This becomes important when a decision affects dispensing, coverage, authorization, or manual review.
• HIPAA and Regulatory Controls: HIPAA compliance applies to the overall environment, not simply to an individual DUR or decisioning component. Organizations need appropriate safeguards, access controls, risk-management processes, and controls for the use and disclosure of PHI across the systems involved.

How to Automate Drug Utilization Review

Automating DUR means separating decision logic from the application code that handles pharmacy, claims, patient, and benefit data. The application supplies the required inputs, a decision layer evaluates the configured rules, and the result is returned to the workflow that needs to act on it.

A typical flow is: Pharmacy/Claims Data → Data Validation → DUR Rules → Decision → Alert, Review, or Claims Action

The implementation typically requires four components:

• Externalize DUR rules: Keep safety, utilization, refill, quantity, and benefit conditions in a configurable rule layer instead of hard-coding them into claims or pharmacy applications. Policy changes can then be made without changing the surrounding application logic.
• Automate deterministic checks: Evaluate rules such as refill-too-soon, quantity limits, duplicate therapy, or formulary requirements when the required data is available. For example: IF refill_days_remaining > 5 AND refill_requested = true → flag_refill_too_soon.
• Connect decisions to existing workflows: Send the result to the system responsible for the next step, such as a pharmacist review queue, prior-authorization workflow, claims response, alert service, or downstream application.
• Version and audit rules: Record which rule version produced each decision and track rule changes, testing, publishing, and rollback. This provides traceability when policies change, or a decision needs to be reviewed.

Challenges in Building DUR Systems

Building a DUR system is less about evaluating individual rules and more about maintaining reliable data, consistent decision logic, and traceable outcomes across connected healthcare systems.

Here are the key challenges teams need to address:

• Data Quality and Interoperability: DUR decisions depend on the data available at evaluation time. Inconsistent drug identifiers, incomplete medication history, outdated benefit data, or missing patient attributes can cause rules to match incorrectly or fail to match when they should.
• Rule Complexity and Maintenance: DUR rules can combine clinical criteria, utilization limits, formulary requirements, and benefit-specific exceptions. Hard-coding this logic into claims or pharmacy applications increases release dependencies and makes policy changes harder to test and maintain.
• False Positives and Alert Fatigue: Rules that generate excessive alerts can overwhelm pharmacists, reviewers, or operations teams. DUR automation should therefore measure false-positive rates and intervention outcomes and adjust thresholds or rules when they create unnecessary review volume.
• Explainability and Auditability: Every material DUR decision should be traceable to the inputs evaluated, rule version applied, resulting decision, and downstream action. Without this information, investigating an incorrect decision or explaining why an intervention occurred becomes difficult.
• Security and PHI: DUR workflows can expose PHI across APIs, databases, logs, service accounts, and external integrations. Access to each component should be limited to what it requires, with appropriate controls for data transmission, storage, authentication, and auditing.
• Human Oversight: Not every case should end with an automated action. Exceptions, incomplete data, conflicting conditions, or decisions requiring clinical judgment should be routed to an appropriate pharmacist, clinician, or authorized reviewer.

Best Practices for Secure DUR Automation

A production DUR implementation should follow a few core principles:

• Centralize and version rules so policy changes are controlled and traceable.
• Separate decision logic from application code to avoid coupling policy changes to software releases.
• Use approved clinical, drug, formulary, and benefit data as inputs rather than treating the rule engine as the source of clinical truth.
• Apply least-privilege access to PHI, rule-management systems, APIs, databases, and production environments.
• Secure data in transit and at rest across DUR integrations and storage systems.
• Log decisions and rule changes so production outcomes can be traced to the logic and inputs used.
• Test rules against representative scenarios before publishing changes to production.
• Monitor alert volume and outcomes to identify false positives and rules that create unnecessary interventions.
• Maintain human-review paths for ambiguous, exceptional, or high-impact cases.

Automating DUR With Nected

Nected can be used as the rule-decision layer for DUR workflows where pharmacy, payer, or PBM systems already provide the required patient, medication, claims, and benefit data. The DUR logic stays outside the application code, so rule changes do not require changes to the systems processing those transactions.

The implementation can be structured around these capabilities:

• Define DUR rules: Use Simple Rules for individual conditions and Decision Tables for rules that evaluate multiple inputs, such as drug status, prior authorization, step-therapy status, quantity, or refill timing.
• Combine related rules: Use RuleSets to group related DUR conditions and evaluate them as part of a single decision flow rather than maintaining each rule independently.
• Trigger decisions through APIs: Existing pharmacy, payer, or PBM applications can send transaction data to Nected through an API and receive the configured decision as the response.
• Connect decisions to workflows: Route rule outcomes to downstream actions such as a review queue, authorization workflow, API, database update, or other application service.
• Version and audit rule changes: Maintain published rule versions and track changes and executions so a DUR decision can be associated with the logic used at the time it was evaluated.

Bottom Line

DUR automation works best when healthcare organizations separate decision logic from the systems that own pharmacy, claims, patient, and benefit data. Nected can provide the configurable decision layer for deterministic DUR and benefit rules, while existing healthcare systems continue to manage the underlying data, transactions, and clinical workflows. 

With versioned rules, secure integrations, decision traceability, and human review for cases requiring clinical judgment, teams can automate repeatable DUR checks without removing the oversight needed for high-impact decisions.

FAQs

What is drug utilization review?

Drug Utilization Review is a systematic process for evaluating medication use against predefined clinical, safety, utilization, and benefit criteria. It can occur before dispensing, during treatment, or after medication use has occurred.

How does a DUR system work?

A DUR system receives prescription, patient, medication, claims, or benefit data, evaluates that information against configured criteria, generates a result when conditions match, and routes the result to an alert, review process, claim action, or other downstream workflow.

What are the three types of DUR?

The three commonly used categories are prospective DUR, concurrent DUR, and retrospective DUR. Prospective review occurs before dispensing, concurrent review occurs during therapy, and retrospective review analyzes historical medication use.

What are DUR rules?

DUR rules are predefined criteria used to identify potential medication-use problems or benefit conditions. They can cover drug interactions, therapeutic duplication, dosage, duration, utilization limits, formulary requirements, and other approved criteria.

What is an example of DUR?

A pharmacy system may evaluate a new prescription against a patient's existing medications and flag a potential drug-drug interaction before dispensing. A retrospective DUR program may instead analyze claims data to identify members with patterns of excessive utilization.

How is DUR automated?

DUR can be automated by collecting the required data, evaluating it against deterministic rules, generating a decision or alert, and routing the result to the appropriate pharmacy, payer, PBM, reviewer, or downstream system.

How do DUR systems protect PHI?

DUR systems should use appropriate administrative, physical, and technical safeguards for electronic PHI, including access controls, secure data exchange, encryption, logging, and controls over use and disclosure. HIPAA's Security Rule establishes national requirements around the confidentiality, integrity, and availability of ePHI.

What is the difference between DUR and DUE?

DUR generally refers to the review and intervention process used to assess medication use, while DUE is often used for a structured evaluation program designed to measure and improve medication-use practices. The terminology overlaps, and the distinction varies by healthcare setting.

‍