Telehealth platforms have solved the access problem. A patient can see a provider, get a diagnosis, and receive a prescription without leaving their couch. What most platforms haven't solved is the safety layer that traditionally sits between the prescription and the patient.
In a brick-and-mortar pharmacy, a pharmacist performs Drug Utilization Review before dispensing. In a hospital, the EHR flags interactions and contraindications at the point of ordering. In a telehealth workflow that routes prescriptions directly to a mail-order pharmacy or e-prescribing network, that safety layer often doesn't exist. The prescription goes from provider to patient with no automated clinical checks in between.
This is the compliance gap in telehealth prescription safety, and it's growing as fast as the industry.
What OBRA '90 Actually Requires
The Omnibus Budget Reconciliation Act of 1990 established the federal mandate for Drug Utilization Review. Every state Medicaid program must maintain a DUR program, and in practice, the requirements have become the baseline expectation for all prescription processing regardless of payer.
OBRA '90 requires prospective review of six categories before dispensing:
- Drug-drug interactions — checking the new prescription against the patient's active medications
- Allergy screening — cross-referencing against documented allergies
- Therapeutic duplication — identifying overlapping medications serving the same purpose
- Dose appropriateness — verifying the dose is within accepted ranges for the patient
- Duration of treatment — checking that days supply and quantity are clinically appropriate
- Clinical abuse or misuse — patterns suggesting inappropriate prescribing or use
The law places this obligation on the dispensing pharmacist. But here's the disconnect: telehealth platforms are generating prescriptions at scale, often with minimal clinical context passed downstream. The pharmacist receiving an e-prescription from a telehealth encounter may not have the patient's full medication list, allergy history, or clinical profile needed to perform meaningful DUR.
The result is that the legal obligation exists but the practical ability to fulfill it is compromised. The prescribing platform has the clinical context. The pharmacy has the legal obligation. Neither has both.
Why Telehealth Platforms Don't Have CDS Built In
Traditional Clinical Decision Support (CDS) systems are designed for EHRs — large, integrated platforms where the patient's complete record lives in one place. They're built as modules within Epic, Cerner, or Allscripts, tightly coupled to the data model and workflow of that specific system.
Telehealth platforms are architecturally different. They're typically built as modern web applications — React frontends, microservice backends, third-party integrations for video, scheduling, and e-prescribing. The CDS module from an enterprise EHR doesn't plug into this stack. And the traditional CDS vendors (FDB, Wolters Kluwer, Medi-Span) sell through enterprise licensing models with integration timelines measured in quarters, not sprints.
So telehealth startups face a choice: spend 6-12 months and significant budget integrating an enterprise CDS solution, or ship without safety checks and rely on the downstream pharmacy to catch problems. Most choose the latter. It's rational in the short term and dangerous in the long term.
The Risk Calculus Is Changing
Three trends are making the "let the pharmacy handle it" approach untenable:
Regulatory scrutiny is increasing. State boards of pharmacy and the DEA are paying more attention to telehealth prescribing patterns, particularly for controlled substances. The Ryan Haight Act already requires specific conditions for prescribing controlled substances via telehealth. As pandemic-era flexibilities expire, enforcement is tightening.
Malpractice exposure is real. When an adverse drug event occurs and the prescribing platform had the patient's medication list but didn't check for interactions, the liability question gets uncomfortable. "We didn't have CDS" is an explanation, not a defense. Plaintiff attorneys are increasingly including the technology platform in addition to the prescriber.
Payer requirements are emerging. Health plans and PBMs are beginning to require evidence of prospective DUR from telehealth prescribers as a condition of network participation. This isn't universal yet, but the direction is clear.
How a REST API Approach Fills the Gap
The reason telehealth platforms don't have CDS isn't that the clinical logic is impossible. It's that the delivery mechanism has been wrong for their architecture. Enterprise CDS is built for enterprise systems. Telehealth needs CDS delivered the way everything else in their stack is delivered: as an API.
A REST API approach to clinical decision support means:
No integration project. A single HTTP endpoint that accepts a prescription payload and returns safety findings. If your platform can make a POST request — and it can, because it already talks to e-prescribing APIs, identity verification services, and payment processors — it can add clinical safety checks.
Milliseconds, not minutes. The API call fits into the existing prescription workflow without adding a separate step. Call it when the provider clicks "sign prescription," display any high-severity findings before the prescription is transmitted, log the response for compliance.
Full OBRA '90 coverage. A well-designed clinical review endpoint checks all six DUR categories in a single call: drug interactions, allergies, dose validation, therapeutic duplication, patient profile analysis, and prescriber credential verification. One request, one response, full coverage.
Audit trail included. Every API response is a timestamped, structured record of what was checked and what was found. This is exactly the documentation that regulators and legal teams need — proof that prospective review happened, what it found, and what action was taken.
What the Integration Looks Like
The practical integration is straightforward. At the point in your prescription workflow where the provider confirms the order, your backend makes a POST to the clinical review endpoint with the drug, patient demographics, active medications, allergies, and prescriber NPI.
The response comes back with each DUR category evaluated. Your frontend renders the findings based on severity:
- High severity — block submission, require the provider to acknowledge or modify the prescription
- Moderate severity — show a warning, allow override with documented reason
- Low/info severity — log for audit, don't interrupt the workflow
This pattern takes a week to implement, not a quarter. The hardest part isn't the API integration — it's designing the provider-facing UX so that warnings are helpful without causing alert fatigue. That's a product design problem, not a technology problem.
The Compliance Argument Is Also the Business Argument
Adding clinical safety checks to a telehealth platform isn't just about avoiding regulatory problems. It's a competitive advantage. Health systems evaluating telehealth partners ask about CDS capabilities. Payer contracts increasingly require it. And providers using the platform trust it more when it has the same safety guardrails they're accustomed to in an EHR.
The platforms that treat prescription safety as a launch requirement rather than a future roadmap item are the ones that will still be operating when the regulatory environment catches up to the technology.
The arxio /v1/clinical-review endpoint provides full OBRA '90 DUR coverage in a single API call. See the documentation for integration details, or try the demo to see a clinical review in action.
This post is educational. It does not constitute medical or legal advice.