Every 5-9 years health organisations replace their information system, beginning from zero every time.
The replacement is determined by the need to technologically update the systems
and / or to proceed with new tenders (in public health) since the assignment of maintenance and professional services to the current supplier cannot be extended beyond a certain number of years.
Like a film that repeats itself, each time the same, then we start from a tender document that, compared to the previous one, has few differences, mostly of a technological kind. At the same application domain, the information to be managed are identical, as well as the processes, the information flows, the peripherals to be used. For example, the data of a hospitalisation, as well as those of an emergency room or laboratory tests are always the same, they do not change over time, equally can be said of the processes and functions to be managed.
However, health information systems are closed and self-contained sets. Each of them has its own data model, its business logic and its own user interface. Even when they are designed with architectural patterns that foresee the separation between the various logical components, such as Model-View-Controller (MVC), this setting remains circumscribed within the systems and cannot be used to preserve components that do not need to be changed.
Take for example the data model. This, if well designed, could “live” much longer than the user interface, which on the contrary is more subject to the evolution of technology. Why then, every time a system is changed, is it necessary to change the data base and perform a data migration that is complicated, expensive and often leads to unsatisfactory results?
The same also applies to processes and functions. For example, acceptance of a hospitalization does not vary over time unless regulatory or organizational changes occur. Health systems, however, implement processes and functions directly in the application code (embedded). If I change the system, I need to make sure that the new software implements the functions and manages the processes in the correct way, starting from scratch, for the “joy” of users and technicians.
All this is, in hindsight, a waste of resources and time that absorbs a good part of the investment capacity of healthcare companies. But what can be done to avoid this situation and not start over again every time?
The answer lies in the global architecture of the information system and in the adoption of new paradigms, such as HL7 FHIR. If we break down the mosaic of the different components and we decline it in terms of resources, we can design a system in which the data model is a resource independent of the application system that uses this information.
Even the basic processes and functions can be isolated and managed with software platforms that allow the definition of rules and workflows, regardless of how the information to be treated will be represented and entered.
It is therefore necessary to overcome the traditional logic of module or application system as a self-contained and self-consistent object, in order to design an architecture based on services and micro-components.
Penelope disrupted the canvas at night because she did not want to complete the funeral sheet of her father-in-law Laerte, to give way to Ulysses to return to Ithaca. But concerning CIOs, which is the reason why they disconnect their information systems every 5-9 years?
Digital-health 