Hospital management
HIS system migration: stages for a safe transition
HIS system migration without disrupting care: assessment, clinical data, testing, cutover, contingency and KPIs. Read the guide.
HIS system migration: how to do it without interrupting clinical care
An HIS is not switched off on a Friday and back on on Monday. While the migration runs, the emergency department keeps receiving patients, the operating theatres keep operating and the wards keep administering medication. An identification error or a lost order reaches the patient before it reaches any report.
This guide explains how to protect clinical continuity during an HIS system migration, following the method we use at K2BHealth. If you are still assessing whether to change systems, we suggest first reviewing the 9 signs of an obsolete HIS.
In short
- Assess before migrating, and postpone during demand peaks or audits.
- Migrate only what is needed to provide care on day one, and authorise the cutover only when every acceptance criterion is met.
- Retire the old system once the KPIs stabilise against the baseline.
What should be assessed before migrating an HIS?
The prior assessment covers six areas:
- Processes and services.
- Systems and integrations.
- Data.
- Users by role and site.
- Infrastructure.
- Constraints, such as contract dates and seasonal peaks.
To decide what to protect first, the clinical impact of a failure is weighed against the volume of each process. The emergency department, operating theatres, inpatient wards, the return of critical results and patient identification almost always come out on top.
Among integrations, those that carry results or orders matter most. A delayed invoice can be recovered; a lost order cannot.
Conditions to start, and when to postpone
Before starting, we ask for five conditions:
- Sponsorship from management.
- Clinical leads with dedicated time.
- Clean master catalogues.
- Verified infrastructure.
- An agreement with the outgoing vendor to access the data.
We recommend postponing during a demand peak, an ongoing audit or accreditation, or another major transformation running in parallel. It is also wise to wait if access to the old data is missing or if testing has not met the acceptance criteria. Postponing in time costs less than a go-live that goes wrong.
The clinical leads have the final say on whether the system is safe for patient care. As vendors, we propose and execute, but we do not decide clinical acceptance.
How should clinical data be prepared and validated?
First, migrate what is needed to care for the patient on day one: identification, history, allergies, active medication, current diagnoses, future appointments, open episodes and balances.
The full history that is no longer edited is kept available for consultation, within legal retention periods. Nothing is deleted without an explicit, documented decision.
Common data quality problems
These are the problems that appear most often and how we solve them:
| Problem | How it is solved |
|---|---|
| Duplicate patients | Matching rules and human review of doubtful cases. |
| Incomplete data | Flagged and completed at the next contact with the patient. |
| In-house codes | Mapped to standard terminologies. |
| Free text | Migrated as text, without inventing a structure. |
Mapping between systems
Each entity and catalogue has a mapping table validated by the relevant lead. SNOMED CT, ICD-10, LOINC and the national drug dictionary are used as the pivot. An index links each old identifier to the new one, so every data point can be traced back to its source.
Whatever cannot be mapped with certainty is flagged for review. Using FHIR as the intermediate format forces every data point to be expressed with a standard meaning.
Validating the migrated data
Validation of the migrated data checks five aspects:
- Completeness: source counts against target counts.
- Accuracy: random samples plus a targeted sample of complex cases, such as chronic patients and pregnant women.
- Integrity of the relationships between data.
- Traceability of each data point back to its source.
- Usage tests with simulated cases.
Finally, clinical validation is signed off by the leads of each service. Without their signature, there is no go-live.
How should the coexistence of both systems and the testing be organised?
The transition can be phased or all at once, depending on how interdependent the services are:
| Phased transition | Big-bang transition | |
|---|---|---|
| What it is | By service, module or site. | The whole hospital in a single cutover. |
| When it fits | Large or multi-site institutions. | Mid-sized institutions with tightly integrated processes. |
| Pros | Reduces the risk of each step. | Shorter, and avoids double data entry. |
| Cons | Extends the coexistence period and requires temporary integrations. | Concentrates the risk in a single moment. |
In practice, combining both strategies works well. Services with few dependencies, such as outpatients and scheduling, go first. Tightly integrated ones, such as the operating theatres with their stock and billing, go together afterwards.
A single system of record during coexistence
While both systems coexist, each data point has a single system of record at any given time. Each workstation shows where data is recorded and where it is looked up. A clinician is never asked to record the same thing in two systems, because the records stop matching.
Testing and acceptance criteria
We test every workflow with real users from each role. Testing includes:
- End-to-end scenarios.
- Risk cases, such as an unidentified patient.
- Integrations with real data.
- Load testing with the busiest day.
- A rehearsal of the cutover and of the rollback.
The switch is authorised only if all of these conditions are met:
- No blocking defects.
- Signed-off data validation.
- Critical integrations working.
- Users trained and assessed.
- Contingency rehearsed.
- Support with assigned shifts.
The go/no-go decision is made by the steering committee, signed by management and the clinical leads.
How should staff be prepared and the cutover carried out?
Before go-live, we train by role and by workflow so that everyone can do their job in the system. For example, the on-call doctor practises a complete shift.
Super users are trained first and then support their colleagues. Each person then works through the cases for their role in a practice environment before accessing production. On adoption, see our change management guide.
The cutover is scheduled for a low-demand period, with super users available and away from accounting closes. This is the sequence:
- We freeze changes in the old system.
- We run the final extraction and load.
- We validate the data.
- We switch on the integrations.
- We enable the users.
- We check the critical services one by one.
- We reinforce on-site support.
Contingency and rollback plan
Contingency is prepared before it is needed and includes:
- Paper procedures for each service.
- Backup lists of inpatients, active medication, allergies and surgeries.
- Activation criteria with a named owner.
- A workflow to enter afterwards whatever was recorded on paper.
- Escalation contacts.
A rollback happens if a patient safety risk appears that the contingency cannot contain. For example, identification errors, corruption of clinical data or the prolonged failure of a critical integration.
The rollback criteria are set before the cutover, because nobody decides well in the middle of a crisis.
Which support and KPIs show that the new HIS has stabilised?
The first days determine whether the team trusts the new system. That is why there is on-site presence in critical services and a dedicated help desk, along with a daily meeting with the committee and prioritisation by clinical impact.
Indicators and baseline
The indicators we track are:
- Incidents by severity and their resolution time.
- Availability and response times of critical screens.
- Adoption: the percentage of records made in the system rather than on paper.
- Admission and consultation times.
- Integration errors and accounts billed on time.
Without a baseline measured before the change, using the same definition for each indicator, there are only impressions. On how to measure results, see our article on medical software ROI.
When to retire the old system
The old system is retired when these conditions are met:
- The indicators are within threshold.
- There are no open critical incidents.
- Everything recorded during contingency has been entered.
- The history is accessible.
- A complete copy is stored in line with regulations.
Retirement closes one stage of the institution’s digital transformation process.
Frequently asked questions
How long does the migration assessment take?
It depends on the size of the institution, its systems and integrations, and the volume of data. It is defined when its scope is agreed.
What happens to data entered in the new system if a rollback is needed?
It is not lost. It is extracted and loaded into the old system, or kept on paper according to the plan. It is then migrated again in the next attempt, reconciled record by record.
What are the most common mistakes?
Underestimating data quality, not allocating clinicians’ time and replicating the old system. Also leaving integrations until the end, training only in theory and retiring the old system too early. Almost all of them can be prevented with early decisions.
How can you plan your HIS migration with K2BHealth?
Migrating without disrupting care depends on coordinating, from the start, the people who provide care and the people who configure the system. That is why we support the project end to end, in the cloud (SaaS) or on your infrastructure:
- Assessment and workflow redesign.
- Configuration of the HIS.
- Migration, data validation and HL7 FHIR integrations with Dandelion.
- Testing, training, go-live and support.
To get started, we propose a migration assessment. It delivers the recommended strategy, the risks, the timeline and the resources the institution needs to provide.
