Digital transformation
Change management in healthcare: how to implement an HIS
Healthcare change management: why staff resist an HIS, how to implement it without disrupting care and which KPIs to track. Read the article.
TL;DR: key points for HIS adoption
- The system does not change the process: it fixes it in place and makes it visible. Around 80% of the discussions in an implementation are about governance, not software.
- Resistance is almost never abstract: it is a specific objection tied to the job, and generally a rational one.
- A 4- to 8-week pilot, with written exit criteria. And more support in week 3 than in week 1.
- Adoption is measured at four levels, always broken down by service and shift.
How to manage the adoption of a hospital information system
Managing the adoption of a Hospital Information System (HIS) means redesigning how work is done and sustaining that redesign. In fact, it involves deciding who records what, at what moment and with what responsibility, before configuring the system. The software is the most predictable part of the project. Adoption, on the other hand, is won through governance, master data, on-the-job support and measurement from week one.
At K2BHealth we have been implementing clinical software for more than 25 years. That is why we know that projects that fail rarely do so because of the technology. In this article we share what change management in the healthcare sector involves and where resistance comes from. We also look at how to go live without interrupting operations and which indicators to use to sustain the change.
What does change management in the healthcare sector involve when implementing an HIS?
Change management in the healthcare sector is the set of decisions on process, data preparation, training, communication and measurement. In other words, what enables an institution to genuinely adopt a hospital information system. It is therefore not just about communicating or training: it is about defining how work will be done and sustaining that definition. If you are still wondering what an HIS is, it is worth starting with that foundation.
In practice, the work is divided across five fronts:
- Process decisions: who records what, at what moment and with what responsibility.
- Master data and catalogues: the real critical path of the schedule, and the one that is always underestimated.
- Training and on-the-job support, by role and by shift.
- Communication with confirmation that it has been received, not just sent.
- Adoption measurement from week one.
What takes the most time, and is almost never in the plan, is defining who makes the new records. For example, who timestamps the end of surgery or who marks a dose as given when administering it. That is why every new data item needs an owner and a moment. In a healthy project, the effort spent on support and definition is comparable to that spent on technical configuration. If the budget does not reflect this, that is already the main risk.
What causes resistance to change in the healthcare sector?
The causes of resistance to change in the healthcare sector are almost never “resistance” in the abstract. On the contrary, they are concrete objections, specific to each role and, in general, rational. Treating them as an attitude problem therefore guarantees they will not be resolved. These are the most common ones by profile:
Doctors
Main cause: The system shifts administrative work onto them that someone else used to do.
Other common causes: Minutes spent on documentation that are taken away from the consultation. A feeling of being monitored. Alerts that interrupt decisions already made.
Nursing
Main cause: They are the ones who record the most and take part least in the definitions.
Other common causes: Double recording with no end date. Hardware far from the bedside. Night-shift training passed on by word of mouth.
Administrative staff
Main cause: Fear that their job will disappear.
Other common causes: The system exposes errors that used to be corrected informally; loss of their own spreadsheet.
In addition, there is one cross-cutting cause that is more corrosive than all the others: the feeling that “I enter data so that someone else can look at it”. The antidote is concrete and inexpensive: give the data back to those who generate it. That way, each service sees its own indicator on its own screen.
Likewise, two characteristics of the system weigh heavily on acceptance. Interoperability removes the objection that is hardest to refute: “I’m going to have to enter everything twice”. Double recording is the number one cause of genuine rejection. However, it disappears when the laboratory, imaging and billing are integrated using a standard such as HL7 FHIR. Flexibility, for its part, comes down to something simple. When a service asks for a reasonable change, is it resolved in the meeting or does it go into a development queue?
How do you implement an HIS without interrupting clinical operations?
First of all, the principle is that care never stops; it is the system that adapts. We apply five stages to achieve this:
Before going live
- Decide the process before configuring. This applies to every workflow that crosses departments: patient identification, admission, medication, shift handover, the surgical pathway and discharge. For each one, four questions: who carries it out, who records it, at what moment and what happens if the data is missing.
- Prepare the master data and migrate little, but well. A deduplicated patient register, professionals assigned to a site and service, and catalogues with an owner and a freeze date. Identity, open episodes, active medication, allergies and future appointments are migrated. The rest remains read-only with a switch-off date.
- Choose a 4- to 8-week pilot. A complete end-to-end process, with sufficient volume and a department head who wants the change. By contrast, it is not advisable to start with the emergency department or with the most conflict-prone service. The exit criteria are written before starting.
Go-live and stabilisation
- Protect the cutover and the first 72 hours. The cutover is carried out at the time of lowest volume. In the first few weeks, the schedule is reduced in a planned way by 20 to 30%. On-site support is also needed on every shift, along with a change freeze and extended on-call cover with named escalation contacts. The go/no-go decision is made 48 to 72 hours beforehand, using a checklist. Postponing a go-live is the most valuable decision a committee can make.
- Sustain weeks 2 to 6. The adrenaline has worn off, the support has been withdrawn and paper reappears: this is where adoption dies. That is why we recommend reserving more support for week 3 than for week 1. It is also advisable to set an end date for double recording.
Our HIS configuration engine enables a key tactic: progressive mandatory fields. You go live with the minimum number of mandatory fields and tighten requirements as recording becomes established. Everything is done from the back office, without touching code.
How do you measure clinical adoption and sustain the change?
Adoption is measured at four levels, because measuring only the first is the classic mistake. The KPIs we use are organised as follows:
Level 1
Use
Are they logging in to the system?
Example KPIs: Active users out of enabled users, by role and service. Sessions per shift, with nights and weekends measured separately.
Level 2
Process coverage
Was the event recorded in the system?
Example KPIs: % of consultations with a clinical record. % of electronic prescriptions. % of doses recorded at the point of administration. % of accounts compiled without manual intervention.
Level 3
Record quality
Is the data useful?
Example KPIs: Latency between the event and its recording. % of structured fields versus free text. % of non-informative values in mandatory fields. Alert override rate.
Level 4
Autonomy and support
Is it self-sustaining?
Example KPIs: Tickets per 100 users per week and their trend; % resolved by key users without escalation.
The latency between the event and its recording is the best indicator of real adoption. It distinguishes “using the system” from “transcribing paper into the system”. There is also a cross-cutting rule: the numerator is always broken down by service and by shift. For example, an institutional average of 85% can hide a service at 30%, and that is where you need to go.
For comparison purposes, some values must be recorded before go-live. For example, documentation time per consultation and per nursing record, measured over 2 to 4 weeks. Also the front-desk time per admission and a short staff survey that is repeated at 6 months. Consequently, if the formula changes between before and after, the comparison is not valid.
Implement a flexible, interoperable HIS with K2BHealth
In short, an HIS does not fix a process that the institution has not defined: it freezes it and makes it visible. Our main recommendation, therefore, is to decide the process before configuring the system. In addition, every decision and every indicator needs a named owner with allocated time. There are three corollaries: start small, do not withdraw support in week 2 and avoid unlimited flexibility.
At K2BHealth we designed our Hospital Information System (HIS) so that change management is carried out with parameters, not memos. Forms, catalogues, indicators and clinical rules are configured from the back office. In addition, HL7 FHIR R4 interoperability makes it possible to coexist with what is already in place. Our methodology includes a specification approved by the institution and three validation gates per feature. In short: flexible on the surface, strict in the model. Let’s talk about how to take your institution’s adoption to a measurable result.
