No products in the cart.
MODULE 6: DRUG DATABASE & FORMULARY MANAGEMENT
Section 6.3: Formulary Tiering and Coverage Policies
Learn how to translate P&T Committee decisions into system reality. We’ll explore the technical builds for formulary restrictions, therapeutic interchanges, and prior authorization rules that drive cost-effective care.
SECTION 6.3
From P&T Minutes to Clinical Practice
Architecting the Rules Engine of the Digital Formulary.
6.3.1 The “Why”: Proactive Enforcement vs. Reactive Firefighting
As a practicing pharmacist, you are a master of reactive formulary management. A prescription comes in for a non-formulary medication, and you spring into action. You investigate alternatives, you call the prescriber with a recommendation, you page them about a prior authorization—you are the human firewall enforcing the Pharmacy & Therapeutics (P&T) Committee’s decisions. This is essential, skilled work, but it is fundamentally reactive. It happens *after* the decision to prescribe the “wrong” drug has already been made. This process is inefficient, frustrating for both you and the prescriber, and can lead to significant delays in patient care.
The core purpose of formulary informatics is to shift this entire process from reactive to proactive. Instead of being the firewall, your job is to build the guardrails directly into the system, guiding the prescriber to the most clinically appropriate, cost-effective choice *at the moment of ordering*. The EHR should not be a passive receptacle for orders; it must be an active participant in the decision-making process, hardwired with the collective intelligence of the P&T Committee.
When the P&T Committee decides to make losartan the preferred ARB over olmesartan due to equivalent efficacy and lower cost, that decision should not just be an entry in the meeting minutes or a memo sent to the medical staff. That decision must be translated into a tangible, functional reality within the EHR. This means building logic that makes losartan easy and attractive to order, while making olmesartan difficult or impossible to order without a compelling reason. This section is a deep dive into the specific informatics tools and techniques you will use to accomplish this. You will learn how to build formulary restrictions, therapeutic interchange alerts, order questions, and other forms of clinical decision support that transform P&T policy into concrete, system-enforced clinical practice. This is how you scale your expertise from a single phone call to a system-wide standard of care.
Retail Pharmacist Analogy: Designing Your Pharmacy’s “Formulary” Layout
Think about how you strategically organize your physical pharmacy to guide customers and manage inventory. This is a perfect physical analogy for building a digital formulary.
- Tier 1 (OTC Generics): You place the store-brand acetaminophen and ibuprofen on the most prominent, eye-level shelf space in the pain reliever aisle. They are easy to find, inexpensive, and accessible to everyone. This is your unrestricted, formulary, preferred generic tier.
- Tier 2 (Preferred Brands): You still carry Advil® and Tylenol®, but you might place them on a slightly higher or lower shelf. They are available, but your layout subtly encourages the more cost-effective generic. This is your formulary, preferred brand tier.
- Non-Formulary (Competitor’s Brands): You don’t carry the generic ibuprofen from a competing pharmacy chain. If a customer insists on it, you have to tell them, “I’m sorry, we don’t stock that specific brand.” This is a hard stop, just like a non-formulary restriction.
- Restricted (Behind the Counter): A patient wants pseudoephedrine. It’s available, but it’s not on the open shelf. They have to come to the pharmacy counter, show their ID, and you have to personally dispense it. This is a formulary drug with restrictions—it’s available, but only through a specific, controlled workflow.
- Therapeutic Interchange: A customer asks for the expensive nasal decongestant spray that’s kept behind the counter. You, the expert, intervene: “You can certainly have that, but did you know that the generic pseudoephedrine tablets work just as well for most people and are a fraction of the cost?” You are presenting a preferred therapeutic alternative at the point of decision.
Your role as a pharmacy informaticist is to be the digital planogram designer. You are arranging the virtual shelves of the EHR to make the right choices easy, the less-preferred choices harder, and the wrong choices impossible, all based on the blueprints provided by your P&T Committee.
6.3.2 The Spectrum of Control: Deconstructing Formulary Status and Restrictions
The first step in translating policy to practice is defining the “status” of every drug in the master file. This is not a binary “formulary vs. non-formulary” switch. It is a spectrum of control, with each level having specific implications for prescribers, pharmacists, and patients. As an informaticist, you must master the precise definition and technical build required for each status.
Masterclass Table: The Formulary Status Matrix
| Formulary Status | Clinical/Operational Definition | Prescriber Experience | Pharmacist Workflow | Informatics Build & Key Attributes |
|---|---|---|---|---|
| Formulary – Preferred | A clinically effective, safe, and cost-effective agent. The standard of care for its indication. | Effortless. The drug is easy to find, often appears as a “favorite” or at the top of search results. Defaults are optimized for standard use. | Standard verification and dispensing. No extra steps. |
|
| Formulary – Restricted | Clinically necessary for specific situations but prone to misuse, high cost, or requires expert oversight (e.g., linezolid, high-cost chemotherapy). | Conditional. The drug is orderable, but the act of ordering triggers additional requirements: a warning pop-up, mandatory order questions (“Does patient have a documented VRE infection?”), or a hard stop requiring a call to pharmacy. | Verification is often blocked pending review of criteria or a clinical consult. May require a pharmacist to enter an override code to approve the order. |
|
| Non-Formulary | A drug for which a preferred, equally effective, and safer/less costly alternative exists on formulary. Its use is discouraged. | Discouraged. The drug is very difficult or impossible to order directly. Ordering it often triggers a non-interactive alert suggesting the preferred alternative(s). A formal “Non-Formulary Request” process is usually required. | Orders that get through require significant intervention: contacting the prescriber, documenting the rationale, and potentially converting the order to the formulary alternative per protocol. |
|
| Not for Use / Do Not Use | A medication deemed unsafe or for which a vastly superior agent exists. Its use is essentially prohibited (e.g., meperidine for pain management). | Blocked. The drug is completely hidden from prescriber search and cannot be ordered. In some cases, searching for it may display a hard stop alert explaining why it’s not used. | No workflow, as orders cannot be initiated. Pharmacists may be involved in educating prescribers who call asking for the drug. |
|
6.3.3 The Build Masterclass: Architecting Clinical Restrictions
A “restriction” is not a single setting; it is a category of powerful tools. As the informaticist, you must choose the right tool for the job based on the P&T Committee’s intent. Is the goal to limit a drug to experts, or to ensure it’s used only for a specific diagnosis? Each requires a different type of build.
The Restriction Builder’s Toolkit
Let’s explore the most common types of restrictions you will be asked to build, using the example of a new, very expensive, broad-spectrum antibiotic called “Superpenem.” The P&T committee wants it on formulary but restricted to the Infectious Disease (ID) service for patients with documented multi-drug resistant infections.
Restriction by Prescriber Service/Specialty
The Goal: To ensure that only specialists with the appropriate expertise can initiate therapy.
The Informatics Build: This is one of the most common and effective restrictions. In the EHR, every provider is associated with a primary service or department (e.g., Cardiology, Oncology, Infectious Disease). The build involves creating a “restricted list” of these services and linking it to the medication record.
IF Order.Medication = “Superpenem”
AND User.Service NOT IN (“Infectious Disease”, “ID Consult”)
THEN Block Order AND Display Alert: “Superpenem is restricted to the ID service. Please consult ID to order.”
The “Covering Provider” Pitfall
What happens when the ID fellow is off for the weekend and a general medicine resident is covering their patients? The resident is not on the “Infectious Disease” service list and will be blocked from re-ordering or adjusting the dose. Your build must have a clearly defined and communicated override process (e.g., a phone call to the on-call pharmacist) to handle these real-world workflow challenges.
Restriction by Clinical Criteria (Order Questions)
The Goal: To force the prescriber to document the specific, approved indication at the time of ordering.
The Informatics Build: This involves building a set of mandatory questions that interrupt the ordering process. The answers are documented as part of the order, providing a clear audit trail for the pharmacist to review.
Order Verification for “Superpenem”
Documented multi-drug resistant P. aeruginosa
Documented carbapenem-resistant Enterobacteriaceae
Other (Requires ID approval)
The system can be configured so that if the prescriber selects “Other,” the order cannot be signed and they are instructed to contact ID. This build is more flexible than a service restriction but relies on accurate prescriber attestation.
Restriction by Patient Diagnosis
The Goal: To link medication use directly to a documented problem on the patient’s chart. This is common for ultra-high-cost drugs for specific genetic disorders.
The Informatics Build: This is a more advanced and complex form of CDS. It requires the system to query the patient’s active problem list for a specific ICD-10 code before the order can be completed.
IF Order.Medication = “CysticFIBRO-Lytic”
AND Patient.ProblemList DOES NOT CONTAIN (“E84.0”, “E84.9”)
THEN Block Order AND Display Alert: “This medication is restricted to patients with a diagnosis of Cystic Fibrosis.”
The “Dirty Data” Problem
This build is only as reliable as the patient’s problem list. If a physician has not yet updated the problem list with the correct diagnosis code, the rule will fail, blocking a clinically appropriate order. This can be a major source of frustration and requires a robust process for managing and updating patient problem lists across the institution.
6.3.4 The Build Masterclass: Hardwiring Therapeutic Interchanges
A therapeutic interchange policy is one of the most powerful tools for standardizing care and controlling costs. But a policy on paper is useless if not enforced. As an informaticist, your job is to build an active, intelligent interchange system that makes doing the right thing the easy thing for prescribers.
The goal is not just to block the non-preferred drug but to seamlessly offer and facilitate the switch to the preferred agent. A well-built interchange is one of the most satisfying informatics projects, as it provides a clear, measurable return on investment and improves patient care.
Anatomy of an Interactive Interchange Alert
Let’s design the user experience for a P&T-approved interchange from the non-formulary PPI pantoprazole to the preferred, formulary PPI omeprazole.
1. Physician orders non-preferred drug: Pantoprazole 40 mg IV daily
Formulary Interchange Alert
Pantoprazole is non-formulary. The preferred formulary alternative is Omeprazole.
Would you like to change the order to the equivalent dose of Omeprazole 40 mg PO daily?
3. Physician clicks “Accept Alternative”
System Response
The system automatically performs two actions in the background:
- The original order for Pantoprazole 40 mg IV daily is cancelled.
- A new, unsigned order for Omeprazole 40 mg PO daily is created and presented to the physician for their final signature.
The Unsigned Order: A Critical Safety Step
Note the critical detail in Step 4: the new order is unsigned. The system should never be allowed to place a final, active order on a physician’s behalf. The interchange alert presents a clinically equivalent *suggestion*, but the prescriber must always perform the final review and electronically sign the new order, confirming their intent. This maintains the chain of accountability and is a fundamental principle of safe CDS design.
