No products in the cart.
MODULE 6: DRUG DATABASE & FORMULARY MANAGEMENT
Section 6.2: Version Control and Change Governance
An essential lesson on the rigorous processes required to manage changes to the drug database, ensuring every modification is tested, approved, and documented to maintain system integrity and patient safety.
SECTION 6.2
The Pharmacist’s Double-Check, Digitized
Implementing a Bulletproof Change Management and Governance Framework.
6.2.1 The “Why”: From “Move Fast and Break Things” to “Move Carefully and Save Lives”
In the world of software development, a popular mantra was once “move fast and break things.” The idea was to innovate rapidly, accepting that some errors were an inevitable cost of progress. In healthcare informatics, this philosophy is not just wrong; it is catastrophically dangerous. A “broken” feature in a social media app might mean a button doesn’t work. A “broken” feature in an EHR’s drug database could mean a fatal overdose alert fails to fire, a chemotherapy drug is billed at one-tenth its actual cost, or an entire class of antibiotics becomes unorderable for the whole hospital.
The medication master file is not a sandbox; it is the live, beating heart of the medication-use system. Every change, no matter how seemingly trivial, carries the potential for profound and widespread consequences. Adding a new strength of an antibiotic is not just data entry; it is a modification to a critical clinical system that must be treated with the same gravity as a pharmacist preparing a high-risk sterile compound. This is the “why” of change governance. It is not about bureaucracy or slowing things down. It is the digital translation of the most sacred principle in pharmacy and medicine: First, do no harm.
Change governance, or change control, is the formal process used to ensure that all modifications to the EHR and its databases are introduced in a controlled, coordinated, and safe manner. It provides a structured framework for requesting, analyzing, building, testing, approving, and deploying changes. For a pharmacy informaticist, this process is your safety net, your documentation trail, and your professional standard of care. It transforms the potentially chaotic act of modifying a complex database into a deliberate, predictable, and auditable workflow. Adhering to this process protects the patient from harm, the organization from financial loss, and you from making a career-altering mistake.
Retail Pharmacist Analogy: The Controlled Substance Clarification Protocol
A physician sends an electronic prescription for “Oxycodone 10mg, #120, 1 tablet every 4-6 hours as needed.” However, in the free-text sig field, they also type “Take 1-2 tablets every 4 hours.” The order is ambiguous and contradictory. You do not simply guess the prescriber’s intent and fill it. You activate a rigorous, unwritten “change control” protocol.
- Step 1: The Request & Analysis. The ambiguous prescription is the “change request.” Your analysis immediately identifies a critical safety issue. You place the prescription in your “On Hold/Needs Clarification” queue. This is the equivalent of a change request ticket being submitted.
- Step 2: The “Build” (Clarification). You call the prescriber’s office. You don’t just ask them to “fix it.” You state the problem and propose a clear solution: “Dr. Smith, the quantity of #120 supports a dose of 1 tablet every 4 hours for 20 days, but the sig also allows for up to 2 tablets. To resolve this, would you like me to change the sig to ‘Take 1 tablet by mouth every 4 hours as needed for pain’?” This is your proposed “build.”
- Step 3: The “Test” & “Approval”. The physician agrees. “Yes, that’s correct. One tablet every four hours.” This is their verbal approval. You meticulously document this conversation: the date, time, the person you spoke with, and the exact change approved. You then update the prescription sig in your system. This is your “testing” and “documentation.”
- Step 4: The Final Verification (“Peer Review”). Before the label prints, another pharmacist comes over to perform the final verification. They review the original prescription, your documented clarification, and the final data entry to ensure everything matches. This is the peer review and final approval step in the change control process.
- Step 5: Deployment. Only after all these steps are complete do you fill the prescription and dispense it to the patient. The change is now “live.”
This entire, multi-step process for a single prescription is a microcosm of IT change governance. You would never make a substantive change to a controlled substance order without a formal, documented process. Managing the hospital’s drug database requires that same level of professional rigor, applied at a system-wide scale.
6.2.2 The Three Rings of Safety: Understanding System Environments
The single most important concept that prevents catastrophic failures is the use of separate, isolated system environments. You would never experiment with a new compounding technique for the first time on a real patient’s IV bag. Instead, you would practice with sterile water in a controlled setting. Similarly, informatics professionals never build or modify the “live” EHR that clinicians are actively using. All changes are made in a separate copy of the system and then promoted through a series of environments, each with a specific purpose.
This multi-environment structure is the bedrock of safe change control. While some smaller organizations might combine roles, the three-ring concept of Development, Testing, and Production is the industry standard and the model you must understand.
The Change Promotion Pathway
1. Development (DEV)
The Sandbox
This is a copy of the system where informaticists (“builders”) perform the initial configuration and build. It is a safe space to experiment, create, and even fail without impacting anyone. Patient data in this environment is typically scrambled or anonymized.
2. Test (TST / QA)
The Dress Rehearsal
Once the build is complete in DEV, it is migrated to the Test environment. This is a stable, controlled copy of the system where formal testing occurs. The builders, other analysts, and end-users (like nurses and pharmacists) access TST to validate that the change works as expected and doesn’t break anything else.
3. Production (PROD)
The Live Show
This is the “live” system that clinicians use for real patient care. No building or testing is ever done in PROD. Changes are only migrated to PROD from the TST environment after they have been fully tested, documented, and approved. This migration is a carefully scheduled and controlled event.
6.2.3 The Change Control Lifecycle: From Request to Release
Every change to the drug database, from adding a new NDC to building a complex chemotherapy regimen, follows a structured lifecycle. This process is typically managed using a ticketing system (like ServiceNow, JIRA, or a homegrown solution) that provides an auditable record of every step.
The Pharmacist’s Playbook: Navigating a Change Request
As a pharmacy informaticist, you are both a builder and a project manager. Understanding and expertly navigating this lifecycle is a core competency of your role. Let’s walk through the detailed steps of a common request: “Add the new FDA-approved antibiotic, Ceftobiprole, to the formulary.”
1The Request: Submission & Triage
The process begins when a stakeholder identifies a need. The Pharmacy Director, after the P&T Committee meeting, submits a formal request via the ticketing system. The request includes the “what” (Add Ceftobiprole) and the “why” (P&T approved it for treating MRSA pneumonia). The informatics team lead receives this ticket, confirms it’s a valid request, and assigns it to you.
2Analysis & Design: Asking the Right Questions
This is the critical thinking phase. Before you build anything, you must become an investigator, gathering all the necessary attributes. You don’t just add “Ceftobiprole.” You ask:
- Clinical: What is the standard dose? Frequency? Renal adjustments? Is it compatible with NS and/or D5W? What is its allergy class (a new cephalosporin subclass)?
- Operational: Will it be stocked in ADCs? Is it refrigerated? Does it need special handling? Which NDCs will we be purchasing?
- Billing: What is the AWP? Is there a HCPCS code? Will it be 340B eligible?
You compile all this information into a “build sheet” or design document within the ticket. This is your blueprint.
3The Build: Configuration in the DEV Environment
With your blueprint in hand, you log into the DEV environment. You meticulously create the new medication records, following the hierarchy. You build the orderable record (“Ceftobiprole 500 mg Injection”), populating all the clinical, operational, and billing fields from your analysis. You link it to the correct allergy class. You add the NDC records provided by the procurement team. You document your build steps in the ticket. This is the hands-on configuration work.
4The Testing Phase: Validation in the TST Environment
Your build is complete in DEV. Now, you request that it be migrated to the TST environment. Once there, you execute a formal test script (which we will detail next). You log in as a physician and try to order it. Does it show up correctly? Do the defaults populate? You log in as a pharmacist. Can you verify it? Does the label print correctly? You log in as a nurse. Can you document administration? Does it show up correctly on the MAR? You might also ask the Pharmacy Director (the original requestor) to log into TST and perform User Acceptance Testing (UAT) to confirm it meets their expectations. You document all test results—pass or fail—in the ticket.
5Approval & Scheduling: The Go/No-Go Decision
Your build is complete and testing has passed. You now formally present the change for approval. This is often done at a weekly Change Advisory Board (CAB) meeting, which includes leaders from IT, clinical departments, and pharmacy. You present your ticket, the build, and the successful test results. The board reviews it to ensure it doesn’t conflict with other changes and gives the final “Go” for deployment. The change is then scheduled for migration to the live environment, typically during a low-traffic time like overnight or on a weekend.
6Deployment & Post-Release Verification
At the scheduled time, the system administrators migrate your fully tested build from the TST environment into the PROD environment. The change is now live. Your job is not over. The first thing you must do is log into PROD and perform a “spot check” to ensure the new medication record moved over correctly and is orderable. You communicate to the pharmacy staff that the drug is now available for use. You monitor the system for any unexpected issues and keep the ticket open for a day or two before formally closing it.
6.2.4 A Masterclass in Verification: Deep Dive into Testing Methodologies
“Testing” is not a single action; it’s a multi-faceted discipline. Simply building a record and ordering it once is not sufficient. A rigorous testing plan is required to ensure a change is not only functional but also safe and integrated. As the analyst, you are responsible for developing and executing this plan. Your ability to think like a detective, anticipating potential failure points, is a critical skill.
The Four Pillars of Robust Testing
| Testing Type | Core Question | Performed By | Example for the New Antibiotic “Ceftobiprole” |
|---|---|---|---|
| Unit Testing | “Does the individual piece I built work correctly in isolation?” | The primary builder (You) |
In the TST environment, you perform a checklist of basic functions:
|
| Integration Testing | “Does my piece work correctly when it interacts with other parts of the system?” | You, plus other analysts |
You test the end-to-end workflow, which crosses multiple system modules:
|
| User Acceptance Testing (UAT) | “Does this change meet the needs and expectations of the end-users who requested it?” | End-users (Pharmacists, Nurses, Physicians) |
You sit with the Pharmacy Director and an Infectious Disease physician and give them a script:
|
| Regression Testing | “Did my change accidentally break something else that used to work?” | You and automated testing scripts (if available) |
The Most Overlooked—and Dangerous—GapThis is the most difficult but most important type of testing. Your change might work perfectly, but it could have unintended consequences. For example, by adding a new Cephalosporin allergy class, did you inadvertently disrupt the cross-sensitivity alerts for Penicillins?
|
