EHR Implementation Checklist: Migration, Training, and Go-Live

EHR implementation is the coordinated work of moving a clinic onto an electronic health record that its people can use reliably—not simply installing the software. A useful checklist connects each requirement to an owner, an expected result and evidence that the receiving workflow works.

Start with these eight checks: agree the launch scope; name the decision makers; map and validate the records; test connected workflows; verify access; demonstrate staff competence; rehearse downtime and cutover; then make a documented go/no-go decision. A project can complete its import and training sessions while still being unready to see patients in the new system.

This guide is for clinical informaticists, implementation leads and practice managers, especially teams replacing an outpatient EHR. It uses the Health IT Playbook to organize responsibilities, migration checks, training and launch decisions.

Sources checked October 22, 2026. U.S. guidance is identified as such; the NHS examples describe England.

Canadian EMR implementation: confirm the requirements and resources applicable to your province or territory and organization. Alberta teams can start with the Alberta Medical Association’s EMR implementation resources, which cover vendor agreements, privacy and security, data migration, and acceptance. The linked resource is specific to Alberta. Record the applicable requirements, source and approving owner in the readiness record below.

Define the launch scope and sequence

Write one operational sentence before building a schedule. For example: “Move the adult outpatient service’s registration, clinical documentation, results inbox and patient portal to the new EHR; retain historical scanned records in the approved read-only archive.” That sentence should name exclusions as well as included workflows. If prescribing, billing or a satellite clinic is excluded, state where it will continue and how the boundary will work.

EHR implementation includes migration and integration, but those are different jobs. Migration moves existing information; integration connects systems that continue operating. A note archive can be complete even when tomorrow’s laboratory results have no working destination. The EHR integration guide covers interface selection in more detail.

Use dependency gates instead of assuming every project takes the same number of weeks:

1. Scope accepted: clinical services, sites, record categories, interfaces and accountable owners are agreed.
2. Build ready for rehearsal: configuration, permissions, data mapping and a safe test environment are available.
3. Rehearsal accepted: migration defects and workflow failures are corrected and retested.
4. People and cutover ready: staff demonstrate their tasks, coverage is funded and recovery is rehearsed.
5. Launch authorized: named leaders review the evidence and approve the precise operating scope.
6. Stabilization accepted: ongoing support can take responsibility without the temporary project team.

The Playbook distinguishes preparation—governance, communication, workflow redesign and education—from implementation work such as tailoring the system, bringing in history and supporting staff. Use that distinction to expose dependencies. Training on an unfinished configuration creates rework; booking go-live before a usable export arrives converts a dependency into a deadline dispute.

For an introductory explanation of what the system does, see what an EHR is in healthcare. Here, the decision is whether the new arrangement is ready to operate.

Illustrative outpatient project plan: schedule from dependencies

This fictional eight-week plan covers one outpatient site, one results interface and the scoped workflows above. Week 1 starts after contracts, funding, supplier availability, a usable export route and a safe test environment are confirmed. Procurement and supplier waiting time sit before this window. Set your launch date from the accepted dependencies and rehearsal results.

How to use the allowance: if the results interface is not ready at the end of week 3, move the joint rehearsal and dependent training/cutover dates. Roster planning can continue in parallel while the retest window stays protected. Reconfirm supplier slots, staff coverage and overlap costs after the change. Extend the five-day allowance when blockers remain unresolved.

Assign responsibility before configuring the system

The Playbook’s leadership-team resource, published in October 2016, distinguishes project coordination from clinical, technical and operational leadership. Small teams may combine roles. Combining roles does not remove the need to identify who accepts the result.

Use this matrix to assign delivery and acceptance. Responsible means doing or coordinating the work; accountable means owning its acceptance. Name the actual people and backups. Consult the affected teams before changes, and inform all affected users when the approved configuration or workflow changes.

On narrow screens, swipe tables sideways or focus a table region and use the arrow keys.

Do not leave “vendor” as the only owner of an unresolved clinical workflow. The supplier may repair the mapping, while the clinic decides whether the repaired record is fit for its intended use. Equally, do not make a clinical lead responsible for technical evidence they cannot inspect: pair the acceptance decision with the appropriate technical reviewer.

Protected time belongs in the plan. An implementation lead who still carries a full operational workload needs either released capacity or a narrower scope. Record which duties will be covered, by whom and for how long.

Migration checks: preserve meaning and unfinished work

Start with a source-to-target inventory. For each category, record the source, included population and dates, target location, transformation rule, validation method, owner and fallback access. Define what is deliberately excluded and who approved that decision.

The Chart Migration and Scanning Checklist is a paper-to-EHR planning resource from 2016. Its distinction between information that is viewable as a scan and information entered for structured use remains useful. A readable PDF is not automatically an allergy field, a searchable result trend or a functioning follow-up task.

Validate at three levels: population (what arrived or failed), meaning (whether important fields survived correctly), and use (whether the intended staff member can find and act on it). Keep excluded, rejected and unresolved records visible in the denominator rather than reporting only successful imports.

Choose the review sample before looking at the results. Include ordinary records and deliberately challenging cases: duplicate identifiers, amended reports, multiple attachments, inactive clinicians, restricted access and outstanding tasks. Record the sample size and selection method; expand the review when a defect suggests a systematic mapping error.

England’s NHS data-checking guidance describes an initial comparison, supplier remediation, a recheck and sign-off. It also addresses work that cannot migrate automatically. Confirm each supplier’s responsibilities in your migration agreement.

Before retiring the old system, prove the agreed archive can still retrieve the records and their attachments. The medical records software guide explains why a readable patient copy and a reconstructable migration export are different deliverables.

EI-01: a successful import that is not ready for go-live

Fictional migration rehearsal.

A clinic is rehearsing a Monday launch. Its agreed scope includes 240 synthetic patient records, 620 attachments and 18 unresolved results/referral tasks. The trial extract closes at Friday 18:00, clinic local time. The configuration is labeled build C / mapping v3. A delta ledger must capture later activity.

For synthetic patient TEST-EI-017, the source contains report R-44 version 1, an outstanding review task, and a covering clinician who has accepted responsibility for Monday’s inbox. An amended R-44 version 2 arrives at 18:20. The supplied workflow requires it to remain unreviewed until that clinician actually reviews it.

The import report says 240/240 records and 620/620 attachments loaded. The destination reveals three problems:

• Only 16/18 open tasks appear in active work queues.
• TEST-EI-017’s task points to an inactive clinician rather than the accepted covering clinician.
• R-44 version 2 is absent because it arrived after the extraction cutoff.

The failure is loss of version context and accountable follow-up. The import totals are correct, but the workflow is not ready.

Show the correction, retest and launch decision

Initial decision: Hold. The clinical lead rejects the result-routing gate. The implementation lead logs defect EI-D03, and the migration team investigates all task mappings affected by inactive clinicians.

Repair: mapping v4 restores both missing tasks and assigns the correct accepted coverage. The delta process imports R-44 version 2 as an amendment linked to version 1. Neither the import nor the repair marks the result reviewed. The records owner reconciles every item in the rehearsal’s post-extraction ledger.

Retest: 18/18 outstanding tasks appear in the expected queues; TEST-EI-017 reaches the covering clinician; both report versions are retrievable; one outstanding review remains visible. Replaying the same delta creates no duplicate result or task. The clinical and technical leads record the evidence references EI-E03 through EI-E06.

Bounded decision: the migration gate passes for build C / mapping v4. Full go-live remains held until the separate permission, training, interface and recovery gates have their own evidence.

The original 240/240 headline did not need to be false to be misleading. It answered whether patient records loaded, not whether the team could carry on unfinished work. The SAFER test-results guide emphasizes clear follow-up responsibility, accepted delegation and the handling of amended results. Use those responsibilities when designing the destination queue, rather than treating task migration as an administrative afterthought.

Test the complete workflow and its failure states

Write the expected result before running a demonstration. The ONC EHR System Testing Plan, published in October 2016, separates functional, system, integrated and performance testing and records who accepted results. A successful screen demonstration is narrower evidence than an accepted end-to-end workflow.

Use these eight cases to build your project’s test plan. Agree the expected states with the responsible clinical and technical teams. Run approved synthetic cases and record the application build, interface version, configuration, role, device, execution time, result and evidence reference.

The SAFER System Management guide calls for distinct production, testing and training environments, with controlled testing of installed production workflows as well. Start rehearsals in an authorized nonproduction environment. Any production validation needs explicit organizational controls for test identities and outbound transactions; do not send fictitious prescriptions, claims or patient messages to live recipients.

Retain failed attempts and their fixes. If a patch changes the mapping or interface, identify the earlier tests it invalidates and rerun those dependencies. “Pass after changing the configuration” belongs to that new configuration, not every earlier or future version.

Include security throughout the project. For U.S. regulated entities, the HHS Security Rule summary describes administrative, physical and technical safeguards for electronic protected health information. Have the responsible team assess the actual data flows, access and contingency arrangements and retain that evidence with the launch decision.

Train by role and observe the work

Training attendance answers who was present. It does not establish whether someone can find the right encounter, recognize a failed save or reach a covering clinician. Use the configured workflow, realistic interruptions and the devices people will use.

NHS England’s migration training guidance treats training as part of the transition. Agree release criteria for each role, then use the demonstrations below to record competence and support needs.

Schedule training, supervised practice and retests as paid work with clinical coverage. Include locums, part-time staff, new starters and out-of-hours coverage where they are in scope. Record the specific version and role demonstrated; a later permission or workflow change may require a targeted refresher.

For a fictional staffing budget, assume eight staff each need three hours of protected learning and rehearsal: 8 × 3 = 24 staff-hours. Add six super-user hours and four trainer hours for 34 staff-hours, then separately price backfill and any reduced appointment capacity. Count each replacement cost once.

Ask staff to show what they would do when they cannot finish a task. Knowing the support route, the clinical escalation boundary and the safe temporary record can matter more than memorizing another menu.

Expand the 34 hours into a project cost worksheet

The Health IT Playbook’s vendor-pricing resource organizes software, implementation, training and support costs for comparison. Use that line-item approach, then add the clinic’s transition costs and dependencies. Source checked October 22, 2026.

For this fictional USD budget, the horizon is the first 12 months from the new subscription’s start. The table uses assumed quantities and rates. The 34-hour exercise comprises 30 internal learner/super-user hours plus four external trainer hours. The clinic buys 30 hours of replacement coverage; existing learner wages remain in normal payroll and are not charged again as incremental cash.

Track existing staff capacity separately: 20 additional coordination/validation hours × $45 loaded hourly cost = $900 of allocated staff time, not an extra cash payment in this example. This excludes the 30 learner/super-user hours already identified in the training plan. If those 20 hours require paid replacement, add that replacement to cash instead of counting it twice. After the old subscription ends, the priced EHR-plus-archive run rate is $340/month, before any other recurring services.

The cost owner must resolve taxes, network/security changes, contract/privacy review, prescribing charges, archive setup, reduced appointment capacity and any extra interfaces or staffing. An unpriced item is unknown, not zero. For every real line, record a dated quote, inclusions/exclusions, quantity, unit, currency, payment date, owner and dependency. A delayed cutover should update overlap, backfill and support costs as well as the schedule.

Copy a blank cost worksheet for your own quotes

Copy cost worksheetSelect text

Copy this blank cost worksheet into your organization’s approved workspace. Keep patient information and confidential evidence off this public page.

EHR IMPLEMENTATION COST WORKSHEET Organization / scoped services / currency / tax basis: [ ] Planning horizon / subscription start / overlap dates: [ ] Configuration and supplier quote versions / quote expiry: [ ] For EACH line: quantity x unit rate = subtotal; classify incremental cash or existing staff time. Also record quote reference, inclusions/exclusions, owner, dependency and payment date. Migration and validation service: [ ] Interface setup and testing: [ ] Equipment, network and security changes: [ ] External training: [ ] Paid backfill (exclude hours already funded elsewhere): [ ] New EHR subscription across the planning horizon: [ ] Old subscription overlap: [ ] Archive setup and ongoing read-only access: [ ] Launch and ongoing support: [ ] Internal coordination and validation hours / loaded rate: [ ] Other local costs: contracts/privacy review, prescribing fees, reduced appointment capacity: [ ] Retest/contingency reserve / drawdown approver: [ ] Incremental cash subtotal: [ ] Reserve (not yet spent): [ ] Cash funding required including reserve: [ ] Existing staff-time allocation (reported separately): [ ] Unpriced items / quote owner / deadline: [ ] Ongoing monthly run rate after overlap / exclusions: [ ] Approver / date / next review trigger: [ ]

Plan cutover, downtime and recovery together

Cutover is the controlled switch between operating arrangements. Define the last source extraction, the window in which changes can occur, the final destination load, interface switching and who authorizes reopening each workflow.

England’s cutover guidance makes an important distinction: information entered after final data production may need a separate re-entry route. Your contract and technical design must establish the actual mechanism—delta import, controlled manual reconciliation or another approved process.

Use a cutover ledger with source event ID → event time and timezone → destination → reconciliation state → owner. Include new registrations, cancellations, consultations, incoming results, corrected documents and open messages. Decide which system is authoritative for each workflow during the transition so staff do not unknowingly maintain two competing records.

Before the switch, confirm:

• Which interfaces are paused, queued or redirected, and who confirms their restoration.
• How patients and external services reach the clinic while portals or messaging routes change.
• How legacy records remain available, for how long, and through whose access account.
• How new work is captured during downtime and reconciled afterward.
• Who can stop the launch, whom they contact and which failure triggers that decision.

The SAFER Contingency Planning guide treats planned and unplanned unavailability as clinical workflow problems as well as technical ones. Rehearse access to essential information, substitute documentation and recovery with the people who will use them.

A rollback is not simply “restore Friday’s backup.” By Monday morning, new encounters, orders and results may exist. The recovery plan must preserve that work, determine the authoritative destination and prevent duplicate transactions when queues restart. Set and test recovery-time and acceptable-data-loss targets for the scoped service; document who approves them and what happens if they cannot be met.

Go-live readiness checklist and decision record

Use Pass, Fail, Not run, or Not applicable—with reason for each gate. A pass needs evidence. A count of checked items is not a safety score, and a “not applicable” decision needs an accountable approver.

Use these nine gates to structure the launch decision. Define severity and stop rules before the final meeting. Wrong-patient writes, lost unfinished clinical work, unauthorized access or an unworkable essential recovery process should hold the affected launch scope while the team resolves the failure or demonstrates an approved safe alternative.

A noncritical reporting-layout defect might have a temporary workaround. Record the affected users, manual effort, owner, expiry, evidence and retest date. That bounded exception must not quietly cover an unrelated clinical routing failure.

Completed fictional decision entry

EI-G02 — Migration. Build C / mapping v3: Fail, despite 240/240 records and 620/620 attachments loaded. Evidence EI-E01/EI-E02 shows 16/18 tasks, inactive coverage and a missing post-cutoff amendment. Remediation owner: migration lead; accountable approver: records owner with clinical acceptance. Retest on mapping v4: Pass for this gate, supported by EI-E03–EI-E06. Outstanding condition: other launch gates remain unrun. Overall decision: Hold. Recheck trigger: any change to extraction cutoff, task mapping, coverage roster or amendment handling.

Keep project evidence in an access-controlled record, including rejected results and decision history.

Editable checklist: all nine gates and eight tests

The planner carries expected results and evidence requirements into every row. Adjust dependencies to your project; every status starts at Not run. Copy the rows into your approved workspace to retain and share them, and use the separate record beneath for project context and the final signed decision.

9 readiness gates + 8 test cases

Expand a row to assign an owner and deadline, adjust dependencies, and record findings. Copy all rows into your approved project workspace as tab-separated columns. Edits stay in this page’s memory and are lost on reload; copy before leaving. Use non-sensitive planning details and secure reference IDs only, not patient information or confidential evidence.

Copy all 17 checklist rowsSelect checklist text

Record the evidence, accountable approver and reason for any “Not applicable” decision. Complete launch authorization in the separate decision record below.

EI-G01 — Scope and staffing · Not run

Expected result

Scope, named owners/backups and protected training/support capacity accepted.

Evidence required

Versioned scope, staffing roster, funded coverage and acceptance record.

Accepting role

Sponsor and operations lead

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencyAgreed service scope, funding and supplier availabilitySecure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

EI-G02 — Migration · Not run

Expected result

Totals, fields, attachments and unfinished work reconcile; exceptions resolved or explicitly accepted.

Evidence required

Source/target counts, field samples, attachment checks, task ownership, amendment/delta ledger and exception decisions.

Accepting role

Records owner and clinical lead

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencyEI-G01; source export and mapping; EI-T01, EI-T02, EI-T03Secure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

EI-G03 — Connected workflows · Not run

Expected result

Authorized end-to-end routes work, including failed acknowledgment, retry and destination verification.

Evidence required

Versioned interface tests, source/destination IDs, failure/retry logs and receiving-queue checks.

Accepting role

Technical and clinical owners

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencyEI-G01; configured interfaces; EI-T03, EI-T04, EI-T06, EI-T08Secure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

EI-G04 — Access and security · Not run

Expected result

Role restrictions and data paths accepted; applicable agreements and risk decisions recorded.

Evidence required

Access tests, data-flow review, agreement references, audit events and approved risk register.

Accepting role

Privacy/security owner

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencyEI-G01; data-flow inventory and access design; EI-T05, EI-T06Secure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

EI-G05 — Role competence · Not run

Expected result

Each in-scope role demonstrates its tasks; supervised practice and absence coverage are assigned.

Evidence required

Named competency records with build/date, failed attempts, retests and coverage roster.

Accepting role

Role leads and operations

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencyStable accepted build; EI-G02, EI-G03, EI-G04; protected staff timeSecure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

EI-G06 — Downtime and recovery · Not run

Expected result

Fallback, restoration and reconciliation preserve new work; stop authority is understood.

Evidence required

Rehearsal timeline, restore result, reconciled work queue and approved stop/escalation route.

Accepting role

Clinical and technical owners

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencyAgreed continuity/restore targets; recovery environment; EI-T07Secure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

EI-G07 — Cutover · Not run

Expected result

Extract cutoff, post-cutoff changes, interface switching and legacy access have named owners and checks.

Evidence required

Dated cutover runbook, timezone, delta ledger, switch rehearsal and legacy-access verification.

Accepting role

Implementation and records leads

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencyEI-G02, EI-G03, EI-G06; confirmed supplier cutover slotSecure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

EI-G08 — Support and monitoring · Not run

Expected result

Contact route and backups are staffed; incidents and workflow measures have review owners.

Evidence required

Support roster, accepted seeded ticket, escalation record, baseline and monitoring schedule.

Accepting role

Operations lead

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencyEI-G01; baseline and severity rules; EI-T08Secure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

EI-G09 — Final decision · Not run

Expected result

Blockers resolved; any exception has scope, owner, expiry and retest; bounded launch decision signed.

Evidence required

Domain approvals, condition/exception register, decision time, approved scope and recheck triggers.

Accepting role

Accountable sponsor with domain sign-offs

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencyEI-G01–EI-G08; current evidence and unresolved-issue registerSecure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

EI-T01 — Ambiguous identity · Not run

Expected result

Ambiguous record quarantined; no information written to the wrong patient.

Evidence required

Source IDs, matching decision and destination search confirming no cross-patient write.

Accepting role

Records owner and clinical lead

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencySafe test environment; synthetic ambiguous source identities and match rulesSecure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

EI-T02 — Historical data and units · Not run

Expected result

Value, unit, date and historical status retained; trend does not imply a new observation.

Evidence required

Source/target field comparison and receiving trend display.

Accepting role

Clinical validator

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencyMapped synthetic historical values, units and source datesSecure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

EI-T03 — Amended result at cutover · Not run

Expected result

Versions remain linked; amendment and outstanding review reach an accepted owner without duplicates.

Evidence required

Both result versions, delta ledger, owner acceptance and receiving review queue.

Accepting role

Clinical owner

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencySynthetic amendment after extraction cutoff; active coverage rosterSecure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

EI-T04 — Acknowledgment lost after successful send · Not run

Expected result

Destination investigated before retry; no duplicate order or message created.

Evidence required

Source event, destination ID, acknowledgment failure and retry log.

Accepting role

Interface and workflow owners

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencyTest interface with controlled lost acknowledgment and destination lookupSecure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

EI-T05 — Permission boundary · Not run

Expected result

Unauthorized operation denied; authorized operation succeeds with appropriate audit trail.

Evidence required

Role/action matrix, denial/success results and audit entries.

Accepting role

Security owner

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencyConfigured authorized and unauthorized test rolesSecure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

EI-T06 — Patient/proxy access · Not run

Expected result

Only the correct recipient sees the permitted information with correct release status.

Evidence required

Patient/proxy portal views, release configuration and access history.

Accepting role

Patient-access lead

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencySynthetic patient/proxy accounts and configured release restrictionsSecure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

EI-T07 — Downtime and restore · Not run

Expected result

Continuity maintained; restored and fallback work reconciled without missing or duplicate actions.

Evidence required

Outage/recovery timeline, restore evidence and reconciled work queue.

Accepting role

Clinical and technical owners

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencyApproved fallback, backup and recovery runbook; seeded new workSecure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

EI-T08 — Realistic load and support · Not run

Expected result

Scoped workload meets local limits; support accepts and escalates a seeded incident.

Evidence required

Device/build/concurrency, timings, ticket acceptance and escalation record.

Accepting role

Operations lead

Named ownerDeadlineStatusNot runFailPassNot applicable—with reason

DependencyAgreed local limits, representative devices/concurrency and staffed supportSecure evidence referencesActual finding / date / configurationRemediation / owner / due date / retestApprover / conditions / N/A reason / expiry

Copyable checklist text

ID Requirement Accepting role Expected result Evidence required Named owner Dependency Deadline Status Secure evidence references Actual finding / date / configuration Remediation / owner / due date / retest Approver / conditions / N/A reason / expiry EI-G01 Scope and staffing Sponsor and operations lead Scope, named owners/backups and protected training/support capacity accepted. Versioned scope, staffing roster, funded coverage and acceptance record. Agreed service scope, funding and supplier availability Not run EI-G02 Migration Records owner and clinical lead Totals, fields, attachments and unfinished work reconcile; exceptions resolved or explicitly accepted. Source/target counts, field samples, attachment checks, task ownership, amendment/delta ledger and exception decisions. EI-G01; source export and mapping; EI-T01, EI-T02, EI-T03 Not run EI-G03 Connected workflows Technical and clinical owners Authorized end-to-end routes work, including failed acknowledgment, retry and destination verification. Versioned interface tests, source/destination IDs, failure/retry logs and receiving-queue checks. EI-G01; configured interfaces; EI-T03, EI-T04, EI-T06, EI-T08 Not run EI-G04 Access and security Privacy/security owner Role restrictions and data paths accepted; applicable agreements and risk decisions recorded. Access tests, data-flow review, agreement references, audit events and approved risk register. EI-G01; data-flow inventory and access design; EI-T05, EI-T06 Not run EI-G05 Role competence Role leads and operations Each in-scope role demonstrates its tasks; supervised practice and absence coverage are assigned. Named competency records with build/date, failed attempts, retests and coverage roster. Stable accepted build; EI-G02, EI-G03, EI-G04; protected staff time Not run EI-G06 Downtime and recovery Clinical and technical owners Fallback, restoration and reconciliation preserve new work; stop authority is understood. Rehearsal timeline, restore result, reconciled work queue and approved stop/escalation route. Agreed continuity/restore targets; recovery environment; EI-T07 Not run EI-G07 Cutover Implementation and records leads Extract cutoff, post-cutoff changes, interface switching and legacy access have named owners and checks. Dated cutover runbook, timezone, delta ledger, switch rehearsal and legacy-access verification. EI-G02, EI-G03, EI-G06; confirmed supplier cutover slot Not run EI-G08 Support and monitoring Operations lead Contact route and backups are staffed; incidents and workflow measures have review owners. Support roster, accepted seeded ticket, escalation record, baseline and monitoring schedule. EI-G01; baseline and severity rules; EI-T08 Not run EI-G09 Final decision Accountable sponsor with domain sign-offs Blockers resolved; any exception has scope, owner, expiry and retest; bounded launch decision signed. Domain approvals, condition/exception register, decision time, approved scope and recheck triggers. EI-G01–EI-G08; current evidence and unresolved-issue register Not run EI-T01 Ambiguous identity Records owner and clinical lead Ambiguous record quarantined; no information written to the wrong patient. Source IDs, matching decision and destination search confirming no cross-patient write. Safe test environment; synthetic ambiguous source identities and match rules Not run EI-T02 Historical data and units Clinical validator Value, unit, date and historical status retained; trend does not imply a new observation. Source/target field comparison and receiving trend display. Mapped synthetic historical values, units and source dates Not run EI-T03 Amended result at cutover Clinical owner Versions remain linked; amendment and outstanding review reach an accepted owner without duplicates. Both result versions, delta ledger, owner acceptance and receiving review queue. Synthetic amendment after extraction cutoff; active coverage roster Not run EI-T04 Acknowledgment lost after successful send Interface and workflow owners Destination investigated before retry; no duplicate order or message created. Source event, destination ID, acknowledgment failure and retry log. Test interface with controlled lost acknowledgment and destination lookup Not run EI-T05 Permission boundary Security owner Unauthorized operation denied; authorized operation succeeds with appropriate audit trail. Role/action matrix, denial/success results and audit entries. Configured authorized and unauthorized test roles Not run EI-T06 Patient/proxy access Patient-access lead Only the correct recipient sees the permitted information with correct release status. Patient/proxy portal views, release configuration and access history. Synthetic patient/proxy accounts and configured release restrictions Not run EI-T07 Downtime and restore Clinical and technical owners Continuity maintained; restored and fallback work reconciled without missing or duplicate actions. Outage/recovery timeline, restore evidence and reconciled work queue. Approved fallback, backup and recovery runbook; seeded new work Not run EI-T08 Realistic load and support Operations lead Scoped workload meets local limits; support accepts and escalates a seeded incident. Device/build/concurrency, timings, ticket acceptance and escalation record. Agreed local limits, representative devices/concurrency and staffed support Not run

Project context and final decision

Copy readiness recordSelect text

Copy this blank readiness record into your organization’s approved workspace. Keep patient information and confidential evidence off this public page.

EHR IMPLEMENTATION READINESS RECORD Organization/site and launch scope: [ ] Jurisdiction / applicable requirements / source and approving owner: [ ] EHR/build, interface versions and environment: [ ] Planned cutover / timezone / extraction cutoff: [ ] Clinical owner / implementation lead / technical owner: [ ] Backup owners and staffed coverage: [ ] REPEAT FOR EACH REQUIREMENT ID and workflow: [ ] Responsible person / accountable approver: [ ] Expected result and permitted workaround: [ ] Evidence required and secure reference: [ ] Actual finding / test date / configuration: [ ] Status: [Not run / Fail / Pass / Not applicable—with reason] Severity and affected scope: [ ] Remediation owner / due time / retest reference: [ ] Accepted exception, reason, expiry and approver: [ ] MIGRATION AND CUTOVER Population/categories in scope / exclusions / archive route: [ ] Counts and reconciliation / field checks / attachments / open work: [ ] Post-extraction changes captured / reconciled / still outstanding: [ ] Legacy access owner / duration / exit verification: [ ] TRAINING AND RECOVERY Roles demonstrated / people still needing supervised practice: [ ] Downtime rehearsal / restore evidence / replay reconciliation: [ ] Who can pause launch / contact route / trigger: [ ] DECISION [Go / Hold / Limited scope with approved conditions] Evidence reviewed and remaining conditions: [ ] Clinical, technical, privacy and operational sign-offs: [ ] Final accountable decision maker / decision date and time: [ ] Next review / trigger to pause or reassess: [ ]

Stabilize before declaring the project finished

At launch, make the support route visible and staffed. Separate urgent clinical concerns from ordinary usability tickets, assign a backup to each critical queue, and make the daily review owner explicit. Do not ask staff to work around an unsafe state silently while waiting for a software fix.

Compare operational measures with a baseline using the same definitions. Useful starting measures include unassigned results, overdue tasks, duplicate transactions, failed message delivery, time spent correcting records, support tickets by severity and staff time outside scheduled work. Report the denominator—such as unmatched results out of all results received—rather than a reassuring total without context.

Interpret apparent improvements carefully. Fewer appointments, extra project staff or a smaller case mix can reduce backlog without proving the new EHR is more efficient. Track the temporary staffing and capacity changes beside the measures.

Define exit from intensive support in advance: important queues have accepted owners, unresolved issues have funded support, staff can use the escalation route, and the operations team accepts responsibility. Continue to reassess after upgrades, interface changes or new services. The healthcare software systems checklist provides a broader framework for evaluating those system boundaries.

If an AI scribe is part of the chosen workflow, include draft review, destination identity, permissions and saved-note verification in the acceptance tests. Assign problem-list migration and outstanding-result ownership to the responsible EHR workstreams.

For that documentation layer, see how Vero Scribe prepares note drafts for clinician review.

Sources and further reading

Sources checked October 22, 2026. The Playbook links below include the 2016 planning tools; the SAFER documents are from ONC’s 2025 collection.

• Health IT Playbook: Electronic Health Records
• ONC: Creating a Leadership Team (October 2016)
• ONC: Chart Migration and Scanning Checklist (June 2016)
• ONC: EHR System Testing Plan (October 2016)
• ONC 2025 SAFER collection: System Management
• ONC 2025 SAFER collection: Contingency Planning
• ONC 2025 SAFER collection: Test Results Reporting and Follow-Up
• NHS England: Data checking (England)
• NHS England: Training (England)
• NHS England: Planning for cutover (England)
• HHS: Summary of the HIPAA Security Rule (United States)
• Alberta Medical Association: Implementing an EMR System (Alberta, Canada)