Implementing an EHR in a hospital: from workflow mapping to go live
A hospital implements an electronic health record successfully when it treats the work as organisational change rather than software installation: governance first, then mapping how every department actually works, configuring the system with each department, testing under real conditions, and supporting staff intensively through go live. The evidence from low resource settings is consistent that people, workflow and project management determine success more than any single feature.
This guide sets out an implementation method for public and provincial hospitals, drawn from WHO planning guidance, peer reviewed studies of implementations in low and middle income countries, and the experience of mapping a whole regional referral hospital. It is written for hospital executives, directors of medical services, health information managers and the ministry officials who oversee them.
Why implementations succeed or fail
The most comprehensive review of the question, a systematic review of electronic medical record implementations in low resource settings published in JAMIA, analysed 47 articles and extracted 381 success criteria grouped into seven categories: ethical, financial, functionality, organisational, political, technical and training [1]. The authors concluded that reliable data handling, skilled human resources with effective project management, and sound technical architecture and infrastructure are the keys to success [1].
A later state of the art review of 32 studies, most from Kenya, added a warning that is often missed: an electronic record alone does not improve efficiency, and digital systems can expose and worsen poor existing processes [2]. The authors recommended optimising paper workflows first and retaining some paper steps during transition to reduce staff anxiety [2].
Sittig and Singh's sociotechnical model gives implementation teams a practical checklist. It identifies eight dimensions that must all be addressed together: hardware and software computing infrastructure; clinical content; the human computer interface; people; workflow and communication; internal organisational features; external rules and regulations; and measurement and monitoring [3]. A plan that covers infrastructure and software but neglects workflow, people or measurement is incomplete by this standard.
The phases of an implementation
WHO's Digital Implementation Investment Guide sets out a systematic process for planning digital health investments: form the team and establish goals, identify health system challenges by mapping current workflows, determine the right interventions and define the future state workflow, plan the implementation, link it to the enterprise architecture, develop a budget with defined phases, and monitor the implementation using data [4]. At hospital level, that process translates into the following phases.
| Phase | Purpose | Key outputs | Exit criterion |
|---|---|---|---|
| Governance | Establish authority and accountability | Steering group, sponsor, department leads, data ownership agreement | Named decision makers for every department |
| Current state mapping | Document how work actually happens | Workflow maps, forms inventory, reporting obligations | Each map approved by its department lead |
| Future state design | Agree how work will happen in the system | Configured workflows, role definitions, reports | Department sign off |
| Configuration and testing | Build and prove the system | Configured departments, test scripts, issue log | Scenarios pass under realistic conditions |
| Readiness | Prepare people, data and infrastructure | Trained users, migrated data, downtime procedures | Readiness checklist complete |
| Go live | Move clinical work into the system | Support roster, command centre, daily issue review | Critical issues resolved |
| Stabilisation and optimisation | Recover performance and improve | Indicators, change requests, refresher training | Indicators at or above baseline |
Governance before software
The first decisions are about authority, not technology. The hospital needs an executive sponsor who can resolve disputes between departments, a clinical lead who carries credibility with medical and nursing staff, a health information or medical records lead who owns reporting obligations, and an ICT lead who owns infrastructure. Most important, every department needs a named lead, usually its Officer in Charge, who will approve how that department's work is configured.
WHO's guidance on digital health investment stresses that technology works only when it addresses local health needs, fits the context and the existing digital architecture, and receives sustained funding [9]. Governance is where those conditions are tested before money is committed.
Governance should also settle data ownership before any patient data is entered: who owns the record, where it is hosted, and who may access it for what purpose. The guide to health data sovereignty covers the questions a ministry should resolve.
Whole hospital workflow mapping
The Agency for Healthcare Research and Quality frames the central task plainly: a successful health IT implementation recognises its impact on both clinical and administrative workflow [5]. Mapping is how that impact becomes visible before go live rather than after.
What a workflow map should capture
- Every point where a patient is identified, registered or handed over between departments
- Every paper form, register and logbook in use, including national programme forms
- Every report the department must produce, for whom, and how often
- Who performs each step, and who approves it
- Where information is currently recorded twice or transcribed
- What happens at night, at weekends and when staff are absent
Mapping the whole facility, not the pilot scope
ANGAU Memorial Provincial Hospital in Lae, the regional referral hospital for the Momase region of Papua New Guinea with a catchment of about 2.8 million people, illustrates why mapping should extend beyond the original scope. The engagement began as a clinical pilot covering emergency, registration and admissions, followed by the wards. Work started with the Officers in Charge of departments across the hospital, and each department's workflow was mapped with the staff who carry it out.
Two developments followed that were not in the original plan. Catering asked for ward nurses to place inpatient meal orders with dietary requirements attached and for invoices to go directly to finance; Maintenance asked for every department to raise jobs from its own dashboard into a single queue. The Cancer Department worked from a national registry form that follows a patient from registration to follow up; the form was sound, so it was configured in the system as it stands rather than redesigned. All 17 departments at ANGAU are now mapped and configured, and go live is expected in the coming weeks. The lessons are described in whole hospital workflow mapping at ANGAU.
The general principle is that departments outside the original scope document are often the clearest test of whether a system serves the hospital as a whole.
Configuration with each department
Configuration should not be treated as a final technical phase. It works best when each department's workflow is built with that department, reviewed by its lead, and approved before the team moves to the next. This keeps the future state grounded in how the department operates and gives each Officer in Charge ownership of the result.
This reflects two of the refreshed Principles for Digital Development: understand the existing ecosystem, and design with people [10]. Two disciplines matter. First, configure rather than customise: changes should use the system's configuration tools so that the hospital remains on the supported product and receives updates. Second, preserve what works. Where a national form, register or reporting format is effective, the system should reproduce it, so that the department's obligations to programmes and the ministry are met from the record without double entry.
Testing, data migration and readiness
Testing under real conditions
Test scripts should follow complete patient journeys across departments, not isolated screens: a patient presenting to emergency, admitted to a ward, sent for a laboratory test, prescribed and dispensed a medicine, and discharged with a referral. Testing should include the hospital's real network conditions, including a dropped connection, as described in the guide to designing health systems for unreliable connectivity.
Downtime procedures
Every hospital needs a written procedure for the rare occasions when the system cannot be used. An analysis of patient safety reports during electronic record downtime found specimen identification errors, delayed results and medication administration errors [6]. Downtime forms, a recovery process for entering paper records afterwards, and a clear chain of communication should be ready before go live.
Data migration
Converting paper records is consistently reported as difficult in low resource settings [2]. A hospital has three practical options: import existing spreadsheets and electronic data with validation; digitise paper records with a final human check before anything enters the record; or begin new records at first presentation after go live and bring older records in on demand. Most hospitals combine all three.
| Readiness item | Ready when |
|---|---|
| Infrastructure | Devices, network and power tested in every department |
| Users | Every user trained for their role and holding working credentials |
| Super users | At least one per department and shift, released from routine duties for go live |
| Data | Priority records migrated and validated |
| Downtime | Procedures printed and rehearsed |
| Reporting | Mandatory national returns tested from system data |
| Support | Roster, escalation path and issue log in place |
Phased rollout or single cutover
The Digital Implementation Investment Guide asks planners to define implementation phases explicitly when budgeting [4]. Within a hospital the choice is usually between moving all departments on one date and moving them in planned groups.
| Approach | Advantages | Risks |
|---|---|---|
| Single cutover | One transition; no period of mixed paper and electronic handovers | All departments need support at once; issues affect the whole hospital |
| Phased by department group | Support concentrated where it is needed; lessons carried forward | Handover gaps between live and paper departments must be managed |
| Phased by facility across a province | Each hospital stabilises before the next begins | Longer programme; national reporting mixes sources during transition |
A useful rule is to phase along patient flow. Registration, emergency and admissions belong together, because a patient record that starts on paper and continues electronically creates exactly the duplication the system is meant to remove.
Go live and stabilisation
Hospitals should plan for a temporary dip in performance. A study in a 24 bed academic emergency department found that median length of stay rose from 185 minutes at baseline to 224 minutes in the first four weeks after go live, then fell to 163 minutes by weeks 20 to 24, with throughput back to baseline by eight weeks [7]. Patient satisfaction recovered more slowly [7].
The practical response is to reduce elective load where possible in the first weeks, provide support at the elbow on every shift, and review issues daily. Super users are central to this. A mixed methods study found that super users who were proactive, explained in depth, framed the change positively and shared information produced significantly greater gains in colleagues' proficiency, and that their engagement depended on how managers selected them and on the implementation climate [8]. The guide to training clinicians on a new EHR covers super user programmes in detail.
After stabilisation, the Digital Implementation Investment Guide recommends monitoring against a logic model, building a culture of data use, and adapting the implementation as evidence emerges [4]. Useful indicators include registration time, emergency length of stay, laboratory turnaround, completeness of mandatory reports, and the number of open issues by severity.
How Moana approaches this
Moana implements department by department, with the people who run each one. Work begins with the hospital executive and the Officers in Charge, followed by sessions with each department and its nursing teams. Every department's workflow is mapped with the staff who carry it out and configured in Moana with them before go live, so that when the system goes into use it already reflects how the hospital operates.
Configuration happens within one platform. Each department works in its own role based workspace in MOANA Desktop, on one patient record shared across the EHR, MOANA LIS, pharmacy, radiology and hospital operations such as beds and wards, theatres, appointments, referrals and billing. National forms that work are built into the record as they stand, and national returns are generated from documented encounters, so that each figure traces to its source record.
The ANGAU engagement is the reference example. Every department, including Catering and Maintenance, has been mapped and configured with its Officer in Charge, and go live is expected in the coming weeks, with rollout and training delivered on site by the Moana team alongside the hospital's own ICT staff. For existing records, the hospital may import from its existing spreadsheets and systems, or have paper records digitised with a final human check before anything enters the record. The full account is in the ANGAU case study.
Moana is live across clinics in Pakistan and clinics in the South Pacific, where the same method applies at smaller scale. Because the platform is designed for unreliable connectivity, go live does not depend on the hospital first upgrading its network. The hospital owns its data, and Moana Digital Health maintains the system and provides support on site and remotely. The method is described on how we work and, for hospitals, on Moana for hospitals.
Key questions for procurement
How long does an EHR implementation take in a public hospital?
It depends on the number of departments, the readiness of infrastructure and the availability of department staff for mapping sessions. Ask suppliers for a phase by phase plan with exit criteria, not a single date, and plan explicitly for a stabilisation period after go live; in the emergency department study cited above, throughput took eight weeks to return to baseline [7].
Should the hospital map every department or only the pilot scope?
Every department. Patients move between all of them, and departments outside the clinical pilot often reveal the double recording and handover gaps that the system must remove.
Who should approve each department's configuration?
The department's own lead, usually its Officer in Charge, supported by the clinical and health information leads. Approval by the supplier or the ICT team alone is not sufficient.
How should existing paper records be handled?
Combine validated import of existing electronic data, digitisation of priority paper records with a final human check, and creation of new records at first presentation after go live.
What support should be in place at go live?
Super users on every shift, the supplier's implementation team on site, a daily issue review with the executive sponsor, rehearsed downtime procedures and a clear escalation path for critical issues.
Sources
- Success criteria for electronic medical record implementations in low resource settings: a systematic review, Journal of the American Medical Informatics Association, 2015
- Benefits and challenges of EMR implementations in low resource settings: a state of the art review, BMC Medical Informatics and Decision Making, 2016
- A new sociotechnical model for studying health information technology in complex adaptive healthcare systems, BMJ Quality and Safety, 2010
- Digital Implementation Investment Guide (DIIG): integrating digital interventions into health programmes, World Health Organization, 2020
- Workflow Assessment for Health IT Toolkit, Agency for Healthcare Research and Quality
- Implications of electronic health record downtime: an analysis of patient safety event reports, Journal of the American Medical Informatics Association, via AHRQ PSNet, 2018
- Transient and sustained changes in operational performance, patient evaluation, and medication administration during electronic health record implementation in the emergency department, Annals of Emergency Medicine, 2014
- A mixed methods study of how clinician super users influence others during the implementation of electronic health records, BMC Medical Informatics and Decision Making, 2015
- Investment in digital health needs careful planning: new WHO guide explains how to do it well, World Health Organization, 2020
- The Principles for Digital Development have been refreshed for the next decade, Principles for Digital Development, 2024
