Section 2: Parallel Runs and Cutover Techniques

• Speed & Simplicity (of Concept): The project has a clear, definitive end date. All energy and resources are focused on a single event. There is no need to build, maintain, or pay for complex temporary interfaces between old and new systems.
• Forced Adoption: There is no safety net. Users cannot revert to old workflows, which forces them to learn and adapt to the new system quickly. This can accelerate the time to realize the project’s benefits.
• Reduced Technical Complexity: The technical team only has to support one production system post-go-live. This simplifies troubleshooting and maintenance significantly.
• Clear Focus: All training, communication, and support efforts are concentrated on a single target state. There is no confusion about which system to use for which task.

• Catastrophic Failure Potential: Any significant unforeseen issue (e.g., data corruption, critical system bug, major interface failure) affects the entire organization simultaneously. There is no isolated “blast radius.” A failure can bring the entire hospital to a standstill.
• Intense Pressure on Support Teams: Go-live day and the subsequent weeks are a period of extreme stress. The command center is flooded with issues from all departments at once, making triage and prioritization incredibly difficult.
• Insufficient Training Payoff: Despite best efforts, users will not have mastered the system. The initial drop in productivity will be steep and organization-wide, potentially impacting patient throughput and length of stay.
• Rollback is Nearly Impossible: Once the go-live occurs and new patient data begins to flow into the new system, rolling back to the old system is a Herculean task. It often requires manually re-entering all the data that was entered into the new system, which is often not feasible. The only path is forward.

• New Facilities (“Greenfield”): When opening a brand-new hospital or pharmacy that has no legacy system to migrate from.
• Complete System Replacement: When the legacy system is being fully decommissioned and is so outdated that building interfaces to it would be impossible or prohibitively expensive.
• Tightly Integrated Systems: For systems where modules are so deeply intertwined that a phased approach is technically impossible (e.g., the core clinical suite of an EHR).
• Small-Scale Deployments: For smaller, less complex projects, like implementing a new temperature monitoring system, where the impact of a failure is contained and manageable.

For a direct cutover of a medication-use system, the pharmacy informatics team is the absolute center of the storm. Your focus must be on:

• Flawless Pre-Go-Live Validation: You must be ruthlessly meticulous in your testing. Your sign-off on the Go/No-Go checklist is a declaration that you have personally witnessed and validated every high-risk medication workflow and found it to be safe. This includes formulary data migration, order set functionality, ADC integration, and IV workflow management.
• Downtime Procedure Mastery: You must be the institutional expert on the medication-use downtime process. During the cutover, the pharmacy will be operating on paper. You must ensure every pharmacist and technician is trained and drilled on these procedures.
• Command Center Leadership: The pharmacy must have a strong, decisive, and knowledgeable presence in the command center 24/7. You will be triaging medication-related issues that could range from a malfunctioning label printer to a critical clinical decision support alert firing incorrectly.
• Hyper-Vigilant Post-Live Auditing: In the first 24-48 hours, you should be proactively auditing orders and MARs, looking for trends and potential errors before they are reported. You are not just waiting for problems; you are hunting for them.

• Risk Containment: This is the primary advantage. A critical issue in Phase 1 only affects the pilot unit. This gives the project team time to fix the problem before it is deployed to the entire organization, dramatically reducing the “blast radius” of any failure.
• Iterative Learning: The project team gets to learn and refine its processes in a real-world setting. Lessons learned from the ICU go-live can be applied to make the Med/Surg rollout smoother. Support models, training materials, and even system configuration can be optimized based on feedback from early adopters.
• Reduced Support Strain: The command center and at-the-elbow support resources are not overwhelmed. They can focus their attention on a smaller group of users at any given time, providing a higher quality of support.
• Builds Momentum & Confidence: A successful pilot in one department can create champions and generate positive buzz, which can help with user adoption in later phases.

• Extended Timeline & “Go-Live Fatigue”: Phased rollouts can take many months or even years. This can lead to project team burnout and a sense of “change fatigue” among end-users who feel like they are in a perpetual state of implementation.
• The Hybrid Workflow Problem: This is the single biggest clinical risk. For the duration of the rollout, the hospital is operating in two worlds. A patient might be admitted through a legacy system, transfer to a “live” CPOE unit, and then transfer back to a legacy unit for discharge. This creates massive potential for communication breakdowns and medication errors.
• Need for Temporary Interfaces: To manage the hybrid state, you often need to build complex, expensive, and disposable interfaces to keep the old and new systems in sync. For example, you might need an interface to pass ADT information from the new system back to the old one. These are costly to build and are a common point of failure.
• Cost: While the risk is lower, the overall cost of a phased approach is often higher due to the extended timeline, the need for temporary interfaces, and longer periods of dedicated project team staffing.

• Large, Multi-Facility Health Systems: It’s the standard approach for rolling out a new EHR across multiple hospitals. You go live at one hospital, stabilize, and then move to the next.
• Highly Risk-Averse Organizations: For institutions where the tolerance for any operational disruption is extremely low.
• Modular Implementations: When implementing a system with clearly distinct modules that can function semi-independently (e.g., implementing a new outpatient module before tackling the inpatient one).
• When introducing a brand new, unproven technology or workflow: The pilot approach allows you to test and refine a novel concept on a small scale before wider adoption.

In a phased rollout, the pharmacy informaticist becomes a master of managing complexity and communication. Your focus is on:

• Designing Safe Hybrid Workflows: You must be at the center of designing the procedures for managing patients who move between “live” and “legacy” units. This involves creating incredibly clear policies. Example: “When a patient transfers from the ICU (live on CPOE) to 4-North (legacy), a full, printed MAR from the new system MUST be sent with the patient, and a pharmacist MUST perform a full verbal handoff with the receiving nurse to reconcile all active orders.”
• Championing Interface Integrity: You must be obsessive about testing the temporary interfaces. You need to validate that medication orders, allergies, and patient demographics flow correctly between the two systems.
• Targeted Training: Your training must be highly specific to the hybrid workflows. Staff need to know not just how to use the new system, but when to use the new system versus the old one.
• Managing Formulary & Order Set Synchronization: If you add a new drug to the formulary, you have to add it to both the old and new systems. This dual maintenance is a significant workload and a potential source of error that you must manage.

• Highest Level of Safety & Risk Mitigation: This is the paramount benefit. The new system is exhaustively proven with live data and workflows before it is allowed to become the system of record. The risk of a catastrophic data or calculation error at cutover is virtually eliminated.
• Seamless Rollback: If unsolvable problems are found in the new system during the parallel period, the rollback plan is simple: stop using the new system. The legacy system has remained fully operational throughout.
• Builds Ultimate User Confidence: Staff see the new system working and producing correct results day after day, which significantly eases their anxiety about the final cutover.
• Excellent Training Vehicle: The parallel run provides the most realistic training environment possible, as users are learning on the live system with real patient scenarios.

• Prohibitively High Cost & Resource Drain: This is the main reason this strategy is rare. It effectively requires doubling the staff workload for the duration of the run. This can mean massive overtime costs, bringing in temporary staff, or pulling clinical staff away from patient care to perform reconciliation tasks. It is often financially unfeasible.
• Staff Burnout and Data Entry Errors: Asking staff to do their job twice is exhausting and demoralizing. As fatigue sets in, the risk of making simple data entry errors in one or both systems increases, which then complicates the reconciliation process.
• User Confusion: Despite training, it can be confusing for staff to know which system is the “real” one and what to do if they see a discrepancy.
• Technical Complexity: While you avoid temporary interfaces, ensuring that both systems receive the exact same inputs can be technically challenging.

• Mission-Critical Financial Systems: This is a common strategy for implementing a new billing or payroll system. The cost of an error is so high that the cost of the parallel run is justified to ensure 100% accuracy.
• Core Pharmacy Dispensing Systems: When implementing a new pharmacy information system or a critical piece of automation like a new IV workflow manager, a parallel run might be used for a short period to verify that every label, every calculation, and every dispense is perfect.
• Life-Support Systems: Any system where a calculation or output error could have immediate, lethal consequences.

In a parallel run, the pharmacy informaticist is the operational commander of the validation process. Your job is to design and execute the reconciliation. Your focus is on:

• Designing the Reconciliation Process: You must create the standard work. This means building checklists and comparison reports. Example: “At 14:00 daily, Technician A will print the ‘ADC Restock Report’ from the legacy system. Technician B will print the same report from the new system. Pharmacist C will perform a line-by-line comparison and document any discrepancies on the Reconciliation Log.”
• Leading the Discrepancy Investigation: When a mismatch is found, you lead the forensic investigation. Was it a simple typo by the user? Or is it a flaw in the new system’s calculation logic? This requires deep analytical skill.
• Managing the Human Factor: You must constantly work with the pharmacy staff, keeping them engaged in a tedious process and reinforcing the importance of their dual data entry.
• Defining “Success”: You help leadership define the exit criteria. For example: “We will cut over to the new system after five consecutive business days with zero P1 (high-risk) discrepancies and less than a 1% variance on P2 (low-risk) discrepancies.”