Managing EHR Implementations

Structures EHR implementation planning with workflow analysis, data migration, and go-live readiness. This skill covers the full lifecycle from vendor selection validation through post-go-live stabilization for certified EHR technology (CEHRT) deployments.

Why This Skill Exists

EHR implementations are among the highest-risk health IT projects. Failed or poorly managed deployments disrupt clinical workflows, compromise patient safety, trigger ONC certification non-compliance, and can cost organizations $50-200M in total losses. A structured approach covering workflow redesign, data migration integrity, interface validation, and go-live command center operations reduces the risk of deployment failures that directly affect patient care.

EHR implementation failures have well-documented consequences: the 2013 Cedars-Sinai system shutdown due to physician rejection, multiple health systems reporting increased mortality during go-live periods, and organizations spending 2-3x their original budgets on remediation. Success requires treating EHR implementation as a clinical transformation project, not an IT project.

Checkpoint A --- Intake & Scoping

Answer every question before proceeding. Mark unknowns with [VERIFY].

Implementation type --- New install, system replacement (e.g., Cerner to Epic), module addition, or major version upgrade?
EHR product and version --- Vendor name, product edition, and ONC certification status (check CHPL listing ID)
Facility scope --- Number of sites, beds, ambulatory clinics, and departments in scope. Phased or big-bang approach?
Clinical domains --- Which modules are in scope? (Inpatient, ambulatory, ED, surgery, pharmacy, radiology, lab)
Current state --- What systems are being replaced? What interfaces exist today? Obtain the current interface inventory
Regulatory drivers --- Cures Act compliance deadlines, Promoting Interoperability reporting periods, state-specific mandates
Timeline constraints --- Contractual go-live dates, fiscal year boundaries, seasonal census patterns to avoid
Staffing model --- Internal team capacity vs. vendor/consultant staffing ratios

Required Documents

Vendor statement of work (SOW) and implementation methodology
Current-state IT system inventory and interface map
Clinical workflow documentation (top 20 workflows per department)
Data migration specification and legacy system data dictionary
ONC Health IT Certification requirements checklist (per 170.315 criteria)
Organizational change management plan

Step 1 --- Validate Certification and Regulatory Readiness

Before design begins, confirm the EHR meets mandatory requirements:

Verify the product's ONC CHPL listing covers all required 170.315 certification criteria for your reporting programs (Promoting Interoperability, MIPS)
Confirm USCDI v4 data class support: Allergies, Assessment/Plan, Care Team, Clinical Notes, Encounter Diagnosis, Immunizations, Laboratory, Medications, Patient Demographics, Problems, Procedures, Vital Signs, Health Insurance, Clinical Tests, Diagnostic Imaging
Validate FHIR R4 Patient Access API (170.315(g)(10)) compliance for patient-facing apps
Check information blocking compliance architecture: the system must not prevent, materially discourage, or interfere with EHI access per 45 CFR Part 171

Step 2 --- Conduct Workflow Analysis

For each clinical domain in scope:

Document current state --- Shadow clinicians through 3-5 representative encounters per workflow. Capture click counts, screen transitions, workarounds, and pain points
Map future state --- Design target workflows using the EHR's native capabilities. Identify gaps requiring customization vs. workflow adaptation
Identify integration points --- Where does the workflow depend on external systems (lab instruments, pharmacy dispensing, radiology PACS, blood bank)?
Decision log --- Record every workflow design decision with rationale, approving clinician, and date. These become the reference for post-go-live optimization
Order set and preference list design --- Build specialty-specific order sets with clinical content committee review. Validate against current formulary and evidence-based guidelines
Clinical decision support design --- Map existing CDS rules to the new platform. Prioritize: drug-drug interactions, drug-allergy alerts, evidence-based order sets, and condition-specific best practice alerts. Avoid importing all legacy CDS without review — this is the opportunity to reduce alert fatigue

Step 3 --- Plan Data Migration

Data migration requires its own workstream with dedicated validation:

Scope determination --- Define which data categories migrate: demographics, problem lists, medication lists, allergy lists, historical lab results, documents, appointments, financial balances
Mapping specifications --- Map legacy system fields to EHR target fields. Apply terminology mapping (legacy codes to SNOMED CT, ICD-10-CM, RxNorm) using the mapping-clinical-terminologies skill
Extraction and transformation --- Build ETL pipelines with checksums at every stage. Document transformation rules for data that requires restructuring
Validation protocol --- Define acceptance criteria per data category: 100% match for patient demographics, 99.5% for active medications, 98% for historical results. Run automated row-count and value-distribution comparisons
Cutover rehearsal --- Execute at least two full migration dry runs against production-volume data. Measure elapsed time to confirm the cutover window is achievable

Step 4 --- Interface Build and Testing

Healthcare interfaces are failure-prone and patient-safety-critical:

Interface inventory --- List every inbound and outbound interface with message type (HL7 v2 ADT, ORM, ORU, MDM; FHIR R4 resources), transport (MLLP, SFTP, REST), and sending/receiving system
Build sequence --- Prioritize interfaces by go-live criticality: ADT feeds first, then orders/results, then ancillary
Testing stages --- Unit test (message parse), integration test (end-to-end with partner system), volume test (peak hour simulation), failover test (what happens when the interface engine is down?)
Validation criteria --- Message acceptance rate > 99.9%, no orphaned orders, no duplicate results, correct patient matching on MRN crosswalk
HL7 FHIR considerations --- For systems using SMART on FHIR apps, validate OAuth 2.0 scopes, token lifecycle, and patient-context launch parameters
FHIR API readiness --- Validate FHIR R4 Patient Access API (170.315(g)(10)) functionality before go-live: SMART on FHIR app launch, patient authorization flow, data scope completeness per USCDI v4, and third-party app registration process

Step 5 --- Training and Change Management

Role-based training plans --- Build training curricula by clinical role (physician, nurse, pharmacist, registration, billing) with minimum hours per role
Credential-for-access policy --- No user gets production access without training completion certification
Super user network --- Recruit and train 1 super user per 10 end users per department. Super users complete 2x the standard training hours
Simulation environments --- Provide training environments with realistic patient data (de-identified). Physicians must complete at least 5 simulated encounters before go-live
Communication cadence --- Weekly stakeholder updates starting 12 weeks pre-go-live; daily updates starting 2 weeks pre-go-live

Step 6 --- Go-Live Readiness and Command Center

The final 30 days before go-live follow a structured checklist:

Readiness assessment scoring --- Score each department on a Red/Yellow/Green matrix across: training completion, workflow sign-off, interface testing, data migration validation, downtime procedures
Go/No-Go decision gate --- All departments must be Yellow or Green. Any Red triggers executive escalation and potential delay
Command center structure --- Staff a physical and virtual command center with: EHR vendor analysts, interface engineers, clinical informaticists, pharmacy, nursing leadership, and IT operations
At-the-elbow support --- Deploy super users and vendor support staff to every clinical unit for the first 72 hours minimum
Issue tracking and triage --- Use a severity classification: P1 (patient safety risk, system down), P2 (workflow blocked), P3 (inconvenience, workaround available), P4 (enhancement request). P1 response time < 15 minutes
Downtime procedures --- Validate paper-based backup procedures. Conduct at least one unannounced downtime drill pre-go-live
Post-go-live optimization roadmap --- Before go-live, establish the optimization backlog and prioritization framework. Items deferred during build should be tracked with estimated implementation dates and responsible owners

Checkpoint B --- Post-Go-Live Stabilization Review

Within 30 days of go-live, validate:

[ ] All P1 and P2 issues from command center are resolved or have approved workarounds
[ ] Interface message volumes match pre-go-live baselines (+/- 10%)
[ ] Promoting Interoperability measures are generating data (CEHRT reporting)
[ ] Patient portal (ONC 170.315(e)(1)) is accessible and patients can view USCDI data
[ ] Clinical documentation time-to-completion is within 20% of pre-go-live baseline
[ ] No outstanding data migration discrepancies in active patient records
[ ] Super user support schedule is transitioned to ongoing optimization team
[ ] FHIR Patient Access API is functional and registered in the national endpoint directory
[ ] CDS alert volume is baselined and alert fatigue monitoring is active
[ ] Post-go-live optimization backlog is prioritized with target implementation dates

Quality Audit

[ ] ONC certification criteria coverage is documented and verified against CHPL
[ ] All clinical workflows have signed-off future-state documentation
[ ] Data migration validation report shows acceptance criteria met for all data categories
[ ] Interface testing results are archived with pass/fail evidence
[ ] Training completion rates meet minimum thresholds by role
[ ] Go/No-Go decision is formally documented with sign-off
[ ] Command center issue log is complete with resolution status for every ticket
[ ] Post-go-live stabilization metrics are baselined for ongoing optimization
[ ] CDS rules have been reviewed and rationalized during implementation (not bulk-imported from legacy)
[ ] FHIR API testing confirms USCDI v4 data class availability via US Core profiles
[ ] Post-go-live optimization governance structure is defined with clinical informatics oversight
[ ] Downtime drill results are documented with identified gaps addressed before go-live

Guidelines

Never skip the migration dry-run. Production data volumes expose timing and transformation issues that test datasets cannot
Treat interface testing as a patient safety activity, not an IT checklist item. A dropped lab result or duplicated medication order can cause direct patient harm
Resist scope creep during build: enhancements identified during workflow design go to a post-go-live optimization backlog, not the implementation timeline
Ensure Cures Act information blocking compliance is validated before go-live, not after. The EHR must support patient access to all EHI without special effort
Maintain a clinical decision register linking every build decision to the responsible clinician. This prevents post-go-live disputes about "who approved this workflow"
Plan for a 15-25% productivity dip in the first 4-6 weeks post-go-live. Communicate this expectation to clinical and financial leadership upfront
Archive all implementation artifacts (SOW, design documents, testing evidence, training records) for ONC audit readiness
CDS rationalization during implementation is a once-in-a-decade opportunity. Do not import hundreds of legacy alerts into the new system without clinical review. Start with evidence-based, high-impact alerts and add incrementally based on clinical need
Post-go-live, establish a standing clinical informatics optimization team (not a project team). EHR optimization is continuous and requires dedicated resources beyond the implementation project closeout