Proposal for a Standard Architecture for the Integration of Clinical Information Systems in a Complex Hospital Environment

Abstract

The evolution of technology in clinical environments increases the level of precision in patient care, as well as optimizes the management of healthcare centers. However, the need to have information systems that are more sophisticated and require interoperability between them means that a great deal of effort has to be made to assume the maintenance and scalability of the systems. Therefore, a proposal for a standard information model for the integration of clinical systems in a healthcare environment is presented. In order to elaborate the model, an analysis of the functional needs of the different clinical areas of a clinical environment is made based on the information systems that make up the system and application map. An evaluation of the technical requirements and the technological solutions that can satisfy these requirements is also carried out, delving into the different technical alternatives that allow the exchange of information. From the analysis carried out, an integration model capable of covering the needs that arise in clinical environments with a high level of complexity is obtained, also allowing the continuous evolution of the systems that make up the model, along with the incorporation of new systems. Although the model presented may fully cover the expectations raised, the rapid evolution in terms of both functional needs and technical aspects makes it necessary to continuously monitor and evaluate the model, in order to adapt it to the needs that arise.

1. Introduction

The implementation of the Electronic Medical Record [1] as a paradigm centralizes patient information in a main system, called HIS (Hospital Information System) [2]. However, it can happen that the HIS is divided into two different systems: a management area (the HIS itself) and a clinical care area (CIS, or Clinical Information System) [3].

Hospital operations will necessarily depend on many other information systems, where an essential aspect is the need for collaboration between systems. These systems are mostly applications, but electromedical devices are also included [4].

Considering the casuistry of the healthcare context, with the needs it raises (24 × 7 continuous operation, rapid evolution and change of systems, high volume of data and criticality of information), the interoperability between these systems is a difficult challenge to address in the day-to-day of a clinical care organization.

For this reason, this article proposes a model for the integration of clinical information systems, which constitutes a uniform solution for the exchange of information in an ecosystem of clinical applications.

It is proposed that an information system integration model may be developed to cover the need of information flows of each of the components, and to provide a basis for obtaining additional services and functionalities that cannot be produced by each of these systems alone.

The model must follow basic principles. Based on the selection of software development principles [5] and engineering requirements for the achievement of objectives in software development [6], the following main aspects are identified, which the proposed integration model must comply with:

• Efficiency. Response times in a clinical environment are often essential, therefore the generation of deadlocks and waits are unacceptable.
• Robustness. In order to guarantee the operability of critical systems, redundancy and a design that contemplates contingencies and optimization in the management of resources are required.
• Scalability. It is necessary to assume the possibility of growth, both in the systems involved and in the volume of information handled.
• Normalization and standardization. The use of open standards is key to guarantee present and future interoperability with other information systems.
• Reuse. The model does not intend to be a unique solution for a particular problem, but to constitute a generic reference.
• Functionality. In addition to complying with the above principles, it must be considered that the information systems to be integrated into the model cover real needs, and the orientation of the information systems must always be to cover those needs of the end users and the organization sponsoring these systems.

Several approaches to enterprise architectures in hospital environments have been analyzed, identifying various aspects to be considered in the architecture proposal presented.

Studies have been carried out for the implementation of architectures in specific geographical areas [7], where the main challenges identified are interoperability, technical infrastructure and alignment of business and IT strategy. Other studies regarding the adoption of architectures in countries with limited resources [8] recognize interoperability and flexibility as key advantages. Cost savings were also indicated as a benefit of these architectures.

The identification of conflicting points when implementing an enterprise architecture in a hospital environment [9] makes it easier to anticipate problems in the implementation of these architectures. They mainly highlight the gap between technical aspects and operational needs in clinical activity.

As a critical factor in hospital architectures, integration and interoperability are recognized as an essential aspect for complex systems where the use of heterogeneous data is critical [10]. For this purpose, the use of standards is proposed as a recommended solution to address the development of frameworks in the clinical environment.

2. Materials and Methods

2.1. Methodology

In order to carry out the integration model approach, the following steps were defined to cover the objectives proposed in point 2. The process flow is shown in Figure 1.

• Phase I: Analysis of functional requirements.
  A detailed analysis of the information system needs in a clinical environment was performed. To this end, the different clinical blocks were broken down into each disciplinary area and these were broken down into the main information systems they require. The different information flows that are communicated between the different systems are reviewed below.
• Phase II: Analysis of technical requirements.
  The identification of the technical requirements to be met by the proposed integration model was carried out in order to define a viable platform that can be implemented in a real environment.
• Phase III: Study of technical solutions.
  An assessment was made of the different information exchange mechanisms for executing the integration processes. Based on the analyzed mechanisms, the comparative review of the different implementations of each mechanism was deepened.
• Phase IV: Model design.
  An integration platform model that covers the functional and technical requirements defined was proposed, using the technical solutions analyzed in phase III.
• Phase V: Implementation proposal, maintenance approach.
  The implementation of the integration model was proposed, as well as the considerations for the operability and maintenance of the platform.
• Phase VI: Evolution of the model and future possibilities.
  Future improvements and evolutions of the platform were contemplated, considering the forecast of the evolution of the technology market in the health field, as well as estimates of future functional needs.

2.2. Functional Requirements

The system must cover the integrated needs of the different information systems that make up the map of systems and applications of the health center. For this reason, both the applications and the electromedical devices that share data with the rest of the systems must be considered.

We proceeded to narrow down the functional scope of the system. For this purpose, the organization of services, units and sections of the largest hospitals in the country was taken as a reference, considering the number of beds in each center as a criterion for size.

The clinical and management areas were compared, separating them according to the type of service provided. This resulted in the following blocks:

• Medical services;
• Central services;
• Surgical services;
• Obstetric, gynecological and pediatric services;
• Multidisciplinary units;
• Non-assistance services.

In turn, we recognized the different special care clinics and areas of management and support that make up a clinical center, which have their own information systems that can be integrated. Figure 2 shows the grouping of the different specialties into blocks.

It will be necessary to know in detail the use that professionals make of information systems, whether through interviews with them, questionnaires or a follow-up of their daily work.

It must be considered that in a real clinical environment, there will be a high degree of heterogeneity in the different information systems. Commercial solutions, opensource tools and custom developments will be combined; following not just different technologies but completely different paradigms: web applications, client/server models, proprietary databases, etc. In relation to the level of integration, several systems will be completely isolated and independent from the rest, and others will have integrations between them at two different points of view: from a functional perspective (sharing of all types of data, only demographic information, clinical test results, etc.) and technical perspective, using different mechanisms.

For the elaboration of an ideal objective model, we started from the inexistence of integrations, or the disappearance of the same ones to carry out a “tabula rasa” model.

Taking real ecosystems of applications implanted in large clinical centers as a reference, we could isolate a generic list of applications and information systems to work with, as shown in Figure 3, Figure 4, Figure 5 and Figure 6. Thus, the information systems used by each clinical area are presented, as well as those information systems of transversal use.

Within these applications, the following typology of information was recognized [11]:

○

Master data;

○

Patient administrative information;

○

Clinical data queries;

○

Alert management;

○

Management of patient movements;

○

Management of patient activity in the practice;

○

Activity management in operating theaters;

○

Surgical waiting list;

○

Clinical trials;

○

Medical orders and prescriptions;

○

Day hospital treatments.

The type of information was broken down into the information flows, as shown in Appendix A.

These flows represent the information that will be exchanged between the different systems. Depending on the functionality of each particular system, specific information flows relating to each system will be identified, for the exchange of information from that system with the others.

2.3. Technical Requirements

The following technical requirements were identified for the proposed integration model:

• Speed and management of response time. In a complex clinical environment, the information exchanged is time sensitive. For example information related to real-time care (in a consultation, in the emergency room or to care for a hospitalized patient) does not have the same priority as the retrieval of laboratory tests or the updating of appointment agendas. For this reason, a solution was sought that allows different levels of priority to be established in communication, and guarantees response times to be adjusted to functional needs for information that needs to be notified urgently. This way, urgent data, normal priority data and low priority data must be differentiated.
• Availability and stability. The power provided by information technologies has a major drawback associated with it: the dependence that they generate. The lack of operability of an integration system can block hospital operations. In order to avoid it, contingency plans are prepared for disasters, but the first measure is to minimize the possibility of failure and denial of service. Therefore, the solution must allow the use of a replicated model, which reduces as much as possible the possibility of general failure of the system, and paralyzes the exchange of information.
• Storage. Final information, consisting of clinical and management data, reports, test results, etc., should be stored in the HIS and departmental applications. However, the information processed in a certain time window, usually several days, must be stored persistently. The purpose of this is to ensure that this information can be retrieved in case of the failure of any of the other information systems, and to be able to follow up if a failure or error has occurred. Although a few days of persistence may suggest that the volume of storage required will not be high, the large amount of information flow that includes multimedia information from diagnostic tests requires the provision of a large volume of storage space. This high volume of information, along with the needs of information exploitation and security measures to be taken (traceability, redundancy, backups) make it necessary to have a stable storage system that allows the handling of information, therefore a database management system was used for this purpose.
• Integrity and consistency. The information communicated in an integration process must be consistent at all points in it, whether in the source system, the integration platform or the target systems. This information does not only cover the data to be sent, but also the transaction metadata.
• Performance. The volume of data to be processed is very high, and some of them with critical priority. In addition, processing will be continuous but uneven: in a complex clinical center, activity is uninterrupted 24 h a day, every day of the year. In certain periods of time and on certain days the workload will be greater than others. Therefore, it is necessary to guarantee that the processing will be efficient enough so as not to generate a queuing that blocks the operation of the systems.
• Traceability. The architecture is required to allow detailed tracking of any transaction, and to know all steps that have been carried out from the system of origin to the destination systems. This information must be very detailed, including the timestamps of each transaction.
• Abstraction. The integration platform must be separated from the logic of the rest of the clinical applications, allowing to add, remove or replace applications with minimal adjustments, without dependence on the internal logic of each system.
• Management and administration. As far as possible, ease of maintenance and parameterization is sought. Maintaining a model that is as simple and consistent as possible reduces the risk of errors and failures, and therefore indirect costs.
• Cost. The total cost of ownership is considered to be a relevant factor, which should be kept as low as possible, provided all other requirements are met. The total cost of ownership includes the cost of hardware devices, software licenses, the cost of personnel for implementation and maintenance and the cost of risk management.
• Scalability. The possibility of extending the integration architecture to cover future needs, either by incorporating new systems, contemplating the management of new information flows or increasing the volume of data to be processed.
• Security and control of users. The model will be performing a critical function in the hospital, and using very sensitive information. It is necessary to comply with the legal requirements of security and data protection, so the possibility of controlling failures, redundancy and contingency plans must be considered, as well as a solid system for controlling access to information.
• Power and flexibility. In a real environment, in order to adapt to changes, it must be possible to make adjustments at each of the points (information source systems, information flows, information destination systems). The system must have a sufficient level of adaptability to be able to integrate with any modern information system that meets any communications standard, even if the complexity of the integration increases. This is not the ideal scenario, but the need to cover functional requirements may require some partial compromise of the technical requirements.

2.4. Technical Solutions

Technical solutions should constitute a platform as a mechanism for the exchange of information. This exchange of information can come in multiple formats, an important factor being that the exchange of clinical data is carried out following standards [12]. Among the standards for the interoperability of clinical systems, HL7 [13] stands out as the main reference, grouping standards that cover the needs of information exchange [14]. Additional standards relevant to clinical information, although more specific, are DICOM images [15] or encodings, such as SNOMED-CT [16], International Classification of Diseases (ICD) [17] and Logical Observation Identifiers Names and Codes (LOINC) [18]. Generic standard formats such as XML, JSON, plain text or PDF are also considered. The most frequent situation is the use of Health Level Seven (HL7) in general, and the inclusion of other embedded information standards [19].

An assessment of the following technical solutions was carried out as exchange mechanisms to carry out the integration processes:

• Database sharing. In this mechanism, the system that wants to share information (master system) allows access in query mode to part of its data repository system that should receive the information (slave system).
  This solution has many drawbacks, two of which stand out: On the one hand, it generates a very high dependence on the operation of the master system: in the event of changes in the data model, the integration is affected. On the other hand, the performance of the master system may be compromised by the access of the slave system, especially in the case where both systems must access the information of the other, where the problems would multiply. There is no homogeneous interface for access to information by several systems, preventing the solution from being scalable. There is also the problem of the difficulty in actively requesting information from the slave system, making it necessary to have processes in the master system that prepare, adapt or process information.
• Exchange files. The master system generates certain files with exchange information, which can be queried by several slave systems. This mechanism has several similarities with the previous one. Although it avoids the impact on the performance of the master system, the problems raised remain: no standardized form of communication is offered, so each client would be forced to make a custom adaptation for a non-homogeneous solution. There is no simple way for the slave system to make requests for information, necessitating tailor-made processes in the master system that conduct surveys in the client system to prepare the information it requires.
• Web Services. The service-oriented model (SOA) using web services as an interchange mechanism, unlike the previous mechanisms, offers a complete separation of the business layer of the master application from the integration layer. It allows a scalable and homogeneous solution for slave systems to query master systems, and for the role of the master or slave system to be combined according to the business needs of each application. This solution model is already feasible and applicable, however it has several drawbacks when used on a large scale. In scenarios such as information systems in large clinical environments, with hundreds of systems sharing information between them, the main stumbling block to overcome is a lack of control. Multiple queries are performed redundantly, generating inefficiencies, and the need arises to control priority in the exchange of information between systems (some require faster response times than others), and changes in production systems and the implementation of new ones make it necessary to modify the operation of integrations, being necessary in this case to modify the logic of each system individually, with the cost, delay and risk that this entails.
• Messaging. Alternatively, there is the possibility of using an Enterprise Serial Bus (ESB) model, a control system that allows for communication between systems and transactions between them. In the health field, there are implementations of ESBs focused on the problems of health systems, called integration engines. The use of integration engines as a mechanism for exchanging information offers the advantages of the web services model presented above, with the addition that they offer a higher level of abstraction, providing a single point of control of the integrations. In this way, through the use of the engine, each integration can be parameterized, defining multiple sources and destinations of information between the integrated systems, making changes in them when necessary, and prioritizing and defining different policies for each integration in each situation (message saturation, errors in the master system, errors in the slave system, processing failures). It also offers the possibility of adding logic to specific integrations in a transparent way for the integrated systems.

To analyze the different options, we classified them, assigning a relevance level according to the technical parameters specified in point 5 (1 minimum–5 maximum), based on their importance (1 minimum–3 maximum). Figure 7 shows the resulting table.

Considering the four options, the most complete, powerful and capable of meeting the technical requirements set out in point 5 is clearly messaging through integration engines. If a second communication channel is required, the use of web services would be used as an alternative communication mechanism, either due to the technical impossibility of integration via messaging with a departmental system, or as a backup measure in the event of failure of the messaging system.

Since messaging through integration engines is clearly the solution best suited to the needs of a clinical environment, and which is strongly oriented to the exchange of information using the HL7 standard, the different technical alternatives available on the market were analyzed and evaluated. Figure 8 shows the main alternatives, as well as the supplier.

In any case, the approach of using an abstraction layer for the interoperability of the systems allows the substitution of this platform by another one, in case the requirements and priorities defined by the organization are modified, or if the changes in the state of the art of technology so advise it.

3. Results

3.1. Target Architecture Proposal

The model was designed considering the following key elements defined in the previous points:

• Information systems, formed by the HIS/CIS, and by the departmental applications corresponding to the different units and clinical services.
• The information flows corresponding to the data to be shared between systems.
• The integration engine, which will house all the logic and control of the system.
  The physical architecture shall consist of the following elements:
• Servers, where the different system applications are hosted (HIS/CIS, departmental applications, integration engine, web services). Data, which are the criticality of the system; the servers will be redundant and in high availability, monitored and with defined backup policies, although the detail of the system model of each application exceeds the scope of this article.
• Communications that guarantee sufficient quality of service for the different applications to provide the service for which they are implemented, and also cover the operational requirements of information exchange of the integration system. As indicated in the previous point, messaging is chosen as the most efficient exchange mechanism.

Each application must adapt its interfaces of information inputs and outputs to receive and send messaging with the data of the operations received, in addition to maintaining their previous interfaces. In addition, it must manage the messaging to be exchanged, controlling the saturation that can generate bottlenecks and glues, and drops in the application itself, which could impact the entire integration system. Finally, you will have to configure your messaging channel to point to the integration engine (IP address and port).

The most delicate point is the parameterization of the integration engine. It involves making the following settings:

• Security management: control of engine users, roles and permissions.
• Configuration of the connection points of each of the departments (IP address and port).
• Creation of input and output channels for each of the applications that will communicate with the engine.
• Configuration of each channel: type of information received, method and time of polling new messages, analysis of messages, recovery of specific data, transformation of the message if appropriate, forwarding to other channels or systems, traceability of messages, level of persistence of messages. This is the most delicate process and requires the most testing.
• Configuration of communication security measures. In certain situations (excessive glued messaging, for example) measures can be taken. These can be internal engine management, such as stopping a channel to avoid excessive consumption of resources, or notifying an administrator.

Within the engine, it is possible to receive and send data exchange with web services enabled as a form of secondary exchange, for those applications that require it. Figure 9 shows the proposed architecture scheme.

3.2. Implementation and Deployment

To address the implementation of such a complex system in a productive environment, the main aspect to consider is business continuity [20], that is, how to minimize the impact of change on the functioning of the organization.

To this end, the following measures are taken to help reduce risks [21] and the impact on the operation of the clinical center:

• Exhaustive pre-tests for all integrations in certification environments, covering the following typology: unit tests, integration tests, functional validation tests, performance tests.
• Preparation of a contingency plan to cover the operation of the clinical center in the event of partial or total failures, either by designing non-IT circuits, using alternative tools in the event of failure of the defined applications or working with the defined applications but in isolation, not integrated with the entire system.
• Involvement of the management of the clinical center, and preparation and dissemination of a communication plan describing the start-up process.
• Execution of previous simulations of the process, including the possibility of reversing in case of critical failure.
• Planning and management of the post-implantation support necessary to cover the incidents and problems once the start-up has been carried out.

The main decision to be made is the mode of deployment. The two main options are either phased, also known as gradual, or Big Bang [22].

In a phased implementation, the different integrations would be divided into subsets, and the coexistence between the existing system model and the new model would be planned, activating each of the subsets of the integrations on different dates.

In a Big Bang implementation, there would be a single process of replacement of the previous system to the new one, where there would be no coexistence of the two systems.

The decision between the two alternatives is not trivial, and strongly depends on the organization of the center, the means at its disposal, the level of technological evolution in which it is found (at a higher technological level, the dependence of the computer systems for clinical practice will also be greater) and the margin of time available to make the change.

In either of the two alternatives, a guide will be prepared that constitutes the roadmap for the process, with the different actions to be carried out to start up the system: preparation of the hardware and communications, configuration of the integration engine and the applications, stops and starts of the information system and validations. This guide must specify the schedule of the different actions to be carried out, the agents that must carry it out and the assessment points where the activation and deactivation of the contingency plan are proposed as well as the possibility of reversing in case of critical failure.

It is important to emphasize the criticality of the activity [23] that is carried out in the type of organization where the integration model will be implemented. The provision of critical clinical services, such as inpatient care, urgent surgical interventions or the operation of the emergency care service makes it necessary to anticipate possible failures, and thus establish preventive measures that reduce as much as possible the care activity of clinicians.

4. Discussion

The proposed system constitutes a model capable of covering the needs of the integration of information systems in highly complex clinical environments, offering the possibility of a detailed level of control in real time, and allowing maintenance in the form of changes in existing integrations and a new, relatively simple incorporation.

The methodological approach allows us to propose an architecture that meets the identified needs, and offer continuous monitoring and improvement in order to adapt to future changes and needs.

The effort into technology only makes sense if it provides value to cover functional needs. Therefore, it is essential to take hospital operations and the information flows managed into account [24].

Although the functional needs have been analyzed in detail, and the approach is a generalist architecture, a certain level of adaptation and customization will be necessary for specific implementations, according to the needs of the specific clinical center.

The technical core of the model is the use of an integration engine and the HL7 standard as an exchange protocol. It is the most efficient and extensible mechanism for integrating clinical systems of medium or high complexity, and is a powerful solution for data maintenance and exploitation.

The complexity of setting up an architectural model that constitutes a complete integration solution makes it advisable to design, implement and start up a previous pilot that corroborates the validity of the proposed model and its viability in the organization that is carrying it out.

From an operational point of view, the practical applications of the architecture are broad. These include complex analysis and operational systems where the use of heterogeneous data is critical for decision support systems (DSSs) in clinical environments [25].

Although doubts have been raised about the effectiveness of information and communication technologies (ICT) in DSS due to the multiple factors involved beyond technology [26], the usefulness of these systems has been demonstrated. Specifically, it is estimated that DSSs improve the average percentage of patients receiving the desired care by 5.8% [27].

The architecture covers the needs of today’s complex clinical environment after having analyzed the current functional requirements. However, the periodic observation of technological evolutions will be necessary for future adaptations of the architecture, according to the improvement of the state of the art different referenced technologies, especially integration systems.

In particular, there is the possibility of technically improving the management of information exchange through the use of Big Data technology [28,29] and Machine Learning algorithms [30], which allow dynamic adjustments to be made according to the messaging exchanged in the specific center in which the implementation has been carried out. This type of evolution may improve the efficiency and power of the proposed model.