Hospital management
Obsolete HIS system: 9 signs it is time to assess a replacement
Learn the 9 signs of an obsolete HIS system and when to fix, modernise or replace your hospital software. Read the article.
How can you tell whether your HIS is obsolete and needs replacing?
An obsolete HIS system is one that no longer keeps up with the institution: it does not interoperate through standards, it cannot change without a custom project, it depends on unsupported technology or it costs more than it delivers. Age, however, is not the criterion. It is worth assessing a replacement when these limitations sit at the core of the system and no adjustment can fix them.
In short
- An HIS’s obsolescence is measured by its ability to adapt, not by its age.
- The nine most common signs range from a lack of HL7 FHIR interoperability to missing traceability.
- Before changing systems, separate three possible causes: process, configuration or system.
- Whether to fix, modernise in layers or replace depends on whether the problem lies at the core of the software.
- Ask the vendor for written evidence, not promises.
When an HIS stops responding, the impact is felt across the whole hospital operation. Clinicians record things twice, results are transcribed by hand and new services run outside the system. In healthcare, slowness is not an annoyance: it is a risk.
In our experience, almost no institution reviews its HIS in cold blood. There is always a trigger: a regulatory requirement with a deadline, a growth project, an incident, end of support or a worn-out clinical team. In this article we share how to identify those limitations and decide which way to go.
What does it mean to have an obsolete HIS?
Having an obsolete HIS means the software can no longer change without every adjustment turning into a project. The institution starts organising itself around the software’s limitations instead of the other way round. An old HIS, on the other hand, can still be fit for purpose if it can still adapt. These are the differences between the two scenarios:
| Old but adequate HIS | Obsolete HIS | |
|---|---|---|
| Changes | Limited adjustments. | Projects lasting months. |
| Vendor | Responsive, with an evolution plan. | No roadmap, or out of the market. |
| Knowledge | Spread across a team. | Concentrated in one or two people. |
| Underlying technology | Supported and patched. | No support or updates. |
Before talking about obsolescence, we separate process, configuration and system. Changing HIS does not fix a badly designed process: it moves it into the new system.
To tell them apart, we ask for the inventory of parallel spreadsheets and the incident log for the last 12 months. We also survey response times on critical screens and the integrations done by hand, and hold short interviews with each role.
What are the signs that you should assess replacing your HIS?
These are the nine signs that come up most often when we assess an HIS. Today, interoperability and traceability carry the most weight in the decision.
Sign 1: the HIS does not interoperate through standards
The system does not speak HL7 FHIR, nor HL7 v2 or CDA reliably. Every integration is custom development that breaks when another system changes. The symptom is clear: someone retypes by hand what another system already had.
Sign 2: clinical information is not structured
The medical record is free text that cannot feed alerts or indicators. Internal codes cannot be mapped to SNOMED CT, ICD-10 or LOINC either. The data exists, but nobody outside the institution can understand it.
Sign 3: duplicate recording and parallel tools
Excel for bed management, whiteboards for theatre status and chat groups to coordinate transfers. When many tools appear, the HIS has stopped being the institution’s system of record.
Sign 4: every service works as an island
The emergency department, operating theatres, inpatient wards and outpatients use different systems. Without a master patient index, the same person appears two or three times, and putting their history together is manual work.
Sign 5: changing the system is expensive and slow
Every adjustment takes months and depends on a few people. When the institution opens a new site and the answer is “it has to be developed”, the new service runs outside the system.
Sign 6: the underlying technology is unsupported
The database, operating system or development platform no longer receives security patches. Exposure grows over time and there is no one to hold accountable.
Sign 7: the HIS does not scale or perform
With slowness at peak hours, clinicians record later, from memory or on paper. An outage in the emergency department forces a switch to paper contingency and later transcription, with a risk of gaps in the medical record.
Sign 8: there is no traceability
The HIS cannot show who viewed or modified a clinical record, nor prove it in an audit.
Sign 9: the HIS does not reach patients or support mobility
There is no patient portal, no self-service booking and no bedside recording. Scheduling turns into queues at the front desk and in the contact centre.
Not all signs are equally urgent, though. This is how we rank them by what they put at risk:
| Signs | Why | |
|---|---|---|
| Priority intervention | Unsupported technology, outages in critical services, regulatory requirements that cannot be met, missing traceability and dependence on one person. | They put the patient, continuity or regulatory compliance at risk. |
| Gradual resolution | Usability, reporting, patient self-service and non-critical integrations. | They affect efficiency and can be planned in stages. |
Should you fix, modernise or replace your hospital software?
The choice between fixing, modernising or replacing hospital software depends on where the problem lies. These are the three paths:
| Path | When it fits | What it involves |
|---|---|---|
| 1. Fix | A sound core: supported technology and an active vendor. | Catalogues, permissions, forms, reports and training. |
| 2. Modernise in layers | The core works, but interoperability, mobility, analytics or AI are missing. | A FHIR layer in front of the system and replacement of the weakest modules. |
| 3. Replace | Technology without updates, a vendor that dropped the product, or a limited data model. | Data migration and a single medical record. |
Modernising in layers lets the institution move forward with its digital transformation without betting everything on a single change. Historical data, master catalogues and the integrations that work well are kept. Replacement is justified when maintaining the system and its parallel tools costs more than replacing it over a 3 to 5-year horizon.
To compare alternatives, we propose this matrix. The weights are indicative and we adjust them with each institution.
| Criterion | Weight |
|---|---|
| Operational continuity and clinical risk | 25 % |
| Interoperability and standards | 20 % |
| Functional scope | 20 % |
| Total cost over 5 years | 15 % |
| Vendor support and evolution | 10 % |
| Security and compliance | 10 % |
The most common mistake we see is deciding on licence cost and leaving interoperability as a footnote. There are also hidden costs. Keeping the system means hours spent on manual tasks and integrations that break. Changing it means data migration and running two systems side by side.
What should you ask the vendor before deciding to modernise the HIS?
Before deciding to modernise the HIS, we recommend asking for evidence, not promises, and getting the answers in writing.
| Topic | Question |
|---|---|
| Support | How were the service level agreements met over the last year, by severity? |
| Technology roadmap | What is the roadmap for the next 24 months, and what was delivered from the previous one? |
| Integrations | Does it support HL7 FHIR, and with which resources and profiles? |
| Costs | How much does a typical change cost, and how long does it take? |
| Data migration | Can the data be exported in full, with attachments and audit trail, in an open format such as FHIR? |
| Operational continuity | What timeline, cost and assistance apply to the export when the contract ends? |
The question that best separates one vendor from another is asking them to show a working integration, rather than a presentation. If the vendor cannot show it, that is already an answer.
How can you assess the evolution of your HIS with K2BHealth?
An obsolete HIS is defined not by its age but by its ability to keep up with the institution. Before deciding, it is worth identifying the source of each limitation and comparing alternatives with operational continuity and interoperability as priorities. At K2BHealth we support that assessment in five steps:
- Survey of processes, systems and integrations.
- Root-cause analysis: process, configuration or system.
- Gap map for the next 3 to 5 years.
- Alternatives with their cost and risk matrix.
- A prioritised roadmap.
We work with a FHIR-first approach and no lock-in: if the best answer is to fix the current system, that is what we recommend. In our HIS, every signed clinical record is published in HL7 FHIR at the moment it is signed.
Book an initial assessment session and receive a short report with the signs detected, their priority and the next steps.
